Models de bases de dades

D’altra banda, també resulta interessant examinar l’arquitectura dels SGBD des d’un punt de vista funcional, ja que coneixent els diferents components, i els fluxos de dades i de control podem entendre el funcionament dels SGBD, i estarem en millors condicions d’utilitzar-los d’una manera òptima.

D’acord amb l’estàndard ANSI/X3/SPARC, hi hauria d’haver tres nivells d’esquemes:

• En el nivell extern se situen les diferents visions lògiques que els processos usuaris (programes d’aplicació i usuaris directes) tenen de les parts de la BD que utilitzen. Aquestes visions s’anomenen esquemes externs.
• En el nivell conceptual hi ha una sola descripció lògica bàsica, única i global, que anomenem esquema conceptual, i que serveix de referència per a la resta d’esquemes.
• En el nivell físic hi ha una única descripció física, que anomenem esquema intern.

La figura representa la relació, d’una banda, entre el nivell físic i l’esquema intern; i, d’una altra banda, entre el nivell lògic i l’esquema conceptual, i els diferents esquemes externs (o vistes).

En definir un esquema extern, només s’inclouran els atributs i entitats que interessin, els podrem reanomenar, podrem definir dades derivades, podrem definir una entitat de tal manera que les aplicacions que utilitzen aquest esquema extern creguin que en són dues, o podrem definir combinacions d’entitats perquè en semblin una de sola, etc.

En l’esquema conceptual, es descriuran les entitats tipus, els seus atributs, les interrelacions i també les restriccions o regles d’integritat.

L’esquema intern o físic contindrà la descripció de l’organització física de la BD: camins d’accés (índexs, hashing, apuntadors…), codificació de les dades, gestió de l’espai, mida de la pàgina, etc.

Actualment, hi ha algunes noves tendències incipients, gràcies al fenomen Internet, tot i que la informació en les empreses segueix utilitzant els models clàssics de BD.

Les BD jeràrquiques es van concebre al principi del anys seixanta, i encara s’utilitzen gràcies al bon rendiment i la millor estabilitat que proporcionen amb grans volums d’informació.

Les dades s’emmagatzemen en forma de registres. Cada registre té un tuple de camps. Un conjunt de registres amb els mateixos camps forma un fitxer.

Però les BD jeràrquiques no ofereixen una perspectiva lògica per sobre de la física. Les relacions entre les dades s’estableixen sempre a nivell físic, mitjançant adreçaments físics al mitjà d’emmagatzemament utilitzat (és a dir, indicant sectors i pistes, en el cas més habitual dels discos durs).

Així, doncs, les interrelacions s’estableixen mitjançant punters entre registres. Qualsevol registre conté l’adreça física del seu registre pare en el mitjà d’emmagatzemament utilitzat. Aquesta circumstància proporciona un rendiment molt bo: l’accés des d’un registre a un altre és pràcticament immediat.

Però, si bé el model jeràrquic optimitza les consultes de dades des dels nodes cap al node arrel, amb les consultes en sentit invers es produeix el fenomen contrari, ja que aleshores cal fer un recorregut seqüencial de tots els registres de la BD.

Altres limitacions d’aquest model consisteixen en la seva incapacitat per evitar la redundància (les repeticions indesitjades de les dades) o per garantir la integritat referencial (ja que els registres poden quedar “orfes” en esborrar-se el node pare respectiu). La responsabilitat per evitar aquests problemes queda a les mans de les aplicacions externes a la BD.

La figura mostra l’estructura de nodes interrelacionats d’una BD jeràrquica.

Dos dels gestors de BD jeràrquiques que tenen més implantació són els següents:

• IMS(information management system), de la multinacional nordamericana IBM.
• Adabas (adaptable database system), de l’empresa alemanya Software AG.

La figura mostra l’estructura de nodes interrelacionats d’una BD en xarxa.

El model en xarxa va comportar una millora respecte al model jeràrquic, perquè permetia controlar de manera més eficient el problema de la redundància de dades.

Malgrat aquests avantatges, el model en xarxa no ha tingut tanta fortuna com el seu predecessor, a causa de la complexitat que comporta l’administració de les BD que l’adopten.

El consorci de la indústria de les tecnologies de la informació CODASYL (acrònim de Conference on Data Systems Languages) va proposar un estàndard que van seguir la majoria de fabricants.

Un dels gestors de BD en xarxa més coneguts, i que segueix l’estàndard CODASYL, és l’IDMS (integrated database management system), de Computer Associates.

A partir dels anys vuitanta, es van començar a comercialitzar gran quantitat de BD que aplicaven aquest model.

Les dades s’estructuren en representacions tabulars, anomenades taules, que representen entitats tipus del món conceptual, i que estan formades per files i columnes. Les columnes formen els camps, que implementen els atributs, és a dir, les característiques que ens interessen de les entitats. I les files són els registres, que implementen les entitats instància, constituïdes pels conjunts dels valors que presenten els camps corresponents a cada instància.

