Diferència entre revisions de la pàgina «M2 - Bases de dades / UF1NF1: Els SGBD»

Revisió del 18:50, 28 set 2014 (mostra codi font) Rsort (Discussió | contribucions) (→‎Permetre la concurrència d’usuaris) ← Vés a l'edició anterior		Revisió del 18:54, 28 set 2014 (mostra codi font) Rsort (Discussió | contribucions) (→‎Contribuir a la seguretat de les dades) Vés a l'edició següent →
Línia 246:		Línia 246:
	====Contribuir a la seguretat de les dades====		====Contribuir a la seguretat de les dades====
		+
		+	L’expressió '''seguretat de les dades''' fa referència a la seva confidencialitat. Sovint, l’accés a les dades no ha de ser lliure o, com a mínim, no ho ha de ser totalment.
		+	Els '''SGBD''' han de permetre definir autoritzacions d’accés a les BD, tot establint permisos diferents en funció de les característiques de l’usuari o del grup d’usuaris.
		+
		+	Actualment, els SGBD permeten definir autoritzacions a diferents nivells:
		+
		+	::*Nivell global de tota la BD
		+
		+	::*Nivell d’entitat
		+
		+	::*Nivell d’atribut
		+
		+	::*Nivell de tipus d’operació
		+
		+	::'''Exemples de drets d’accés'''
		+
		+	::Els usuaris del departament de comptabilitat potser no haurien de tenir accés a l’entitat que emmagatzema les dades personals dels empleats de l’empresa, a diferència de l’usuari que ostenta el càrrec de director general, que les podrà consultar per tal d’optimitzar la ubicació dels treballadors el l’organigrama en funció del respectiu perfil, o també dels usuaris del departament de recursos humans, que haurien de poder fins i tot modificar-les.
		+
		+	::En general, els usuaris no haurien de tenir accés als atributs que emmagatzemen l’adreça particular dels empleats, a no ser que es tracti del personal de recepció, si resulta que és l’encarregat d’enviar-los certa correspondència a domicili (com ara les nòmines o els certificats de retencions d’IRPF), i per tant hauria, si més no, de poder consultar-los.
		+
		+	Aquests mecanismes de seguretat requereixen que cada usuari es pugui identificar. El més freqüent és utilitzar un nom d’usuari i una contrasenya associada per a cada usuari. Però també hi ha qui fa servir mecanismes addicionals, com ara targetes magnètiques o de reconeixement de la veu. Actualment, s’investiga en altres direccions com, per exemple, en la identificació personal mitjançant el reconeixement de les empremtes dactilars.
		+
		+	Un altre aspecte a tenir en compte en parlar de la seguretat de les dades és la seva encriptació. Molts SGBD ofereixen aquesta possibilitat, en alguna mesura.
		+
		+	Les '''tècniques d’encriptació''' permeten emmagatzemar la informació utilitzant codis secrets que no permeten accedir a les dades a persones no autoritzades i que, per tant, no disposen dels codis esmentats.
		+
		+	L’encriptació pot fer disminuir el rendiment en l’accés a les dades, ja que comporta la utilització d’algoritmes addicionals en les operacions de consulta. Per això se n’ha de dosificar l’ús. Ara bé, sempre que sigui possible, és convenient encriptar les contrasenyes.
	==Llenguatges de SGBD==		==Llenguatges de SGBD==

---

Revisió del 18:54, 28 set 2014

Els SGBD són un tipus de programari que té com a finalitats la gestió i el control de les BD.

Evolució dels SGBD

l’evolució dels SGBD ha estat, sovint, intrínsecament lligada a l’evolució del maquinari.

La figura següent mostra un esquema de les etapes evolutives per les quals han passat els SGBD, en el qual se n’indiquen les principals característiques.

Anys cinquanta: processament seqüencial

Inicialment, l’únic maquinari disponible per emmagatzemar la informació consistia en paquets de cintes perforades i en cintes magnètiques. Aquests dispositius només es podien llegir de manera seqüencial i, per tant, el programari de l’època estava limitat per aquesta circumstància. Com que la grandària de les dades a processar era molt superior a la de la memòria principal de les computadores, els programes només podien realitzar processos per lots, de la manera següent:

