Asidai 225x c03 Ud1

Introducci a les bases de dades
Carlos Manuel Mart Hernndez
Anlisi i disseny de bases de dades
ndex
Introducci ............................................................................................... Objectius ................................................................................................... 1. Les dades: conceptes introductoris .................................................. 1.1. La interconnexi entre el mn real, el conceptual i el de les representacions ................................................................ 1.1.1. El mn real i els objectes ................................................. 1.1.2. El mn conceptual i la informaci ................................. 1.1.3. Les dades i la seva representaci ................................... 1.1.4. La interpretaci de les dades .......................................... 1.2. El mn conceptual ...................................................................... 1.2.1. Entitats, atributs i valors ................................................. 1.2.2. El factor cronolgic .......................................................... 1.2.3. Entitats tipus i entitats instncia ................................... 1.2.4. Tipus de dada i domini dels atributs .............................. 1.2.5. Valor nul dels atributs ...................................................... 1.2.6. Atributs identificadors i claus ......................................... 1.3. El mn de les representacions ................................................. 1.3.1. Les representacions tabulars i la seva implementaci: els fitxers ............................................... 1.3.2. Les BD ................................................................................ 1.3.3. Laccs a les dades: tipologies ......................................... 1.3.4. El nivell lgic i el nivell fsic ............................................ 2. Les BD: evoluci i models .................................................................. 2.1. Concepte i origen de les BD ....................................................... 2.2. Fitxers i BD .................................................................................. 2.3. Les diferents visions de les dades ............................................. 2.4. Models de BD .............................................................................. 2.4.1. Model jerrquic ................................................................. 2.4.2. Model en xarxa .................................................................. 2.4.3. Model relacional ............................................................... 2.4.4. El paradigma de lorientaci a objectes ......................... 3. Els SGBD: objectius i arquitectura .................................................. 3.1. Evoluci dels SGBD .................................................................... 3.1.1. Anys cinquanta: processament seqencial .................... 3.1.2. Anys seixanta i setanta: sistemes centralitzats ............. 3.1.3. Anys vuitanta: SGBD relacionals ....................................
5 6 7 7 8 9 11 12 12 13 14 15 15 16 17 18 18 20 21 23 24 24 26 28 29 30 32 32 34 35 35 36 36 37
3.1.4. Anys noranta: BD distribudes, arquitectures lient/servidor, i llenguatges de quarta generaci .......... 3.1.5. Tendncies actuals: orientaci a objectes, Internet, i elements multimdia ..................................................... 3.2. Objectius i funcionalitats dels SGBD ........................................ 3.2.1. Possibilitar les consultes no predefinides de qualsevol complexitat ................................................. 3.2.2. Garantir la independncia fsica i la independncia lgica de les dades ............................................................ 3.2.3. Evitar o solucionar els problemes derivats de la redundncia ............................................................. 3.2.4. Protegir la integritat de les dades ................................... 3.2.5. Permetre la concurrncia dusuaris ............................... 3.2.6. Contribuir a la seguretat de les dades. ........................... 3.3. Llenguatges de SGBD ................................................................. 3.4. Usuaris i administradors ............................................................ 3.4.1. Usuaris dSGBD ................................................................ 3.4.2. Administradors dSGBD ................................................... 3.5. Arquitectura dels SGBD ............................................................. 3.5.1. Esquemes i nivells ............................................................ 3.5.2. Components funcionals dels SGBD ................................ 42 43 44 46 47 49 49 50 50 51 52 42 41 39 41 37
Introducci
Avui en dia la interacci amb les bases de dades s una cosa tan freqent que moltes vegades ni tan sols ens adonem d'aquest fet. Senzillament, quan traiem diners d'un caixer automtic estem utilitzant bases de dades. Per tant, tot tcnic superior en informtica ha de tenir molt clars una srie de conceptes al voltant de les dades i de la seva representaci informtica. Aquesta unitat didctica t com a objectiu principal el daproximar-nos conceptualment al mn de les dades i al de les seva representaci informtica per excellncia, les bases de dades. Al llarg del nucli dactivitat Les dades: conceptes introductoris, examinarem els tres mbits que hem de ser capaos de diferenciar per tal de treballar correctament amb les dades: el mn real, el mn conceptual i el mn de les representacions. Per mn real, sentn la part de la realitat (tingui un caire tangible o no) que en un moment determinat ens interessa informatitzar perqu hem rebut un encrrec en aquest sentit. Mitjanant una srie de processos que impliquen, en primer lloc, lobservaci de la realitat i, a continuaci, un conjunt dabstraccions de les informacions considerades rellevants, es construeix un model que conceptualitza els aspectes de la realitat amb els quals volem treballar. Finalment, cal implementar alguna representaci informtica concreta dels conceptes abstrets durant la fase anterior, per tal de poder-hi treballar fent servir les tecnologies que ens ofereixen les bases de dades i, tamb, els seus sistemes gestors. Durant el nucli dactivitat Les BD: evoluci i models, coneixerem les diferncies que comporta treballar amb bases de dades en contraposici a treballar utilitzant altres mitjans, com ara els fitxers. Tamb es plantegen diferents models de bases de dades (jerrquic, en xarxa, relacional, orientat a objectes, etc.) que han tingut, tenen i tindran, ms o menys implantaci al llarg del temps, segons levoluci tant de les necessitats tcniques com dels mercats. Ja en el nucli dactivitat Els SGBD: objectius i arquitectura, abordarem el programari que gestiona i controla les bases de dades, s a dir, els sistemes gestors. Farem un reps dalgunes de les orientacions ms importants que han tingut, que tenen i que (potser) tindran, i dels objectius generals que persegueixen. I, finalment, ens introduirem en algunes nocions bsiques relatives a larquitectura dels SGBD.
Objectius
En acabar la unitat didctica, heu de ser capaos del segent: 1. Diferenciar entre l'esquema extern, l'esquema conceptual i l'esquema fsic, d'una base de dades (o BD). 2. Interpretar l'estructura d'un diccionari de dades, els aspectes que gestiona i la forma d'actualitzaci, segons les prestacions del sistema i/o llenguatge. 3. Deduir els avantatges operatius d'un sistema gestor de bases de dades (SGBD) respecte a un sistema gestor de fitxers. 4. Interpretar els objectius i les caracterstiques tcniques i funcionals dels models de SGBD, a partir de documentaci especfica. 5. Identificar l'arquitectura i l'estructura interna dels SGBD.
1. Les dades: conceptes introductoris
Les dades que sutilitzen de manera informatitzada semmagatzemen, habitualment, en bases de dades (BD). Per tal destar en condicions dabordar lestudi de les BD i del programari que serveix per gestionar-les, s a dir, els sistemes gestors de bases de dades (SGBD), s imprescindible entendre prviament uns quants conceptes terics fonamentals, referents a les dades i a la seva representaci. Aix, cal conixer tres mons diferents, per al mateix temps dependents entre ells, que sn determinants a lhora de treballar amb BD. Aquests tres mbits fan referncia als aspectes segents: La realitat. Les abstraccions que els informtics fem sobre la realitat. Les representacions informtiques de les abstraccions esmentades.
1.1. La interconnexi entre el mn real, el conceptual i el de les representacions

Per a tot informtic que hagi de treballar amb BD, s imprescindible saber distingir aquests tres mbits ben diferenciats, per que al mateix temps estan fortament interrelacionats, els quals fan referncia, respectivament, a la realitat, a la seva conceptualitzaci, i a la seva representaci informtica ulterior. Aix, doncs, considerem els tres mons segents: El mn real. Est constitut pels objectes (materials o no) de la realitat que ens interessen i amb els quals haurem de treballar. El mn conceptual. s el conjunt de coneixements o informacions obtinguts grcies a lobservaci de la part del mn real que ens interessa. Un mateix mn conceptual pot donar lloc a diferents mons conceptuals, en funci de la manera de percebre la realitat, o els interessos de lobservador daquesta. El mn de les representacions. Est format per les representacions informtiques, o dades, del mn conceptual, necessries per poder treballar.
En la figura 1 es representen, de manera esquematitzada, els tres mons que els informtics han de considerar, i les interrelacions que mantenen.
Figura 1. Els tres mons
1.1.1. El mn real i els objectes

Com a informtics, moltes vegades haurem de construir sistemes dinformaci (SI) per a les organitzacions o empreses que ens ho demanin. Aquests sistemes dinformaci hauran de fer referncia al mn real. Per, evidentment, noms hauran de tenir en compte la part del mn real que tingui a veure amb lactivitat prpia de lempresa o de lorganitzaci de qu es tracti en cada cas. Daltra banda, a lhora de construir un SI, una de les primeres tasques a fer consistir a establir-ne lesquema conceptual mitjanant una modelitzaci determinada.
Anomenem mn real la part concreta de la realitat que ens interessa modelitzar.
Exemple de mn real El mn real dun projecte dinformatitzaci dels prstecs que realitza una biblioteca, per exemple, estar format per una srie dobjectes relacionats amb lactivitat que es vol modelitzar. En aquest cas, probablement, ens interessar tenir en compte els llibres, les revistes, els CD i els DVD que siguin objecte de prstec. I, segurament, tamb haurem de tenir constncia dels socis de la biblioteca. En canvi, en aquest cas, s molt improbable que ens interessi reflectir el mobiliari de qu disposa la biblioteca, ja que, tot i estar format per objectes que hi pertanyen, no tenen relaci amb lactivitat que es vol modelitzar.
El mn real est compost per objectes concrets, els quals poden ser materials (una persona, un ordinador...) o immaterials (assegurances, crdits...). !
Cal advertir, per, que all que sentengui per mn real dependr, en certa manera, de les concepcions filosfiques de cadasc.
Des dun punt de vista purament objectivista, la realitat existeix independentment del fet de ser observada o no, per part dalg. Per tant, lnica cosa que cal per treballar correctament amb la realitat s descriure-la correctament. Entenent daquesta manera la realitat, el procs a seguir per descriure-la ha de ser, en certa manera, trivial.
Lobjectivisme s una actitud filosfica que concedeix primacia als objectes en les seves relacions amb els subjectes.
En canvi, des dun posicionament ms aviat constructivista, es pot fer la doble afirmaci segent:
La realitat existeix independentment del fet de ser observada o no, per part dalg, certament.
Per laprehensi daquesta realitat no es pot fer directament, de manera automtica, sin mitjanant la concepci personal daquesta que tingui cada observador.
Aprehendre, en filosofia, significa conixer alguna cosa sense afirmar ni negar res respecte a aquesta.
Des daquesta darrera perspectiva, doncs, la relaci entre una realitat i la seva conceptualitzaci s fonamentalment subjectiva. Tant s aix, que aquesta associaci pot ser objecte de discussi entre els diferents observadors duna mateixa realitat. I, a ms, qualsevol acord en aquest sentit shaur de modificar de tant en tant, en funci de com evolucioni la realitat o les diferents concepcions sobre aquesta que tinguin els diferents observadors.
1.1.2. El mn conceptual i la informaci
Lobservaci de la realitat possibilita lobtenci de coneixements. A partir dels objectes del mn real, i mitjanant uns processos danlisi i disseny, es pot extreure el que sanomena informaci.
La traducci dels objectes del mn real del nostre inters en informacions no s automtica, ja que consisteix en una srie de processos que formen part dall que es coneix com a disseny conceptual. !
10
La fase de disseny conceptual consisteix, fonamentalment, en el segent: Observaci. Per recopilar tota la informaci necessria de la part del mn real que ens proposem modelitzar. Anlisi, sntesi i abstracci. Per estructurar convenientment les informacions anteriors, de tal manera que siguin susceptibles de ser informatitzades. En la figura 2, es pot veure lentramat de processos que permeten elaborar les conceptualitzacions a partir del mn real.
Figura 2. Disseny conceptual: processos necessaris per obtenir informaci
Anomenem mn conceptual el conjunt dinformacions obtingudes mitjanant lobservaci del mn real. Aquestes informacions sn abstraccions de la realitat que, duna banda, ajuden els ssers humans a raonar, i de laltra, faciliten la comunicaci entre ells.
Exemple dobtenci dinformaci
Lobservaci dels prstecs bibliotecaris ens pot permetre adonar-nos de lexistncia de diferents tipus dobjectes, com ara els socis de la biblioteca i el material que es pot prestar. I tamb podrem deduir certes propietats comunes a cada tipus dobjecte. Per exemple, els CD de udio tindran un ttol, un autor, un any de producci i una discogrfica. A partir daqu estarem en condicions destructurar informacions concretes, com ara que llbum Kind of blue t com a autor principal el msic Miles Davis, que es va enregistrar lany 1959, i que Columbia el va llanar al mercat.
En realitat, les informacions sn coneixements estructurats entorn dun conjunt dobjectes del mn real. Poden ajudar a resoldre problemes i a prendre decisions. Per, a ms, estan en condicions de ser representades, la qual cosa s molt interessant des duna perspectiva informtica.
11
1.1.3. Les dades i la seva representaci