La figura mostra l’estructura de taules corresponent a una BD relacional.

Les interrelacions s’han d’implementar utilitzant les taules: quan és necessari s’han d’afegir, a les taules, un o més camps que actuïn com a el que anomenarem clau forana i que, per tant, “apuntin” al camp o camps referenciats d’una altra taula, els quals han de formar la seva clau primària. En coincidir els valors dels camps de la clau primària i de la clau forana, s’estableix la interrelació entre els registres.

El model relacional comporta certs avantatges respecte al model jeràrquic i al model en xarxa:

• Proporciona eines per evitar la duplicitat de registres, mitjançant claus primàries i foranes que permeten interrelacionar les taules.
• Vetlla per la integritat referencial: en eliminar-se un registre o en modificar-se el seu valor, o bé no permet fer-ho si hi ha registres interrelacionats en altres taules, o bé s’esborren o es modifiquen en cascada els registres interrelacionats, en funció de quina orientació hàgim seguit en administrar la BD.
• En no tenir importància la ubicació física de les dades, afavoreix la comprensibilitat. De fet, el model relacional, com a tal, es limita al nivell lògic, i deixa de banda el nivell físic. Per aquest motiu, es diu que el model relacional possibilita la independència física de les dades.

Aquest nou model admet la possibilitat que els tipus de dades siguin, a més dels tradicionals, tipus abstractes de dades (TAD). Amb aquesta particularitat, s’acosten els sistemes de BD relacionals al paradigma de la programació orientada a objectes.

Els models estrictament orientats a objectes defineixen les BD en termes d’objectes, de les seves propietats i, el que és més innovador, de les seves operacions. Els objectes amb una mateixa estructura i comportament pertanyen a una classe, i les classes s’organitzen en jerarquies. Les operacions de cada classe s’especifiquen en termes de procediments predefinits, anomenats mètodes.

La figura mostra l’estructura de classes, subclasses i instàncies, d’una BD orientada a objectes.

Actualment, hi ha organitzacions que gestionen grans quantitats de dades i que aquestes dades les han de consultar habitualment i els cal que aquestes consultes siguin ràpides. Típicament aquesta necessitat es va crear en empreses que necessitaven consultar dades per a la presa de decisions.

Es pot pensar, per exemple, en una multinacional que disposa de BD relacionals on emmagatzema totes les seves factures, totes les línies de factures, que s’han anat fent al llarg de 15 anys d’història. Disposar d’un resum global de l’evolució de la facturació dels darrers 10 anys, pot suposar, en aquesta BD relacional la consulta de milions de registres. Es pot intuir, doncs, que resultarà un procés costós obtenir aquesta informació.

El model relacional, doncs, moltes vegades no dóna una resposta prou eficient per a gestionar aquests tipus d’informació i per això van començar a aparèixer els sistemes Datawarehouse. Els Datawarehouse són magatzems de dades que integren eines per a extreure transformar i carregar informació anomenada d’intel·ligència empresarial així com informació de metadades.

Més enllà dels Datawarehouse existeixen les BD multidimensionals.

Un cub OLAP és una estructura de dades que permet accessos ràpids a la informació i que s’organitza aquesta informació en diverses perspectives o dimensions.

Disposar de forma eficient de la informació organitzada des de totes aquestes perspectives es pot veure com a un hipercub d’informació, on cada dimensió del cub (que pot ser de dues, tres, quatre, etc. dimensions) correspon a una forma (perspectiva) d’accedir a aquestes dades.

Un cas particular de BD multidimensional són les BD multivalor. Les BD multivalor solen dissenyar BD on els atributs emmagatzemen llistes de valors, a diferència de les BD relacionals on els atributs són monovalor. Moltes vegades es coneix a les BD multivalor com a BD post-relacionals.

Les BD multivalor proporcionen llenguatges d’accés a les dades molt més semblants al llenguatge natural i, per tant, més senzills que SQL. La dificultat actual resideix en què cada implementació de BD multivalor disposa del seu propi llenguatge, no existint, en l’actualitat un estàndard comú.

Últimament, i per influència de les tècniques de desenvolupament de programari orientades a l’objecte, han aparegut alguns models semàntics com a noves extensions del model ER originari, entre les que destaca especialment l’UML (unified modeling language).

La notació del llenguatge UML és diagramàtica, com la notació del model ER. Els diagrames UML es poden utilitzar per expressar els dissenys conceptuals, tal com es fa amb els diagrames ER.

Però cal tenir en compte que el disseny de BD s’encarrega, fonamentalment, de la part estàtica dels sistemes d’informació (és a dir, la que no hauria de canviar al llarg del temps, com ara, justament, l’estructuració de les dades).

En l’UML, la part estàtica dels sistemes es representa mitjançant els anomenats diagrames de classes i, concretament, amb els components següents:

• Les classes i els atributs respectius (però no necessàriament, les operacions).
• Les relacions entre classes, com les associacions i les generalitzacions (però no tant, les dependències ni les realitzacions).

