Introducci a les bases de dades i als sistemes gestors de bases de dades

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. A
banda, doncs, dels conceptes relatius a les dades i a les bases de dades, caldr conixer quines representacions de la informaci sutilitzen habitualment aix com levoluci del programari daquest
mbit.

Les dades i les bases de dades

Per a tot informtic que hagi de treballar amb bases de dades (BD), s imprescindible saber distingir
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 real 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 Els tres mns

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, normalment, 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.

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 d'entitat, 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.

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.

Entitats instncia
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 adjacent.

Tipus de dada i domini dels atributs

Anomenem domini tot el conjunt de valors que un atribut determinat pot prendre vlidament.
El concepte domini 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.
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 sen 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.

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.
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 labsncia total de valor.

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 lentitat
vulgui modelitzar.
Exemple d'atribut 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 d'un atribut
Per tal de diferenciar les instncies duna entitat que vol reflectir les notes finals dels alumnes en
cada assignatura en qu shagin 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 shagi 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.
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.

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.

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.
Figura Exemple de representaci no informatitzada
En la figura.2 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.
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 latribut de lentitat instncia de qu es tracti.
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.
La implementaci informtica de les representacions tabulars es materialitza mitjanant els anomenats fitxers de dades. Sentn per 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 shan demmagatzemar 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.
Per en cap cas no es comprometria la complexitat de lestructura tabular, que seria, essencialment,
la mateixa.
Taula Exemple de representaci tabular
Cotxes
Matrcula Marca
QWE1234 Citron
ASD0987 Ford

ZXC5678 Citron
MNB5432 Renault

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 d'entitats 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, es mostra una representaci de les dues entitats (COTXES i MARQUES) interrelacionades.
Figura
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 mostra la interrelaci entre els dos fitxers corresponents a lentitat COTXES i a lentitat
MARQUES.
Figura 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.
Un sistema gestor de bases de dades (SGBD) s un tipus de programari especialitzat en gestionar i
administrar bases de dades.
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.

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, 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. LSGBD ens permet accedir a les dades
emmagatzemades en el disc dur considerant noms aspectes de nivell lgic, com ara seqncies de
registres.
Figura 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.

Conceptes de fitxers i bases de dades

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, orientat a objectes, etc.
s interessant, doncs, conixer les caracterstiques de cadascun dels models.

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.

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 noptimitzava 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).
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 lactualitzaci 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.

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 cont una breu descripci de les principals diferncies entre
els sistemes basats en fitxers tradicionals i les BD.
Taula Fitxers i BD
Fitxers

Bases de dades
Les BD contenen entitats instncia
Les entitats instncia dun fitxer pertanyen
Entitats tipus
dinfinitat dentitats tipus
a una sola entitat tipus.
interrelacionades.
El sistema t previstes eines per
Interrelacions El sistema no interrelaciona fitxers.
interrelacionar fitxers.
s necessari crear fitxers a mida de cada
Tcnicament, totes les aplicacions
aplicaci, amb totes les dades necessries, poden treballar amb la mateixa BD,
Redundncies
encara que estiguin repetides en altres
la qual cosa evita la redundncia de
fitxers.
dades i els riscos que comporta.
Si les interrelacions estan ben
s possible que els valors dunes mateixes
dissenyades, les dades noms han
dades en diferents fitxers no coincideixin,
Inconsistncies
destar emmagatzemades en la BD
si els programadors no les han actualitzat
un sol cop. Per tant, no hi ha risc
degudament.
dinconsistncies.
Si no hi ha una aplicaci que obtingui les Permeten obtenir qualsevol conjunt
dades que volem, o b sha de fer un
de dades, segons les necessitats, dels
Obtenci de
programa a mida, o b sha daprofitar la del seu propi entorn de treball, sense
dades
sortida dun programa amb objectius
haver descriure, compilar i executar
similars, i fer els clculs necessaris
cap nou programa daplicaci contra
manualment.
la BD.
Les dades estan disperses i allades en
Totes les dades sn en la mateixa
Allament de
diferents arxius, la qual cosa dificulta el
BD, interconnectades, la qual cosa en
dades
desenvolupament de les aplicacions.
facilita lobtenci.
Els programes han dimplementar totes les
La BD sencarrega directament
restriccions sobre les dades, afegint el codi
dimplementar les restriccions sobre
Integritat de
font corresponent. El manteniment s
les dades. Els programes no han
dades
complicat quan la informaci es cont en
dincorporar codi font addicional per
diferents fitxers utilitzats per diferents
garantir-les.
aplicacions.
Alguns conjunts doperacions sobre les
dades shan dexecutar de manera
Les BD incorporen la tcnica de les
indivisible (o tots o cap), independentment
transaccions per tal de garantir
de les fallades que el sistema pugui
Atomicitat
fcilment lexecuci atmica duna
presentar (com ara per un tall de
pluralitat de processos sobre les
subministrament elctric). Per aix s
dades.
molt difcil de garantir amb un sistema
dinformaci basat en fitxers.
Amb la tcnica del bloqueig, les BD
Lactualitzaci simultnia de dades dun
garanteixen automticament la
Accs
mateix fitxer per part de diferents usuaris o consistncia de les dades, malgrat
concurrent
aplicacions en pot provocar fcilment la
que ms dun usuari o ms duna
inconsistncia.
aplicaci les vulguin actualitzar
simultniament.
Seguretat
Habitualment, cada fitxer serveix per a un 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.
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.
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.

