M2 - Bases de dades / UF1NF1: Els SGBD

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. Procediment:

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

La comunicació entre els SGBD i els seus usuaris s’ha de realitzar mitjançant algun tipus de llenguatge. Els llenguatges de BD es poden classificar en dues grans tipologies segons la finalitat:

1. Llenguatges de definició de dades (data definition languages, en anglès, o DDL). Estan especialitzats en la definició de l’estructura de les BD mitjançant l’especificació d’esquemes.

2. Llenguatges de manipulació de dades (data management languages, en anglès, o DML). Possibiliten la consulta, modificació i eliminació, de les dades emmagatzemades, i també la inserció de noves informacions. Podem considerar l’existència de dos subtipus, bàsicament:

• Procedimentals. Requereixen especificar no solament les dades que es necessiten, sinó també els procediments que s’han de seguir per obtenir-les. S’utilitzaven de manera exclusiva abans de l’arribada del model relacional. Actualment, es continuen utilitzant, però només quan cal optimitzar algun procés que no rendeix prou, pel fet d’estar implementat de manera declarativa. Són més eficients que els declaratius, però més complicats, ja que exigeixen tenir certs coneixements sobre el funcionament intern del SGBD utilitzat.

• Declaratius. Només requereixen especificar quines dades es necessiten, sense que calgui especificar com s’han d’obtenir. Són més senzills d’aprendre que els procedimentals, però també menys eficients.

El llenguatge més utilitzat per interaccionar amb els SGBD relacionals és l’SQL.

L’SQL engloba les dues tipologies de llenguatges de BD descrites. Les seves operacions es poden classificar, doncs, en un dels dos tipus esmentats (DDL i DML) amb finalitats pedagògiques, però en realitat totes formen part d’un únic llenguatge.

Exemples d’operacions DDL i DML del llenguatge SQL

Com a instruccions de tipus DML, podem esmentar SELECT (per fer consultes), i també INSERT, UPDATE i DELETE (per realitzar el manteniment de les dades).

I com a instruccions de tipus DDL, podem considerar CREATE TABLE (que ens permet definir les taules, les seves columnes i les restriccions que calgui).

En relació al component DML de l’SQL, cal dir que és fonamentalment declaratiu, tot i que té possibilitats procedimentals, que es poden explotar en diferents SGBD:

• PL/SQL, llenguatge procedimental per treballar amb els SGBD creats per Oracle.

• PL/PgSQL, similar al PL/SQL d’Oracle, però dissenyat per treballar amb PostgreSQL.

Cal dir que, a més del respectiu llenguatge nadiu de BD (habitualment, SQL), els SGBD ofereixen, des de ja fa molt de temps, dues possibilitats més per incrementar la productivitat en el treball amb BD, que són els llenguatges de quarta generació i les interfícies visuals, sovint proporcionades dins de l’entorn d’una sola eina.

Sovint, l’accés a les BD també es fa des d’aplicacions externes al SGBD, escrites en llenguatges de programació (com per exemple C, Java, etc.), els quals normalment no incorporen instruccions pròpies que permetin la connexió amb BD.

Per respondre a aquesta necessitat, hi ha dues opcions:

1. Realitzar, dins del programa, crides a diferents funcions que són en llibreries que implementen estàndards de connectivitat de BD amb programes escrits en certs llenguatges, com ara els següents:

• ODBC (open data base connectivity), sistema creat per Microsoft i compatible amb molts sistemes com, per exemple, Informix, MS Access, MySQL, Oracle, PostgreSQL, SQL Server, etc.

• JDBC (Java data base connectivity), per realitzar operacions amb BD des d’aplicacions escrites en Java.

2. Hostatjar les sentències del llenguatge de BD que siguin necessàries, dins d’un programa amfitrió escrit en el llenguatge de programació utilitzat. És imprescindible que el compilador utilitzat accepti la introducció de sentències escrites en el llenguatge de BD utilitzat (que normalment serà l’SQL).

Usuaris i administradors

Podem diferenciar tres categories d’usuaris de SGBD en funció de la manera en què interactuen amb el sistema: externs, sofisticats i programadors d’aplicacions.

1. Usuaris externs. Són usuaris no sofisticats, que no interactuen directament amb el sistema, sinó mitjançant alguna aplicació informàtica desenvolupada prèviament per altres persones amb aquesta finalitat.

Exemple d’usuari extern

Qualsevol persona assumeix aquest rol quan treu diners d’un caixer automàtic, ja que accedeix a la BD de l’entitat financera identificant-se mitjançant una targeta magnètica i un número d’identificació personal secret (personal identification number, en anglès, o PIN).