Per tant, aquí no considerarem ara altres aspectes de l’UML que s’ocupen de modelitzar més aviat la part dinàmica dels sistemes d’informació (és a dir, els aspectes que canvien amb el temps).

En la taula, podem veure les equivalències més importants entre la notació emprada en els diagrames ER, i l’emprada en els diagrames de classes UML.

Taula Taula d’equivalències entre els diagrames ER i els diagrames de classe UML

	Diagrama ER	Diagrama de classe UML
Entitats: atributs
Interrelacions: cardinalitats, rols i atributs
Generalitzacions encavalcades
Generalitzacions disjuntes

Les classes permeten especificar molts altres detalls, com ara el tipus de dada de cada atribut, la seva visibilitat, etc.

Aquesta línia pot ser dirigida, és a dir, que pot acabar amb una punta de fletxa (no tancada) en un dels extrems (o en tots dos).

A més, les associacions, poden incloure una etiqueta amb el nom que tinguin assignat o, fins i tot, dues, si preferim especificar el rol que adopta cadascuna de les dues classes.

Si, en un diagrama ER, una interrelació té atributs propis, el diagrama de classes UML equivalent haurà d’incorporar un requadre addicional, dividit verticalment en dues seccions. En la secció superior haurà de constar el nom de l’associació, i en la inferior s’hauran d’incloure els atributs. Finalment, aquest requadre haurà d’anar unit amb una línia discontinua amb l’associació.

Les restriccions de cardinalitat s’especifiquen en els diagrames de classe UML de manera molt semblant a com es fa en els diagrames ER. També s’utilitza la forma màx .. mín que ja coneixem, per tal d’indicar el màxim i el mínim d’associacions en què pot participar cada instància de la classe. Ara bé, habitualment, la n es representa amb un asterisc (*), i la ubicació de les etiquetes que indiquen les restriccions de cardinalitat és exactament la inversa de la que correspon en un diagrama ER.

Cal parar atenció en el fet que les interrelacions n-àries d’ordre superior a 2 no es poden representar directament en els diagrames de classe UML.

Si es tracta d’una generalització encavalcada (és a dir, quan les instàncies de la superclasse també poden ser instàncies, simultàniament, de més d’una subclasse), cal establir una línia i una punta de fletxa pròpia per a cada subclasse.

En canvi, quan es vol representar una generalització disjunta (és a dir, quan les instàncies de la superclasse només poden ser, també, instàncies d’una sola de les subclasses), les línies que parteixen de les subclasses han d’acabar confluint en una única punta de fletxa buida que apunti a la superclasse.

Un dels sectors informàtics on més s’està evolucionant darrerament, tot integrant el desenvolupament tecnològic amb la innovació metodològica, és el relatiu als sistemes distribuïts d’informació.

Amb aquesta darrera expressió volem fer referència a la utilització de dades emmagatzemades en diferents ubicacions, de vegades molt distants entre si, però que al mateix temps estan connectades, mitjançant una xarxa de comunicacions.

Aquesta tendència es fa palesa en l’ús habitual d’Internet per part de qualsevol de nosaltres, però també hi ha nombroses empreses i institucions que necessiten que els sistemes informàtics (i per tant, també les BD) s’adaptin cada cop més a la seva estructura geogràfica o funcional.

Un cas concret d’aquests sistemes el constitueixen les bases de dades distribuïdes. És important conèixer les diferents arquitectures aplicades als sistemes de bases de dades, en general. Podem distingir entre les arquitectures centralitzades (incloent-hi els sistemes client-servidor) i les descentralitzades, en què s’ha de tenir en compte el funcionament dels sistemes paral·lels.

També és important conèixer les diferents metodologies per distribuir BD, en funció dels objectius plantejats en la fase de disseny, i també de si l’estratègia emprada té un caràcter ascendent o descendent. S’han de tenir en compte, però, les dues conseqüències més problemàtiques de la distribució de BD: la duplicació i la fragmentació de les dades, on hem de diferenciar entre fragmentacions horitzontals, verticals i mixtes.

No hem d’oblidar tampoc les problemàtiques específiques que representen per a les BD distribuïdes tant les transaccions com la concurrència, ni els diferents protocols amb els quals es dóna resposta a aquestes eventualitats.

L’arquitectura de tot sistema de BD està molt condicionada per les característiques del sistema informàtic sobre el qual s’executa, i en especial pels aspectes següents:

• La connexió en xarxa de diferents computadores.
• El processament paral·lel de consultes dins d’una mateixa computadora.
• La distribució de les dades en diferents computadores, fins i tot allunyades entre si.

Aquestes innovacions tecnològiques han permès, respectivament, el desenvolupament, a partir dels inicials sistemes totalment centralitzats en una sola computadora, de diferents arquitectures de sistemes de BD més evolucionades, i que permeten donar resposta a una gran varietat de necessitats dels usuaris i de les organitzacions en què aquests treballen, com ara:

• Sistemes client-servidor.
• Sistemes paral·lels.
• Sistemes distribuïts.

Inicialment els sistemes de BD eren de tipus estrictament centralitzat, en el sentit que s’executaven sobre un únic sistema informàtic, sense necessitat d’interaccionar amb cap altre.

Però l’abaratiment dels ordinadors personals i el desenvolupament vertiginós de les seves capacitats, juntament amb la implantació de les xarxes i d’Internet, ha fet evolucionar els sistemes centralitzats cap a arquitectures de tipus client-servidor.

En els sistemes monousuaris, els sistemes de BD centralitzats són petits sistemes de BD pensats per a les tasques que pugui fer un sol usuari amb una estació de treball. Aquests sistemes no sempre ofereixen totes les possibilitats que sempre ha de garantir qualsevol sistema de BD multiusuari, per modest que sigui, com per exemple el control automàtic de la concurrència.

En els sistemes multiusuaris, en canvi, es tracta de grans sistemes que poden donar servei a un gran nombre d’usuaris. Aquests només disposen per interaccionar amb el sistema de terminals sense capacitat pròpia per emmagatzemar dades ni tampoc per processar consultes, ja que de la realització d’aquestes tasques s’encarrega l’únic sistema centralitzat existent.

Gradualment, els antics terminals dels sistemes centralitzats han estat substituïts per ordinadors personals, igualment connectats als subsistents sistemes centrals. Com a conseqüència d’això, pràcticament tots els sistemes centralitzats actuen avui en dia com a sistemes servidors que satisfan les peticions que els envien els respectius sistemes clients.

Actualment, els estàndards ODBC i JDBC permeten que tot client que utilitzi qualsevol dels dos, es pugui connectar a qualsevol servidor que proporcioni la interfície respectiva.

Podem distingir dues tipologies de sistemes servidors:

• Servidors de dades. S’utilitzen en xarxes d’àrea local en què s’arriba a una alta velocitat de connexió entre els clients i el servidor, sempre que les estacions de treball siguin comparables al servidor quant a la capacitat de processament. En entorns així definits, pot tenir sentit enviar les dades als clients, fer allà totes les tasques de processament d’aquestes dades, i finalment reenviar, si cal, els resultats al servidor.
• Servidors de consultes. Proporcionen una interfície, mitjançant la qual els clients els envien peticions per tal que resolguin consultes, i els retornin els resultats obtinguts. Així doncs, les transaccions s’executen sobre el servidor, però les dades resultants es visualitzen en el client del qual provenia la petició, si escau.

La descentralització de les arquitectures de BD pot consistir en el repartiment de la càrrega de feina entre diferents components físics del sistema (bàsicament pel que fa a processadors, memòria principal i memòria persistent) comunicats entre si mitjançant una xarxa d’interconnexió.

Però una arquitectura descentralitzada també pot consistir en la distribució de la mateixa BD en diferents computadores, seguint la metodologia més adient per assolir l’objectiu proposat.

Els sistemes paral·lels són molt útils (o fins i tot són imprescindibles) en el treball quotidià amb BD molt grans (de l’ordre de terabytes), o que han de processar moltes transaccions (de l’ordre de milers per segon), ja que normalment els sistemes centralitzats i els sistemes client-servidor no tenen prou capacitat per donar resposta a aquest tipus de necessitats.

Avui en dia molts ordinadors de gamma alta ofereixen un cert grau de paral·lelisme, atès que incorporen dos o quatre processadors. Però hi ha computadores paral·leles que suporten centenars de processadors i discos durs.

Ara bé, una de les característiques que permet avaluar la utilitat d’un sistema paral·lel de BD és la seva ampliabilitat, la qual ha de garantir el funcionament ulterior del sistema a una velocitat acceptable, encara que creixi la grandària de la BD o el nombre de transaccions.

Però la veritable ampliabilitat dels sistemes paral·lels ve donada per la comunicació dels seus components mitjançant alguna xarxa que faci possible connectar-los entre si. Les tres tipologies de xarxa més utilitzades són les següents:

• Bus: es pot tractar d’una xarxa ethernet o una interconnexió paral·lela. En tot cas, aquesta estructura només és apta per al treball amb un petit nombre de processadors.
• Malla: cada component està connectat amb tots els nodes adjacents. (Si la malla és bidimensional els nodes adjacents seran 4, i si és tridimensional, 6).
• Hipercub: s’assigna a cada component un nombre binari exclusiu, de tal manera que dos components han de tenir una connexió directa entre si sempre que els nombres binaris respectius només difereixin en un sol bit. Així doncs, cadascun dels n elements del sistema estarà directament connectat amb uns altres log(n) components.

D’altra banda, hi ha diferents models d’arquitectures paral·leles de BD. Alguns dels models més importants són:

• Memòria compartida. Tots els processadors comparteixen una memòria comuna, habitualment mitjançant un bus. Les arquitectures de memòria compartida han de dotar cada processador de molta memòria cau, per tal d’evitar els accessos a la memòria compartida sempre que això sigui possible. Ara bé, el límit raonable de processadors treballant en paral·lel ve donat, justament, pel cost que representa el manteniment de la coherència de la memòria cau.
• Discos compartits. Tots els processadors comparteixen un conjunt de discos comú, mitjançant una xarxa d’interconnexió. Aquest model permet el treball en paral·lel d’un nombre de processadors més gran que amb el model de memòria compartida, però com a contrapartida la comunicació entre ells és més lenta, ja que utilitzen una xarxa en lloc d’un bus.
• Sense compartició. Els processadors no comparteixen ni memòria ni discos. Aquest model té unes potencialitats d’ampliació encara més grans que el de compartició de discos, però en canvi els costos de comunicació són superiors als del model esmentat.
• Jeràrquic. Combinació de les característiques dels models anteriors. Aquesta arquitectura s’estructura en diferents nivells. Al nivell més alt, els nodes, connectats mitjançant una xarxa d’interconnexió, no comparteixen ni memòria ni discos. Cadascun d’aquests nodes pot ser, internament, un sistema de memòria compartida entre diferents processadors. O bé cadascun d’aquests nodes pot ser, internament, un sistema de discos compartits que inclogui, a un tercer nivell, un sistema de memòria compartida.

Els processadors de les diferents computadores que formen un sistema distribuït es comuniquen entre si mitjançant una xarxa de comunicacions, però no comparteixen ni memòria ni discos. Cadascuna d’aquestes computadores constitueix, per tant, un node del sistema distribuït.

Normalment, els nodes de les BD distribuïdes es troben en llocs geogràficament distants, s’administren parcialment de manera independent i tenen una interconnexió força lenta entre ells.

Normalment, tot SGBD actual és capaç de treballar amb un altre d’idèntic. Però això no sempre és tan fàcil entre SGBD de diferents fabricants. En funció d’aquesta eventualitat, es distingeix entre dos tipus de sistemes distribuïts de BD:

• Sistemes homogenis: són sistemes fortament acoblats, en què tots els nodes utilitzen el mateix SGBD o, en el pitjor dels casos, diferents SGBD del mateix fabricant.
• Sistemes heterogenis: els SGBD que utilitzen els nodes són diferents, i, per tant, solen ser més difícils d’acoblar.

En tot cas, els usuaris dels sistemes distribuïts de BD no han de conèixer els detalls d’emmagatzemament de les dades que utilitzi, com ara la seva ubicació concreta o la seva organització. D’aquesta característica se’n diutransparència. Evidentment, els administradors de la BD sí que hauran de ser conscients d’aquests aspectes.

Hi ha bones raons per implementar BD distribuïdes, com ara la compartició de la informació, la disponibilitat de les dades o l’agilització del processament d’algunes consultes:

• Compartició de la informació i autonomia local. Un avantatge de compartir les dades mitjançant la distribució consisteix en el fet que des de cada node es pot controlar, fins a cert punt (de fet, fins allà on permeti l’administrador global de la BD), l’administració de les dades emmagatzemades localment. Aquesta característica es coneix com a autonomia local.
• Fiabilitat i disponibilitat. Si es produeix una fallada en algun node d’un sistema distribuït o en les comunicacions amb aquest, és possible que els altres nodes puguin continuar treballant, si les dades que conté el node caigut o incomunicat estan repetides en altres nodes del sistema.
• Agilització del processament de consultes. Quan una consulta necessita accedir a dades emmagatzemades en diferents nodes, pot ser possible dividir la consulta en diferents subconsultes que s’executin en els nodes respectius.

Però l’ús de BD distribuïdes també té els seus punts febles, com per exemple l’increment dels costos en desenvolupament de programari i l’augment de possibilitat d’errors, i el temps addicional a afegir al temps de processament:

• Increment en els costos de desenvolupament de programari. És més difícil estructurar un sistema distribuït de BD, i també són més complicades les aplicacions que han de treballar amb aquest sistema, que no pas si es tracta d’un sistema de BD centralitzat.
• Més possibilitat d’errors. Com que els diferents nodes del sistema distribuït operen en paral·lel, és més difícil garantir la correcció dels algorismes.
• Temps extra que cal afegir al temps de processament. L’intercanvi de missatges i els càlculs necessaris per garantir la integritat de les dades distribuïdes entre tots els nodes comporten un afegitó extra de temps, inexistent en els sistemes centralitzats.

El disseny de la distribució d’una BD implica adoptar certes decisions. La primera té a veure amb la mateixa idoneïtat d’utilitzar una BD distribuïda i no pas una altra arquitectura. Aquesta decisió s’ha de fonamentar en el rendiment esperat de cadascuna de les arquitectures disponibles, aplicades al mateix conjunt de necessitats.

A continuació, en el cas d’optar per una BD distribuïda, cal prendre altres decisions no menys importats sobre quina és la millor manera d’ubicar en els diferents nodes del sistema tant les dades com les aplicacions que hagin d’accedir a aquestes dades.