Un cop estructurats, els conceptes entorn de la realitat passen a ser veritables informacions, amb les quals els humans ens podem comunicar i comenar a treballar. Per encara cal donar un altre pas que ens permeti representar aquestes informacions, de tal manera que les puguem tractar informticament mitjanant BD i aplicacions, i aprofitem aix tot el potencial de les noves tecnologies.
Les dades sn representacions informtiques de la informaci disponible, relativa als objectes del mn real del nostre inters. El mn de les representacions est format per les dades informatitzades amb les quals treballem.
Ara b, la conversi de les concepcions en dades no s automtica, ni de molt. Requereix passar per dues fases successives de disseny, en qu es prenen decisions que poden derivar en resultats dispars. Aquestes dues fases de disseny sn les segents: 1) Fase de disseny lgic. Es treballa amb el model abstracte de dades obtingut al final de letapa de disseny conceptual, per tal de traduir-ho al model de dades utilitzat pel SGBD amb el qual es vol implementar i mantenir la futura BD. 2) Fase de disseny fsic. Es poden fer certes modificacions sobre lesquema lgic obtingut en la fase de disseny anterior, per tal dincrementar leficincia en algunes de les operacions que shagin de fer amb les dades. Per tant, cal ser conscients que, en un mateix conjunt de coneixements entorn duna mateixa realitat, aquests es poden representar de maneres diferents a causa, per exemple, dels factors segents: Les decisions de disseny preses (tant a nivell conceptual, com a nivell lgic i fsic). La tecnologia emprada (fitxers, BD relacionals, BD distribudes, etc.). La possibilitat que hi hagi aquestes diferncies no implica que tots els resultats es puguin considerar equivalents, sense ms ni ms, ja que, nor-
12
malment, les representacions diferents donen lloc a nivells deficincia tamb diferents. Aquest fet pot tenir conseqncies importants, ja que la responsabilitat de tot informtic inclou garantir la correcci de les representacions, per tamb leficincia de les implementacions.
1.1.4. La interpretaci de les dades

Perqu resultin tils, les dades shan de poder interpretar correctament. s a dir, se nha de poder extreure coneixement. Obtenir una srie de dades no serveix de res, si no sabem exactament a quins conceptes fan referncia. Per tant, hem de ser capaos dinterpretar correctament el significat de les representacions informtiques.
Exemple de dada no interpretable Normalment, obtenir una dada duna biblioteca, i prou, no aporta cap mena dinformaci. Aix, en una BD que gestioni els prstecs duna biblioteca, la dada 1984 pot representar el ttol duna novella, lany de publicaci duna altra, o lany de naixement dun soci, per exemple. Per la indefinici de la dada en qesti encara s ms gran, ja que no solament no se sap a quina propietat fa referncia, sin que tampoc no se sap ni a quin tipus dobjecte fa referncia (llibre, soci) ni, encara menys, a quin objecte concret del mn real pertany.
La interpretaci de les dades constitueix un procs invers al que se segueix per representar informticament les informacions. Per tant, podem definir les informacions com la interpretaci que es fa de les dades.
Una bona interpretaci de les dades noms est garantida si la representaci de les informacions compleix dos requisits: Que s'hagi elaborat correctament. Que estigui suficientment ben documentada.
1.2. El mn conceptual
El mn conceptual est format per coneixements sobre el mn real, convenientment estructurats, de tal manera que arriben a constituir informacions (les quals, com ja sabem, sn representables informticament). Les informacions en general, s a dir, no solament en l'mbit informtic, fan referncia a objectes i en descriuen propietats.
13
En informtica, i concretament en lmbit del mn conceptual, s freqent referir-se als objectes com a entitats, i a les seves propietats com a atributs, els quals adopten valors.
Exemple dinformaci La informaci referida a una pellcula (un objecte) en descriur algunes de les propietats (les que ens interessin), com ara el ttol, el director, lany de producci, etc.
1.2.1. Entitats, atributs i valors
Tres elements caracteritzen fonamentalment les informacions: 1) Les entitats sn els objectes del mn real que conceptualitzem. Sn identificables, s a dir, distingibles els uns dels altres. I ens interessen algunes (com a mnim una) de les seves propietats. 2) Els atributs sn les propietats de les entitats que ens interessen. 3) Els valors sn els continguts concrets dels atributs, les determinacions concretes que assoleixen.
En principi, els atributs haurien demmagatzemar un sol valor en cada instant. Daquesta manera, els nostres models seran, de bon principi, compatibles amb el model lgic de dades ms mpliament utilitzat: el model relacional.
Atributs multivaluats Permeten emmagatzemar ms dun valor simultniament. El seu s no s gaire recomanable perqu sn incompatibles amb el model relacional i amb la immensa majoria dels SGBD que hi ha en el mercat.
Exemple dentitat, atributs i valors Considerarem que una pellcula concreta s una entitat, perqu s un objecte del mn real, que hem conceptualitzat dins duna categoria (la dels films cinematogrfics), i que al mateix temps s distingible daltres entitats de la mateixa categoria (s a dir, daltres films). Daquesta pellcula ens interessaran alguns aspectes, que anomenarem atributs, com per exemple, el ttol, el director i lany de producci. Finalment, aquests atributs adoptaran uns valors concrets com ara, i respectivament, Paths of glory, Stanley Kubrick i 1957.
Si noms coneixem dos daquests tres elements, no disposarem duna veritable informaci, ja que es produir alguna de les mancances segents: Desconeixerem lentitat (lobjecte) a qu va associat latribut i el valor respectiu, i per tant no servir de gaire conixer els altres aspectes. Desconeixerem quin atribut (propietat) de lentitat adopta el valor obtingut, la qual cosa pot donar lloc a equvocs. Sabrem que lentitat t una certa propietat, per en desconeixerem el valor, i per tant aquest coneixement difcilment ens resultar til.
14
1.2.2. El factor cronolgic

Les entitats poden tenir un atribut o ms. Per, en tots els casos, cada atribut noms pot tenir un valor concret en un mateix instant. ! Evidentment, al llarg del temps, els valors dels atributs es poden modificar, com passa amb moltes de les propietats dels objectes del mn real.
Exemple de canvi del valor dun atribut en transcrrer el temps Considerem una entitat que faci referncia als escolars dun collegi, i que tingui un atribut, entre daltres, que serveixi per a tenir constncia de lalada de cadascun. El valor daquesta propietat anir canviant al llarg del temps, ja que, si tothom evoluciona com cal, els alumnes aniran augmentant destatura.
Si el sistema dinformaci no actualitza les dades quan cal, aquestes no es correspondran amb els valors presents en el mn real i, per tant, no serviran de gaire. Per si l'SI actualitza sense ms ni ms els valors dels atributs, es perdran les dades anteriors, encara que podria ser interessant conservar-les.
Exemples de prdua dinformaci per mal s del temps Si latribut que recull lalada no sactualitza peridicament, en poc temps no tindr gaire a veure amb la realitat, per la qual cosa resultar intil. En canvi, si sactualitza sense conservar els valors anteriors es perdr informaci, i mai no podrem fer, per exemple, un seguiment de levoluci de lalada dels alumnes.
Daltra banda, sovint, una dada no est prou ben caracteritzada si no en consta el moment de l'actualitzaci.
Exemple dindefinici de la informaci en no tenir en compte el temps El valor de latribut que emmagatzema lalada no proporcionar gaire informaci si no sabem a quin moment correspon: al dia en qu lescolar es va matricular?, a la data en qu se li va fer lltima revisi mdica?, i, en tot cas, quan es van produir aquests esdeveniments?
A ms dels tres elements bsics que caracteritzen la informaci (s a dir, entitats, atributs i valors), cal tenir en compte el factor cronolgic.
Fins i tot, en alguns casos, pot ser necessari tenir constncia de ms duna data referent a lactualitzaci de la dada, per reflectir, per exemple, el moment del canvi en el mn real i el moment del canvi en la BD.
Exemple de la necessitat de tenir en compte el temps Pensem, per exemple, en un alumne que tradueix el seu nom al catal durant els seus estudis. Aquest alumne es va matricula amb un nom, per en el ttol que se li haur dexpedir en acabar els estudis n'hi haur dhaver un altre. Seria molt interessant que el sistema fos capa demmagatzemar tant el nom originari com el tradut, a ms de la data oficial del canvi (a l'efecte de dexpedici de ttols) i, fins i tot, la data de canvi dins del propi sistema (per associar degudament les notes obtingudes en cada moment per aquesta persona).
15
Cal remarcar que, actualment, els SGBD no ofereixen gaires facilitats per afegir, de manera automtica, informaci sobre el temps com un element addicional que contribueix poderosament a caracteritzar la informaci. Tot i que es continua treballant en la lnia que acabem dapuntar, ara per ara la responsabilitat principal en la consideraci del temps com a factor de caracteritzaci de la informaci recau, gaireb de manera exclusiva, en els dissenyadors de BD.
1.2.3. Entitats tipus i entitats instncia

El terme entitat fa referncia a algun objecte concret del mn real, conceptualitzat, i del qual ens interessen algunes caracterstiques. Per aquest terme pot tenir dos significats diferents, segons a qu faci referncia. Per tal de distingir-los, es pot afegir un adjectiu al substantiu esmentat i obtenir, aix, els dos sintagmes segents: Entitat tipus. Es tracta dun tipus genric dentitat o, si es prefereix, duna abstracci, que fa referncia a una classe de coses com, per exemple, els cotxes, en general. Entitat instncia. Es refereix a la conceptualitzaci dun objecte concret del mn real, com ara un cotxe concret, distingible dels altres objectes del mateix tipus, grcies a alguna propietat (com podria ser el valor de latribut Matricula).
En terminologia de teoria de conjunts, podrem dir que una entitat tipus s un conjunt, i que cada entitat instncia s un element del conjunt, tal com es reflecteix en la figura 3.
Figura 3. Entitat tipus i entitat instncia
1.2.4. Tipus de dada i domini dels atributs
Anomenem domini tot el conjunt de valors que un atribut determinat pot prendre vlidament.
Aquest concepte no es correspon amb el de tipus de dada, utilitzat tant en lmbit de les BD com tamb en el de programaci.
Un tipus de dada defineix un conjunt de valors amb unes caracterstiques comunes que els fan compatibles, per la qual cosa tamb defineix una srie doperacions admissibles sobre aquests valors.
16
Exemple de tipus de dada Podem considerar els nombres enters com un tipus de dada (diferent daltres tipus, com per exemple els nombres reals, els carcters, etc.), sobre el qual es poden definir certes operacions, com la suma, la resta, la multiplicaci o la divisi entera (per no la divisi exacta, que noms s possible entre els nombres reals).
Aix, doncs, ambds conceptes (domini i tipus de dada) sassemblen, ja que tots dos limiten els valors acceptables. All que els diferencia s que un domini no estableix per si mateix cap conjunt doperacions, mentre que un tipus de dada, per definici, si que ho fa. Una altra diferncia s que, en la prctica, un domini s un subconjunt de valors possibles dun tipus de dada. En alguns casos, pot interessar delimitar el rang de valors admesos per un tipus de dada determinat. Aix es fa establint un domini.
Exemple de domini Imaginem que, en lmbit duns estudis determinats, sexigeix un mnim dassistncia a classes presencials per tal daconseguir el ttol corresponent, independentment de les qualificacions obtingudes. Imaginem que sadmet, durant tot el curs acadmic, un mxim de vint faltes injustificades. Doncs b, hi podria haver un atribut de lentitat ALUMNE, anomenat, per exemple, NombreFaltes, que recolls aquesta circumstncia. Aquest atribut podria emmagatzemar dades de tipus enter. I tamb se'n podria limitar el domini de 0 (per indicar que no hi ha hagut cap inassistncia) a vint faltes injustificades, ja que en arribar a aquest lmit es produiria lexpulsi de lalumne.
1.2.5. Valor nul dels atributs