• Obtenint les dades en un ordre determinat (des d’una o més cintes).
• Fent algun càlcul sobre les dades.
• Escrivint el resultat (en una nova cinta).

Exemple de processament seqüencial

Imaginem que una empresa necessita actualitzar els preus dels productes que ofereix: en primer lloc, caldria gravar els increments dels preus en targetes perforades.

A continuació, s’aniria llegint el paquet de les cintes perforades anteriors, sincronitzadament amb la cinta mestra que contingués totes les dades relatives als productes. Les targetes perforades haurien de respectar l’ordre dels registres del fitxer de productes contingut en la cinta.

Amb totes les dades relatives als productes contingudes en la cinta mestra, més els preus actualitzats en funció dels nous valors reflectits en les targetes perforades, es gravaria una nova cinta, que passaria a ser la nova cinta mestra dels productes de l’empresa.

Anys seixanta i setanta: sistemes centralitzats

Durant la major part de les dues dècades dels anys seixanta i setanta, els SGBD van tenir una estructura centralitzada, com corresponia als sistemes informàtics d’aleshores: un gran ordinador per a cada organització que se’l pogués costejar, i una xarxa de terminals no intel·ligents, sense capacitat pròpia per processar dades.

Inicialment, només es feien servir per gestionar processos per lots amb grans volums de dades. Posteriorment, amb l’aparició dels terminals, de vegades connectats mitjançant la línia telefònica, es van anar elaborant aplicacions transaccionals, per exemple per reservar i comprar bitllets en línies de transports, o per realitzar operacions financeres.

Els programes encara estaven molt lligats al nivell físic, i s’havien de modificar sempre que es feien canvis en el disseny de la BD, ja que aquests canvis implicaven, al seu torn, modificacions en l’estructura física de la BD. El personal que realitzava aquestes tasques havia d’estar altament qualificat.

Anys vuitanta: SGBD relacionals

Tot i que des del principi dels anys setanta ja s’havia definit el model relacional, i l’accés no procedimental a les dades organitzades seguint aquest model, no va ser fins als anys vuitanta quan van anar apareixent SGBD relacionals en el mercat.

La raó d’aquesta demora en l’ús dels sistemes relacionals va ser el pobre rendiment que oferien inicialment els productes relacionals en comparació amb les BD jeràrquiques i en xarxa. Però la innovació en el maquinari, primer amb els miniordinadors i posteriorment amb els microordinadors, va comportar un cert abaratiment de la informàtica i la seva extensió a moltes més organitzacions.

Fins aleshores, la feina dels programadors que treballaven amb BD prerelacionals havia estat massa feixuga, ja que, d’una banda, havien de codificar les seves consultes de manera procedimental, i d’una altra, havien d’estar pendents del seu rendiment i fer consideracions d’índole física a l’hora de codificar-les.

Però a causa de l’expansió de la informàtica que va tenir lloc durant la dècada que comentem, calia simplificar el desenvolupament de les aplicacions. Els SGBD ho van aconseguir, tot independitzant els programes dels aspectes físics de les dades.

A més, l’aparició del llenguatge de consulta estructurat (structured query language, o SQL, en anglès) i, sobretot, la seva estandardització a partir de l’any 1986 van facilitar enormement l’ús dels sistemes relacionals i, per tant, la seva implantació massiva.

Finalment, les BD relacionals van poder competir, fins i tot, en matèria de rendiment amb les jeràrquiques i amb les estructurades en xarxa, amb la qual cosa van acabar reemplaçant les seves competidores en la majoria dels casos.

Anys noranta: BD distribuïdes, arquitectures client/servidor, i llenguatges de quarta generació

Com ja sabem, els primers sistemes de BD eren centralitzats: totes les dades del sistema estaven emmagatzemades en un únic gran ordinador al qual es podia accedir des de diferents terminals. Però l’èxit gradual dels ordinadors personals (personal computers, o PC, en anglès), cada vegada més potents i amb preus més competitius, juntament amb el desenvolupament de les xarxes, va possibilitar la distribució d’una mateixa BD en diferents ordinadors (o nodes).