La ubicació de les aplicacions habitualment no comporta grans problemes. Depèn de les funcionalitats que aquestes han d’oferir i dels llocs des dels quals s’utilitzaran majoritàriament o exclusivament. Però també s’ha de tenir molt en compte si hauran de treballar amb un sistema homogeni o heterogeni, i els SGBD utilitzats en cada cas.

Però la distribució de les dades és més crítica i ha de perseguir la consecució de certs objectius: potenciació del processament local, distribució ideal de la càrrega de feina i reducció dels costos d’emmagatzemament. A més, cal seguir una estratègia general de disseny ascendent o descendent, tot i que tots dos enfocaments no són mútuament excloents i es poden emprar en un mateix projecte en diferents etapes d’aquest. Finalment, i com a conseqüència de tot això, s’ha d’adoptar una metodologia concreta de distribució de dades, és a dir, multiplicació, divisió, etc.

Hi ha un cert consens en alguns dels objectius bàsics que ha de perseguir tot sistema distribuït de BD, com ara:

• Potenciació del processament local. En un sistema distribuït hi ha dos tipus de transaccions: les locals i les globals. Les primeres únicament necessiten accedir al mateix node del qual parteix la petició. En canvi, les segones necessiten accedir a dades ubicades en altres nodes, la qual cosa comporta un cost addicional, ja que cal utilitzar la xarxa que els comunica. Si les dades són distribuïdes acostant-les a les aplicacions que més les utilitzen, es maximitza el processament local.
• Distribució ideal de la càrrega de feina. La distribució de les dades també ha de tenir en compte les característiques de les diferents computadores ubicades a cada node i els usos més adients per a cadascuna d’elles. D’aquesta manera es potencia el paral·lelisme en l’execució de les aplicacions. Ara bé, cal advertir que la persecució d’aquest objectiu pot afectar negativament la potenciació del processament local.
• Reducció dels costos d’emmagatzemament. La repetició de les dades en diferents nodes d’un sistema distribuït pot contribuir a la disponibilitat d’aquestes, ja que si es produeix una fallada en un dels nodes, es podrà continuar treballant amb les duplicacions existents en un altre. Això comporta, entre altres coses, un increment dels costos d’emmagatzematge que ha de ser tingut en compte, encara que últimament resulta irrellevant si es compara amb els costos derivats en matèria d’UCP, E/S i transmissions per la xarxa.

El disseny ascendent és una estratègia que pot ser aplicada quan s’ha de dissenyar una nova BD a partir de petites BD preexistents que han de ser integrades en una de sola, però conservant en la mesura que es pugui la ubicació originària de les dades.

Els sistemes distribuïts resultants d’un disseny ascendent amb BD preexistents són amb certa freqüència heterogenis, llevat que el projecte prevengui la migració a un SGBD distribuït, comú a tots els nodes.

El disseny descendent de BD distribuïdes és l’estratègia més adient quan es tracta de dissenyar aplicacions i BD noves, o quan es pot prescindir de conservar les estructures de dades anteriors, en cas que n’hi hagi. Evidentment, en aquests casos en què el dissenyador té més capacitat decisòria, el més recomanable és optar per implantar un sistema homogeni.

De fet, en l’àmbit de les BD distribuïdes, el disseny conceptual (que dóna lloc a entitats i a interrelacions entre elles) es pot interpretar com una integració de les diferents vistes dels usuaris.

Posteriorment, el disseny lògic inclourà totes les decisions en matèria de distribució de les dades. En funció de la metodologia de distribució adoptada, les relacions s’ubicaran senceres en diferents nodes del sistema, o bé es dividiran en fragments per ser distribuïts entre els nodes d’aquesta manera.

Finalment, en els nodes en què es consideri oportú, es podrà fer el disseny físic, a nivell local.

Hi ha diferents metodologies per orientar la distribució de les BD, cadascuna de les quals té els seus avantatges i els seus inconvenients:

• Multiplicació.
• Divisió.
• Distribució amb node principal.
• Distribució amb duplicacions en nodes seleccionats.

L’avantatge principal de la multiplicació és evident, ja que les consultes es fan localment, sense haver d’accedir a la xarxa de comunicacions i, per tant, de manera molt ràpida. A més, en cas que caigui algun node, la resta pot continuar treballant.

Però no en falten de desavantatges, ja que les operacions d’actualització de dades s’han de fer en tots els nodes per tal de mantenir la coherència de la BD, la qual cosa implica un trànsit molt intens a la xarxa. I encara que actualment, en la majoria de casos, sigui un problema menor, cal dir que aquest model multiplica pel nombre total de nodes l’espai necessari per emmagatzemar la BD.

En la figura es mostra un exemple de BD multiplicada, on cada node del sistema conté replicada completament la BD.

L’avantatge principal de la divisió és que les operacions d’actualització són molt senzilles, ja que no es requereix actualitzar de manera transaccional les mateixes dades en diferents nodes. A més, tampoc no es necessita més espai d’emmagatzemament del que es necessitaria si es tractés d’una BD centralitzada.