De vegades, el valor dun atribut s desconegut o, fins i tot, no existeix. Per representar aquesta circumstncia, latribut en qesti haur dadmetre el valor nul.
Lexpressi valor nul indica que no hi ha cap valor associat a un atribut determinat duna entitat instncia concreta.
Perqu un atribut admeti el valor nul, sha despecificar aquesta possibilitat a lhora de definir-ne el domini.
Exemple de valor nul Considerem ara que lentitat ALUMNE disposa dun atribut anomenat Telefon, per emmagatzemar un nmero telefnic de contacte de cadascuna de les persones matriculades. Si latribut Telefon no admets valors nuls, el sistema no permetria que es matriculessin persones que no disposessin de telfon. En canvi, si sha adms aquesta possibilitat en definir el domini de latribut que ara ens ocupa, el sistema acceptar la matrcula de les persones que no disposin de telfon, o b de les que senzillament no sel saben de memria i que, per tant, no el poden indicar en el moment de formalitzar la matrcula, de manera que la seva incorporaci en la BD queda pendent.
17
No sha de confondre valor nul amb el zero, si estem tractant amb valors numrics, o amb lespai en blanc, si estem treballant amb carcters. Tant lun com laltre sn valors amb un significat propi. En canvi, el valor nul implica l'absncia total de valor. !
1.2.6. Atributs identificadors i claus
Un atribut identificador s el que permet distingir inequvocament cada entitat instncia de la resta, pel fet que el seu valor s nic, i no es repeteix en diferents entitats instncia.
Els atributs duna entitat seran identificadors, o no, en funci de lobjecte del mn real que l'entitat vulgui modelitzar.
Exemple datribut identificador Latribut DNI pot servir molt b per identificar les instncies duna entitat que modelitzi els alumnes dun centre docent, ja que cada alumne tindr un DNI diferent. Per si lentitat amb qu treballem vol modelitzar les qualificacions finals dels alumnes, el DNI per si sol no permetr identificar les diferents entitats instncia, ja que a cada alumne correspondr una nota final per a cada assignatura en la qual shagi matriculat.
De vegades, un sol atribut no s suficient per identificar inequvocament les diferents instncies duna entitat. Aleshores, cal recrrer a la combinaci dels valors de dos o ms atributs de la mateixa entitat.
Tot atribut o conjunt datributs que permeten identificar inequvocament les instncies duna entitat sanomenen claus.
Tot atribut identificador s, al mateix temps, una clau. Per els atributs que formen part dun conjunt de ms dun atribut que actua com a clau de lentitat no sn identificadors, ja que, per si mateixos, no sn capaos didentificar les entitats instncia. !
Exemple de clau formada per ms dun atribut Per tal de diferenciar les instncies duna entitat que vol reflectir les notes finals dels alumnes en cada assignatura en qu s'hagin matriculat, cal combinar els valors de dos atributs: un que designi lalumne de qu es tracti (tpicament, el DNI), i un altre que indiqui lassignatura a la qual correspon la nota (que podria ser una cosa com ara CodiAssignatura). Aix s aix perqu un alumne podr estar matriculat en diferents assignatures, per la qual cosa el seu DNI es repetir en diferents instncies. I, al mateix temps, diversos dalumnes podran estar matriculats duna mateixa assignatura i, per tant, els valors de latribut CodiAssignatura tamb es podran repetir. En canvi, cada alumne tindr una instncia per a cada assignatura en qu s'hagi matriculat, fins que laprovi, per tal de reflectir la nota final. Modelitzada lentitat daquesta manera, la combinaci de valors de DNI i CodiAssignatura no es repetir mai, i el conjunt format per aquests dos atributs podr servir com a clau.
18
Per definici, ni els atributs identificadors ni els que formen part duna clau poden admetre mai el valor nul, perqu aleshores no servirien per distingir les entitats instncia sense valor en un dels tipus datribut esmentat de la resta. !
1.3. El mn de les representacions

Ja sabem que les dades sn informacions representades informticament. Per tant, tamb podrem anomenar mn de les dades el mn de les representacions. La representaci informtica ms freqent en lmbit de les BD s la representaci tabular, la qual simplementa habitualment en fitxers que sestructuren en registres i camps. En el fons, les BD noms sn conjunts de fitxers interrelacionats (o, si es prefereix, que emmagatzemen dades que estan interrelacionades). Per no serveix de res emmagatzemar dades si, posteriorment, no hi accedim. Hi ha diferents tipus daccs a les dades que conv examinar: seqencial, directe, per valor i per posici.
1.3.1. Les representacions tabulars i la seva implementaci: els fitxers

Les informacions sn conceptualitzacions obtingudes a partir de lobservaci del mn real. Ara b, les informacions no sn gaire cmodes per treballar. En la figura 4 podem veure una representaci grfica, no informatitzada, de lentitat COTXES, que consta de dos atributs: Matrcula i Marca. Evidentment, si augments el nombre dentitats instncia, o b el nombre datributs a considerar, aquest tipus de representaci no serviria per a res.
Figura 4. Exemple de representaci no informatitzada
19
s necessari representar les informacions per facilitar les tasques a fer amb elles, com ara les consultes, els processaments, les transmissions, etc.
La representaci ms freqent en lmbit informtic de les BD s lanomenada representaci tabular (o, el que s el mateix, en forma de taula).
Cada taula representa una entitat genrica, i est estructurada en files (agrupacions horitzontals de celles) i columnes (agrupacions verticals de celles): ! Cada fila representa una entitat instncia. Cada columna representa un atribut. Cada cella (s a dir, cada intersecci duna fila i duna columna) emmagatzema el valor que tingui l'atribut de l'entitat instncia de qu es tracti.
La implementaci informtica de les representacions tabulars es materialitza mitjanant els anomenats fitxers de dades. Sentn per
Fitxer El terme fitxer t altres accepcions, com ara en lmbit dels sistemes operatius, que no tenen gaire a veure amb el concepte que hem exposat aqu.
fitxer la implementaci informtica duna taula, amb les dades estructurades en registres i camps.
Els fitxers simplementen seguin aquestes consideracions: La implementaci de cada entitat instncia sanomena registre, i equival a una fila de la representaci tabular. La implementaci de cada atribut sanomena camp, i equival a una columna de la representaci tabular. Cada intersecci dun registre i dun camp emmagatzema el valor que tingui el camp del registre de qu es tracti. Els fitxers s'han d'emmagatzemar en algun dispositiu de memria externa de lordinador, tpicament un disc dur, per tal de conservar les dades permanentment. Lemmagatzemament en la memria interna no satisf aquest objectiu perqu s voltil. En la taula 1, podem veure una representaci tabular de lentitat COTXES, que noms consta de dos camps: Matrcula i Marca. Si augments el nombre de registres a emmagatzemar noms caldria afegir ms files. I si hagussim de considerar ms camps, noms caldria afegir ms columnes.
20
Per en cap cas no es comprometria la complexitat de lestructura tabular, que seria, essencialment, la mateixa.
Taula 1. Exemple de representaci tabular Cotxes Matrcula QWE1234 ASD0987 ZXC5678 MNB5432 Marca Citron Ford Citron Renault
1.3.2. Les BD
Normalment, quan hgim de representar informticament certes informacions (corresponents, doncs, al mn conceptual), no ens trobarem amb una sola entitat tipus, sin amb unes quantes. Intutivament, podem pressuposar que si partim dun nombre concret dentitats tipus necessitarem, com a mnim, el mateix nombre de taules per representar-les (i probablement algunes ms). Ara b, aquestes taules, o fitxers, no seran objectes inconnexos, sin que hauran destar interrelacionats.
Les interrelacions sn informacions que permeten associar les entitats entre elles.
Les interrelacions entre els registres de dues (o ms) taules es fan mitjanant camps del mateix tipus de dada que emmagatzemin els mateixos valors.
Exemple dentitats interrelacionades Imaginem ara que construm una petita BD. Noms hi ha dues entitats tipus del nostre inters: COTXES i MARQUES. Tamb tenim una altra informaci complementria, sobre la interrelaci entre ambdues entitats: cada cotxe ser duna marca concreta, per hi podr haver molts cotxes de cada marca. En la figura 5, es mostra una representaci de les dues entitats (COTXES i MARQUES) interrelacionades. Lentitat MARQUES noms t latribut Marca, i lentitat COTXES noms t latribut Matrcula. El fitxer per representar COTXES haur dafegir un camp addicional, per tal de permetre la interrelaci amb el fitxer que representa lentitat MARQUES. La figura 6 mostra la interrelaci entre els dos fitxers corresponents a lentitat COTXES i a lentitat MARQUES.
21
Figura 5. Exemple dentitats interrelacionades
Figura 6. Exemple de fitxers interrelacionats
La interrelaci entre fitxers implica que els canvis de valor dels camps que serveixen per interrelacionar-los (o, fins i tot, la seva supressi) han de quedar reflectits en tots els fitxers implicats, per tal de mantenir la coherncia de les dades. Per tant, els programes que treballen amb fitxers de dades interrelacionats sempre tindran un plus de complexitat, derivat de lexigncia que acabem de comentar.
Una BD consisteix en un conjunt de fitxers de dades interrelacionats.
En aquest sentit, els SGBD shan anat desenvolupant tenint com a un dels objectius principals facilitar la programaci amb accs a dades persistents, i per gestionar laccs simultani a les dades per part de diferents usuaris.
Un sistema gestor de bases de dades (SGBD) s un tipus de programari especialitzat en gestionar i administrar bases de dades.
1.3.3. Laccs a les dades: tipologies