En funció del nombre de SGBD utilitzats, els sistemes distribuïts poden ser de dos tipus:

• Homogenis, si tots els nodes utilitzen el mateix SGBD. Les interaccions entre els diferents nodes són més senzilles. Però les actualitzacions del sistema gestor implicaran necessàriament a tots els nodes.

• Heterogenis, si cada node utilitza un SGBD diferent. Les interaccions entre els diferents nodes poden ser més complicades. Però hi haurà més flexibilitat a l’hora d’actualitzar el sistema gestor de cada node.

Els punts a favor dels sistemes distribuïts són fonamentalment dos:

• Rendiment. Si el sistema està ben dissenyat, la majoria de les operacions es realitzaran amb dades emmagatzemades localment. D’aquesta manera les respostes seran més ràpides, disminuirà la despesa en comunicacions, i s’evitarà la dependència d’un node central col·lapsat.

• Disponibilitat. Els sistemes distribuïts són més resistents a les aturades que no pas els centralitzats. En un sistema centralitzat, l’aturada del node central atura tot el sistema. En canvi, en un sistema distribuït, si un dels nodes queda temporalment fora de servei per qualsevol eventualitat, la resta continuarà funcionant normalment, i podrà donar servei sempre que no es necessitin les dades emmagatzemades en el node aturat. Però, a més, segons quin esquema de disseny s’hagi seguit en fer la distribució, si les dades del node aturat estan duplicades en un altre, continuaran estant disponibles.

Però, evidentment, no tot són avantatges. Per exemple, en el cas dels sistemes heterogenis, sovint és necessari realitzar conversions de dades per permetre la comunicació dels diferent nodes entre ells. A més, en general, la comunicació és més complexa i, per tant, la quantitat d’errors i de problemes derivats d’aquest fet que s’han de controlar és molt més gran que en un sistema centralitzat.

La tecnologia utilitzada habitualment en la distribució de BD és l’arquitectura client/servidor (coneguda també com a arquitectura C/S). Actualment, tots els SGBD comercials estan adaptats a aquesta realitat.

El funcionament dels sistemes basats en aquest tipus d’arquitectura és, esquemàticament, el següent: dos processos s’executen en un mateix sistema o en dos de diferents, de tal manera que un fa de client (o peticionari d’un servei), i l’altre de servidor (o proveïdor del servei demanat).

La classificació dels processos en les categories de client i de servidor és de tipus lògic (i no físic) i, per tant, cal tenir en compte alguns aspectes que deriven d’aquesta circumstància, com ara els següents:

• Un client pot demanar serveis a diversos servidors.

• Un servidor pot rebre peticions de molts clients.

• El client i el servidor poden residir en un mateix sistema.

Finalment, durant els anys noranta, la implantació arreu de les BD, fins i tot en petits sistemes personals, va motivar l’aparició dels anomenats llenguatges de quarta generació (fourth generation languages, o 4GL, en anglès), els quals es continuen utilitzant en l’actualitat.

Es tracta de llenguatges molt senzills, però al mateix temps molt potents, especialitzats en el desenvolupament d’aplicacions centrades en l’accés a BD. Ofereixen moltes facilitats per definir, generalment de manera visual, finestres des de les quals es poden consultar, introduir, modificar o esborrar dades, fins i tot en entorns client/servidor.

Tendències actuals: orientació a objectes, Internet, i elements multimèdia

Actualment, els SGBD relacionals acaparen el mercat. Han evolucionat de tal manera que ja no tenen competidors en rendiment, fiabilitat o seguretat. D’altra banda, ja no necessiten habitualment tasques de manteniment planificades que en comportin l’aturada periòdica. Per tant, la disponibilitat que ofereixen és molt elevada, ja que s’acosta a les vint-i-quatre hores de tots els dies de l’any.

Però, al mateix temps, tots estan immersos en un complex procés de transformació per tal d’adaptar-se a les innovacions tecnològiques de més èxit:

1. Les tecnologies multimèdia. Els tipus de dades que tradicionalment admetien els SGBD ara es veuen incrementats per altres de nous que permeten emmagatzemar imatges i sons.

Exemple d’incorporació de tecnologies multimèdia en un SGBD