Com a contrapartides, podem dir que les operacions de consulta són sempre molt costoses, ja que la majoria són globals, la qual cosa comporta un trànsit molt intens a la xarxa. A més, la caiguda de qualsevol node implica la impossibilitat de poder accedir a aquella part de la BD emmagatzemada en ell.

En la figura tenim un exemple de BD dividida, on cada node conté només les dades que li són pròpies, sense que estigui duplicada cap part de la BD en més d’un node.

L’avantatge principal de la distribució amb node principal és que les dades s’acosten als nodes que més les utilitzen, la qual cosa potencia el processament local. A més, la disponibilitat és força bona, ja que totes les dades estan replicades com a mínim una vegada, pel fet d’estar emmagatzemades en algun dels nodes del sistema, a més d’estar-ho en el node principal.

Els desavantatges consisteixen fonamentalment en el fet que els costos de les operacions d’actualització i el d’emmagatzemament sempre seran més elevats (tot i que sense arribar als extrems de les BD multiplicades) que els produïts en sistemes centralitzats.

La figura mostra un exemple de BD distribuïda amb un node principal (Barcelona) que conté tota la BD, mentre que la resta de nodes només contenen, duplicades, les dades que els són pròpies.

La distribució amb duplicacions en nodes seleccionats es tracta d’una solució amb uns avantatges i uns inconvenients similars als del model basat en la distribució amb node principal. L’avantatge respecte a aquell és que, com que no hi ha un node principal que contingui tota la BD, la disponibilitat és un xic més elevada.

La figura proporciona un possible exemple de BD distribuïda amb duplicacions en nodes seleccionats. Cada node conté les dades que li són pròpies, i a més, conté replicada una altra part de la BD. No hi ha un node principal que contingui tota la BD, però la duplicació d’aquesta és completa si considerem les dades contingudes en tots els nodes.

Les BD distribuïdes emmagatzemen les relacions seguint principalment un dels dos esquemes referits a continuació:

• Duplicació. El sistema conserva còpies idèntiques (com a mínim una) de cada relació en diferents nodes.
• Fragmentació. Les relacions es divideixen en diferents fragments i s’emmagatzemen en diferents nodes. La fragmentació es realitza seguint alguna de les metodologies disponibles (horitzontal, vertical, etc.).

La duplicació i la fragmentació es poden utilitzar de manera combinada, fragmentant les relacions i distribuint còpies de cadascun dels fragments resultants entre els diferents nodes del sistema.

La duplicació és un tipus d’esquema d’emmagatzematge de les BD distribuïdes que comporta tant avantatges com inconvenients.

D’una banda, la duplicació de les dades millora la seva disponibilitat respecte als sistemes centralitzats, ja que si falla un dels nodes que conté una relació o un fragment d’aquesta, es pot acudir (encara que només sigui temporalment) a un dels altres nodes que contingui les mateixes dades.

D’altra banda, la duplicació de les dades en diferents nodes incrementa el paral·lelisme, ja que fa augmentar les possibilitats de que les dades es trobin en el mateix node des del qual es llença la consulta.

Però, al mateix temps, la duplicació de dades implica un increment de la sobrecàrrega del sistema quan es produeixen actualitzacions de dades, ja que cal garantir la consistència de totes les rèpliques existents.

El problema fonamental de la fragmentació inherent a les BD distribuïdes consisteix a trobar la unitat ideal de distribució de les dades. Normalment les relacions no són la millor opció de distribució per moltes raons.

D’una banda, les vistes que proporcionen les aplicacions habitualment són subconjunts de relacions. Per tant, pot ser molt més convenient considerar aquests subconjunts de relacions com les unitats desitjables de distribució.

Però, a més, la descomposició d’una relació en diferents fragments, allotjats en diferents nodes del sistema, pot contribuir a millorar el rendiment del sistema, ja que permet l’execució concurrent de transaccions, i provoca, en molts casos, l’execució paral·lela de les consultes, quan s’han de dividir en diferents subconsultes per tal d’operar sobre els diferents fragments.

La taula mostra una relació, anomenada PROVEIDOR, per tal d’exemplificar els mètodes principals de fragmentació.

La taula i taula mostren dos possibles fragments horitzontals de la relació PROVEIDOR. Els tuples s’han dividit en funció de la localitat de cada proveïdor.

A més dels atributs seleccionats, cada fragment haurà de contenir la clau primària de la relació, per tal de poder associar els tuples de tots els fragments pertanyents a una mateixa relació, que estiguin allotjats en els diferents servidors del sistema.

Els atributs poden estar presents en més d’un fragment, però han d’estar com a mínim en un d’ells per tal que la fragmentació sigui correcta.

La taula i taula mostren dos possibles fragments verticals de la relació PROVEIDOR. Els fragments resulten de seleccionar només els atributs de cada proveïdor que utilitzaran amb més freqüència els nodes que respectivament els emmagatzemin.