No serveix de res estructurar dades i emmagatzemar-les si desprs no s'hi pot daccedir, per consultar-les, modificar-les o transmetre-les. En general, hi ha dues maneres bsiques daccedir a les dades: Laccs seqencial a un registre determinat, que implica laccs previ a tots els registres anteriors. Laccs directe a un registre concret, que implica lobtenci directa del registre.
22
A ms, hi ha una altra classificaci habitual de tipologies daccessos: ! Laccs per valor, que permet obtenir el registre en funci del valor dalgun (o alguns) dels seus camps, sense considerar la posici que ocupa el registre. Laccs per posici, que obre laccs a un registre que ocupa una posici determinada, sense considerar el contingut del registre. Combinant les dues dicotomies anteriors, resulten quatre mtodes daccs a les dades, tal com es mostra en la taula 2, que sajusten ms a la realitat.
Taula 2. Mtodes daccs a les dades P per posici S seqencial D directe SP DP V per valor SV DV
Examinem, doncs, les quatre tipologies daccs a dades ms freqents: SP (accs seqencial per posici). Desprs dhaver accedit a un registre que es troba en una posici determinada, saccedeix al registre que ocupa la posici immediatament posterior. DP (accs directe per posici). Sobt directament un registre pel fet docupar una posici determinada. SV (accs seqencial per valor). Desprs dhaver accedit a un registre que t un valor concret, saccedeix al registre que ocupa la posici immediatament posterior, segons lordenaci establerta a partir d'un camp determinat (o ms). Lordre ser creixent o decreixent, si es tracta dun camp numric, o alfabtic ascendent o descendent, si es tracta dun camp de carcters. DV (accs directe per valor). Sobt directament un registre pel fet de tenir un valor determinat en un dels seus atributs (o ms).
Exemples de tipus daccs a les dades Imaginem que disposem un fitxer en qu semmagatzema informaci relativa als alumnes dun centre docent: DNI, nom, cognoms, data de naixement, adrea, telfon, etc. A continuaci, es dna un exemple de cadascun del quatre mtodes daccs estudiats. SP (accs seqencial per posici): la llista de tots els alumnes, sense establir cap ordenaci. DP (accs directe per posici): en lmbit de la programaci, el cas ms tpic s el de les cerques dicotmiques en vectors ordenats; en lmbit de les BD, aquest tipus daccs es produeix en utilitzar un ndex de tipus hashing.
23
SV (accs seqencial per valor): la llista de tots els alumnes, seguint un ordre alfabtic ascendent, en primer lloc dels cognoms i desprs del nom. DV (accs directe per valor): obtenci de les dades emmagatzemades en un registre corresponent a un alumne concret, que es digui, per exemple, Pere Garca Manent (s a dir, que el camp Nom cont el valor Pere, i el camp Cognoms cont el valor Garca Manent).
1.3.4. El nivell lgic i el nivell fsic

Lorganitzaci de les dades, i el seu enregistrament i accs, es poden considerar des de dos punts de vista, ms o menys propers a la implementaci fsica de lenregistrament de les dades: Nivell lgic. Permet treballar amb les dades de manera ms senzilla, independentment de la implementaci fsica concreta, que no cal conixer. s la manera de treballar ms productiva i, per tant, la ms recomanable, sempre que les circumstncies no ens obliguin a fer optimitzacions a nivells ms baixos. Nivell fsic. Implica un coneixement a baix nivell de la implementaci fsica de lorganitzaci de les dades i el seu accs. En la figura 7, es mostra la doble perspectiva apuntada, la lgica i la fsica. En el disc dur es desen les dades, organitzades de determinada manera a nivell fsic. L'SGBD ens permet accedir a les dades emmagatzemades en el disc dur considerant noms aspectes de nivell lgic, com ara seqncies de registres.
Figura 7. Nivell lgic i nivell fsic
Exemples de treball a nivell lgic i a nivell fsic Nivell lgic: es treballa tenint en compte, fonamentalment, les taules, amb els camps i registres corresponents, i les seves interrelacions. Nivell fsic: es treballa considerant altres factors a ms baix nivell, com ara lencadenament dels registres fsics, la compressi de dades, les tipologies dndexs, etc.
24
2. Les BD: evoluci i models
Les BD sn conjunts estructurats de dades organitzades en entitats, les quals estan interrelacionades. s important conixer el concepte de BD i el seu origen. Tamb s interessant establir una comparativa davantatges i dinconvenients segons si sutilitzen fitxers tradicionals o BD. Hi ha diferents perspectives des de les quals es pot observar una BD, i diferents tasques i mtodes de treball sobre una BD, que tot informtic ha de conixer. En el mercat hi ha diferents models de BD: el jerrquic, en xarxa, relacional i orientat a objectes.
2.1. Concepte i origen de les BD

Les BD no existeixen per casualitat. Van aparixer per donar resposta a una srie de necessitats. La millor manera dentendre tant aquestes circumstncies com el concepte de BD que van originar s fer una petita aproximaci histrica a la seva evoluci. Les aplicacions informtiques dels anys seixanta del segle XX tenien, per regla general, les caracterstiques segents: Normalment, consistien en processos per lots (en angls, batch processing), amb les particularitats segents: Un lot s un conjunt finit de feines que es volen tractar com un tot. El seu processament, una vegada engegat, no necessita cap interacci amb lusuari. Normalment, aquest tipus dexecuci es realitza en tasques repetitives sobre gran volums dinformaci. Realitzaven tasques molt especfiques, relacionades amb molt poques entitats tipus, com per exemple lemissi de factures, la confecci de nmines de personal, etc. Normalment, els programes treballaven de manera seqencial sobre un sol fitxer mestre, que estava emmagatzemat en una cinta magntica (encara no, en un disc dur), i generaven un altre fitxer com a resultat.
25
Quan es detectava la necessitat dimplementar una nova aplicaci que utilitzs parcialment les dades contingudes en un fitxer i, a ms, algunes altres de noves, es dissenyava un nou fitxer amb tots els camps necessaris, i somplia amb les dades corresponents: Les dades que ja eren en lantic fitxer es podien copiar en el nou, justament, mitjanant un altre processament per lots (batch). Daquesta manera saconseguia que el nou programa no hagus de treballar amb molts fitxers, la qual cosa en simplificava el codi, duna banda, i duna altra n'optimitzava el temps dexecuci. Com a contrapartida, aquesta manera de treballar comportava la redundncia dalgunes dades, que eren repetides en diferents fitxers. Aquest fet dificultava el manteniment de la coherncia daquestes dades. Posteriorment, levoluci tecnolgica va fer possible la implantaci progressiva de tres nous elements: Els terminals. Dispositius de maquinari per introduir o mostrar dades de les computadores. Els discos durs. Dispositius demmagatzemament dalt rendiment, que no estaven limitats de facto a laccs seqencial. Les xarxes de comunicaci. A partir daquestes innovacions, els programes informtics van haver dimplementar la possibilitat de realitzar consultes i actualitzacions de les mateixes dades, simultniament, per part de diferents usuaris. ! Al mateix temps, es va anar produint un fenomen que consistia en la integraci de les diferents aplicacions informtiques que utilitzava cada organitzaci (per exemple, gestions destocs, facturacions, provedors...). Aquesta tendncia requeria les accions segents: Interrelacionar els fitxers de les antigues aplicacions. Eliminar la redundncia, s a dir, la repetici innecessria de dades, que a ms de resultar ineficient posa en risc la seva coherncia. Tant la interrelaci dels fitxers com el fet que cada vegada hi accedien simultniament ms usuaris exigien unes estructures fsiques que proporcionessin accessos raonablement rpids, com ara ndexs. Al comenament dels anys setanta, aquests conjunts de fitxers interrelacionats, compartits per diferents processos i usuaris simultniament, i amb estructures complexes, van rebre inicialment el nom de data bases, o DB (bases de dades, o BD, en catal).
26
I al final dels anys setanta van anar sortint al mercat programaris encara ms sofisticats, que permetien gestionar ms fcilment les relacions entre fitxers, i ja estaven en condicions de garantir l'actualitzaci simultnia de dades per part de diferents usuaris, etc. Aquests programaris es van anomenar sistemes gestors de bases de dades, o SGBD (data base management systems, o DBMS, en angls). ! Amb aquesta perspectiva histrica, doncs, podem donar una definici de BD ms completa.
Una BD s la representaci informtica dels conjunts dentitats instncia corresponents a diferents entitats tipus i de les relacions entre aquestes. Aquest conjunt estructurat de dades ha de poder ser utilitzat de manera compartida i simultnia per una pluralitat dusuaris de diferents tipus.
2.2. Fitxers i BD
Els fitxers tradicionals (i els programes necessaris per treballar-hi) shan trobat amb serioses dificultats per satisfer les creixents necessitats dels usuaris en prcticament tots els mbits. Per aquesta ra, les BD shan anat implantant com a mecanisme per excellncia demmagatzematge, processament i obtenci dinformaci, tot desplaant progressivament els fitxers de la seva posici preeminent anterior. La taula 3 cont una breu descripci de les principals diferncies entre els sistemes basats en fitxers tradicionals i les BD.
Taula 3. Fitxers i BD Fitxers Les entitats instncia dun fitxer pertanyen a una sola entitat tipus. El sistema no interrelaciona fitxers. s necessari crear fitxers a mida de cada aplicaci, amb totes les dades necessries, encara que estiguin repetides en altres fitxers. s possible que els valors dunes mateixes dades en diferents fitxers no coincideixin, si els programadors no les han actualitzat degudament. Bases de dades Les BD contenen entitats instncia dinfinitat dentitats tipus interrelacionades. El sistema t previstes eines per interrelacionar fitxers. Tcnicament, totes les aplicacions poden treballar amb la mateixa BD, la qual cosa evita la redundncia de dades i els riscos que comporta. Si les interrelacions estan ben dissenyades, les dades noms han destar emmagatzemades en la BD un sol cop. Per tant, no hi ha risc dinconsistncies.
Entitats tipus
Interrelacions
Redundncies
Inconsistncies
27
Fitxers Si no hi ha una aplicaci que obtingui les dades que volem, o b sha de fer un programa a mida, o b sha daprofitar la sortida dun programa amb objectius similars, i fer els clculs necessaris manualment. Les dades estan disperses i allades en diferents arxius, la qual cosa dificulta el desenvolupament de les aplicacions. Els programes han dimplementar totes les restriccions sobre les dades, afegint el codi font corresponent. El manteniment s complicat quan la informaci es cont en diferents fitxers utilitzats per diferents aplicacions. Alguns conjunts doperacions sobre les dades s'han d'executar de manera indivisible (o tots o cap), independentment de les fallades que el sistema pugui presentar (com ara per un tall de subministrament elctric). Per aix s molt difcil de garantir amb un sistema dinformaci basat en fitxers. Lactualitzaci simultnia de dades dun mateix fitxer per part de diferents usuaris o aplicacions en pot provocar fcilment la inconsistncia.
Bases de dades Permeten obtenir qualsevol conjunt de dades, segons les necessitats, dels del seu propi entorn de treball, sense haver descriure, compilar i executar cap nou programa daplicaci contra la BD. Totes les dades sn en la mateixa BD, interconnectades, la qual cosa en facilita l'obtenci. La BD sencarrega directament dimplementar les restriccions sobre les dades. Els programes no han dincorporar codi font addicional per garantir-les.
Obtenci de dades
Allament de dades
Integritat de dades
Les BD incorporen la tcnica de les transaccions per tal de garantir fcilment lexecuci atmica duna pluralitat de processos sobre les dades.
Atomicitat
Accs concurrent
Amb la tcnica del bloqueig, les BD garanteixen automticament la consistncia de les dades, malgrat que ms dun usuari o ms duna aplicaci les vulguin actualitzar simultniament. Una BD pot ser compartida per molts usuaris de diferents tipus (fins i tot, simultniament), els quals poden tenir diferents visions (vistes) del mn real, en funci del seu perfil i dels permisos que shagin de concedir en cada cas.
Seguretat
Habitualment, cada fitxer serveix per a un sol usuari o una sola aplicaci (sobretot simultniament), i ofereix una visi nica del mn real. Per no sempre tots els usuaris que utilitzen un fitxer haurien de tenir accs a totes les dades que cont.
Evidentment, les prestacions de les BD sn molt superiors a les que proporcionen els sistemes de fitxers. Per aix no vol dir que en alguns casos no sigui millor utilitzar fitxers, com ara quan el volum de les dades a contenir s molt petit, o quan noms hem de treballar amb una entitat instncia i, per tant, no cal considerar interrelacions. Algunes utilitzacions possibles dels fitxers en lactualitat sn les segents: Fitxers de configuraci daplicacions. Fitxers de configuraci de sistemes. Fitxers de registres d'esdeveniments (logs).
28
En casos com aquests, no compensaria carregar innecessriament el sistema amb una BD (i amb el sistema gestor corresponent), ja que no saprofitarien els avantatges de les BD per, en canvi, empitjoraria el rendiment del sistema.
2.3. Les diferents visions de les dades