D’aquesta manera, per exemple, la taula que emmagatzemi les dades personals dels empleats d’una empresa determinada podrà contenir la foto de cadascun, la qual cosa pot resultar especialment interessant si l’organització disposa d’un entorn virtual de treball (de tipus intranet, per exemple) en què els correus electrònics incorporin la foto del remitent, a fi de permetre la identificació visual.

2. L’orientació a objectes. Aquest paradigma de la programació ha acabat influint en l’orientació de molts SGBD, que segueixen alguna de les dues línies esbossades a continuació:

• SGBD relacionals amb objectes, els quals admeten tipus abstractes de dades(TAD), a més dels tipus tradicionals.

• SGBD orientats a objectes, que estructuren les dades en classes, les quals comprenen tant les dades (atributs) com les operacions sobre elles (mètodes). Les classes s’estructuren jeràrquicament, de tal manera que les de nivells inferiors (subclasses) hereten les propietats de les de nivells superiors (superclasses).

3. Internet. Avui en dia, la majoria de SGBD professionals incorporen els recursos necessaris per donar suport als servidors de pàgines web dinàmiques (és a dir, amb accés a les dades contingudes en un SGBD allotjat en el servidor web corresponent).

Una altra línia d’innovació que segueixen alguns SGBD és el treball amb els anomenats magatzems de dades (data warehouse, en anglès). Aquests magatzems consisteixen en rèpliques elaborades de les dades generades pel funcionament quotidià de l’organització o l’empresa de què es tracti, durant un cert període de temps per tal de realitzar anàlisis estratègiques d’índole financera, de mercats, etc.

El llenguatge de marques extensible (extensible markup language, o XML, en anglès) també influeix en el món dels SGBD, tot i que inicialment no es va concebre com una tecnologia per donar servei a les BD, sinó per estructurar documents molt grans. Però aquesta capacitat per emmagatzemar les dades de què es compon un document el fan susceptible de ser utilitzat, també, en l’àmbit de les BD.

Hi ha dues maneres d’incorporar la tecnologia XML en els SGBD:

• Els SGBD relacionals amb suport per a XML, que en el fons continuen essent relacionals i que, per tant, emmagatzemen tota la informació de manera tabular. La seva utilitat principal és que les dades que retornen les consultes sobre la BD poden estar expressades en format XML, si així es demana al sistema gestor.

• Els sistemes gestors per a BD natives XML, que no són en realitat relacionals, sinó més aviat jeràrquics, i que no solament estan en condicions d’oferir els resultats de les consultes en format XML, sinó que també emmagatzemen la informació en documents XML. El llenguatge estàndard de consultes per a aquest tipus de SGBD s’anomena XQuery.

La utilització de dades estructurades mitjançant l’estàndard XML resulta especialment interessant en l’intercanvi d’informació entre sistemes basats en plataformes poc compatibles entre elles.

Objectius i funcionalitats dels SGBD

Tots els SGBD del mercat volen assolir una sèrie d’objectius i oferir una sèrie de funcionalitats, amb més o menys encert, que actualment es consideren indispensables per al bon funcionament de qualsevol sistema d’informació:

• Possibilitar les consultes no predefinides de qualsevol complexitat.

• Garantir la independència física i la independència lògica de les dades.

• Evitar o solucionar els problemes derivats de la redundància.

• Protegir la integritat de les dades.

• Permetre la concurrència d’usuaris.

• Contribuir a la seguretat de les dades.

Possibilitar les consultes no predefinides de qualsevol complexitat

Els usuaris autoritzats d’un SGBD han de poder plantejar directament al sistema qualsevol consulta sobre les dades emmagatzemades, de la complexitat que sigui necessària, tot respectant, això sí, les regles sintàctiques perquè la sentència sigui correcta.

A continuació, el SGBD ha de ser capaç de respondre ell mateix a la consulta formulada, sense que sigui necessari recórrer a cap aplicació externa.

Quan no existien ni les BD ni els sistemes gestors, per tal d’obtenir un subconjunt de les dades emmagatzemades en un fitxer, hi havia dues possibilitats:

• Llançar un llistat seqüencial de totes les dades i, a continuació, seleccionar manualment les que interessessin.