Algunes utilitzacions possibles dels fitxers en lactualitat sn les segents:

Fitxers de configuraci daplicacions.
Fitxers de configuraci de sistemes.
Fitxers de registres desdeveniments (logs).
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.

L'accs a les dades: tipologies

No serveix de res estructurar dades i emmagatzemar-les si desprs no shi 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.
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, que sajusten ms a la realitat.
Taula Mtodes daccs a les dades
P - per posici V - per valor
S - seqencial SP
SV
D - directe
DP
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 dun 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 d'accs 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.
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).

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
lestructuraci 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
shan de preocupar daquesta complexitat. Ni tan sols necessiten conixer-la.
Els administradors de BD treballen habitualment amb aquest nivell dabstracci.
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, es poden veure els diferents nivells dabstracci utilitzats per facilitar la interacci dels
usuaris amb les BD.
Figura Nivells dabstracci de dades

Els SGBD
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.

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 mostra un esquema de les etapes evolutives per les quals han passat els SGBD, en el qual
se nindiquen les principals caracterstiques.
Figura Evoluci histrica dels SGBD

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.
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.
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.
SQL
El 1986, lInstitut 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
lSQL.
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.
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).
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, laturada 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.
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.

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).
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.
4GL
Aquests sn alguns entorns actuals de desenvolupament que utilitzen llenguatges de quarta generaci: eDeveloper, de Magic Software, Oracle Developer, dOracle Corporation, SAS System, de SAS
Institute Inc., etc.
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.
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 laturada 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 d'incorporaci 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 lorganitzaci 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.
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.
XQuery
LXQuery 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).
La utilitzaci de dades estructurades mitjanant lestndard XML resulta especialment interessant
en lintercanvi dinformaci entre sistemes basats en plataformes poc compatibles entre elles.

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.
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.
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.
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 lexecuci 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.
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 sactualitzen poden perdre la integritat. Quan es modifica el valor
duna dada que est repetida, shan 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 daquestes quan sactualitzen.
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 lSGBD ha de ser garantir lactualitzaci 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 sha dencarregar dactualitzar degudament les dades derivades en funci dels canvis soferts per les dades primitives de les quals depenen.
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 lautoritza si les compleix, o denega el perms en cas contrari.
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.
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.
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 l'usuari
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.

Permetre la concurrncia d'usuaris

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.
La concurrncia dusuaris en una BD consisteix en laccs simultani a la BD per part de ms dun
usuari.
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 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 shan dexecutar com una unitat.
Les operacions incloses dins duna transacci mai no shan 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.
COMMIT i ROLLBACK
La instrucci COMMIT indica, al SGBD, que un conjunt doperacions determinat sha dexecutar
de manera transaccional. Loperaci ROLLBACK desf els canvis produts en cas que les operacions duna transacci shagin executat parcialment.
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.
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 lempresa 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.

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.
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 d'accs

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 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 ls. Ara b,
sempre que sigui possible, s convenient encriptar les contrasenyes.

Llenguatges de SGBD
La comunicaci entre els SGBD i els seus usuaris sha 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 shan 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.
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 d'operacions DDL i DML del llenguatge SQL
Com a instruccions de tipus DML, podem esmentar SELECT (per fer consultes), i tamb INSERT,
UPDATE i DELETE (per realitzar el manteniment de les dades).
I com a instruccions de tipus DDL, podem considerar CREATE TABLE (que ens permet definir les
taules, les seves columnes i les restriccions que calgui).
En relaci al component DML de lSQL, cal dir que s fonamentalment declaratiu, tot i que t possibilitats procedimentals, que es poden explotar en diferents SGBD:
PostgreSQL s un SGBD distribut amb llicncia BSD (Berkeley Software Distribution)
PL/SQL, llenguatge procedimental per treballar amb els SGBD creats per Oracle.
PL/PgSQL, similar al PL/SQL dOracle, per dissenyat per treballar amb PostgreSQL.