Un dels principals objectius de les BD s proporcionar, als usuaris, una visi abstracta de les dades. Amb aquesta finalitat, el sistema amaga als usuaris certs detalls relatius a lemmagatzemament i manteniment de les dades, per facilitar-los la feina, duna banda, per tamb per garantir certs aspectes en matria de seguretat. Perqu les BD resultin tils, han de ser mnimament eficients a lhora de recuperar les dades. Per aquest motiu, els sistemes de BD tenen implementades, a baix nivell, estructures de dades bastant complexes.
Sutilitzen tres nivells dabstracci fsic, lgic i de vistes per tal damagar aquestes estructures complexes i simplificar, daquesta manera, la interacci dels usuaris amb el sistema.
1) Nivell fsic: s el nivell dabstracci ms baix de tots els utilitzats. Descriu com semmagatzemen realment les dades a baix nivell, especificant en detall les complexes estructures que es necessiten. No s freqent treballar a aquest nivell. Noms es fa quan calen optimitzacions en l'estructuraci de les dades a baix nivell. 2) Nivell lgic: s el nivell dabstracci intermedi. Descriu totes les dades emmagatzemades en la BD i les seves interrelacions, mitjanant un nombre no gaire elevat destructures fora simples (tpicament, taules). La implementaci daquestes estructures lgiques pot comportar la presncia destructures molt ms complexes a nivell fsic. Per els usuaris del nivell lgic no s'han de preocupar daquesta complexitat. Ni tan sols necessiten conixer-la. Els administradors de BD treballen habitualment amb aquest nivell dabstracci.
29
3) Nivell de vistes: s el nivell dabstracci ms alt. La majoria dels usuaris no necessiten conixer tota lestructuraci lgica de la BD amb qu treballen. Tractant-se duna BD gran, a ms, conixer tota la seva estructura pot comportar un esfor considerable. Daltra banda, sovint, i per motius tant de seguretat com de privacitat, no resulta convenient que els usuaris tinguin accs a totes les dades, sin solament a la part que estrictament necessiten per realitzar la seva feina. Cada vista noms descriu una part de la BD. Lestabliment de vistes simplifica la interacci de lusuari amb el sistema, el fa ms segur, i proporciona ms privacitat. Es poden establir diferents vistes, segons les necessitats, sobre la mateixa BD. En la figura 8, es poden veure els diferents nivells dabstracci utilitzats per facilitar la interacci dels usuaris amb les BD.
Figura 8. Nivells dabstracci de dades
2.4. Models de BD
Les BD representen informticament la part del mn real del nostre inters, que prviament hem conceptualitzat, mitjanant uns processos dobservaci i dabstracci. Per tant, podem afirmar que les BD sn models de la realitat. Per no hem de confondre aquesta caracterstica de les BD amb el que sentn per model de dades (o model de base de dades). Lestructura concreta de cada
30
BD est construda a partir del model de dades respectiu, triat pel dissenyador en funci de les necessitats i de les eines disponibles.
Els models de dades sn uns conjunts deines lgiques per descriure les dades, les seves interrelacions, el seu significat i les restriccions a aplicar per tal de garantir-ne la coherncia.
Tots els models de BD, en general, proporcionen tres tipus deines: Estructures de dades. Elements amb els quals es construeixen les BD, com ara taules, arbres, etc. Regles dintegritat. Restriccions que les dades hauran de respectar, com per exemple tipus de dada, dominis, claus, etc. Operacions a realitzar amb les dades. Altes, baixes, modificacions i consultes, com a mnim.
Els models de dades ms utilitzats al llarg del temps han estat els segents, exposats en ordre daparici: 1) Jerrquic 2) En xarxa 3) Relacional 4) Relacional amb objectes / orientat a objectes
2.4.1. Model jerrquic