• Escriure el codi font d’un programa específic per resoldre la consulta en qüestió, compilar-lo i executar-lo.

Els SGBD actuals, en canvi, estan perfectament capacitats per interpretar directament les consultes, expressades habitualment com a sentències formulades en el llenguatge de consulta SQL.

Evidentment, això no vol dir que no es puguin continuar produint programes que incorporin consultes mitjançant les quals accedeixen a BD. De fet, aquesta és l’opció més encertada i còmoda si es tracta de consultes que s’han de repetir al llarg del temps.

Garantir la independència física i la independència lògica de les dades

Cal garantir la màxima independència física de les dades respecte als processos usuaris, en general (és a dir, tant pel que fa a les consultes interpretades pel SGBD com als programes externs que accedeixen a la BD), de tal manera que es puguin dur a terme tot tipus de canvis tecnològics d’índole física per millorar el rendiment (com ara afegir o treure un índex determinat), sense que això impliqui haver de modificar ni les consultes a la BD ni les aplicacions que hi accedeixen.

De manera similar, també és desitjable la independència lògica de les dades, la qual implica que les modificacions en la descripció lògica de la BD (per exemple, afegir un nou atribut o suprimir-ne un altre) no han d’impedir l’execució normal dels processos usuaris no afectats per aquelles.

I, pel que fa a la independència lògica de les dades, fins i tot pot interessar (i, de fet, aquesta és una opció freqüent) que convisquin diferents visions lògiques d’una mateixa BD, en funció de les característiques concretes dels diferents usuaris o grups d’usuaris.

Evitar o solucionar els problemes derivats de la redundància

Tradicionalment, la repetició de les dades s’ha considerat una cosa negativa, ja que comporta un cost d’emmagatzematge innecessari. Avui en dia, però, aquesta característica, tot i ser certa, gairebé no es té en compte, a causa de l’abaratiment dels discos durs i de l’augment de la seva capacitat i rendiment.

Però hi ha un altre aspecte a considerar que no ha perdut vigència, i és el fet que la repetició de les dades és perillosa, ja que quan s’actualitzen poden perdre la integritat. Quan es modifica el valor d’una dada que està repetida, s’han de modificar simultàniament els valors de les seves repeticions perquè es mantingui la coherència entre totes.

La redundància consisteix en la repetició indesitjada de les dades, que incrementa els riscos de pèrdua d’integritat d’aquestes quan s’actualitzen.

Malgrat tot, els SGBD han de permetre al dissenyador de BD la definició de dades repetides, ja que de vegades (sobretot en matèria de fiabilitat, de disponibilitat o de costos de comunicació) és útil mantenir certes rèpliques de les dades.

Ara bé, en tots aquests casos, l’objectiu de l’SGBD ha de ser garantir l’actualització correcta de totes les dades allà on estiguin duplicades, de manera automàtica (és a dir, sense que l’usuari del SGBD s’hagi d’encarregar de res).

Un altre tipus de duplicitat admissible és la que constitueixen les anomenades dades derivades. Es tracta de dades emmagatzemades en la BD, que en realitat són el resultat de càlculs fets amb altres dades també presents en la mateixa BD.

Les dades derivades també poden ser acceptables, tot i que comporten una repetició evident d’algunes dades, si permeten fer consultes de caire global molt ràpidament, sense haver d’accedir a tots els registres implicats.

Però també aquí, el SGBD s’ha d’encarregar d’actualitzar degudament les dades derivades en funció dels canvis soferts per les dades primitives de les quals depenen.

Protegir la integritat de les dades

A més de la redundància, hi ha molts altres motius que poden fer malbé la consistència de les dades, com ara els següents:

• Els errors humans.

• Les deficiències en la implementació dels algoritmes de les aplicacions.

• Les avaries dels suports físics d’emmagatzematge.

• Les transaccions incompletes com a conseqüència de les interrupcions del subministrament elèctric.

Els SGBD han de protegir la integritat de les dades en tots aquests casos. Per a això disposen, d’una banda, de les regles d’integritat, també anomenades restriccions, i d’una altra, dels sistemes de restauració basats en còpies de seguretat.