Una vegada autoritzada a entrar en el sistema, podrà realitzar diferents operacions de consulta o, fins i tot, d’actualització. En el cas plantejat, després de treure diners, el saldo del compte corrent associat a la targeta patirà el decrement corresponent.

2. Usuaris sofisticats. Interactuen directament amb el sistema, sense utilitzar les interfícies proporcionades per programes intermediaris. Formulen les consultes en un llenguatge de BD (normalment, SQL), des de dins de l’entorn que el SGBD posa a la seva disposició. Tradicionalment, aquest entorn ha estat una consola en què es podien escriure les consultes, però cada vegada són més freqüents entorns que permeten construir les consultes de mode visual, com autèntiques eines CASE.

3. Programadors d’aplicacions. Són professionals informàtics que creen els programes que accedeixen als SGBD i que, posteriorment, són utilitzats pels usuaris que hem anomenat externs. Aquestes aplicacions es poden desenvolupar mitjançant diferents llenguatges de programació i eines externes al SGBD. Però molts SGBD comercials també inclouen entorns propis de desenvolupament i llenguatges de quarta generació que faciliten enormement la generació de formularis i informes que permeten visualitzar i modificar les dades.

Administradors d’SGBD

Els administradors són uns usuaris especials que realitzen tasques d’administració i control centralitzat de les dades, i gestionen els permisos d’accés concedits als diferents usuaris i grups d’usuaris, per tal de garantir el funcionament correcte de la BD.

Els administradors han d’actuar, evidentment, per solucionar les eventuals aturades del sistema, però la seva responsabilitat fonamental consisteix, justament, a evitar que es produeixin incidents.

La feina dels administradors no és fàcil, tot i que els SGBD incorporen cada vegada més eines per facilitar-la, i en la majoria dels casos amb interfície visual. Es tracta, per exemple, d’eines de monitoratge de rendiment, d’eines de monitoratge de seguretat, de verificadors de consistència entre índexs i dades, de gestors de còpies de seguretat, etc.

Una llista no exhaustiva de les tasques dels administradors podria ser la següent:

• Crear i administrar els esquemes de la BD.

• Administrar la seguretat: autoritzacions d’accés, restriccions, etc.

• Realitzar còpies de seguretat periòdiques.

• Controlar l’espai de disc disponible.

• Vigilar la integritat de les dades.

• Observar l’evolució del rendiment del sistema i determinar quins processos consumeixen més recursos.

• Assessorar els programadors i els usuaris sobre la utilització de la BD.

• Fer canvis en el disseny físic per millorar el rendiment.

• Resoldre emergències.

Components funcionals dels SGBD

El programari que conforma els SGBD es divideix en diferents mòduls, encarregats de les respectives funcionalitats que ha de garantir el sistema.

El components funcionals dels SGBD més importants són el gestor d’emmagatzemament i el processador de consultes.

Gestor d’emmagatzemament

Les BD corporatives tenen enormes requeriments d’espai d’emmagatzematge en disc. Les dades es transfereixen entre el disc en què estan emmagatzemades i la memòria principal de l’ordinador només quan és necessari. I, com que la transferència de dades cap al disc o des del disc és lenta en comparació amb la velocitat de la unitat central de processament, és molt important que el SGBD estructuri les dades de tal manera que se’n minimitzi la necessitat de transferència entre el disc i la memòria principal.

El gestor d’emmagatzemament proporciona la interfície entre les dades, considerades a baix nivell, i les consultes i els programes que accedeixen a la BD. Les dades s’emmagatzemen en disc fent servir el sistema d’arxius que proporciona el sistema operatiu utilitzat. I el gestor tradueix les instruccions DML a ordres comprensibles pel sistemes d’arxius a baix nivell.

Els components del gestor d’emmagatzemament són els següents:

• Gestor d’autoritzacions i d’integritat. Comprova que se satisfacin tant les restriccions d’integritat com les autoritzacions dels usuaris per accedir a les dades.

• Gestor de transaccions. Assegura que la BD es mantingui en un estat de consistència malgrat les fallades del sistema, i també que les transaccions concurrents no s’interfereixin entre elles.

• Gestor d’arxius. Gestiona la reserva d’espai d’emmagatzemament en disc i les estructures de dades utilitzades per representar la informació emmagatzemada en disc.

• Gestor de memòria intermèdia. Transfereix les dades des del disc a la memòria principal, i decideix quines dades s’han de tractar en memòria cau. Permet al sistema tractar amb dades de grandària molt superior a la de la memòria principal.

D’altra banda, el gestor d’emmagatzemament utilitza certes estructures de dades que formen part de la implementació física del sistema:

• Arxius de dades. Emmagatzemen la BD pròpiament considerada.