Les BD jerrquiques es van concebre al principi del anys seixanta, i encara sutilitzen grcies al bon rendiment i la millor estabilitat que proporcionen amb grans volums dinformaci.
Les BD jerrquiques emmagatzemen la informaci en una estructura jerrquica que podem imaginar amb una forma darbre invertit, on cada node pare pot tenir diferents fills. El node superior, que no t pare, es coneix com a arrel. I els nodes que no tenen fills sanomenen fulles.
31
Les dades semmagatzemen 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 jerrquiques no ofereixen una perspectiva lgica per sobre de la fsica. Les relacions entre les dades sestableixen sempre a nivell fsic, mitjanant adreaments fsics al mitj demmagatzemament utilitzat (s a dir, indicant sectors i pistes, en el cas ms habitual dels discos durs). Aix, doncs, les interrelacions sestableixen mitjanant punters entre registres. Qualsevol registre cont ladrea fsica del seu registre pare en el mitj demmagatzemament utilitzat. Aquesta circumstncia proporciona un rendiment molt bo: laccs des dun registre a un altre s prcticament immediat. Per, si b el model jerrquic 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 seqencial de tots els registres de la BD. Altres limitacions daquest model consisteixen en la seva incapacitat per evitar la redundncia (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 9 mostra lestructura de nodes interrelacionats duna BD jerrquica.
Figura 9. Estructura duna BD jerrquica
Dos dels gestors de BD jerrquiques que tenen ms implantaci sn els segents:
32
IMS (information management system), de la multinacional nordamericana IBM. Adabas (adaptable database system), de lempresa alemanya Software AG.
2.4.2. Model en xarxa
Al comenament del anys setanta, en el mercat, van anar sorgint BD que seguien un model en xarxa, semblant al model jerrquic, amb registres interrelacionats mitjanant una estructura en forma darbre invertit, per ms flexible, ja que permetia que els nodes tinguessin ms dun sol pare.
La figura 10 mostra lestructura de nodes interrelacionats duna BD en xarxa.

Figura 10. Estructura duna BD en xarxa
El model en xarxa va comportar una millora respecte al model jerrquic, perqu permetia controlar de manera ms eficient el problema de la redundncia 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 ladministraci de les BD que ladopten. El consorci de la indstria de les tecnologies de la informaci CODASYL (acrnim de Conference on Data Systems Languages) va proposar un estndard que van seguir la majoria de fabricants. Un dels gestors de BD en xarxa ms coneguts, i que segueix lestndard CODASYL, s lIDMS (integrated database management system), de Computer Associates.
33
2.4.3. Model relacional

Model relacional Va ser proposat formalment per E. F. Codd, lany 1970, en el seu treball A Relational Model of Data for Large Shared Data Banks (Un model relacional de dades per a grans bancs de dades compartides).
El model relacional es basa en la lgica de predicats i en la teoria de conjunts. Actualment, s el sistema ms mpliament utilitzat per modelitzar dades.
A partir dels anys vuitanta, es van comenar a comercialitzar gran quantitat de BD que aplicaven aquest model. Les dades sestructuren en representacions tabulars, anomenades taules, que representen entitats tipus del mn conceptual, i que estan formades per files i columnes. Les columnes formen els camps, que implementen els atributs, s a dir, les caracterstiques que ens interessen de les entitats. I les files sn els registres, que implementen les entitats instncia, constitudes pels conjunts dels valors que presenten els camps corresponents a cada instncia. !
En els models de dades jerrquic i en xarxa les dades sestructuraven grcies a dos elements: els registres i les interrelacions. Per el model relacional noms consta dun element: les relacions o taules.
La figura 11 mostra lestructura de taules corresponent a una BD relacional.

Figura 11. Estructura duna BD relacional
Les interrelacions s'han d'implementar utilitzant les taules: quan s necessari s'han d'afegir, a les taules, un o ms camps que actun com a clau forana i que, per tant, apuntin al camp o camps referenciats duna altra taula, els quals han de formar la seva clau primria. En coincidir els valors dels camps de la clau primria i de la clau forana, sestableix la interrelaci entre els registres. ! El model relacional comporta certs avantatges respecte al model jerrquic i al model en xarxa: Proporciona eines per evitar la duplicitat de registres, mitjanant claus primries i foranes que permeten interrelacionar les taules.
34
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 hgim seguit en administrar la BD. En no tenir importncia la ubicaci fsica de les dades, afavoreix la comprensibilitat. De fet, el model relacional, com a tal, es limita al nivell lgic, i deixa de banda el nivell fsic. Per aquest motiu, es diu que el model relacional possibilita la independncia fsica de les dades.
2.4.4. El paradigma de lorientaci a objectes
El model de dades relacionals amb objectes s una extensi del model relacional en sentit estricte.
Aquest nou model admet la possibilitat que els tipus de dades siguin, a ms dels tradicionals, tipus abstractes de dades (TAD). Amb aquesta particularitat, sacosten els sistemes de BD relacionals al paradigma de la programaci orientada a objectes. Els models estrictament orientats a objectes defineixen les BD en termes dobjectes, de les seves propietats i, el que s ms innovador, de les seves operacions. Els objectes amb una mateixa estructura i comportament pertanyen a una classe, i les classes sorganitzen en jerarquies. Les operacions de cada classe sespecifiquen en termes de procediments predefinits, anomenats mtodes.
Figura 12. Estructura duna BD orientada a objectes
TAD Un tipus abstracte de dades (TAD) s un concepte que defineix les dades juntament amb les seves operacions associades.
Oracle Alguns SGBD presents en el mercat des de fa molt de temps, van estenent el model relacional per tal dincorporar conceptes relatius a lorientaci a objectes. Aquest s el cas de la coneguda firma Oracle, la qual est treballant en aquesta lnia des de la versi 8 del seu producte.
La figura 12 mostra lestructura de classes, subclasses i instncies, duna BD orientada a objectes.
35
3. Els SGBD: objectius i arquitectura
Els SGBD sn un tipus de programari que t com a finalitats la gesti i el control de les BD.
s interessant conixer levoluci daquest tipus de programari al llarg de la seva histria, i els objectius que tots ells persegueixen amb ms o menys encert. Tamb cal destacar que hi ha nocions relatives tant a larquitectura dels SGBD com a les aplicacions que els fan servir. Tamb sha de destacar que hi ha diferents tipologies dusuaris i administradors de BD, i llenguatges que tots han dutilitzar per comunicar-se amb els sistemes gestors.
3.1. Evoluci dels SGBD

Per tal dentendre millor per qu els SGBD sn avui dia tal com els coneixem, conv repassar breument la seva histria. Igual que en altres mbits de programari (com, per exemple, en el dels sistemes operatius), levoluci dels SGBD ha estat, sovint, intrnsecament lligada a levoluci del maquinari. ! La figura 13 mostra un esquema de les etapes evolutives per les quals han passat els SGBD, en el qual se nindiquen les principals caracterstiques.
Figura 13. Evoluci histrica dels SGBD
36
3.1.1. Anys cinquanta: processament seqencial

Inicialment, lnic maquinari disponible per emmagatzemar la informaci consistia en paquets de cintes perforades i en cintes magntiques. Aquests dispositius noms es podien llegir de manera seqencial i, per tant, el programari de lpoca estava limitat per aquesta circumstncia. Com que la grandria de les dades a processar era molt superior a la de la memria principal de les computadores, els programes noms podien realitzar processos per lots, de la manera segent:
Obtenint les dades en un ordre determinat (des duna o ms cintes). Fent algun clcul sobre les dades. Escrivint el resultat (en una nova cinta).
Exemple de processament seqencial 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, saniria llegint el paquet de les cintes perforades anteriors, sincronitzadament amb la cinta mestra que contingus totes les dades relatives als productes. Les targetes perforades haurien de respectar lordre dels registres del fitxer de productes contingut en la cinta. Amb totes les dades relatives als productes contingudes en la cinta mestra, ms 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 lempresa.
3.1.2. Anys seixanta i setanta: sistemes centralitzats

Durant la major part de les dues dcades dels anys seixanta i setanta, els SGBD van tenir una estructura centralitzada, com corresponia als sistemes informtics daleshores: un gran ordinador per a cada organitzaci que sel pogus costejar, i una xarxa de terminals no intelligents, sense capacitat prpia per processar dades. Inicialment, noms es feien servir per gestionar processos per lots amb grans volums de dades. Posteriorment, amb laparici dels terminals, de vegades connectats mitjanant la lnia telefnica, es van anar elaborant aplicacions transaccionals, per exemple per reservar i comprar bitllets en lnies de transports, o per realitzar operacions financeres Els programes encara estaven molt lligats al nivell fsic, i shavien de modificar sempre que es feien canvis en el disseny de la BD, ja que aquests canvis implicaven, al seu torn, modificacions en lestructura fsica de la BD. El personal que realitzava aquestes tasques havia destar altament qualificat.
37
3.1.3. Anys vuitanta: SGBD relacionals

Tot i que des del principi dels anys setanta ja shavia definit el model relacional, i laccs 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 daquesta demora en ls dels sistemes relacionals va ser el pobre rendiment que oferien inicialment els productes relacionals en comparaci amb les BD jerrquiques 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 informtica i la seva extensi a moltes ms organitzacions. Fins aleshores, la feina dels programadors que treballaven amb BD prerelacionals havia estat massa feixuga, ja que, duna banda, havien de codificar les seves consultes de manera procedimental, i duna altra, havien destar pendents del seu rendiment i fer consideracions dndole fsica a lhora de codificar-les. Per a causa de lexpansi de la informtica que va tenir lloc durant la dcada que comentem, calia simplificar el desenvolupament de les aplicacions. Els SGBD ho van aconseguir, tot independitzant els programes dels aspectes fsics de les dades. A ms, laparici del llenguatge de consulta estructurat (structured query language, o SQL, en angls) i, sobretot, la seva estandarditzaci a partir de lany 1986 van facilitar enormement ls dels sistemes relacionals i, per tant, la seva implantaci massiva. Finalment, les BD relacionals van poder competir, fins i tot, en matria de rendiment amb les jerrquiques i amb les estructurades en xarxa, amb la qual cosa van acabar reemplaant les seves competidores en la majoria dels casos.
SQL El 1986, l'Institut Nacional Nordameric de Normalitzaci (American National Standards Institute, o ANSI, en angls) va publicar les primeres normes que enunciaven la sintaxi i la semntica de l'SQL.
3.1.4. Anys noranta: BD distribudes, 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 lxit gradual dels ordinadors personals (personal computers, o PC, en angls), cada vegada ms potents i amb preus ms competitius, juntament amb el desenvolupament de les xarxes, va possibilitar la distribuci duna mateixa BD en diferents ordinadors (o nodes).
38
En funci del nombre de SGBD utilitzats, els sistemes distributs poden ser de dos tipus: Homogenis, si tots els nodes utilitzen el mateix SGBD. Les interaccions entre els diferents nodes sn ms senzilles. Per les actualitzacions del sistema gestor implicaran necessriament a tots els nodes. Heterogenis, si cada node utilitza un SGBD diferent. Les interaccions entre els diferents nodes poden ser ms complicades. Per hi haur ms flexibilitat a lhora dactualitzar el sistema gestor de cada node. Els punts a favor dels sistemes distributs sn fonamentalment dos: Rendiment. Si el sistema est ben dissenyat, la majoria de les operacions es realitzaran amb dades emmagatzemades localment. Daquesta manera les respostes seran ms rpides, disminuir la despesa en comunicacions, i sevitar la dependncia dun node central collapsat. Disponibilitat. Els sistemes distributs sn ms 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 distribut, 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 ms, segons quin esquema de disseny shagi seguit en fer la distribuci, si les dades del node aturat estan duplicades en un altre, continuaran estant disponibles. Per, evidentment, no tot sn 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 ms, en general, la comunicaci s ms complexa i, per tant, la quantitat derrors i de problemes derivats daquest fet que shan de controlar s molt ms gran que en un sistema centralitzat. La tecnologia utilitzada habitualment en la distribuci de BD s larquitectura 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 darquitectura s, esquemticament, el segent: dos processos sexecuten en un mateix sistema o en dos de diferents, de tal manera que un fa de client (o peticionari dun servei), i laltre de servidor (o provedor del servei demanat).
Arquitectura client/servidor Una arquitectura client/servidor es caracteritza pel fet de disposar dun sistema en xarxa on hi ha uns ordinadors que actuen com a servidors de peticions i uns altres (els clients) que demanen serveis.
39
La classificaci dels processos en les categories de client i de servidor s de tipus lgic (i no, fsic) i, per tant, cal tenir en compte alguns aspectes que deriven daquesta circumstncia, com ara els segents: 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 laparici dels anomenats llenguatges de quarta generaci (fourth generation languages, o 4GL, en angls), els quals es continuen utilitzant en lactualitat. Es tracta de llenguatges molt senzills, per al mateix temps molt potents, especialitzats en el desenvolupament daplicacions centrades en laccs 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.
4GL Aquests sn alguns entorns actuals de desenvolupament que utilitzen llenguatges de quarta generaci: eDeveloper, de Magic Software, Oracle Developer, d'Oracle Corporation, SAS System, de SAS Institute Inc., etc.
3.1.5. Tendncies actuals: orientaci a objectes, Internet, i elements multimdia

Actualment, els SGBD relacionals acaparen el mercat. Han evolucionat de tal manera que ja no tenen competidors en rendiment, fiabilitat o seguretat. Daltra banda, ja no necessiten habitualment tasques de manteniment planificades que en comportin l'aturada peridica. Per tant, la disponibilitat que ofereixen s molt elevada, ja que sacosta a les vint-i-quatre hores de tots els dies de lany. Per, al mateix temps, tots estan immersos en un complex procs de transformaci per tal dadaptar-se a les innovacions tecnolgiques de ms xit: 1) Les tecnologies multimdia. Els tipus de dades que tradicionalment admetien els SGBD ara es veuen incrementats per altres de nous que permeten emmagatzemar imatges i sons.
Exemple dincorporaci de tecnologies multimdia en un SGBD Daquesta manera, per exemple, la taula que emmagatzemi les dades personals dels empleats duna empresa determinada podr contenir la foto de cadascun, la qual cosa pot resultar especialment interessant si l'organitzaci disposa dun entorn virtual de treball (de tipus intranet, per exemple) en qu els correus electrnics incorporin la foto del remitent, a fi de permetre la identificaci visual.
2) Lorientaci a objectes. Aquest paradigma de la programaci ha acabat influint en lorientaci de molts SGBD, que segueixen alguna de les dues lnies esbossades a continuaci: SGBD relacionals amb objectes, els quals admeten tipus abstractes de dades (TAD), a ms dels tipus tradicionals.
40
SGBD orientats a objectes, que estructuren les dades en classes, les quals comprenen tant les dades (atributs) com les operacions sobre elles (mtodes). Les classes sestructuren jerrquicament, 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 pgines web dinmiques (s a dir, amb accs a les dades contingudes en un SGBD allotjat en el servidor web corresponent). Una altra lnia dinnovaci que segueixen alguns SGBD s el treball amb els anomenats magatzems de dades (data warehouse, en angls). Aquests magatzems consisteixen en rpliques elaborades de les dades generades pel funcionament quotidi de lorganitzaci o lempresa de qu es tracti, durant un cert perode de temps per tal de realitzar anlisis estratgiques dndole financera, de mercats, etc. ! El llenguatge de marques extensible (extensible markup language, o XML, en angls) tamb influeix en el mn 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 lmbit de les BD. Hi ha dues maneres dincorporar 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 sn en realitat relacionals, sin ms aviat jerrquics, i que no solament estan en condicions doferir els resultats de les consultes en format XML, sin que tamb emmagatzemen la informaci en documents XML. El llenguatge estndard de consultes per a aquest tipus de SGBD sanomena
XQuery L'XQuery s un llenguatge de consultes dissenyat per consultar colleccions de dades XML, creat pel World Wide Web Consortium (conegut abreujadament com a W3C). El W3C s un consorci internacional que produeix estndards per a la World Wide Web (coneguda abreujadament com a WWW).
XQuery.
La utilitzaci de dades estructurades mitjanant lestndard XML resulta especialment interessant en lintercanvi dinformaci entre sistemes basats en plataformes poc compatibles entre elles. !
41
3.2. Objectius i funcionalitats dels SGBD
Tots els SGBD del mercat volen assolir una srie dobjectius i oferir una srie de funcionalitats, amb ms o menys encert, que actualment es consideren indispensables per al bon funcionament de qualsevol sistema dinformaci: Possibilitar les consultes no predefinides de qualsevol complexitat. Garantir la independncia fsica i la independncia lgica de les dades. Evitar o solucionar els problemes derivats de la redundncia. Protegir la integritat de les dades. Permetre la concurrncia dusuaris. Contribuir a la seguretat de les dades.
3.2.1. Possibilitar les consultes no predefinides de qualsevol complexitat

Els usuaris autoritzats dun SGBD han de poder plantejar directament al sistema qualsevol consulta sobre les dades emmagatzemades, de la complexitat que sigui necessria, tot respectant, aix s, les regles sintctiques perqu la sentncia sigui correcta. A continuaci, el SGBD ha de ser capa de respondre ell mateix a la consulta formulada, sense que sigui necessari recrrer a cap aplicaci externa. Quan no existien ni les BD ni els sistemes gestors, per tal dobtenir un subconjunt de les dades emmagatzemades en un fitxer, hi havia dues possibilitats: Llanar un llistat seqencial de totes les dades i, a continuaci, seleccionar manualment les que interessessin. Escriure el codi font dun programa especfic per resoldre la consulta en qesti, compilar-lo i executar-lo. Els SGBD actuals, en canvi, estan perfectament capacitats per interpretar directament les consultes, expressades habitualment com a sentncies formulades en el llenguatge de consulta SQL.
42
Evidentment, aix no vol dir que no es puguin continuar produint programes que incorporin consultes mitjanant les quals accedeixen a BD. De fet, aquesta s lopci ms encertada i cmoda si es tracta de consultes que shan de repetir al llarg del temps.
3.2.2. Garantir la independncia fsica i la independncia lgica de les dades

Cal garantir la mxima independncia fsica 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 tecnolgics dndole fsica 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 independncia lgica de les dades, la qual implica que les modificacions en la descripci lgica de la BD (per exemple, afegir un nou atribut o suprimir-ne un altre) no han dimpedir l'execuci normal dels processos usuaris no afectats per aquelles. I, pel que fa a la independncia lgica de les dades, fins i tot pot interessar (i, de fet, aquesta s una opci freqent) que convisquin diferents visions lgiques duna mateixa BD, en funci de les caracterstiques concretes dels diferents usuaris o grups dusuaris.
3.2.3. Evitar o solucionar els problemes derivats de la redundncia