Mitjançant les regles d’integritat, el sistema valida automàticament certes condicions en produir-se una actualització de dades, i l’autoritza si les compleix, o denega el permís en cas contrari.

Exemple de restricció del model

Un SGBD relacional mai no acceptarà que una taula emmagatzemi registres amb una clau primària idèntica, perquè aleshores la clau no serviria per identificar inequívocament els registres entre ells.

Les regles d’integritat poden ser de dos tipus:

• Restriccions del model. Són regles inherents al model de dades que utilitza el SGBD (com ara el model relacional). El sistema les incorpora predefinides, i sempre s’acompleixen.

• Restriccions de l’usuari. Són regles definides pels usuaris (dissenyadors i administradors, fonamentalment) de la BD, que no incorpora a priori el SGBD, i que serveixen per modelitzar aspectes específics del món real.

Exemple de restricció de l’usuari

En una taula que emmagatzema els alumnes d’un centre docent, es vol evitar que hi hagin alumnes matriculats en cicles formatius de grau superior que fossin menors d’edat, ja que la normativa vigent no ho admet. Aleshores, cal establir una restricció en aquest sentit per calcular si la diferència entre la data del sistema en el moment de la matrícula i la data de naixement de cada alumne és igual o superior als 18 anys. En aquest cas, el sistema permetria la matrícula, i en cas contrari la prohibiria.

Els SGBD també proporcionen eines per realitzar periòdicament còpies de seguretat de les dades (o backups, en anglès) que permeten restaurar les dades malmeses i retornar-les a un estat consistent.

Ara bé, els valors restaurats es correspondran amb els que hi havia en el moment de realitzar la còpia de seguretat, abans de l’incident que origina la restauració, i per tant mai no estaran del tot actualitzats, encara que siguin correctes.

Permetre la concurrència d’usuaris

Un objectiu fonamental de tot SGBD és possibilitar de manera eficient l’accés simultani a la BD per part de molts usuaris. A més, aquesta necessitat ja no està circumscrita només a grans companyies o a administracions públiques amb molts usuaris, sinó que cada cop és més freqüent, a causa de l’expansió d’Internet i l’èxit de les pàgines dinàmiques, allotjades en servidors web que han d’incorporar un SGBD.

Hem de considerar dues tipologies d’accessos concurrents, amb problemàtiques ben diferenciades:

• Accessos de consulta de dades. Poden provocar problemes de rendiment, derivats sobretot de les limitacions dels suports físics disponibles (per exemple, si la lentitud de gir del disc dur que conté la BD, o del moviment del braç que porta incorporat el capçal, no permeten atendre degudament totes les peticions d’accés que rep el sistema).

• Accessos de modificació de dades. Les peticions simultànies d’actualització d’unes mateixes dades poden originar problemes d’interferència que tinguin com a conseqüència l’obtenció de dades errònies i la pèrdua d’integritat de la BD.

Per tractar correctament els problemes derivats de la concurrència d’usuaris, els SGBD fan servir fonamentalment dues tècniques: les transaccions i els bloquejos.

Una transacció consisteix en un conjunt d’operacions simples que s’han d’executar com una unitat.

Les operacions incloses dins d’una transacció mai no s’han d’executar parcialment. Si per algun motiu no s’han pogut executar totes correctament, el SGBD ha de desfer automàticament els canvis produïts fins aleshores. D’aquesta manera, es podrà tornar a llançar l’execució de la mateixa transacció, sense haver de fer cap modificació en el codi de les diferents operacions que inclogui.

Exemple de transacció

Imaginem que el conveni col·lectiu d’una empresa determina que els salaris dels treballadors s’han d’apujar el mes de gener un 3%. La millor opció consistirà a actualitzar la taula d’empleats i, més concretament, els valors del camp que recull els sous dels empleats, mitjançant una consulta d’actualització que modifiqui totes aquestes dades i les incrementi en un 3%.

Si volem garantir que l’actualització del salaris no quedi a mitges, haurem de fer que totes les instruccions que impliqui aquest procés es comportin de manera transaccional, és a dir, que s’executin totes o bé que no se n’executi cap.