• Diccionari de dades. Emmagatzema les metadades relatives a tota l’estructura de la BD.

• Índexs. Proporcionen un accés ràpid a certes dades en funció dels seus valors.

Processador de consultes

El processador de consultes ajuda el SGBD a simplificar l’accés a les dades. Les vistes a alt nivell contribueixen a assolir aquest objectiu, ja que eviten que els usuaris hagin de conèixer detalls de la implementació física del sistema. Però això no treu que el sistema no hagi de perseguir l’eficàcia en el processament de les consultes i de les actualitzacions de dades. De fet, el sistema ha de traduir les instruccions escrites, a nivell lògic, en un llenguatge no procedimental (típicament, SQL), a una seqüència d’operacions a nivell físic, amb uns mínims d’eficiència.

Els components del processador de consultes són els següents:

• Intèrpret DDL. Interpreta les instruccions de tipus DDL i registra les definicions en el diccionari de dades.

• Compilador DML. Tradueix les instruccions DML formulades en un llenguatge de consultes (normalment, SQL) a una sèrie d’instruccions a baix nivell que pot interpretar el motor d’avaluació de consultes. En realitzar la traducció esmentada, un bon compilador DML també s’encarregarà de fer una optimització de consultes triant, entre totes les alternatives, la de menor cost.

• Motor d’avaluació de consultes. Executa les instruccions de baix nivell generades pel compilador DML.

La següent figura mostra tots aquests components i les connexions entre ells.

Diccionari de dades

Un diccionari de dades d’una base de dades és el conjunt de metadades que proporcionen informació sobre el contingut i l’organització de la base de dades.

Un diccionari de dades, segons IBM Dictionary of Computing es pot definir com un “repositori centralitzat d’informació sobre dades com ara el significat, relacions amb altres dades, orígen, ús i format.”

De vegades el concepte de diccionari de dades o metadades també és conegut amb el nom de catàleg del sistema o, també, com a repositori de metadades.

Els diferents SGBD específics implementen de diverses formes el diccionari de dades, de forma que cada programari implementa amb un conjunt de taules i ofereix un conjunt de vistes a diferents tipus d’usuaris del sistema. Així doncs, normalment, un usuari amb privilegis d’administrador del sistema (DBA) pot visualitzar més informació i de tipus més específic que un usuari sense aquests privilegis.

Els elements que es troben habitualment a un diccionari de dades inclouen:

• Definicions de l’esquema de la base de dades.

• Descripcions detallades de taules i camps, així com de tots els objectes de la base de dades (vistes, clusters, índexos, sinònims, funcions i procediments, triggers, etc.).

• Restriccions d’integritat referencial.

• Informació de control d’accés, com ara noms d’usuari, rols, i privilegis.

• Paràmetres d’ubicació de l’emmagatzemament.

• Estadístiques d’ús de la base de dades.

Tot aquest conjunt d’informació, s’emmagatzema en centenars de taules d’informació. Tot i que hi ha organismes que intenten estandarditzar l’organització d’aquesta meta-informació, la realitat és que cada distribuïdor de programari específic (cada SGBD) ofereix la seva pròpia estructura.

Un administrador del sistema o DBA haurà de conèixer com accedir i consultar tota aquesta informació consultant la guia de referència del sistema amb què treballi.

El diccionari de dades en Oracle

En Oracle és l’usuari SYS el propietari del diccionari de dades i l’únic que pot fer actualitzacions sobre la informació que conté. Tot i que, alterar o manipular el diccionari de dades és una operació d’administració que cal fer amb moltes precaucions, doncs pot provocar danys permanents.

En Oracle es creen tres tipus de vistes diferents, que permeten consultar informació sobre diferents tipus de dades. Així les vistes poden tenir un d’aquests prefixos:

• USER: Per a visualitzar informació sobre els objectes propietat de l’usuari.

• ALL: Per a consultar informació sobre els objectes on té accés l’usuari.

• DBA: Que dóna accés a tots els objectes del sistema, per a poder ser controlats i gestionats.

Així doncs, per exemple, es poden consultar el conjunt d’objectes a què es té accés des d’un usuari donat d’Oracle amb la següent sentència:

SELECT owner, object_name, object_type FROM ALL_OBJECTS;

Diccionari de dades en MySQL

En MySql, en canvi, és la vista INFORMATION_SCHEMA qui proporciona informació sobre les bases de dades que s’emmagatzemen en el sistema.

Per a obtenir certa informació sobre una base de dades concreta anomenada db_name en un SGBD MySQL podríem executar una sentència com ara:

SELECT table_name, table_type, engine, FROM information_schema.tables WHERE table_schema = 'db_name';