Tradicionalment, la repetici de les dades sha considerat una cosa negativa, ja que comporta un cost demmagatzematge innecessari. Avui en dia, per, aquesta caracterstica, tot i ser certa, gaireb no es t en compte, a causa de labaratiment dels discos durs i de laugment de la seva capacitat i rendiment. Per hi ha un altre aspecte a considerar que no ha perdut vigncia, 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 simultniament els valors de les seves repeticions perqu es mantingui la coherncia entre totes.
Sn dades ntegres les que es mantenen senceres i correctes.
La redundncia consisteix en la repetici indesitjada de les dades, que incrementa els riscos de prdua dintegritat d'aquestes quan s'actualitzen.
43
Malgrat tot, els SGBD han de permetre al dissenyador de BD la definici de dades repetides, ja que de vegades (sobretot en matria de fiabilitat, de disponibilitat o de costos de comunicaci) s til mantenir certes rpliques de les dades. Ara b, en tots aquests casos, lobjectiu de l'SGBD ha de ser garantir l'actualitzaci correcta de totes les dades all on estiguin duplicades, de manera automtica (s a dir, sense que lusuari del SGBD shagi dencarregar 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 sn el resultat de clculs fets amb altres dades tamb presents en la mateixa BD.
Les dades derivades tamb poden ser acceptables, tot i que comporten una repetici evident dalgunes dades, si permeten fer consultes de caire global molt rpidament, sense haver daccedir a tots els registres implicats. Per tamb aqu, el SGBD s'ha dencarregar dactualitzar degudament les dades derivades en funci dels canvis soferts per les dades primitives de les quals depenen.
3.2.4. Protegir la integritat de les dades

A ms de la redundncia, hi ha molts altres motius que poden fer malb la consistncia de les dades, com ara els segents: Els errors humans. Les deficincies en la implementaci dels algoritmes de les aplicacions. Les avaries dels suports fsics demmagatzematge. Les transaccions incompletes com a conseqncia de les interrupcions del subministrament elctric. Els SGBD han de protegir la integritat de les dades en tots aquests casos. Per a aix disposen, duna banda, de les regles dintegritat, tamb anomenades restriccions, i duna altra, dels sistemes de restauraci basats en cpies de seguretat.
Mitjanant les regles dintegritat, el sistema valida automticament certes condicions en produir-se una actualitzaci de dades, i l'autoritza si les compleix, o denega el perms en cas contrari.
44
Les regles dintegritat poden ser de dos tipus: Restriccions del model. Sn regles inherents al model de dades que utilitza el SGBD (com ara el model relacional). El sistema les incorpora predefinides, i sempre sacompleixen.
Exemple de restricci del model Un SGBD relacional mai no acceptar que una taula emmagatzemi registres amb una clau primria idntica, perqu aleshores la clau no serviria per identificar inequvocament els registres entre ells.
Restriccions de lusuari. Sn regles definides pels usuaris (dissenyadors i administradors, fonamentalment) de la BD, que no incorpora a priori el SGBD, i que serveixen per modelitzar aspectes especfics del mn real.
Exemple de restricci de lusuari En una taula que emmagatzema els alumnes dun centre docent, es vol evitar que hi hagin alumnes matriculats en cicles formatius de grau superior que fossin menors dedat, ja que la normativa vigent no ho admet. Aleshores, cal establir una restricci en aquest sentit per calcular si la diferncia entre la data del sistema en el moment de la matrcula i la data de naixement de cada alumne s igual o superior als 18 anys. En aquest cas, el sistema permetria la matrcula, i en cas contrari la prohibiria.
Els SGBD tamb proporcionen eines per realitzar peridicament cpies de seguretat de les dades (o backups, en angls) 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 cpia de seguretat, abans de lincident que origina la restauraci, i per tant mai no estaran del tot actualitzats, encara que siguin correctes.
3.2.5. Permetre la concurrncia dusuaris

Un objectiu fonamental de tot SGBD s possibilitar de manera eficient laccs simultani a la BD per part de molts usuaris. A ms, aquesta necessitat ja no est circumscrita noms a grans companyies o a administracions pbliques amb molts usuaris, sin que cada cop s ms freqent, a causa de lexpansi dInternet i lxit de les pgines dinmiques, allotjades en servidors web que han dincorporar un SGBD. Hem de considerar dues tipologies daccessos concurrents, amb problemtiques ben diferenciades: Accessos de consulta de dades. Poden provocar problemes de rendiment, derivats sobretot de les limitacions dels suports fsics disponibles (per exemple, si la lentitud de gir del disc dur que cont la BD, o
La concurrncia dusuaris en una BD consisteix en laccs simultani a la BD per part de ms dun usuari.
45
del moviment del bra que porta incorporat el capal, no permeten atendre degudament totes les peticions daccs que rep el sistema). Accessos de modificaci de dades. Les peticions simultnies dactualitzaci dunes mateixes dades poden originar problemes dinterferncia que tinguin com a conseqncia lobtenci de dades errnies i la prdua dintegritat de la BD. Per tractar correctament els problemes derivats de la concurrncia dusuaris, els SGBD fan servir fonamentalment dues tcniques: les transaccions i els bloquejos.
Una transacci consisteix en un conjunt doperacions simples que s'han d'executar com una unitat.
Les operacions incloses dins duna transacci mai no s'han dexecutar parcialment. Si per algun motiu no shan pogut executar totes correctament, el SGBD ha de desfer automticament els canvis produts fins aleshores. Daquesta manera, es podr tornar a llanar lexecuci 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 collectiu duna empresa determina que els salaris dels treballadors shan dapujar el mes de gener un 3%. La millor opci consistir a actualitzar la taula dempleats i, ms concretament, els valors del camp que recull els sous dels empleats, mitjanant una consulta dactualitzaci que modifiqui totes aquestes dades i les incrementi en un 3%. Si volem garantir que lactualitzaci del salaris no quedi a mitges, haurem de fer que totes les instruccions que impliqui aquest procs es comportin de manera transaccional, s a dir, que sexecutin totes o b que no se nexecuti cap.
COMMIT i ROLLBACK La instrucci COMMIT indica, al SGBD, que un conjunt doperacions determinat s'ha d'executar de manera transaccional. Loperaci ROLLBACK desf els canvis produts en cas que les operacions duna transacci shagin executat parcialment.
Per tamb es pot donar la situaci en qu diferents transaccions vulguin accedir a la BD simultniament. En aquests casos, encara que cada transacci, individualment considerada, sigui correcta, no es podria garantir la consistncia de les dades si no fos per ls de la tcnica del bloqueig.
Un bloqueig consisteix a impedir laccs a determinades dades durant el temps en qu siguin utilitzades per una transacci. Aix saconsegueix que les transaccions sexecutin com si estiguessin allades, de tal manera que no es produeixen interferncies entre elles.
Exemple de bloqueig Imaginem que el departament de recursos humans de l'empresa de lexemple anterior disposa duna aplicaci que li proporciona certes dades de caire estadstic sobre de les remuneracions dels empleats, com ara el salari mitj.
46
Si es vol executar de manera concurrent la transacci descrita, que incrementa els sous en un 3%, i al mateix temps es llana lexecuci de laplicaci que calcula el salari mitj de tots els empleats de lempresa, el resultat obtingut per aquest programa probablement ser erroni. Per tal de garantir la correcci del clcul, shaur de bloquejar una de les dues transaccions mentre laltra sexecuta. Si es bloqueja lactualitzaci 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 estadstic, en primer lloc sactualitzaran totes les dades, i desprs 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 sesforcen a minimitzar aquests efectes negatius.
3.2.6. Contribuir a la seguretat de les dades.

Exemple de dades confidencials Resulta evident la necessitat de restringir laccs als secrets militars o, fins i tot, comercials (com ara les dades comptables). Per tamb sha de respectar la privacitat, fins i tot per imperatiu legal, en altres vessants aparentment ms modestos, per en realitat no menys importants, com sn les dades personals.
Lexpressi seguretat de les dades fa referncia a la seva confidencialitat. Sovint, laccs a les dades no ha de ser lliure o, com a mnim, no ho ha de ser totalment.
Els SGBD han de permetre definir autoritzacions daccs a les BD, tot establint permisos diferents en funci de les caracterstiques de lusuari o del grup dusuaris.
Actualment, els SGBD permeten definir autoritzacions a diferents nivells: Nivell global de tota la BD Nivell dentitat Nivell datribut Nivell de tipus doperaci
Exemples de drets daccs Els usuaris del departament de comptabilitat potser no haurien de tenir accs a lentitat que emmagatzema les dades personals dels empleats de lempresa, a diferncia de lusuari que ostenta el crrec de director general, que les podr consultar per tal doptimitzar la ubicaci dels treballadors el lorganigrama 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 accs als atributs que emmagatzemen ladrea particular dels empleats, a no ser que es tracti del personal de recepci, si resulta que s lencarregat denviarlos certa correspondncia a domicili (com ara les nmines o els certificats de retencions dIRPF), i per tant hauria, si ms no, de poder consultar-los.
Aquests mecanismes de seguretat requereixen que cada usuari es pugui identificar. El ms freqent s utilitzar un nom dusuari i una contrasenya associada per a cada usuari. Per tamb hi ha qui fa servir mecanismes addicionals, com ara targetes magntiques o de reconeixement de la veu. Actualment, sinvestiga en altres direccions com, per exemple, en
47
la identificaci personal mitjanant 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 tcniques dencriptaci 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.
Lencriptaci pot fer disminuir el rendiment en laccs a les dades, ja que comporta la utilitzaci dalgoritmes addicionals en les operacions de consulta. Per aix se nha de dosificar l's. Ara b, sempre que sigui possible, s convenient encriptar les contrasenyes.
3.3. Llenguatges de SGBD

La comunicaci entre els SGBD i els seus usuaris s'ha de realitzar mitjanant 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 angls, o DDL). Estan especialitzats en la definici de lestructura de les BD mitjanant lespecificaci desquemes. 2) Llenguatges de manipulaci de dades (data management languages, en angls, o DML). Possibiliten la consulta, modificaci i eliminaci, de les dades emmagatzemades, i tamb la inserci de noves informacions. Podem considerar lexistncia de dos subtipus, bsicament: Procedimentals. Requereixen especificar no solament les dades que es necessiten, sin tamb els procediments que s'han de seguir per obtenir-les. Sutilitzaven de manera exclusiva abans de larribada del model relacional. Actualment, es continuen utilitzant, per noms quan cal optimitzar algun procs que no rendeix prou, pel fet destar implementat de manera declarativa. Sn ms eficients que els declaratius, per ms complicats, ja que exigeixen tenir certs coneixements sobre el funcionament intern del SGBD utilitzat. Declaratius. Noms requereixen especificar quines dades es necessiten, sense que calgui especificar com shan dobtenir. Sn ms senzills daprendre que els procedimentals, per tamb menys eficients.
48
El llenguatge ms utilitzat per interaccionar amb els SGBD relacionals s lSQL.
LSQL 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 pedaggiques, per en realitat totes formen part dun nic llenguatge.
Exemples doperacions 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).
Amb relaci al component DML de lSQL, 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 ms del respectiu llenguatge nadiu de BD (habitualment, SQL), els SGBD ofereixen, des de ja fa molt de temps, dues possibilitats ms per incrementar la productivitat en el treball amb BD, que sn els llenguatges de quarta generaci i les interfcies visuals, sovint proporcionades dins de lentorn duna sola eina. Sovint, laccs 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 prpies 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 sn en llibreries que implementen estndards de connectivitat de BD amb programes escrits en certs llenguatges, com ara els segents: 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.
PostgreSQL s un SGBD distribut amb llicncia BSD (Berkeley Software Distribution)
Logotip de PostgreSQL
49
JDBC (Java data base connectivity), per realitzar operacions amb BD des daplicacions escrites en Java. 2) Hostatjar les sentncies del llenguatge de BD que siguin necessries, dins dun programa amfitri escrit en el llenguatge de programaci utilitzat. s imprescindible que el compilador utilitzat accepti la introducci de sentncies escrites en el llenguatge de BD utilitzat (que normalment ser l'SQL).
3.4. Usuaris i administradors

Les persones que treballen amb SGBD es poden classificar com a usuaris en sentit estricte, els quals simplement interactuen amb el sistema (tot i que de diferents maneres i amb diferents finalitats), o b com a administradors, si a ms realitzen tasques de gesti i control.
3.4.1. Usuaris dSGBD
Podem diferenciar tres categories dusuaris de SGBD en funci de la manera en qu interactuen amb el sistema: externs, sofisticats i programadors daplicacions.
1) Usuaris externs. Sn usuaris no sofisticats, que no interactuen directament amb el sistema, sin mitjanant alguna aplicaci informtica desenvolupada prviament per altres persones amb aquesta finalitat.
Exemple dusuari extern Qualsevol persona assumeix aquest rol quan treu diners dun caixer automtic, ja que accedeix a la BD de lentitat financera identificant-se mitjanant una targeta magntica i un nmero didentificaci personal secret (personal identification number, en angls, o PIN). Una vegada autoritzada a entrar en el sistema, podr realitzar diferents operacions de consulta o, fins i tot, dactualitzaci. En el cas plantejat, desprs 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 interfcies proporcionades per programes intermediaris. Formulen les consultes en un llenguatge de BD (normalment, SQL), des de dins de lentorn 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 sn ms freqents entorns que permeten construir les consultes de mode visual, com autntiques eines CASE. 3) Programadors daplicacions. Sn professionals informtics que creen els programes que accedeixen als SGBD i que, posteriorment, sn utilitzats pels usuaris que hem anomenat externs. Aquestes aplicacions es poden desenvolupar mitjanant diferents llenguatges de programaci i eines externes al SGBD. Per molts SGBD comercials tamb inclouen entorns
Eines CASE Les eines CASE (acrnim de computer aided software engineering, o enginyeria del programari assistida per ordinador) sn aplicacions informtiques destinades a augmentar la productivitat en el desenvolupament de programari reduint el cost del desenvolupament en termes de temps i de diners.
50
propis de desenvolupament i llenguatges de quarta generaci que faciliten enormement la generaci de formularis i informes que permeten visualitzar i modificar les dades.
3.4.2. Administradors dSGBD
Els administradors sn uns usuaris especials que realitzen tasques dadministraci i control centralitzat de les dades, i gestionen els permisos daccs concedits als diferents usuaris i grups dusuaris, per tal de garantir el funcionament correcte de la BD.
Els administradors han dactuar, 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 fcil, tot i que els SGBD incorporen cada vegada ms eines per facilitar-la, i en la majoria dels casos amb interfcie visual. Es tracta, per exemple, deines de monitoratge de rendiment, deines de monitoratge de seguretat, de verificadors de consistncia entre ndexs i dades, de gestors de cpies de seguretat, etc. Una llista no exhaustiva de les tasques dels administradors podria ser la segent: Crear i administrar els esquemes de la BD. Administrar la seguretat: autoritzacions daccs, restriccions, etc. Realitzar cpies de seguretat peridiques. Controlar lespai de disc disponible. Vigilar la integritat de les dades. Observar levoluci del rendiment del sistema i determinar quins processos consumeixen ms recursos. Assessorar els programadors i els usuaris sobre la utilitzaci de la BD. Fer canvis en el disseny fsic per millorar el rendiment. Resoldre emergncies.
3.5. Arquitectura dels SGBD
El 1975, el comit ANSI/X3/SPARC va proposar una arquitectura per als SGBD estructurada en tres nivells dabstracci (intern, conceptual i extern), que resulta molt til per separar els programes daplicaci de la BD considerada des dun punt de vista fsic.
Daltra banda, tamb resulta interessant examinar larquitectura dels SGBD des dun punt de vista funcional, ja que coneixent els diferents com-
51
ponents, i els fluxos de dades i de control podem entendre el funcionament dels SGBD, i estarem en millors condicions dutilitzar-los duna manera ptima.
3.5.1. Esquemes i nivells
Per gestionar les BD, els SGBD han de conixer la seva estructura (s a dir, les entitats, els atributs i les interrelacions que cont, etc.). Els SGBD necessiten disposar duna descripci de les BD que han de gestionar. Aquesta definici de lestructura rep el nom desquema de la BD, i ha destar constantment a labast del SGBD perqu aquest pugui complir les seves funcions.
Dacord amb lestndard ANSI/X3/SPARC, hi hauria dhaver tres nivells desquemes: En el nivell extern se situen les diferents visions lgiques que els processos usuaris (programes daplicaci i usuaris directes) tenen de les parts de la BD que utilitzen. Aquestes visions sanomenen esquemes externs. En el nivell conceptual hi ha una sola descripci lgica bsica, nica i global, que anomenem esquema conceptual, i que serveix de referncia per a la resta desquemes. En el nivell fsic hi ha una nica descripci fsica, que anomenem esquema intern. La figura 14 representa la relaci, duna banda, entre el nivell fsic i lesquema intern; i, duna altra banda, entre el nivell lgic i lesquema conceptual, i els diferents esquemes externs (o vistes).
Figura 14. Esquemes i nivells
Comit ANSI/X3/SPARC s un grup destudi de lStandard Planning and Requirements Committee (SPARC) de lANSI (American National Standards Institute), dins del comit X3, que socupa dordinadors i dinformtica.
52
En definir un esquema extern, noms sinclouran 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 sn dues, o podrem definir combinacions dentitats perqu en semblin una de sola, etc. En lesquema conceptual, es descriuran les entitats tipus, els seus atributs, les interrelacions i tamb les restriccions o regles dintegritat. Lesquema intern o fsic contindr la descripci de lorganitzaci fsica de la BD: camins daccs (ndexs, hashing, apuntadors...), codificaci de les dades, gesti de lespai, mida de la pgina, etc.
3.5.2. Components funcionals dels SGBD