Però també es pot donar la situació en què diferents transaccions vulguin accedir a la BD simultàniament. En aquests casos, encara que cada transacció, individualment considerada, sigui correcta, no es podria garantir la consistència de les dades si no fos per l’ús de la tècnica del bloqueig.

Un bloqueig consisteix a impedir l’accés a determinades dades durant el temps en què siguin utilitzades per una transacció. Així s’aconsegueix que les transaccions s’executin com si estiguessin aïllades, de tal manera que no es produeixen interferències entre elles.

Exemple de bloqueig

Imaginem que el departament de recursos humans de l’empresa de l’exemple anterior disposa d’una aplicació que li proporciona certes dades de caire estadístic sobre de les remuneracions dels empleats, com ara el salari mitjà.

Si es vol executar de manera concurrent la transacció descrita, que incrementa els sous en un 3%, i al mateix temps es llança l’execució de l’aplicació que calcula el salari mitjà de tots els empleats de l’empresa, el resultat obtingut per aquest programa probablement serà erroni.

Per tal de garantir la correcció del càlcul, s’haurà de bloquejar una de les dues transaccions mentre l’altra s’executa.

Si es bloqueja l’actualització de dades, el salari mitjà estarà calculat a partir dels sous antics (és a dir, abans de ser actualitzats).

En canvi, si es bloqueja el programari estadístic, en primer lloc s’actualitzaran totes les dades, i després es calcularan els resultats a partir dels nous valors del camp que emmagatzemi el salari.

Els bloquejos provoquen esperes i retencions, i per això les noves versions dels diferents SGBD del mercat s’esforcen a minimitzar aquests efectes negatius.

Contribuir a la seguretat de les dades

L’expressió seguretat de les dades fa referència a la seva confidencialitat. Sovint, l’accés a les dades no ha de ser lliure o, com a mínim, no ho ha de ser totalment. Els SGBD han de permetre definir autoritzacions d’accés a les BD, tot establint permisos diferents en funció de les característiques de l’usuari o del grup d’usuaris.

Actualment, els SGBD permeten definir autoritzacions a diferents nivells:

• Nivell global de tota la BD

• Nivell d’entitat

• Nivell d’atribut

• Nivell de tipus d’operació

Exemples de drets d’accés

Els usuaris del departament de comptabilitat potser no haurien de tenir accés a l’entitat que emmagatzema les dades personals dels empleats de l’empresa, a diferència de l’usuari que ostenta el càrrec de director general, que les podrà consultar per tal d’optimitzar la ubicació dels treballadors el l’organigrama en funció del respectiu perfil, o també dels usuaris del departament de recursos humans, que haurien de poder fins i tot modificar-les.

En general, els usuaris no haurien de tenir accés als atributs que emmagatzemen l’adreça particular dels empleats, a no ser que es tracti del personal de recepció, si resulta que és l’encarregat d’enviar-los certa correspondència a domicili (com ara les nòmines o els certificats de retencions d’IRPF), i per tant hauria, si més no, de poder consultar-los.

Aquests mecanismes de seguretat requereixen que cada usuari es pugui identificar. El més freqüent és utilitzar un nom d’usuari i una contrasenya associada per a cada usuari. Però també hi ha qui fa servir mecanismes addicionals, com ara targetes magnètiques o de reconeixement de la veu. Actualment, s’investiga en altres direccions com, per exemple, en la identificació personal mitjançant el reconeixement de les empremtes dactilars.

Un altre aspecte a tenir en compte en parlar de la seguretat de les dades és la seva encriptació. Molts SGBD ofereixen aquesta possibilitat, en alguna mesura.

Les tècniques d’encriptació permeten emmagatzemar la informació utilitzant codis secrets que no permeten accedir a les dades a persones no autoritzades i que, per tant, no disposen dels codis esmentats.

L’encriptació pot fer disminuir el rendiment en l’accés a les dades, ja que comporta la utilització d’algoritmes addicionals en les operacions de consulta. Per això se n’ha de dosificar l’ús. Ara bé, sempre que sigui possible, és convenient encriptar les contrasenyes.

Llenguatges de SGBD

Usuaris i administradors

Components funcionals dels SGBD

Diccionari de dades