Logotip de 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 daplicacions 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.
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 lSQL).

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.
Usuaris d'SGBD
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 d'usuari 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.
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.
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 propis de desenvolupament i
llenguatges de quarta generaci que faciliten enormement la generaci de formularis i informes que
permeten visualitzar i modificar les dades.
Administradors d'SGBD
Els administradors 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.

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 d'emmagatzemament
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 lordinador
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 sen 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.
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.
Motor davaluaci de consultes. Executa les instruccions de baix nivell generades pel compilador DML.
La figura mostra tots aquests components i les connexions entre ells.

Figura Components funcionals dels SGBD

Diccionari de dades
Un diccionari de dades duna base de dades s el conjunt de metadades que proporcionen informaci sobre el contingut i lorganitzaci de la base de dades.
Un diccionari de dades, segons IBM Dictionary of Computing es pot definir com un repositori
centralitzat dinformaci sobre dades com ara el significat, relacions amb altres dades, orgen, s i
format.
De vegades el concepte de diccionari de dades o metadades tamb s conegut amb el nom de catleg del sistema o, tamb, com a repositori de metadades.
Els diferents SGBD especfics implementen de diverses formes el diccionari de dades, de forma que
cada programari implementa amb un conjunt de taules i ofereix un conjunt de vistes a diferents
tipus dusuaris del sistema. Aix doncs, normalment, un usuari amb privilegis dadministrador del
sistema (DBA) pot visualitzar ms informaci i de tipus ms especfic que un usuari sense aquests
privilegis.
DBA
DBA s lacrnim de Data Base Administrator o Administrador de Bases de Dades, que s la persona encarregada de gestionar les BD, dintre del SGBD.
Els elements que es troben habitualment a un diccionari de dades inclouen:
Definicions de lesquema de la base de dades.
Descripcions detallades de taules i camps, aix com de tots els objectes de la base de dades
(vistes, clusters, ndexos, sinnims, funcions i procediments, triggers, etc.).
Restriccions dintegritat referencial.
Informaci de control daccs, com ara noms dusuari, rols, i privilegis.
Parmetres dubicaci de lemmagatzemament.
Estadstiques ds de la base de dades.
Tot aquest conjunt dinformaci, semmagatzema en centenars de taules dinformaci. Tot i que hi
ha organismes que intenten estandarditzar lorganitzaci daquesta meta-informaci, la realitat s
que cada distribudor de programari especfic (cada SGBD) ofereix la seva prpia estructura.
Un administrador del sistema o DBA haur de conixer com accedir i consultar tota aquesta informaci consultant la guia de referncia del sistema amb qu treballi.
El diccionari de dades en Oracle
En Oracle s lusuari SYS el propietari del diccionari de dades i lnic que pot fer actualitzacions
sobre la informaci que cont. Tot i que, alterar o manipular el diccionari de dades s una operaci
dadministraci que cal fer amb moltes precaucions, doncs pot provocar danys permanents.
En Oracle es creen tres tipus de vistes diferents, que permeten consultar informaci sobre diferents
tipus de dades. Aix les vistes poden tenir un daquests prefixos:
USER: Per a visualitzar informaci sobre els objectes propietat de lusuari.
ALL: Per a consultar informaci sobre els objectes on t accs lusuari.
DBA: Que dna accs a tots els objectes del sistema, per a poder ser controlats i gestionats.
Aix doncs, per exemple, es poden consultar el conjunt dobjectes a qu es t accs des dun usuari
donat dOracle amb la segent sentncia:
SELECT owner, object_name, object_type FROM ALL_OBJECTS;

Diccionari de dades en MySQL

En MySql, en canvi, s la vista INFORMATION_SCHEMA qui proporciona informaci sobre les
bases de dades que semmagatzemen en el sistema.
Per a obtenir certa informaci sobre una base de dades concreta anomenada db_name en un SGBD
MySQL podrem executar una sentncia com ara:
SELECT table_name, table_type, engine FROM
information_schema.tables WHERE table_schema = db_name;
Anar a la pgina anterior:
Referncies
Anar a la pgina segent:
Activitats
Aquest document est subjecte a una llicncia oberta de Creative Commons, es reserva el dret de reconeixement de
l'autoria, d'exigir que no se'n faci cap mena d's comercial. Si altereu o transformeu aquesta obra, o en genereu obres
derivades, noms podeu distribuir l'obra generada amb una llicncia idntica a aquesta.
Hy-phen-a-tion