El programari que conforma els SGBD es divideix en diferents mduls, encarregats de les respectives funcionalitats que ha de garantir el sistema.
El components funcionals dels SGBD ms importants sn el gestor demmagatzemament i el processador de consultes.
Gestor demmagatzemament
Les BD corporatives tenen enormes requeriments despai demmagatzematge en disc. Les dades es transfereixen entre el disc en qu estan emmagatzemades i la memria principal de l'ordinador noms quan s necessari. I, com que la transferncia 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 transferncia entre el disc i la memria principal. El gestor demmagatzemament proporciona la interfcie entre les dades, considerades a baix nivell, i les consultes i els programes que accedeixen a la BD. Les dades semmagatzemen en disc fent servir el sistema darxius que proporciona el sistema operatiu utilitzat. I el gestor tradueix les instruccions DML a ordres comprensibles pel sistemes darxius a baix nivell. Els components del gestor demmagatzemament sn els segents: Gestor dautoritzacions i dintegritat. Comprova que se satisfacin tant les restriccions dintegritat com les autoritzacions dels usuaris per accedir a les dades.
53
Gestor de transaccions. Assegura que la BD es mantingui en un estat de consistncia malgrat les fallades del sistema, i tamb que les transaccions concurrents no sinterfereixin entre elles. Gestor darxius. Gestiona la reserva despai demmagatzemament en disc i les estructures de dades utilitzades per representar la informaci emmagatzemada en disc. Gestor de memria intermdia. Transfereix les dades des del disc a la memria principal, i decideix quines dades shan de tractar en memria cau. Permet al sistema tractar amb dades de grandria molt superior a la de la memria principal. Daltra banda, el gestor demmagatzemament utilitza certes estructures de dades que formen part de la implementaci fsica del sistema: Arxius de dades. Emmagatzemen la BD prpiament considerada. Diccionari de dades. Emmagatzema les metadades relatives a tota lestructura de la BD. ndexs. Proporcionen un accs rpid a certes dades en funci dels seus valors.
Processador de consultes
El processador de consultes ajuda el SGBD a simplificar laccs a les dades. Les vistes a alt nivell contribueixen a assolir aquest objectiu, ja que eviten que els usuaris hagin de conixer detalls de la implementaci fsica del sistema. Per aix no treu que el sistema no hagi de perseguir leficcia en el processament de les consultes i de les actualitzacions de dades. De fet, el sistema ha de traduir les instruccions escrites, a nivell lgic, en un llenguatge no procedimental (tpicament, SQL), a una seqncia doperacions a nivell fsic, amb uns mnims deficincia. Els components del processador de consultes sn els segents: Intrpret 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 srie dinstruccions a baix nivell que pot interpretar el motor davaluaci de consultes. En realitzar la traducci esmentada, un bon compilador DML tamb sencarregar de fer una optimitzaci de consultes triant, entre totes les alternatives, la de menor cost.
54
Motor davaluaci de consultes. Executa les instruccions de baix nivell generades pel compilador DML. La figura 15 mostra tots aquests components i les connexions entre ells.
Figura 15. Components funcionals dels SGBD

Asidai 225x c03 Ud1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Asidai 225x c03 Ud1

Uploaded by

Copyright:

Available Formats

Introducci a les bases de dades

Carlos Manuel Mart Hernndez

Anlisi i disseny de bases de dades

Anlisi i disseny de bases de dades

Introducci a les bases de dades

Anlisi i disseny de bases de dades

Introducci a les bases de dades

Anlisi i disseny de bases de dades

Introducci a les bases de dades

Anlisi i disseny de bases de dades

Introducci a les bases de dades

Anlisi i disseny de bases de dades

Introducci a les bases de dades

1. Les dades: conceptes introductoris

1.1. La interconnexi entre el mn real, el conceptual i el de les representacions

Anlisi i disseny de bases de dades

Introducci a les bases de dades

1.1.1. El mn real i els objectes

Anomenem mn real la part concreta de la realitat que ens interessa modelitzar.

Anlisi i disseny de bases de dades

Introducci a les bases de dades

1.1.2. El mn conceptual i la informaci

Anlisi i disseny de bases de dades

Introducci a les bases de dades

Exemple dobtenci dinformaci

Anlisi i disseny de bases de dades

Introducci a les bases de dades

1.1.3. Les dades i la seva representaci

Anlisi i disseny de bases de dades

Introducci a les bases de dades

1.1.4. La interpretaci de les dades

Anlisi i disseny de bases de dades

Introducci a les bases de dades

1.2.1. Entitats, atributs i valors

Anlisi i disseny de bases de dades

Introducci a les bases de dades

1.2.2. El factor cronolgic

Anlisi i disseny de bases de dades

Introducci a les bases de dades

1.2.3. Entitats tipus i entitats instncia

Figura 3. Entitat tipus i entitat instncia

1.2.4. Tipus de dada i domini dels atributs

Anlisi i disseny de bases de dades

Introducci a les bases de dades

1.2.5. Valor nul dels atributs

Anlisi i disseny de bases de dades

Introducci a les bases de dades

1.2.6. Atributs identificadors i claus

Anlisi i disseny de bases de dades

Introducci a les bases de dades

1.3. El mn de les representacions

1.3.1. Les representacions tabulars i la seva implementaci: els fitxers

Anlisi i disseny de bases de dades

Introducci a les bases de dades

Anlisi i disseny de bases de dades

Introducci a les bases de dades

Anlisi i disseny de bases de dades

Introducci a les bases de dades

Figura 5. Exemple dentitats interrelacionades

Figura 6. Exemple de fitxers interrelacionats

Una BD consisteix en un conjunt de fitxers de dades interrelacionats.

1.3.3. Laccs a les dades: tipologies

Anlisi i disseny de bases de dades