En funció de com es combinen les fragmentacions horitzontal i vertical, s’obtenen quatre tipologies mixtes:

1. Fragmentació VH. Es desenvolupa en primer lloc la fragmentació vertical, i a continuació l’horitzontal.
2. Fragmentació HV. S’aplica primer una divisió horitzontal i tot seguit es desenvolupa una altra de vertical sobre els fragments prèviament generats.
3. Fragmentació semàntica. La fragmentació de les relacions es fa alternant successivament fragmentacions horitzontals i verticals, però sempre tenint en compte el significat de les operacions més habituals que s’han de fer sobre les dades.
4. Fragmentació simultània. S’apliquen de manera simultània, i no pas seqüencial, la fragmentació horitzontal i la vertical, i la relació originària es transforma en una matriu, les cel·les de la qual són els fragments que s’han de distribuir. El nivell de fragmentació així obtingut normalment és molt elevat, la qual cosa no vol dir que sempre sigui més eficient.

En fragmentar una BD ha de ser valorat el grau de fragmentació que assolirà aquesta BD, ja que aquest paràmetre influirà notablement en el rendiment del sistema a l’hora d’executar consultes.

La figura mostra esquemàticament algunes possibilitats de fragmentació d’una relació.

Els SGBD en general, i els distribuïts en particular, han de garantir la integritat de les dades, mitjançant el compliment d’aquestes característiques:

• Atomicitat. O bé es fan correctament en la BD totes les operacions incloses en la transacció, o bé no se’n fa cap.
• Consistència. L’execució aïllada de la transacció (és a dir, sense la concurrència de cap altra transacció) conserva la consistència de la BD.
• Aïllament. Davant la concurrència de transaccions, el sistema garanteix que l’execució de cadascuna d’elles pressuposa, o bé que l’execució de les altres encara no ha començat, o bé que ja ha finalitzat completament.
• Durabilitat. Després de la finalització amb èxit d’una transacció, els canvis produïts en la BD romanen, fins i tot, en cas de fallades del sistema.

Les BD distribuïdes tenen els mateixos requisits transaccionals que les BD centralitzades. Però, evidentment, és més difícil garantir l’atomicitat i l’aïllament de les transaccions globals en un sistema distribuït que no pas les transaccions ocasionades en un altre de centralitzat.

Per tal de garantir la integritat de les dades en l’execució de transaccions, els SGBD distribuïts executen els anomenats protocols de compromís.

El protocol de compromís més senzill, però que a la vegada és també un dels més utilitzats, s’executa en dues fases:

• 1a fase. Un dels servidors dels nodes implicats en la transacció, que actua com a coordinador, pregunta als servidors dels altres nodes si estan en condicions de confirmar la transacció. Aleshores cadascun d’aquests servidors fa les comprovacions necessàries (per exemple, en matèria de restriccions d’integritat) per tal de donar una resposta. El servidor coordinador confirmarà la transacció si obté una resposta afirmativa per part de cadascun dels altres servidors implicats. En cas contrari, haurà de cancel·lar la transacció.
• 2a fase. El servidor que actua com a coordinador envia un missatge a la resta de servidors implicats en la transacció comunicant-los si han de confirmar o cancel·lar la transacció.

Aquest protocol és molt sensible a la caiguda dels nodes implicats, a les fallades de la xarxa, o fins i tot, a la disminució de la seva velocitat, atès el nombre de missatges a intercanviar entre els nodes implicats en cada transacció.

Però el problema potencial més important d’aquest protocol és la possibilitat de bloqueig del sistema. Si el servidor que actua com a coordinador cau durant el procés, o s’interrompen les comunicacions amb ell, la transacció pot quedar activa en la resta de servidors, la qual cosa acabaria per produir un bloqueig del sistema, o d’alguns dels seus nodes, ja que aquests servidors no haurien de cancel·lar unilateralment l’operació, ja que no sabrien si la resta de servidors han confirmat ja els canvis i haurien d’esperar indefinidament fins al restabliment de les comunicacions amb el servidor coordinador de la transacció.

Per a moltes aplicacions el problema latent del bloqueig durant l’execució del protocol de compromís en dues fases no és acceptable, per la qual cosa s’han anat desenvolupat protocols alternatius, que si bé comporten certs avantatges, tampoc no estan exempts de problemes.

El protocol de compromís en tres fases evita alguns inconvenients del protocol de compromís en dues fases, del qual es pot considerar una extensió. Però, al mateix temps, comporta uns increments de complexitat i de sobrecàrrega tals, que no és gaire utilitzat.

Aquest protocol pressuposa que no pot tenir lloc una fragmentació de la xarxa, i que mai no fallaran més d’un nombre predeterminat de nodes. Aleshores s’evita la possibilitat de bloqueig, afegint-hi una tercera fase addicional, en la qual s’impliquen uns quants nodes addicionals al que actua com a coordinador en la presa de decisió del compromís.