Introduccio Bases Dades

INTRODUCCIÓ A LES BASES DE DADES

INTRODUCCIÓ A LES

BASES DE DADES

SANTIAGO ORTEGO

data de revisió: Febrer 2003

��

© Santiago Ortego, 2002 Escola Universitària Politècnica de Mataró

Santiago Ortego Carazo

[email protected]

Versió: setembre de 2002

��


�� Aquests fulls pretenen ser una ajuda i una guia pel seguiment de les classes de l’assignatura de Ba-ses de Dades, complementant els diferents aspectes teòrics que s'explicaran al llarg del curs. En aquest curs es presenten quatre aspectes diferenciats, sobre els quals es va treballant:

• El primer és conèixer què és la informació, què és un Sistema d'Informació, i quines són les etapes necessàries per a construir-ne un, i les diferencies entre una base de dades i un siste-ma gestor de bases de dades

• Després es passa a presentar tècniques per tal d'esbrinar quina és l'estructura de la informa-

ció, per tal de poder, a partir d'aquesta, construir un model conceptual de dades. Es presen-ten dues notacions per representar aquest model.

• En els ordenadors caldrà utilitzar alguna mena de representació de la informació, la més uti-

litzada actualment és la relacional, de la qual es presenta el model i la forma de transformar-hi en un model conceptual.

• Al darrers anys s'ha establert com a llenguatge estàndard de Bases de Dades el SQL, del

qual es presenten la seva visió estàtica, de definició d'objectes, la utilització en consultes i modificacions i la forma d'implementar la seguretat.

Al darrer capítol es fa una revisió del procés de creació d'una base de dades

��


��


��

��!��"#�� 1.1 El concepte d’informació 1 1.2 Els Sistemes d'Informació 2 1.3 Precedents històrics del tractament de la informació 4 1.4 El tractament automàtic de la informació 7 1.5 El futur de les Bases de Dades a les organitzacions 11 1.6 Del món real a la Base de Dades 12 1.7 Les Bases de Dades i els SGBD 14 $ %&��%��!�'�%�� 2.1 El món conceptual 17 2.2 Els mecanismes d'abstracció 18 2.3 Les regles de negoci 20 2.4 El model de dades IE 21 2.5 Les entitats 22 2.6 Les associacions 27 2.7 Les entitats dependents 33 2.8 Les generalitzacions 34 2.9 Estudi de casos 35 2.10 Criteris per escollir entre conceptes 37 2.11 Utilització de submodels 38 2.12 La qualitat dels models 43 2.13 La notació UML 45 2.14 Exercicis 48 ( %&��%��%��% 3.1 Presentació Històrica del model relacional 69 3.2 Les relacions 71 3.3 Els valors nuls 75 3.4 Les restriccions d'integritat 77 3.5 La notació del model relacional 80 3.6 SGBDs comercials 80

��


) %��*%+�� 4.1 Del model concpetual al model lògic 83 4.2 Transformacions de les associacions un-a-molts 83 4.3 Transformacions de les associacions molts-a-molts 85 4.4 Transformació de les entitats associatives 86 4.5 Transformació de les associacions reflexives 87 4.6 Transformació de les entitats febles 88 4.7 Transformacions de les associacions un-a-un 89 4.8 Transformació de les generalitzacions 92 4.9 El model lògic ampliat 94 4.10 Estudi de casos 95 4.11 La normalització del disseny 99 4.12 Exercicis 100 , �-�. %%%��'��/��

5.1 L'entorn de la Base de Dades 101 5.2 Els tipus de dades nadius 103 5.3 Les taules 106 5.4 Les restriccions d'integritat 108 5.5 Gestió de la integritat 113 5.6 Les seqüències 115 5.7 Els sinònims 116 5.8 Comentaris 117 5.9 Exercicis 117

0 �-�. %%%��'��&��/�� 6.1 Taules d'exemple 119 6.2 Literals 120 6.3 Consultes sobre una única taula 122 6.4 Combinació de vàries taules 128 6.5 Consultes resum 131 6.6 Utilització de subconsultes 134 6.7 Pseudocolumnes i consultes jeràrquiques 140 6.8 Les funcions numèriques 142 6.9 Consultes amb caràcters 144 6.10 Consultes amb dates 146 6.11 Utilització d'intervals 148 6.12 Consultes amb estats nuls 150 6.13 Modificacions de la Base de dades 153 6.14 Les vistes 156 6.15 Exercicis 158

��


1 ��'��&��2��/��&�� 7.1 Introducció 169 7.2 Identificació i autentificació 171 7.3 Control d'accés discrecional d'una Base de Dades 173 7.4 La llei de protecció de dades de caràcter personal 176 3 %!��4��2'��"�� 8.1 Les bases de dades i el sistema d'informació 189 8.2 El cicle de vida de la base de dades 190 8.3 El disseny de la base de dades 192

��


��

��

��

��

La paraula informació ve del llatí �� , que vol dir "construir

a partir de" o "donar forma a". Als sistemes d'informació es cons-

trueixen estructures a partir de les dades, revelant els seus patrons,

trets i tendències, aquestes característiques de les dades són les que

els usuaris necessiten per realitzar el seu treball.

Les necessitats d'informació de la societat actual són cada dia més

importants; l'OCDE afirma que "la informació és la clau pel futur

de la humanitat i és indispensable per modelar bé aquest esdeve-

nir". El problema de la informació està molt relacionat amb el des-

envolupament econòmic i social; la investigació, la planificació i la

pressa de decisions demanen una informació precisa, oportuna,

complerta, coherent i adaptada a les necessitats de cada usuari i de

cada circumstància.

El concepte d'informació ha anat passant per diferents etapes, asso-

lint enfocaments molt diferenciats, però que englobaven sempre a

l'anterior. Una primera accepció està relacionada amb la investiga-

ció, i considera la informació com instrument essencial i com ele-

ment d'entrada/sortida en tota activitat del camp de la recerca. Altra

accepció identifica informació amb coneixement transmissible, la

qual cosa amplia el cercle d'usuaris de la informació per sobre dels

científics. Una visió molt més general considera que la informació,

a l'igual que la matèria i l'energia, constitueix un recurs fonamental,

un bé, en el sentit econòmic, que cal que sigui utilitzat en qualsevol

activitat humana.

Sota aquesta darrera accepció de la informació-recurs, es demana el

dret a la informació, el qual està contemplat a la Declaració Uni-

versal dels Drets de l'Home: "Tot individu té dret a la llibertat d'o-

pinió i d'expressió; això implica rebre i difondre, sense considera-

En moltes regulacions de rang inferior també està presenta aquesta declaració del "dret a la informació".

�� !��"�� #��$��

��

ció de fronteres, la informació i les idees per qualsevol mitjà d'ex-

pressió..... (Art. 19)".

Dels darrers paràgrafs es pot deduir alguns binomis en els quals in-

tervé la informació, entre ells es pot destacar: informació/actiu em-

presarial, informació/poder, informació/dret, informació/cultura; un

aprofundiment més exhaustiu en el tema relacionaria la informació

amb una gran part de la nostra civilització.

La informació ha de tenir unes certes qualitats per tal que pugui ser

utilitzada per individus i organitzacions, aquestes són:

• �� : ha de tenir el màxim percentatge d'informació correcta

sobre el total d'informació del sistema.

• �� el temps transcorregut des del moment en què es

produeix el fet que origina la dada fins al moment en què la in-

formació està a disposició de l'usuari ha d'ésser mínim.

• �� la informació ha de ser prou completa per a poder

complir els seus fins.

• � �� : és imprescindible que la informació tingui el màxim

contingut semàntic possible, és a dir, cal que sigui comprensible

i interessant.

• �� per tal d'obtenir resultats concordants, tota la in-

formació continguda en un sistema cal que sigui coherent amb

ella mateixa.

• !�� : la informació ha de representar el més fidelment

possible el món real.

��

Tota organització necessita pel seu funcionament un conjunt d'in-

formacions que es transmeteixen entre els seus diferents elements i

també des de, i cap, a l'exterior del sistema; una part d'aquesta co-

municació es realitza per medi de contactes interpersonals, el no-

menat sistema d'informació informal, mentre que la resta utilitza un

sistema d'informació formal (organitzacional) que és el que s'estu-

diarà en aquest apartat.

Una definició molt utilitzada en el món de la gestió empre-sarial és considera informació a tot allò que ens pugui treure de la incertesa.

�� "

��

Tot sistema d'informació formal es dissenya per a satisfer les ne-

cessitats d'informació d'una organització i està immers en ella; el

sistema d'informació ha de poder prendre dades de la pròpia orga-

nització i de fora d'ella, i els seus resultats seran la informació que

l'organització necessita per a la seva gestió i presa de decisions.

Una definició de sistema d'informació podria ser: "conjunt

d'elements ordenadament relacionats entre si d'acord amb u-

nes certes regles que aporta a l'organització, a la qual serveix

i que li marca les directrius de funcionament, la informació

necessària pel compliment dels seus fins, per la qual cosa

haurà de recollir, processar i emmagatzemar dades, proce-

dents tant de la mateixa organització com de fons externes,

facilitant la recuperació, elaboració i presentació dels matei-

xos".

Les característiques d'un Sistema d'informació es poden agrupar en:

• #��$� %�� que afecten al rendiment i seguretat del sistema

des del punt de vista de l'equip.

• &�� %��: que es refereixen a que el sistema fa

allò que cal d'un forma correcta (eficàcia) i si el sistema és capaç

d'adaptar-se a requisits canviants.

• ��$� %��: que posen èmfasi en el cost del sistema i en l'efi-

ciència amb la que respon als objectius.

• �� : que són les que tenen un impacte sobre l'entorn social

en què es desenvolupa el sistema.

Un sistema d'informació està constituït per:

'� � !��"�� #��$��

��

% ��&��'"�� '!��

• �� : és el conjunt de dades, amb la seva corresponent

descripció, estructurades i emmagatzemades en un suport d'or-

dinador.

• �%� ��( ��)��*��+��l'ordinador que ha de suportar la funció

de procés de les dades i tot l'equip perifèric imprescindible pel

compliment dels seus fins.

• �%� ��$� ��)��*��+� és el conjunt de programes que són ne-

cessaris per a gestionar les dades, controlar les comunicacions i

donar resposta a les necessitats de tractaments específics.

• ,� �� que té la missió d'assegurar la qualitat i

permetre l'ús correcte i permanent de les dades emmagatzema-

des; moltes vegades es diferencien les àrees de dades de les d'in-

formàtica.

• ,�� ho són totes les persones que cal que accedeixen al

Sistema d'Informació; aquests tant poden ser informàtics com

usuaris finals amb pocs coneixements d'informàtica que necessi-

ten consultar o actualitzar les seves dades.

��"�� $� ��

La humanitat s'ha interessat sempre per les dades, al menys durant

els darrers 12000 anys, i encara que avui en dia s'associa el concep-

te de dada al d'ordinador, històricament han existit molt mètodes

Sistema d'Informació

Software

Contingut

Unitat d'admi-

nistració

Hardware Usuaris

�� -

��

primitius de tractar dades, en realitat, alguns d’ells encara es fan

servir.

A Irak encara és possible trobar pastors que porten el control dels

seus ramats amb pedretes; quan les ovelles surten del corral a pas-

turar, el pastor col·loca una pedreta en un sac, quan tornen, el pas-

tor treu una pedreta per a cada ovella, d'aquesta forma disposa d'un

mètode per a determinar si s'ha perdut cap animal del ramat.

Excavacions realitzades a la regió de Zaros, Iran, i datades al 8500

a.C., han permès desenterrar "fitxes" o "comptadors" de fang que,

es considera, foren utilitzats per a realitzar registres de formes pri-

mitives de comptabilitat; aquestes "fitxes" també s'han trobat a

Turquia i Pakistan. Cap el 3000 a.C. a l'actual ciutat de Susa, Iran,

l'ús d'aquestes fitxes havia arribat a un major nivell de complexitat;

algunes amb marques especials se segellaven en recipients de fang i

representaven factures d'embarcament dels articles comercials en

trànsit.

Aproximadament al mateix temps que va existir la cultura de Susa,

persones de la ciutat-estat de Uruk a Sumària portaven registres en

textos de fang; amb pictogrames, numerals i ideogrames, descrivien

les vendes de terres i les transaccions de negocis. Altres mètodes

neolítics de portar registres són les osques en un pal, que es van fer

servir a Anglaterra fins al segle XII i els nusos en un cordill que es

van fer servir a Sud-Amèrica.

Els orígens primaris de l'interès per les dades es poden seguir fins

al sorgiment de les ciutats; les cultures primitives de caçadors, re-

col·lectors de subsistència i després agrícoles, feien poc ús de les

dades. Les ciutats i la conseqüent cultura que va començar a l'edat

del bronze van canviar la forma de vida, els principis de la produc-

ció en massa, l'especialització de la mà d'obra i la possibilitat de

llogar serveis i productes per a les necessitats de la vida feien ne-

cessari la conservació de dades de registre.

Amb el pas del temps, es van conservar més tipus de dades i regis-

tres diferents: calendaris, dades censals, investigacions, registres de

propietat de la terra i matrimonis, contribucions a l'Església i l'Es-

Les "fitxes" indicaven la quantitat de béns que s'envia-ven i no es podien treure del recipient sense trencar-lo; les inscripcions a l'exterior d'a-quest i els segells relacionats proporcionaven un registre complet de la mercaderia.

.� � !��"�� #��$��

��

tat, arbres genealògics, etc. Els mercaders calien que controlessin

els inventaris, embarcaments i pagaments. Conforme l'agricultura

va passar del nivell de subsistència i va arribar l'etapa feudal, va

sorgir la necessitat de conservar dades de la quantitat de productes

per al consum, bescanvi i de conservació de llavors per a l'any se-

güent.

Les Creuades, que van tenir lloc a finals del segle XI fins al segle

XIII, van incrementar de gran manera la visió que es tenia del mon

i l'interès comercial, la forma més normal de comerç era establir

societats entre els mercaders, capitans de les naus i propietaris per a

facilitar els viatges comercials; aquest increment de la complexitat

comercial va provocar un increment de la conservació de registres

cada vegades més complicats; així va sorgir la comptabilitat per

partida doble. La comptabilitat per partida doble va començar als

centres comercials italians al segle XIV, l'exemple més antic que

es coneix prové d'un mercader a Gènova a l'any 1340, el seu us es

va anant difonent fins que a l'any 1494 un franciscà de nom Luca

Paciole va publicar el llibre "Summa de Arithmetica, Geometrica,

Proportioni et Proporcionalitat".

Conforme va declinar el domini dels mercaders italians, altres paï-

sos es van involucrar en forma activa en el comerç i, per tant, en la

conservació de dades i registres. En el moment que va disminuir la

utilització de societats temporals de comerç i es van establir orga-

nitzacions mercantils més estables a llarg termini, van fer falta al-

tres tipus de dades; per exemple, els estats de pèrdues i guanys a-

nuals, en compte, d'operació a operació.

Va ser també al segle XVII quan les persones van començar a inte-

ressar-se en dispositius que pogueren processar les seves dades "au-

tomàticament", encara que fora de forma rudimentària. Un dels

primers i més coneguts va ser construït a França al 1640 per Blas

Pascal, se suposa que per ajudar al seu pare que era recaptador

d'impostos, es tractava d'una petita capsa que portava engranatge

entrellaçats i era capaç de realitzar sumes i restes. Aproximadament

al 1694 Gottfried Wilhem von Leibnitz va construir una màquina

més complexa, constituïda per cilindres i rodes dentades que s'en-

L'àmplia difusió del paper i de la impremta va provocar un avanç imparable de la comptabilitat i per tant de l'ús dels registres.

Al 1673 el Codi de comerç francès obligava als comerci-ants a realitzar un balanç cada dos anys.

�� /

��

trellaçaven; podia multiplicar i dividir amb números de varis dígits.

Ambdues màquines eren dispositius de càlcul mecànics.

Al 1805 Joseph Marie Jacquard a França va inventar un dispositiu

que creava patrons de forma automàtica durant el procés del teixit;

el seu nucli era una sèrie de targes perforades, que permetien que

els diferents fils s'entreteixeissen en una seqüència que produïa el

patró desitjat. Encara que el teler de Jacquard no era una màquina

de càlcul pròpiament dita, el seu mètode d'emmagatzemar patrons

de teixit amb targes perforades va tenir molta importància en el

desenvolupament futur dels dispositius de còmput.

El darrer dels invents, en aquesta àrea, va ésser degut a Charles Ba-

bbage, matemàtic del segle XIX; durant les dècades de 1820 i 1830

va desenvolupar i construir una màquina, a la que va nomena "mà-

quina de diferències"; aquesta màquina era capaç de tabular sèries

de números derivats de polinomis complicats, útils per l'astrologia i

la navegació. Al 1833 Babbage va començar a treballar sobre una

altra invenció a la que va denomina "màquina analítica", encara que

degut al deficient desenvolupament mecànic de l'època mai la va

poder acabar, en el seu disseny estaven inclosos molts dels princi-

pis dels ordinadors moderns.

��'��

Una base de dades es pot considerar com la més moderna tècnica

d'enregistrament de dades, tot va començar amb les targes perfora-

des que va inventar el Dr. Herman Holleterith, de l'Oficina del

Cens dels Estats Units, cap al 1880. El Dr. Holleterith es va trobar

amb el problema de completar el cens de 1880 de 13 milions de

nord-americans abans de 1890, quan començava el següent cens; al

1886 va tenir clar que la feina no estaria acabada a temps utilitzant

els mètodes manuals dels quals disposava. A partir del coneixement

de l'ús de les targes perforades als telers de Jacquard, el Dr. Holle-

terith inventà un mètode d'enregistrament d'informació basat en a-

quelles; així va començar l'era dels fitxers de targes mecanitzades,

que van subsistir com a mitja per l'enregistrament durant els se-

güents setanta anys.

La màquina analítica hauria estat formada per un "magat-zem" per a contenir dades, i un "molí" per a treballar amb ells; la màquina hauria estat preparada per a emmagatze-mar les dades en targes perfo-rades.

0� � !��"�� #��$��

��

El primer ordinador electrònic, ENIAC, va ésser operatiu al 1946,

fou dissenyat pels professors Eckert i Mauchley de la Universitat

de Pennsylvania, pel Departament de Defensa dels Estats Units, fo-

namentalment pel càlcul de trajectòries i taules de tir. En aquells

primers dies, els ordinadors foren molt utilitzats per a càlculs cien-

tífics, a on la possibilitat d'enregistrament no era un requisit impor-

tant; més quan es va estendre el seu ús pel processat de dades, les

limitacions dels fitxers de targes es van començar a notar. Una de

les organitzacions a la que afectava més aquesta limitació era a l'O-

ficina del Cens; quan aquesta va tenir que processar el cens de

1950, l'Oficina va arribar a la conclusió que necessitava un medi

d'enregistrament més ràpid, això va conduir a la invenció dels dis-

positius de cinta magnètica. Al 1951, un nou ordinador, el UNI-

VAC-1, dissenyat pels mateixos inventors de l'ENIAC, va ser lliu-

rat a l'Oficina del cens, tenia un únic dispositiu, nomenat "Sistema

de Cinta Magnètica", que podia llegir una cinta magnètica, tant en-

davant con enrera a gran velocitat.

L'impacte de la cinta magnètica per l'enregistrament de dades fou

aclaparador. Aquells que, abans de l'aparició de la cinta, es van

veure implicats en algun procés de fitxers de targes recorden encara

la frustració de trobar targes mal perforades, perforades lleugera-

ment fora de lloc i targes arrugades a la sortida de l'ordinador, la

por que caigués, per accident, una capsa de targes i trobar-les des-

ordenades era considerable. Amb l'arribada de la cinta magnètica

van desaparèixer tots aquests mals somnis, era lleugera, fiable i ne-

ta; la seva capacitat i velocitat, comparades amb les targes magnè-

tiques, eren enormes. Malgrat això, la cinta perforada no variava

substancialment la forma de processat. L'organització de fitxers

continuava, sent seqüencial, encara que permetia la representació

de registres de llargada variable d'una forma més adient; tota la

nomenclatura dels sistemes de targes, com fitxers, registres i

camps, es va traslladar al sistema de cinta magnètica.

Els sistemes de processat de dades que es feien servir als anys cin-

quanta eren subsistemes molt simples, dissenyats aïlladament i amb

independència d'altres subsistemes relacionats. La situació va can-

viar quan en el següent intent de processar sistemes més complexes

va portar un nou tipus d'experts, els analistes de sistemes; aquests

L l’Oficina del Cens va pro-vocar els dos invents més im-portants (per l'enregistrament de dades) en setanta anys: les targes perforades i la cinta magnètica.

�� 1

��

van introduir el concepte de fitxers integrats, per a ser compartits

per un cert nombre de programes de més d'un subsistema; aquests

fitxers compartits eren relativament grans, i el problema d'escriure

llargues descripcions de dades, a cada programa per a cada fitxer,

es va resoldre amb la instrucció COPY del COBOL, que permetia a

un programa copiar una descripció general de les dades prèviament

escrites en un fitxer. La instrucció COPY va representar, conceptu-

alment, un pas fonamental cap endavant en la separació de la des-

cripció de les dades del programa. A partir d'aquell moment co-

mença a la història de l'evolució de les Bases de Dades una creixent

acumulació d'avenços cap l'enregistrament integrat de dades.

La introducció del disc magnètic, a la meitat dels setanta, va ser

l'empenta definitiva a aquesta integració. Per accedir a un registre

d'una cinta magnètica és necessari examinar seqüencialment tots

els registres, més en un disc és possible accedir al registre directa-

ment, saltant els altres registres, guanyant d'aquesta forma una ve-

locitat de l'ordre de 2 a 4 vegades sobre la cinta magnètica. L'enre-

gistrament en disc proporcionà un suport adequat per als grans fit-

xers integrats.

A mitjans dels setanta, el concepte de Sistema d'Informació de Ges-

tió, IMS, va guanyar actualitat; l'enfocament bàsic era l'execució

dels programes del paquet IMS sobre els fitxers de sortida per tots

els subsistemes pertinents; més aviat es va trobar que per una gran

organització, el nombre de fitxers d'entrada del paquet IMS era

massa gran, el que provocava problemes d'operació i verificació; a

més a més, la fallada d'algun subsistema podia destruir l'operació

total; la duplicació de dades en els fitxers, resultant de les inconsis-

tències d'actualització, provocava encara més problemes. Tot això

va fer que els paquets IMS resultessin poc fiables i va demostrar la

necessitat d'una integració més gran.

Un dels productes més sobresortints d'aquella època va ser el "Ma-

gatzem de Dades Integrades", IDS, presentat per General Electric

al 1965; el IDS es va utilitzar per a crear grans fitxers integrats, que

podien ésser compartits per un cert nombre d'aplicacions. Va ser el

precursor dels moderns sistemes de gestió de Bases de Dades i po-

�2� � !��"�� #��$��

��

dia suportar un cert nombre d’estructures de dades. El seu creador

va ser Charles W, Bachman.

Al IDS el van seguir molts altres paquets IMS, basats en fitxers in-

tegrats per a sistemes jeràrquics; moltes organitzacions van invertir

gran quantitat de diners per a descobrir, al final, que els paquets no

eren tant efectius com esperaven; el problema era la manca de co-

ordinació entre els fitxers dels sistemes jeràrquics. Aviat es van a-

donar que el que necessitaven era una Base de Dades que tingués

una col·lecció integrada de dades generalitzada, de forma que tots

els subsistemes de l'organització utilitzant tots els programes po-

guessin accedir-hi. Es va reconèixer que aquesta Base de Dades

hauria d'ésser independent tant del programa com del llenguatge, si

es volia fer servir per a totes les aplicacions, i, en particular, un

canvi de dades no provoqués la necessitat d'un canvi en el progra-

ma d'aplicació. Si una Base de Dades ha de respondre eficientment

a les necessitats, en conflicte, de tots els programes d'aplicació, a

les hores, hauria de poder proporcionar una representació de dades

adequada.

Al mercat dels primers anys setanta van aparèixer un cert nombre

de sistemes de gestió de Base de Dades, amb diferents models d'or-

ganització de les dades. El Codasyl (Conference On Data Systems

Languages) es va interessar per les Bases de Dades a finals dels

seixanta, i va crear un grup de treball per a definir un model comú

de dades, nomenat model Codasyl o model de xarxa.

Paral·lelament al desenvolupament del model Codasyl, s'ha treba-

llat en altres idees basades en conceptes matemàtics; la fita fona-

mental de la investigació va ser el model relacional degut al Dr.

Edgar F. Codd, que va ser proposat per primera vegada al 1970. El

model relacional era simple i elegant i, malgrat això, potent; va ser

la inspiració principal a la nova àrea d'investigació de Bases de Da-

des. Si Bachman era el pare de les Bases de Dades, a les hores,

Codd ho era de la investigació sobre elles. A l'any 1976 es va des-

envolupar, per P. Chen, un primer model conceptual que permetia

representar la realitat en una sèrie d'esquemes, i a partir d'aquests

construir la Base de Dades.

��

��

Els anys 80 són els de la complerta extensió del model relacional,

al 1983 ANSI/SPARC reconeixia l'existència de més de cent siste-

mes relacionals, també van aparèixer SGBD per a ordinadors per-

sonals, una fita important dintre d'aquests anys va ser la publicació

d'un primer estàndard de llenguatge de consulta a les Bases de Da-

des, el SQL. La recerca en aquests anys es va centrar en les Bases

de Dades per Sistemes Experts, Bases de Dades orientades als ob-

jectes i arquitectures client/servidor; aquests darrers camps han vist

durant els noranta una gran quantitat de desenvolupaments comer-

cials.

��-��3�� 4��

De cara al futur i donada la gran quantitat d'informació que es té

enregistrada en diferents Bases de Dades van apareixent unes noves

paraules: Data Warehouse, un gran "supermercat" de Dades, situa-

des en diferents llocs i amb diferents Sistemes Gestors, a les quals

es pot accedir conjuntament; Data Mining, explotar la informació

amagada entre les dades separant la ganga de la mena; OLAP, On

Line Analytical Processing, permet realitzar tot tipus d'anàlisi de

les dades.

Cada vegada més, els sistemes hauran de contestar a preguntes que

permetin eliminar incerteses (aquesta és la definició d'informació).

Els sistemes d'informació hauran de suportar com a mínim quatre

nivells d'anàlisis:

• Contestar a simples preguntes o elaborar informes sobre les da-

des actuals i històriques que estiguin a la Base de Dades.

• El segon nivell és més profund i requereix l'habilitat de proces-

sar preguntes de la forma "què passa si....?".

• El Sistema també haurà de fer una anàlisi retrospectiva per tal de

poder esbrinar que ha passat per tal que el sistema hagi esdevin-

gut a l'estat actual.

• En darrer terme el sistema haurà de permetre "veure" que ha

succeït en el passat i "endevinar" quines necessitats haurà en el

futur.

�� !��"�� #��$��

��

En resum, el mateix que en el seu moment es va passar de les dades

a la informació, actualment s'està fent el salt de la informació al

coneixement.

Un altre punt d'interès en el futur serà, és, Internet; els WWW

(World Wide Web) proporcionen a qualsevol usuari accés a tot un

"maremàgnum" d'informacions, els fabricants de Bases de Dades

estan desenvolupant productes que permetin lligar els seus sistemes

amb Internet; a més de permetre múltiples tipus de cerca (normal-

ment no previstos quan es va introduir la informació i respondre a

les consultes de les màquines de cerca (yahoo, google....).

No es podria acabar aquest breu repàs d'allò que pot ser el futur

sense parlar de dues paraules màgiques d'aquest principi de segle:

Java i XML. Java és un nou llenguatge que ens prometen que servi-

rà per a tot i que darrerament s'ha incorporat al món de les Bases de

Dades. XML és un llenguatge de marques, que té la particularitat

de permetre guardar les dades l'estructura d'aquestes dades, la qual

cosa el fa molt útil per transferir dades entre diferents sistemes.

Comencen a aparèixer Sistemes Gestors de Bases de Dades que re-

presenten la informació en XML.

��.�3��3��

El dissenyador de Bases de Dades es dedica a crear "dipòsits" en

els quals pugui guardar la informació. Aquests "dipòsits" hauran de

ser a mida de la informació, això ens obliga a fer tot un llarg procés

per passar des del món real a un disseny adequat de la Base de Da-

des.

Es pot definir el món real com la part de la realitat que ens interes-

sa, és el que percebem amb els nostres sentits i és compost per ob-

jectes concrets, físics o no.

Tot observant el món real, els humans són capaços de deduir-ne

coneixements, informació. El conjunt dels coneixements obtinguts

observant el món real, es nomena món conceptual i per arribar-hi

cal realitzar un procés d'abstracció que permeti modelitzar l'estruc-

tura, les propietats i el funcionament de la realitat.

Al darrers anys les Bases de Dades s’han anat acostant ca-da vegada més a Internet, desenvolupant-se protocols que tant serveixen per les da-des com pels "browsers", la qual cosa tindrà una impor-tància cabdal en el desenvo-lupament del comerç electrò-nic.

Un mateix món real pot ser vist de maneres diferents per diferents observadors segons el seu entorn o marc de refe-rència.

�� "

��

El món de les concepcions o dels coneixements és un món mental,

però per a poder treballar amb aquests coneixements i poder comu-

nicar-los, fa falta projectar els pensaments a l'exterior i poder repre-

sentar-los físicament d'alguna manera. Aquest és el món de les re-

presentacions.

Es dona el nom de dades a les representacions físiques dels conei-

xements que es té dels objectes del món real. El pas dels coneixe-

ments a les dades (d'una concepció a una representació informàti-

ca), no és automàtic, és un procés humà conegut com disseny lògic.

% ��&��$�� #��$��

Mentre que el món conceptu-al és una visió del problema, el món de les representacions és una visió de la solució.

Representació

Món real

Món conceptual

Món de les

representacions

Base de Dades

Implementació

Abstracció

�5��6�78�

��6,�!9�

�'� � !��"�� #��$��

��

En un darrer pas caldrà implementar les dades en un ordinador, a-

quest darrer és conegut com a disseny físic i dependrà, en gran ma-

nera, del tipus d'ordinador i de software que s'estigui utilitzant.

��/�6��3�� :�3�

Des del moment en què els usuaris van disposar d'ordinadors, s'han

plantejat el problema de com podien arxivar dades, i com extreu-

re'ls dels dispositius perifèrics dels ordinadors. Al principi, les da-

des s'emmagatzemaven en cintes magnètiques, en les que s'agrupa-

ven formant registres físics. En la forma en què aquests registres fí-

sics representaven objectes de la mateixa naturalesa que es repetien

un cert nombre de vegades, es feia amb ells una col·lecció per a

constituir un fitxer.

Pràcticament tots els fitxers, que han estats construït per a respon-

dre a les necessitats plantejades per les aplicacions informàtiques,

tenen elements comuns, associacions que no són aprofitades, do-

nats que se'ls utilitza aïlladament, independentment uns dels altres.

Paral·lelament a les limitacions relatives a la utilització dels fitxers,

va aparèixer, cap a l'any 1963 (en Santa Monica USA), el concepte

de Base de Dades, i uns avenços tecnològics que permetien emma-

gatzemar quantitats d'informació cada vegada més gran.

Una Base de Dades es pot definir de moltes formes possibles, una

de les més complerta és: "una Base de Dades és una col·lecció o

dipòsit de dades integrades, amb redundància controlada i amb una

estructura que reflecteixi les interrelacions i restriccions existents al

món real; les dades, que han de poder ser compartides per diferents

usuaris i aplicacions, cal que es mantingui independents d'aquestes,

i la seva definició i descripció, úniques per a cada tipus de dades,

cal que estiguin emmagatzemades juntament amb elles. Els proce-

diments d'actualització i recuperació, comuns i ben determinats,

caldrà que siguin capaços de conservar la integritat, seguretat i con-

fidencialitat del conjunt de les dades. Les dades hauran de cobrir

les necessitats d'informació d'una organització."

�� -

��

Per tal d'aconseguir que les funcionalitats anteriors farà falta un

programa capaç de realitzar-les, aquest programa rep el nom de

Sistema Gestor de Bases de Dades (SGBD). Un SGBD es pot defi-

nir com el sistema software que permet als usuaris definir, crear i

mantenir la Base de Dades i els proporciona un accés controlat a les

dades.

A la figura 1.3 es mostren els nou components essencials d'un en-

torn de bases de dades i llur interrelació. Tot seguit es fa una breu

descripció de cadascun d'ells:

% �&��&(�� '"��#��$��

• � ��8��)��;8 ��*�� +� eines

automàtiques utilitzades per dissenyar la base de dades i els pro-

grames d'aplicació.

• 3 �� 3�� base de dades de la pròpia Base de Da-

des, on troba tota la seva descripció.

Diccionari de Dades

SISTEMA GESTOR DE BASES DE DADES

Programa d’aplicació

Interfície d’administració

Eina CASE

Base de Dades

Desenvolupador

Administrador

Usuari final

�.� � !��"�� #��$��

��

• � ��:��3��)�:�3+� software utilitzat

per proporcionar accés a la base de dades i al diccionari de da-

des.

• �� col·lecció integrada de dades, organitzada de

forma que permeti resoldre les necessitats d'informació a múlti-

ples usuaris d'una organització. És important distingir entre base

de dades i diccionari de dades, la primera conté les dades i el se-

gon la definició de les dades.

• �� són programes d'ordinador creats per

tal de crear i mantenir la base de dades, i proporcionar informa-

ció als usuaris.

• 8�� 3�� persones responsables

de desenvolupar polítiques per tal que la base de dades mantin-

gui llur seguretat i integritat, també són els responsables del fun-

cionament físic i del rendiment de la base de dades.

• 3��<�� persones que dissenyen la Base de Dades.

• �,�� persones que afegeixen, esborren i modifiquen

dades de la base de dades i que demanen i reben informació des

de la base de dades.

��

��

��

��

La humanitat sempre ha tingut codi per descriure el món real, i fins

i tot, el món dels sentiments. El més usual és el llenguatge i l'es-

criptura. De vegades s'utilitza codis específics per a necessitats

molts concretes, un plànol és una representació del territori, per

construir-lo s'ha eliminat tot allò que no era rellevant, s'han classi-

ficats les diferents informacions (carreteres, ciutats, rius, ....) i s'han

representat utilitzant un codi. Un plànol és un model del territori.

Es pot definir un �� com una representació simbòlica o

abstracte d'alguna cosa real o imaginada.

Un procés semblant és pot utilitzar per passar del món real al món

conceptual, primer caldrà fer una abstracció per tal d'estriar els e-

lements que cal representar i després caldrà utilitzar alguna mena

de codi per representar-los.

A qualsevol part del món real (univers de discurs, problema, ..) es

poden distingir dues parts, una dinàmica que respon a la pregunta

què fa?, i una altra estàtica, que és la que contesta a les preguntes

què és?, com és?. Un model de conceptual de dades ha de donar

resposta a la part estàtica.

Si s'intenta respondrà a la pregunta com està compost el món real?,

i altres preguntes semblants el resultat serà un llistat dels diferents

elements que el componen, aquests elements reben el nom genèric

d'objectes del negoci. Si la pregunta fora com és?, la resposta vin-

dria donada per una colla d'explicacions, de condicionants, de nor-

mes que compleix, aquesta relació rep el nom genèric de regles del

negoci.

A partir d’un territori es pot imaginar un plànol i a partir d'un plànol es té una idea de com és el territori.

Encara que a priori sembla fàcil diferenciar entre les re-gles i els objectes del negoci, el cert és que estan íntima-ment lligades i moltes vega-des una regla de negoci indica l'existència d'un objecte, o a l'inrevés, un objecte està sub-jecte a diferents regles de ne-goci.

��

��

!�� "#��$��

Un model conceptual de dades haurà de representar tots els objec-

tes del negoci i recollir el màxim possible de regles de negoci. L'è-

xit de la segona part dependrà de metodologia escollida i de l'habi-

litat del dissenyador per representar les diferents regles, aquesta si-

tuació ve representada a la figura 2.1

Un model de dades s'ha de procurar que reuneixi tres característi-

ques principals:

• ��, el model ha de recollir totes les propietats impor-

tants, sense incorporar les que no tinguin importància.

• �� , el model ha de ser intuïtivament clar i entene-

dor des de qualsevol punt de vista.

• ��, el model representa allò pel que va ser creat.

��

L'abstracció és el mecanisme psicològic principal per "extreure" els

objectes del negoci i moltes de les relacions entre ells, les quals

permetran recollir regles de negoci.

R E G L E S D E N E G O C I

O B J E C T E S D E N E G O C I

M O D E L C O N C E P T U A L

D E D A D E S Regles de

negoci

��

��

Es nomena abstracció al procés mental que es fa servir quan

se seleccionen algunes característiques i propietats d'un con-

junt d'objectes i s'exclouen altres característiques que no són

rellevants.

L'abstracció permet comprendre, classificar i modelitzar la realitat.

Per medi de l'abstracció, es poden classificar els objectes del món

real i analitzar les relacions existents entre ells, per això s'utilitzen

els següents mecanismes primaris d'abstracció: la classificació i la

instanciació, la identificació, la generalització i l'especialització, l'-

agregació i l'associació.

La de classificació és utilitzada per a definir un concepte com una

classe d'objectes del món real caracteritzats per unes propietats co-

munes; per exemple, el concepte "MES" és la classe que té com a

membres gener, febrer, ..., quan es pensa en "mes" s'obliden en els

aspectes diferencials (el nombre de dies) i es fa èmfasi en tots els

aspectes comuns a tots els mesos.

La instanciació (també es pot nomenar exemplarització) és la in-

versa de la classificació i es refereix a la generació i examen espe-

cífic de diferents objectes de la classe. Generalment tots els objec-

tes de la classe hauran de tenir una estructura similar.

La identificació és el procés d'abstracció per medi del qual els ob-

jectes són identificats de forma única. Els treballadors d'una empre-

sa es diferencien pel seu nom, els automòbils per la seva matrícula.

La identificació és necessària per identificar els objectes del món

real i donar-los un equivalent al model.

L'especialització és el procés de classificar els objectes d'una classe

en subclasses més especialitzades. La generalització, inversa de

l'anterior, defineix un conjunt d'interrelacions entre els elements de

dos, o més, classes; per exemple, la classe VEHICLE és una gene-

ralització de la classe BICICLETA, ja que cada bicicleta és un ve-

hicle. La generalització, encara que molt intuïtiva, no és utilitzada

en tots els models de dades; de totes formes és molt interessant ja

Els conceptes aparellats clas-sificació/instanciació o gene-ralització/especialització són contraris.

El mateix objecte del món re-al pot ser classificat de múlti-ples formes, per exemple el conjunt d'objectes {cadira blanca, taula negra, cadira negra, taula blanca} permet pensar en les classes: TAU-LES, CADIRES, MOBLES BLANCS i MOBLES NE-GRES.

Una conseqüència directa d'-aquesta abstracció és que al model tots els objectes hauran de tenir nom diferent.�

��

��

que presenta la propietat de l'herència: a una generalització, totes

les característiques de la classe genèrica són heretades per tot el

subconjunt de classes. �

L'agregació defineix una nova classe a partir d'un conjunt de clas-

ses que representen les parts components; així, s'aplica aquesta abs-

tracció quan a partir de les classes RODES, PEDAL, MANI-

LLAR,... s'obté la nova classe BICICLETA.

�

La classificació és el procés utilitzat quan a partir dels elements in-

dividuals d'informació s'identifiquen els tipus de camp; l'agregació

és el procés a través del qual es va reunint camps relacionats fins

agrupar-los en un tipus de registre.

L'abstracció d'associació es fa servir per establir correspondències

entre les classes; una associació és una correspondència entre dues

classes; per exemple, VIU és una associació entre les classes PER-

SONA i CASA la qual estableix una correspondència entre els e-

lements de les dues classes. És possible establir diferents associaci-

ons entre les mateixes classes.

�� !��"��"��

Una regla de negoci és una qüestió, política o requeriment del ne-

goci (domini del problema), moltes d'elles impliquen l'existència

d'algun "objecte del negoci" i altres, d'alguna propietat; en els dar-

rers anys s'han anat presentat metodologies que utilitzaven aquest

concepte.

Les regles de negoci es poden classificar de la següent forma:

• �� # presenta la definició d'un objecte percebut, a-

questa definició acostuma a generar un objecte dintre del model.

És interessant ja que en aquest punt es pot realitzar una definició

complerta de l'objecte.

• �� # un fet representa una relació entre dos objectes, de

qualsevol complexitat, del Sistema.

��

��

• �� : representa alguna mena de límit en el nombre

d'ocurrències o en les característiques i/o atributs d'alguns dels

objectes.

• �� $��# és un mètode per mitjà del qual alguns objec-

tes poden ser construïts, calculats o derivats d'altres objectes.

Els Estatuts, les normatives, les lleis, els convenis, els contractes, ...

representen la font més fiable de regles de negoci, una lectura de-

tinguda d'aquests es farà imprescindible; també cal tenir en compte

totes aquelles regles no escrites, però que tothom coneix, així com

el dret consuetudinari.

�

��%��&��

Una classificació molt simplista dels diferents models conceptuals

de dades que s'estan utilitzant actualment, permetria parlar de mo-

dels de dades orientats a l'objecte i models de dades semàntics, se-

gons donessin més importància al comportament (orientació a l'ob-

jecte) o al significat (semàntic).

El modelat semàntic va ser introduït per Abrial al 1974 amb el seu

model binari semàntic de dades, que va ser millorat per Chen

(1976) amb el model Entitat-relació, el qual s'ha mantingut durant

molts anys com el paradigma de la modelització conceptual de da-

des, altres models són el SMD (Model semàntic de Dades) de

Hammer-McLeod (1981), el model de dades funcionals de Ship-

man (1981), el ORM (Object-Role Modelling) , el NIAM (Natural-

language Information Analysis Method) presentat per Halpin al

llarg dels 80. Aquests models i les seves extensions, enfoquen el

problema del modelat de dades des de diferents perspectives, per

totes elles tenen en comú l'objectiu de proporcionar un mitjà per

capturar la semàntica o significat de l'àrea d'aplicació que s'està

modelant.

Basant-se en aquests models de caire força teòric, diferents autors

han presentat metodologia (conjunt d'estratègies) per aplicar-les.

Una de les metodologies més utilitzades, sobre tot en el domini de

les eines CASE, és la metodologia presentada per James Martin al

1990 nomenada "Information Engineering", Enginyeria de la In-

��

��

formació; la qual amb pocs elements i una notació molt simple és

capaç de recollir la major part de la semàntica de qualsevol pro-

blema. Encara que sembli un contrasentit, aquesta metodologia es

pot considerar una simplificació de la metodologia entitat-Relació

ampliada.

Cada dia està guanyant més adeptes la notació UML (Unified Mo-

deling Language ), aquesta notació intenta ser un llenguatge de

modelització universal vàlid pels diferents àmbits de la informàtica.

Al darrer apartat d'aquest capítol s'indica un breu resum d'aquesta

notació.

��'�!��

Una entitat és una col·lecció d'individus, coses, fets o esdeveni-

ments similars que tenen interès pel sistema d'informació que es

vol modelitzar. Algunes entitats són concretes i denoten persones o

coses; altres són abstractes i denoten conceptes, categories, esdeve-

niments més o menys instantanis o situacions més o menys durade-

res.

Martin defineix una entitat com "persones, coses o conceptes

que són d'importància per a l'empresa i de les quals es vol

emmagatzemar informació, aquestes poden ser tangibles o in-

tangibles".

Una altra definició d'entitat fora : tipus d'entitat és una classe d'ob-

jectes del mon real que té una existència independent, tan un objec-

te amb existència física (una persona, una casa, un empleat,..) com

un objecte amb existència conceptual (una feina, un curs universita-

ri,..). Les instàncies (els exemplars) d'una entitat, és a dir, els mem-

bres individuals de la classe representada per l'entitat, han de poder

distingir-se una de l'altra i poder-se contar. El nombre d'exemplars

d'una entitat rep el nom de població, que pot ser gran o petita, està-

tica o variable. Les entitats que sols tenen una única instància no

acostumen a representar-se. Les entitats es representen gràficament

per medi de rectangles tal com es pot veure a la figura 2.2.

��

��

(�)*+,�

-��)./0!�

1�/�0)�

2�3&��4�

�!�� "��

Cadascuna de les entitats vindrà identificada, de forma única, per

un nom, el qual haurà de complir les següents característiques:

• el nom ha de descriure els objectes o informacions del món real

representats per l'entitat; el nom haurà de ser significatiu per la

comunitat d'usuaris i reflectir exactament allò que es vol enre-

gistrar.

• haurà de ser auto-explicatiu, sola a partir d'ell es podrà entendre

què és l'entitat.

• reflectirà la naturalesa lògica de l'entitat, sense parar atenció a la

representació física, característiques o representacions; una enti-

tat no es podrà dir FITXER DE PERSONAL, si no serà PER-

SONA.

• contenir el mínim nombre de paraules necessàries per etiquetar

de forma complerta i única l'objecte.

• sempre serà una paraula en singular i, si és possible, sense adjec-

tius; MATERIAL és una bona etiqueta, MATERIAL CADU-

CAT no.

• complir el requeriments i limitacions que demani l'eina CASE

que s'utilitzi en el disseny, utilització de ñ, accents, ....

• el nom no haurà d'incorporar mai: abreviatures ni acrònims, a no

ser que siguin d'utilització normal dintre de l'àmbit del proble-

ma; noms d'organitzacions individuals, ordinadors, pantalles,

formularis,...; paraules innecessàries, articles, preposicions, con-

juncions,...

�%� � ��

��

• el nom haurà d'expressar un únic concepte o idea, tan de forma

explícita com implícita.

De cadascuna de les entitats caldrà realitzar una definició, aquesta

ha d'expressar allò que l'entitat realment és a l'organització on es-

tem treballant, moltes vegades no és útil la definició que pugui pre-

sentar un diccionari. Cal explicar per què l'entitat és important a

l'organització.

Si l'entitat apareix en diferents aspectes (o departaments, divisi-

ons,...) de l'organització caldrà especificar clarament una definició

per a cada vista del Sistema. Per tal que les definicions siguin profi-

toses és important realitzar-les tant aviat con s'hagi trobat l'entitat i

validar-les amb els clients. Cal defugir de les definicions que des-

criuen com, on o quan l'entitat serà utilitzada; així mateix com de

les definicions que és una re-escriptura del nom de l'entitat afegint

articles, preposicions, adverbis i conjuncions que no donen més in-

formació.

Quan els dissenys són grans o es dissenyen per parts s'ha de resol-

dre el problema dels sinònims, una única entitat amb dos noms i el

del homònims, dos entitats diferents que han rebut el mateix nom.

Tota entitat ha de posseir, com a mínim, un atribut, en altre cas no

podrà ser descrit; aquests atributs són comuns a totes les ocurrènci-

es de l'entitat. Tots els atributs d'una entitat són diferents entre ells.

Els diferents tipus atributs d'una entitat es representen a la part infe-

rior del rectangle que representa l'entitat, figura 2.3.

La definició ha ser utilitària, és a dir, clara i econòmica, dir-ho tot sense posar una pa-raula de més de les necessàri-es.

Enginyeria de la Informació, IE, defineix atribut en termes de element de dades (data i-tem), un "element d'informa-ció" és allò que conté un úni-ca peça d'informació i que no pot ser trencada en parts sen-se perdre el seu significat.

�� '�

��

(�)*+,�

Dni Nom Cognom Data neixement

-��)./0!�

Número

1�/�0)�

Número Data

2�3&��4� Adreça Ciutat

�

!�� "%�&��' ��

Cadascun dels atributs d’una entitat tindrà un nom diferent i una

descripció, les regles per donar noms als atributs i per descriure'ls

seran les mateixes que s'han detallat anteriorment per les entitats.

Els valors de tots els tipus d'atributs hauran de ser atòmics, és a dir,

no es podran descompondre més dintre l'àmbit del model. Un atri-

but no podrà tenir estructura interna, o per exemple, en el cas de

que la tingui, una adreça formada per carrer, ciutat, codi postal, ...,

si 'l'atribut estriat és adreça, no es tindrà consciència de la composi-

ció interna, en el cas que sigui necessari accedir a ella, caldrà defi-

nir en comptes de l'atribut adreça, tots els seus components.

Per a cadascun dels tipus d'atributs existirà un conjunt format per

tots els valors possibles que pot prendre aquest atribut, aquest con-

junt rep el nom de Domini de l'atribut. Com tot conjunt un domini

es pot definir per extensió, explicitant tots els possibles valors que

podrà prendre l'atribut; o per intensió, indicant la propietat que

compleixen tots els valors. En les definicions per intensió és força

normal indicar el tipus de dades, per exemple caràcters, i la seva

mida.

El valor per defecte d'un atribut atributs es refereix aquell valor

que prendrà en el cas de que se li assigni cap en concret en el

moment de la creació de l'exemplar de l'entitat; encara que és una

propietat important dels atribut cal anar molt en compte i sols uti-

litzar-los en cas que s'estigui molt segur. Encara que de vegades s'-

utilitzi no és una bona política utilitzar el valor per defecte com va-

En moltes entitats poden exis-tir atributs que es poden cal-cular o derivar a partir d’altres atributs, atributs calculats o derivats; encara que aquests poden tenir una certa impor-tància a l'organització, no és recomanable recollir-los en el model de dades i en tot cas ja es calcularan, o derivaran, en el moment que siguin neces-saris.

�5� � ��

��

lors per marcar un estat, per exemple, la no existència de valor.

Quan un atribut no té cap valor per un exemplar es diu que aquest

atribut està en el estat nul.

Un atribut es considerà opcional si existeixen exemplars del

tipus d'entitat que no en tenen cap valor per aquell atribut; ai-

xò és indicatiu de que existeix algun fet a l'organització que

diferencien els exemplars pels quals l'atribut és una caracte-

rística vàlida, de aquells pels qual no ho és.

Una de les propietats de les entitats és que tots els seus exemplars

han de ser distingibles, si un exemplar d'entitat ve caracteritzat per

les seves propietats, és a dir, pels seus atributs, no poden existir dos

exemplars amb els mateixos atributs. De totes formes per distingir

un exemplar d'un altre és possible que no calguin tots els atributs,

això es pot comprovar amb l'entitat PERSONA.

(�)*+,�Número DNINom1er Cognom2on cognomData de naixementAdreçaNúmero SS

�

!�� "(��)��*&�

En aquesta entitat es poden distingir els diferents exemplars, per

algunes de les següents combinacions d'atributs:

• Número de DNI;

• Nom, 1er Cognom, 2on Cognom, Data de naixement;

• Número SS (Seguretat Social).

Totes aquestes combinacions de propietats, o millor dir atributs, re-

ben el nom d'identificadors, ja que identifiquen de forma unívoca

��

��

cadascun dels exemplars d’entitat, i cada exemplar d'entitat sols té

una combinació d'atributs.

Totes les entitats tenen, com a mínim, un identificador (en el pitjor

dels casos serà la combinació de tots els atributs de l'entitat); si en

té diferents identificadors caldrà estriar-ne un com a principal i in-

dicar-lo en la representació de l'entitat, subratllant totes els atributs

que el formin, també s'acostuma a col·locar en primer lloc els atri-

buts que formen l'identificador principal, tal com mostra la figura

2.5

(�)*+,�Número DNINom1er Cognom2on cognomData de naixementAdreçaNúmero SS

(�)*+,��Nom1er Cognom2on cognomData de naixementAdreçaNúmero DNINúmero SS

(�)*+,� Número SSNúmero DNINom1er Cognom2on cognomData de naixementAdreça

�

!�� "+��'��,��

No tots els identificadors són iguals de bons, les propietats que ha

de complir un bon identificador primari són:

• 6��, que tots els atributs que el componen siguin obligato-

ris i existeixin en el moment de crear l'exemplar;

• ��, el valor d'aquest atribut ha de variar el mínim al llarg

de la vida de l'exemplar;

• -��, l'identificador ha d'estar format pel mínim nombre

possible d'atributs;

• *��, és a dir, que en el seu interior no con-

tingui cap mena d'informació;

• ��, aquesta propietat ha de ser pública i coneguda per

tots els "elements" del Sistema.

Segons això la millor elecció, possiblement, fora el Número DNI,

ja que compleix totes les propietats.

�

��

��

��5�!��

Una associació és una col·lecció d'interaccions similars que

existeixen entre exemplars d'unes entitats donades i que són

d'interès pel Sistema d'Informació que s'està considerant.

Una associació connecta dos entitats, cadascuna de les quals rep el

nom de participant a l'associació, la connexió amb l'associació rep

el nom de rol. Si en una associació els dos rols corresponen a una

única entitat participant aquesta rep el nom de recursiva. Les asso-

ciacions es representen per línies que uneixen les dues entitats par-

ticipants. Tota associació pot tenir un nom (sols serà imprescindible

a les associacions de molts a molts), el nom de les associacions a-

costuma a ser un verb; i, si és necessari (ho serà a les associacions

reflexives), es definiran el rol que realitza cada entitat a l'associa-

ció.

La cardinalitat expressa el nombre mínim i màxim d'exemplars d'u-

na entitat associades amb un exemplar de l'altre entitat participant;

la cardinalitat estableix els límits baix i alt permesos pel rol de l'as-

sociació, normalment 0 ó 1 per mínim i 1 ó n pel màxim, s'acostu-

ma a referir-se a aquest límits com cardinalitat mínima i màxima.

La cardinalitat mínima rep, també, el nom de participació, així si

val 0 es diu que l'entitat té una participació opcional a l'associació i

si val 1 la té obliga

Les associacions es poden classificar en tres tipus diferents segons

les cardinalitats màximes de les dues entitats que uneixen:

• un-a-un;

• un-a-molts;

• molts-a-molts.

A la figura 2.6 es presenten els tres casos de cardinalitat un-a-un.

Entre dues entitats poden e-xistir múltiples associacions.

Cal anar molt en compte amb les associacions que siguin obligatòries per les dues parts, ja que pot succeir un fenomen conegut com abra-çada mortal, tots els exem-plars d'una de les entitats has d'estar associats amb algun de l'altre i viceversa. El pro-blema succeeix quan es vol crear el primer exemplar, no és possible en cap de les dues entitats. Aquest problema és equivalent al clàssic, de l'a-braçada mortal.

��

��

CASAR

POSSEIR

VENDRE

7�,�6+)

Codi Nom Adreça Telèfon

8+,� Codi Habitants Superficie

/!&�,� Codi Nom Adreça

��)9� Codi Límit

6+,�

Dni Nom

2+-�

Dni Nom

Un venedor pot vendre en una única zona. Tots els venedors tenen zona. Cada zona sols té un únic venedor. Totes les zones tenen venedor

Un client poseeix una única tarja de crèdit. Hi han client que no tenen tarja de crèdit. Cada tarja de crèdit pertany a un únic client. Totes les tarjes de crèdit pertanyen a un client.

Una dona pot estar casada amb un únic home. Hi han dones que no estan casades. Un home pot estar casat amb una única dona. Hi han homes que no estan casats.

��

!�� "-�&�� .�. �

La Figura 2.7 representa les diferents menes d’associacions del ti-

pus un-a-molts, aquest sols ser la forma més usual de representar la

informació.

Abans de deixar una associa-ció obligatòria per les dues bandes cal comprovar si la representació de tota la in-formació en una única entitat no representa millor al siste-ma.

��

��

COMPRAR

TENIR

SEGUIR

ASSIGNAR

()+1�**+)

Dni Nom

6�(�)��-�,�

Codi Nom

�*�06&�,� Dni Nom

�0�+) Dni Nom

-0*�0

Nom Adreça

:0�6)�

Títol Autor

/!&�,�

Dni Nom

()+60/�� Referència Preu

Tots els Departaments tenen assignat algun Professor. Tots els Departaments poden tenir assignat més d'un Professor. Tots els Professors pertany a un únic Departament. Tots els Professors pertanyen a algun Departament.

Pot haver-ne Tutors que no realitzin el seguiment de cap Estudiant. Tots els Tutors poden fer el seguiment de més d'un Estudiant. Tots els Estudiants tenen Tutor. Tots els Estudiants ten un únic Tutor.

Pot haver-ne Clients que no comprin cap Producte. Tots els clients poden comprar més d'un Producte. Hi han Productes que no han estat comprats per cap client. Un Producte sols pot ser comprat per un únic Client.

Tots els Museus tenen algun Quadre. Tots els Museus poden tenir més d'un quadre. Hi han Quadres que no estan en cap Museu. Un Quadre sols pot estar en un Museu.

!�� "/�&�� .�.��

La Figura 2.8 representa els tres diferents casos de associacions

molts-a-molts que es poden presentar.

��

��

AGRADAR

MATRICULAR

TREBALLAR

�-(!�� Dni Nom

()+9�/�� Codi Nom

�*�06&�,�

Dni Nom

�**&4,��0)�

Codi Nom

,+& Dni Nom

,+&�

Dni Nom

Tot Empleat treballa en Projectes. Tot Empleat pot treballar amb més d'un Projecte. Tot Projecte té assignat algun Empleat. Tot Projecte pot tenir assignats més d'un empleat.

Tot Estudiant està matrículat en alguna Assignatura. Tot Estudiant pot estar matriculat en més d'una Assignatura. Hi han Assignatures que pot ser no tenen cap Estudiant matriculat. Totes les Assignatures poden tenir més d'un Estudiant matriculat.

Hi han Nois als quals els hi agraden Noies. Hi han Nois als quals els hi agrada més d'una Noia. Hi han Noies als quals els hi agraden Nois. Hi han Noies als quals els hi agrada més d'una Noi.

�

!�� "0�&��.�.��

En el cas d’associacions reflexives, caldrà indicar els dos diferents

rols que realitza l'entitat a l'associació, tal com mostra la figura 2.9.

La millor forma de interpretar aquests esquemes és suposar l'exis-

tència de dues entitats diferents (que en realitat són la mateixa) rea-

litzant cadascuna un rol diferent.

��

��

MANAR

Cap

Subordinat

MANAR

�-(!�� Dni Nom Adreça Telèfon

�-(!��;/� < Dni Nom Adreça Telèfon

�-(!��;��< Dni Nom Adreça Telèfon

Tots els Caps són Empleats. Tots els Subordinats són Empleats. Tots els Subordinats són Empleats.

Tots els empleats poden tenir un Cap Cap Empleat pot tenir més d’un Cap

Tots els Caps tenen Subordinats. Tots els Caps poden tenir més d’Un subordinat.

.

!�� "1�&��,��2��

En els casos d’associacions de molts-a-molts és relativament nor-

mal trobar-se amb propietats (atributs) que no són de cap entitat en

concret, si no que pertanyen a la parella, o dit d'altre forma, a l'as-

sociació; per representar aquesta situació es defineixen les entitats

associatives A la figura 2.10 es presenten diferents exemples d'enti-

tats associatives.

Una altra forma de considerar les entitats associatives es la de pen-

sar que són entitats formades pels atributs que es representen més

els identificadors de les entitats que associen, la combinació dels

qual forma l'identificador de l'entitat.

Un empleat pot realitzar el rol de cap o de subordinat.

Les entitats associatives (també es podrien nomenar associacions "entitatives") no són més que un artifici nota-cional per representar aquest atributs de l'associació, i per tant no tenen identificadors.

��

��

�

!�� "#��

�

�

��!��

Existeixen entitats que no tenen identificadors propis, és a dir, cap

combinació dels seus propis atributs, li permeten identificar com-

pletament l'entitat; no obstant això els diferents exemplars d'aques-

tes entitats tenen existència pròpia i diferenciada els uns dels altres,

per identificar-los és necessari conèixer informació d'una altra enti-

tat; aquestes entitats reben el nom d'entitats dependents (o febles).

Els exemplars d'una entitat dependents són identificats per la seva

associació amb una altra d'entitat, la qual reb el nom d'entitat iden-

tificadora (propietària) i l'associació que les relaciona reb el d'asso-

ciació identificadora. Per identificar cada exemplar d'una entitat

dependent es fa servir una combinació d'atributs de l'entitat depen-

dent (identificador parcial) i de l'identificador de l'entitat identifi-

cadora.

La figura 2.11 mostra un exemple d'entitat dependent, els comptes

corrents, a l'estat espanyol, venen identificats per 10 caràcters, úni-

ques dintre de cada sucursal, 4 caràcters que identifiquen la sucur-

sal, únics dintre de cada entitat bancària i 4 caràcters que identifi-

�-(!��DniNom

()+9�/��CodiNom

�*�06&�,�DniNom

�**&4,��0)�CodiNom

,+&DniNom

,+&�DniNom

�)�3�!!�)Hores

-��)&/0!�)Any

�4)�6�)Intensitat

L’Empleat treballa un nombre d’hores en un Projecte

L'Estudiant està matriculat a l'Assignatura en un any.

El noi i la noia s'agraden amb una intensitat.

%� � ��

��

quen l'entitat bancària; el compte corrent vindrà determinat per a-

quests 18 caràcters (més dos de validació), encara que part dels a-

tributs no li pertanyen directament; a l'exemple es representa que

totes les entitats bancàries tenen sucursals, mentre que pot haver-ne

Sucursals que no tinguin, en algun moment donat, cap compte cor-

rent.

�

�

�

!�� "##��

��!��"��=��

Els ésser humans acostumem a descriure les entitats de tres formes

diferents: a) descriure l'objecte i les seves característiques; b) des-

criure la globalitat de l'objecte i cadascuna de les seves parts; c)

desenvolupar una taxonomia i utilitzar aquesta estructura per iden-

tificar les diferències i similituds entre els objectes. Aquest darrer

mètode es conegut com generalització; una jerarquia de generalit-

zació és una estructura que agrupa tota una colla d'entitats que te-

nen característiques comunes. Aquesta eina de disseny és molt po-

tent ja que permet modelar, utilitzant l'herència, els aspectes co-

muns entre les entitats i preservar les diferències.

�-(!��DniNomCategoria

/+-�)/&�!Comissió

-�,��,&-�,�Hores extres

�!�)�*

!�� "#��2��$��3� ��2��

la cobertura de l’entitat em-pleat ha de ser total i per això en aquest cas cal crear el sub-tipus altres.

/+-(��/+))�,�CodiData oberturaSaldo

*0/0)*�!CodiAdreça

�,�&��3�,/>)&�CodiNom

�� '�

��

A la figura 2.12 es veu l'empleat que és l'entitat nomena supertipus

i els seus refinaments, els subtipus, comercial, manteniment, altres;

en aquest cas els tres subtipus són mútuament exloents, la intersec-

ció entre ells és el conjunt buit. Els exemplars d'empleats comerci-

als tenen tots els atributs d'empleat més el de comercial.

��

Per tal de poder veure la utilització de tots els elements metodolò-

gics anteriorment exposats es presenten a continuació quatre casos

resolts:

(��# D'una empresa dedicada al lloguer d'automòbils es co-

neixen els següents fets:

• Un determinat client pot tenir en un moment donat diferents llo-

guers.

• Un lloguer el realitza un únic client, però pot involucrar dife-

rents cotxes.

• És important contemplar les dades de començament i final pre-

vist del lloguer.

• Tot cotxe pot estar assignat a un determinat garatge.

• Cada lloguer el realitza una determinada agència.

També es vol guardar informació sobre aquelles persones que han

demanat informació, malgrat no hagin, encara, llogat un cotxe.

5� � ��

��

4�)��4�Adreça

/+,�)�/��NúmeroData inici

/+�?�MatrículaMarcaModelColor

/!&�,�DniNomAdreçaTelèfon

/+,*0!��,�NomAdreçaData

�4@,/&�NomAdreça

�1�/��)Data fi

�

!�� "#%�4��#�

�

�

*"�� # Donada la gran quantitats d'Eleccions al Congrés de

Diputats que ha de supervisar l'Estat, el "Ministerio del Interior"

vol tenir un informació centralitzada per tal de realitzar el control

de les diferents Eleccions. En primer lloc es voldria tenir un arxiu

històric dels polítics de l'Estat, que contingui informació de les se-

ves afiliacions als diferents partits al llarg de la seva trajectòria po-

lítica, fins i tot, en moments no electorals.

Cada Elecció té una data de convocatòria (la qual l'identifica) que

és la del dia en que es fan les votacions. L'Estat està dividit en pro-

víncies, les quals poden tenir un nombre d'escons variables per a

cada Elecció.

Les persones, independents o d'un o més partits que es presenten a

les convocatòries d'Eleccions s'agrupen en forma de candidatures.

Interessa guardar els resultats de les diferents convocatòries per a

cadascuna de les províncies. Els partits poden presentar candidatu-

res a totes, o només algunes, de les províncies.

��

��

(�)*+,�DniNom

/�,6&6��0)�SiglaNomResultat

�!�//&AData

�1&!&�/&ANúmeroData iniciData fi

(�)�&�SiglaNom

()+7&,/&�Nom

/+))�*(+,6)�Escons

!�� "#(��4��

��/��

Modelitzar objectes del món real és un problema molt crític,

obert a múltiples solucions alternatives; la mateixa realitat

pot ser modelitzada de moltes formes.

La figura següent mostra dos exemples d'esquemes que representes

la mateixa realitat. En aquesta secció es presenten varis criteris per

a escollir la millor representació.

Entitat o atribut simple: aquest problema representa escollir si un

objecte del món real està millor modelitzat com a una entitat o com

a un atribut; cal elegir-lo com a una entitat quan varies propietats

(atributs, generalitzacions, interrelacions) poden associar-se amb

l'objecte modelitzat, en aquest moment o en qualsevol altre del pro-

cés de disseny; cal representar-lo com un atribut quan l'objecte té

una estructura atòmica simple i que sembla que no existeix cap

propietat interessant que sigui aplicable a ell. Per exemple, el con-

cepte de color és típicament un atribut, per exemple de l'entitat

AUTO, mentre que si l'aplicació està relacionada amb la construc-

��

��

ció de peces de mobiliari, i, en particular, en el procés de coloració,

el COLOR pot esdevenir una entitat, amb els atributs NOM, CO-

DI_COLOR, NOMBRE_CAPES, ....

!�� "#+�4��5 ��

Generalització o atribut: s'utilitzarà una generalització quan s'espe-

ra que (ara o més tard) alguna propietat sigui associada a entitats de

nivell més baix (tal com un atribut o a una interrelació), en qualse-

vol altre cas s'escollirà com atribut. Per exemple, una generalització

de PERSONA basada en COLOR_CABELL no és usual, ja que no

és una característica que es doni normalment, encara que si que es

pot utilitzar per la base de dades d'una perruqueria.

��0��=��

Quant un problema és molt gran és normal utilitzar diferents sub-

models o visions realitzats per un o més dissenyadors per tal de po-

der abordar el problema d'una forma fàcil; aquests submodels

s'hauran de fusionar en un únic model corporatiu que representi to-

ta l'organització.

NEIX

(�)*+,�DniNomData naixementciutat naixement

/&0��Nom

(�)*+,��DniNomData naixementciutat naixement

(�)*+,�DniNom

2+-� 6+,�nº parts

(�)*+,��DniNomSexeNº parts

��

��

Els problemes que es poden trobar quan es realitzar la fusió

es classifiquen en dos tipus: a) conflictes de noms; b) conflic-

tes estructurals.

Els conflictes amb els noms sorgeixen per la utilització de sinònims

i homònims, els primers apareixen quan el mateix concepte es no-

menat de forma diferents en diversos submodels i els segons quan a

dos conceptes diferents se'ls dona el mateix nom en diferents llocs.

La millor forma de resoldre aquests problemes és crear un glossari

comú per a tots els dissenyadors i submodels.

Els conflictes estructurals es refereixen a la utilització d'estructures

diferents per representar un mateix concepte, aquestes estructures

poden ser equivalents o compatibles o incompatibles i caldrà anar

resolen, via consens, les diferents interpretacions i els nous pro-

blemes (efecte dominó) que crearan els canvis a cada submodel.

Per tal de veure l'aplicació d'aquesta metodologia el resolt un pro-

blema, en el qual de forma incremental es van creant els diferents

submodels fins arribar al model final.

Es vol construir un Sistema d'Informació pel control de la produc-

ció i distribució dels vins d'un país. En aquest país existeixen dife-

rents firmes comercials que són, en realitat, els fabricants i embote-

lladors dels vins. Aquestes firmes concedeixen "concessions en ex-

clusiva" per les diferents zones del territori del país a empreses dis-

tribuïdores, encara que una empresa pot treballar amb diferents dis-

tribuïdores, una per zona, i una distribuïdora pot treballar per dife-

rents firmes comercials. Aquestes concessions es firmen per un

termini de temps determinat, prorrogable sempre que convingui, i

són vàlides per vendre totes les marques de vi que la firma comer-

cial fabrica. De les diferents zones interessa saber, a efectes d'estra-

tègia de mercat, la seva extensió i població. La figura 2.16 presenta

el submodel corresponent a aquest paràgraf.

Un glossari és una col·lecció d'explicacions sobre els mots i els seus significats.

%��

��

1&)-��/+-�)/&�!NIFNom

/+,/�**&ANúmeroData iniciData fi

8+,�NomExtensióPoblació

6&*�)&30B6+)�NIFNom

�!�� "#-�� '��

De cada marca de vi hi ha diverses varietats o tipus (blanc, rosat,

negre, escumós, etc.), i la majoria d'aquestes marques tenen deno-

minació d'origen (per exemple Alella, Priorat, Rioja, ..), però algu-

nes, donada la seva poca qualitat, no en tenen. També es vol tenir

constància de les varietats de vins equivalents, particularment de

cara al seu preu. El submodel corresponent està representat a la fi-

gura 2.17

1&)-��/+-�)/&�!NIFNom

6�,+-&,�/&A�6�+)&4�,Nom

�&(0*Nom

-�)/�Nom

!�� "#/�� '��

�� %��

��

Les empreses distribuïdores tenen uns magatzems que faciliten la

distribució de les ampolles als diferents clients (com restaurants,

bars, supermercats, ...) encara que no sempre aquests magatzems

estan situats a les zones de distribució que una empresa distribuïdo-

ra hagi pogut aconseguir. Interessa saber si l'estoc actual de les di-

ferents varietats de vins. El submodel resultant està representat a la

figura 2.18

6&*�)&30B6+)�NIFNom

-�)/�Nom


-�4��8�-Adreça

40�)6�)Quantitat

�

!�� "#0�� '��$��

Les empreses de distribució serveixen comandes als diferents cli-

ents, identificant la comanda amb un codi, intern a cada empresa

distribuïdora, a on consta la quantitat d'ampolles demanades de ca-

da varietat. Les firmes comercials, les empreses distribuïdores i els

clients poden identificar-se pel seu NIF. A la figura 2.19 es pot

veure l'esquema d'aquesta part.

%��

��

6&*�)&30B6+)�NIFNom

-�)/�Nom

/+-�,6�CodiData

/!&�,�NifNomAdreça

6�-�,�)Quantitat

!�� "#1�� '��

La figura 2.20 representa la fusió de tots els submodels.

1&)-��/+-�)/&�!NIFNom

/+,/�**&ANúmeroData iniciData fi


6&*�)&30B6+)�NIFNom

6�,+-&,�/&A�6�+)&4�,Nom

�&(0*Nom

-�)/�Nom

-�4��8�-Adreça

40�)6�)Quantitat

/+-�,6�CodiData

/!&�,�NifNomAdreça

6�-�,�)Quantitat

!�� "��'��

�� % �

��

��!��C��

Si es consulta un diccionari es pot comprovar que hi ha diferents

accepcions per la paraula qualitat: a) allò que, posseït per una cosa,

fa que aquesta sigui tal com és; b) manera d'ésser d'una persona o

cosa; c) el grau d'excel·lència que una persona o cosa posseeix.

Si es miren aquestes accepcions es pot veure que indiquen dues i-

dees: a) que la qualitat inclou alguns aspectes de caràcter, o de

completesa, ha de tenir totes una colla de característiques per ser

definida d'una forma donada; b) el segon aspecte és el del grau

d'excel·lència, el qual representa una definició més actual de quali-

tat.

Quan, a partir d'ara, es parli de qualitat es tindran en compte els dos

conceptes: la completesa i la correctesa. Quan es parla de la qualitat

d'un model de dades hi ha que comprovar com aquestes propietats

es reflecteixen, tant des d'un punt de vista conceptual, com sintàc-

tic, això es pot veure reflectit a la figura 2.21

!��"��"�#�6��5 ��

%%� � ��

��

Tenint en compte cadascuna de les dimensions i planificant com es

contemplarà en el model, és pot incrementar la possibilitat de que

els models de dades representin les característiques necessàries pel

disseny d'un Sistema d'Informació. A continuació es fa una breu

descripció de cadascuna d'aquestes dimensions de la qualitat:

La correctesa conceptual implica que el model de dades reflectirà

de forma acurada tots els conceptes de negoci de l'organització.

Aquests conceptes estaran "encastats" dintre de plans plantejats o

no plantejats, polítiques, objectius, estratègies i normes que l'orga-

nització ha estriat pel seu funcionament. La correctesa conceptual

depèn de l'habilitat de l'analista per traslladar l'entorn de negoci a

una semàntica que representi acuradament el món real. És impor-

tant que existeixin "experts" que coneguin tant el negoci com el

llenguatge del model de dades per tal de poder validar el model.

La completesa conceptual implica que el model de dades conté els

objectes adequats per descriure tot l'àmbit del domini del negoci

que el model pretén representar. El descuit d'un sol element pot ar-

ribar a invalidar un model de dades.

La correctesa sintàctica implica que els objectes continguts al mo-

del de dades no violen cap de les regles sintàctiques del llenguatge

utilitzat per modelitzar. És possible trobar casos en que el model

representa fidelment l'organització, però com hi ha problemes sin-

tàctics es fa impossible finalitzar el disseny.

La completesa sintàctic implica que cadascun dels objectes del mo-

del de dades és "capturat" en el moment apropiat del procés de mo-

delització. Una metodologia de treball representa un procés hi cada

element cal tenir-lo en compte en el moment adequat.

La consciència d'organització, el model ha de representar allò que

necessita el client i aquest ha de poder reconèixer en el model de

dades l'esperit de la seva organització. Un bon model de dades

haurà de poder ser, no sols, una etapa en el disseny d'un Sistema

d'Informació, si no, també, un element que permeti veure el "que

és" l'organització.

��

��

Aquestes cinc característiques no són independents, qualsevol can-

vi que es faci en una d'elles tindrà influència sobre les altres, trobar

l'equilibri adequat a cada problema serà la feina d'un bon analista

de dades.

��

En UML existeixen diferents (uns 12 actualment) tipus de diagra-

mes, per representar el model conceptual es fa servir una versió

simplificada del diagrames de classes. A la figura 2.22 es mostra

una entitat amb diferents tipus d'atributs

��

Darrera dels atributs que forma l'identificador de l'entitat és

col·loca la marca {ident}. Si es tracta d'un atribut calcula s'indica

amb /, per exemple /SalariAnyal. El atributs estructurats es mar-

quen amb una identació, per exemple l'atribut Adreça està format

per Carrer, ciutat i CodiPostal. Si un atribut pot tenir diferents va-

lors, s'indica la seva multiplicitat darrera el nom [1..5].

Les associacions binàries s'indiquen amb una línia que uneix les

entitats i es pot col·locar sobre el nom. Les cardinalitats i participa-

cions s'indiquen de forma numèrica: 1 (sols un), 0..1 (zero o

un),1..* (un o molts), 0..* (zero o molts), 2..6 (de dos a sis).

��

�� !�� "��#��

��

A la figura 2.23 es representa una entitat associativa, Treballar que

té l'atribut Hores.

La notació UML també permet representar associacions ternàries (o

en general, n-àries), la figura 2.24 representa un exemple d'aquest

cas.

$�� %�

Per representar les entitats depenents és fa servir el concepte equi-

valent de composició o agregació forta., la figura 2.25 és un exem-

ple.

$�� &�

Per representar les generalitzacions, la figura 2.26

$�� '�

De vegades és difícil indicar quina és la cardinalitat de ca-dascuna de les entitats que participa en una associació n-ària, per tant no és gaire re-comanable utilitzar-les.

��

��

Es pot veure que les generalitzacions tenen dues propietats, la par-

ticipació que indica si és opcional o obligatori que tots els exem-

plars de l'entitat participen en la generalització (dit d'altra manera si

pot existir la subentitat altres); i la superposició, pot un exemplar de

l'entitat pertànyer a dues sub-entitats alhora (dit d'altra forma, les

entitats són mútuament excloents).

A tall d'exemple es presenta el següent cas i el seu model concep-

tual de dades (figura 2.27):

El Professor de Matemàtiques ens ha demanat una petita Base de

Dades per guardar totes les notes que té de les seves assignatures

que imparteix a diferents titulacions. Al llarg del curs fa diferent

proves, de les quals vol guardar el resultat, i al final del curs posa

una qualificació final i una nota. Malauradament té alguns estudi-

ants que repeteixen, i per afinar millor en la seva qualificació vol-

dria poder veure tots els resultats dels exàmens que han fet de l'as-

signatura en els diferents cursos.

$�� (�

%��

��

��%��D��

Dissenyeu el model dades pels següents casos

��%�� Una empresa de reparació d'aparells domèstics vol guardar

la següent informació: codi d'empleat, nom de l'empleat, categoria

de l'empleat, tipus d'aparells que reparen, marca i model dels apa-

rells reparats, cost per hora de reparació de cada tipus i marca d'a-

parell, número de sèrie de cada aparell reparat i data de reparació,

nom del propietari de cada aparell i qui ha reparat cada aparell.

��%�� La nostra Organització compra articles a un cert nombre de

proveïdors, es vol conservar un registre dels articles que s'han

comprat a cadascun d'ells. Cada proveïdor pot tenir més d'una adre-

ça i cal conèixer-les. També s'ha d'enregistrar la data a la qual els

proveïdors han canviat, per darrera vegada, el preu a cada article.

��%� El grup Y publica una certa quantitat de revistes periòdi-

ques, cadascuna de les quals té un nom, les diferents edicions s'i-

dentifiquen per la data de publicació. Cada revista conté diferents

articles, els quals poden estar escrits per periodistes interns o ex-

terns; es vol mantenir una llista de tots els autors externs, amb el

seu nom i adreça. La quantitat pagada i el nombre de fotografies

per cada article de cada autor extern també és una informació im-

portant. Tant mateix, s'enregistra el departament que ha produït l'ar-

ticle intern, cada departament té un nom i un telèfon de contacte.

��%�% Una companyia d'autobusos de llarg recorregut realitza dife-

rents rutes internacionals; les rutes tenen una ciutat de sortida, una

ciutat d'arribada, i varies ciutats intermèdies, una ciutat pot pertà-

nyer a diferents rutes. A l'oficina de reserves un passatger pot re-

servar un seien per una part donada de la ruta que realitza l'autobús.

Amb cada reserva s'ha d'enregistrar el DNI, el nom i el telèfon del

passatger, el número de seient, la ruta, les ciutats d'origen i final i la

data del viatge.

�� %��

��

��%�' La policia municipal de la ciutat de Dirdam vol gestionar de

forma àgil les denuncies de tràfic. Les denuncies són posades pels

agents als automòbils, indicant, si aquest és present, el nom del

conductor, el lloc on s'ha posat la denúncia, la data, l'hora i la causa

de la multa. En el cas de les multes per aparcament indegut, si l'au-

tomòbil no és retirat pel conductor, aquest serà traslladat a algun

dels dipòsit municipals de vehicles per una grua.

��%�5 Nostra empresa de venda de SGBD, donada la dificultat que

troba per tal que els clients aprofitin al màxim els seus productes,

ha decidit impartir cursos de formació en diferents aspectes de les

Bases de dades. S'han establert les següents normes:

Cada curs s'identificarà amb un codi, encara que també tindrà un

nom descriptiu, hi haurà un Professor responsable, tindrà una dura-

da definida i serà d'un tipus específic (per exemple, Administració

de Bases de Dades). Cada curs es pot realitzar diferents vegades, en

una data i en un lloc determinat.

El curs pot ser impartit al públic en general o de forma restringida a

una empresa específica. El normal (i desitjable) és que hi hagin va-

ris alumnes a cada curs, els quals pertanyen a alguna empresa. S'e-

labora una estructura de tarifes per a cada curs; hi ha una tarifa per

alumne d'un curs general i una tarifa especial (per curs complert i

sense càrrec extra per alumne) per aquells cursos restringits que es

realitzen a les instal·lacions de l'empresa.

Els empleats de l'empresa poden ser responsables i/o impartidors de

tot o part dels cursos; en aquest segon cas caldrà enregistrar els dies

dedicats a la impartició del curs.

�

��%�� Projectes SA és una empresa d'enginyeria amb, aproxima-

dament, 500 treballadors; es vol enregistrar informació sobre els

seus empleats, els projectes que tenen assignats i el departament en

que treballen. Cada empleat té un únic número assignat per l'em-

presa, necessari per conèixer el seu nom i la data de naixement. Si

un empleat està, actualment, casat amb un altre empleat de l'empre-

'��

��

sa, es desitja conèixer la data del casament i qui està casat amb qui;

no obstant, no és necessària aquesta informació si el cònjuge no

pertany a l'empresa. Cada empleat té una categoria (enginyer, se-

cretaria, venedor, directiva,...); l'empresa està interessada en guar-

dar informació més concreta de les següents categories: secretaria

(velocitat amb que escriu a màquina) i enginyer (especialitat ). Un

empleat no pot tenir més d'una categoria al mateix temps, i no és

necessari retenir informació sobre les categories que ha pogut tenir

anteriorment l'empleat.

Hi han onze departaments, cadascun amb un nom únic; un empleat

pertany sols a un departament. Cada departament té un número de

telèfon.

Per proporcionar els diferents tipus d'equipament, cada departa-

ment tracta amb diferents proveïdors; el més normal és que un pro-

veïdor proporcioni equipament a diferents departaments. Es desitja

enregistrar el nom i l'adreça de cada proveïdor i la data de la darre-

ra reunió entre el departament i el proveïdor.

Alguns empleats poden treballar en un, o més, projectes, però sols

poden tenir assignat un únic projecte en una ciutat. Per a cada ciutat

es desitja informació sobre la seva població. Els projectes són dife-

renciats per números de projecte i també és necessari enregistrar el

cost aproximant.

��%�� L'Ajuntament de la nostra Ciutat vol realitzar el manteni-

ment i control del mobiliari urbà: bancs, fanals, papereres, semà-

fors, tanques, ....

El mobiliari es compra a diferents proveïdors, cadascun dels quals

té un NIF i un nom (raó social, diferent per a cada proveïdor), en

una data determinada i per un preu; per raons pressupostàries sols

es considera "mobiliària urbà" aquells elements que tinguin un cost

inferior al milió de pessetes. Cada element del mobiliari ve identi-

ficat per un codi, té una descripció i és d'un tipus específic de mo-

biliari (dintre una classificació tancada que ha creat l'Ajuntament,

formada per un codi i una descripció). L'Ajuntament té reconeguts

�� '��

��

uns quants proveïdors per a cada tipus de mobiliari, als quals sem-

pre hi cal comprar. Cada peça de mobiliari es col·loca en un punt

de la ciutat que està identificat pel carrer i el número de l'habitatge

que té davant.

Els diferents tipus de mobiliari tenen una vida útil prevista, al cap

de la qual "caldria" reposar-los; malauradament hi han "brètols"

que practiquen l'esport de destrossar les propietats comunitàries, i

és relativament normal que molts elements no arribin al final de la

seva vida prevista. Les destrosses són descobertes, usualment, pels

agents municipals (identificats pel número de placa), els quals in-

formen del lloc i el tipus de mobiliari, la data i els danys causats.

��%��Després de múltiples reunions amb els diferents treballadors

del taller de reparacions d'automòbils , s'han arribat a les següents

conclusions:

Els nostres clients són els propietaris dels automòbils, els quals els

porten a reparar; és important que estiguin ben especificats, per tal

de poder realitzar correctament la factura, i localitzables, per si és

necessari consultar sobre alguna reparació.

A cada reparació es poden realitzar multitud d'operacions, per rea-

litzar cadascuna d'elles un mecànic determinat haurà trigat un

temps; el director ha insistit molt en que vol que resti constància d'-

aquests fets. De tots els mecànics que intervenen en una reparació

un d'ells serà el responsable.

A més a més, algunes reparacions inclouen la utilització de certa

quantitat de materials, dels quals es registra la descripció i el preu

unitari.

Totes les reparacions tenen una garantia de 6 mesos, i caldrà pre-

veure prou informació com per poder aplicar aquesta clàusula de la

forma adequada.�

�

�

��%�� En els múltiples viatges que feu per l'autopista Barcelona-

Mataró haureu vist un carrils especials a l'àrea de peatge que ser-

'��

��

veixen per pagar amb el "TeleTac", això és un petit dispositiu que

enganxat al parabrises del cotxe l'identifica en el peatge. L'empresa

d'autopistes CARESA que gestiona l'autopista Barcelona-Madrid,

vol implementar un sistema semblant, però es troba amb la dificul-

tat de que els vehicles es poden incorporar i sortir de l'autopista per

múltiples accessos. Una empresa d'electrònica els hi ha resolt a-

quests problemes tècnics i ara ens toca a nosaltres guardar la in-

formació necessària.

La experiència ens indica que gran part dels usuaris que utilitzen el

servei de "TeleTac" pertanyen a empreses i que són aquestes les

que paguen les factures de tota la seva flota d'automòbils, a les fac-

tures volen un detall, per a cada automòbil, dels trajectes que ha re-

alitzat, indicant en quin accés han entrat i quin han sortit i la data

en que s'ha realitzat; no obstant això, també hi ha una gran quantitat

d'usuaris particulars que tenen un únic cotxe. De tots els clients s'ha

de conèixer el seu nom, el nif, l'adreça i la domiciliació bancària.

Per tal de poder realitzar la factura s'ha de tenir constància de les

tarifes, és a dir, del cost del peatge entre dos accessos.

�

��%��El "Periòdic de Catalunya", com la majoria de diaris, té una

secció dedicada a informar sobre les pel·lícules que fan els dife-

rents cines (per tal que els lectores puguin anar o demanar informa-

ció, el diari indica l'adreça i el telèfon de cadascun) de les princi-

pals ciutats de Catalunya. La majoria de cines són multisales i, a

cada sala, es passen pel·lícules diferents dies de la setmana a diver-

ses hores. De les pel·lícules és important el títol, l'any d'estrena, la

nacionalitat, un petit resum de l'argument i la "classificació moral";

els cinèfils volen conèixer el nom del director i el dels protagonis-

tes principals.�

�

��%�� La “Academia del Cine Español” és molt coneguda per que

lliura cada any els premis Goya, malgrat això no és aquesta la seva

tasca principal, si no que és la de portar un control de l’exhibició de

pel·lícules arreu de l’estat espanyol. Tant ha augmentat el nombre

d’espectadors que han decidit crear un petit departament informàtic

per portar el control del taquillatge. Es donen les següents especifi-

cacions:

�� ' �

��

És necessari mantenir informació corresponent a totes les

pel·lícules estrenades als cinemes espanyols en els darrers anys.

Sobre cada pel·lícula cal conèixer informació (sobre tot la naciona-

litat) sobre el director, actors i productors que participen a la matei-

xa, com els premis que hagi pogut obtenir en els diferents festivals

internacional als qual s’hagi presentat (Cannes, Berlín, San Sebas-

tián, Hol·lywood, ...), tan la pel·lícula com qualsevol dels seus par-

ticipants. També interessa conèixer el nombre d’entrades venudes

en cadascun dels cinemes en els qual s’ha projectat.

També ens han fet els següents recordatoris:

Poden existir pel·lícules diferents amb el mateix títol, fins i tot, rea-

litzades al mateix any.

Hi ha persones que al llarg de la seva carrera han participat de dife-

rent forma en pel·lícules, o fins i tot, en una pel·lícula han fet

d’actor i d’alguna altre cosa (Santiago Segura, de director).

Existeixen pel·lícules “corals”, les quals poden tenir més d’un di-

rector o productor.

A cada pel·lícula, els actors poden realitzar diferents papers (encara

que és més normal que realitzin un de sol), per exemple: protago-

nista femení, actriu secundària, ..

De vegades, els festivals donen premis “ex-aequo”, o els deixen de-

serts.

�

��%�� Una gran superfície d'àmbit cultural que s'ha obert darre-

rament al centre de Barcelona, ens proposa crear una Base de Da-

des segons els següents requeriments:

Al Centre es venen discos i llibres, cada element s'identifica amb

un codi de barres diferent, els atributs descriptius són els típics d'a-

quests productes, diferents per discos i llibres, encara que els dos

'%� � ��

��

tenen preu. De vegades pot ser que es faci un descompte sobre al-

gun exemplar concret d’algun article que tingui algun petit defecte.

Els clients passen per les diferents caixes per pagar les compres, en

elles se’ls dona un tiquet que serveix pel cas de que es vulgui can-

viar algun producte, en aquest tiquet apareix el número de caixa on

s'ha pagat i el número d'operació de la caixa. Per tal de poder com-

provar els possibles errors (i depurar responsabilitats) és important

mantenir informació sobre quin empleat estava a cada caixa a cada

moment.

�

�

��%��% �

�

REPARACIONSURGENTS S.A.

1�/�0)�

número

data

N.I.F.En/Na

domicili

quantitat concepte

SUMA

Descompte

TOTAL

%

%IVA

�+��!�(�4�)

+3*�)7�/&+,*

preu import

ciutat

��

��%��' El Col·legi Oficial de Farmacèutics de Barcelona vol posar

en marxa un sistema de gestió de les diferents farmàcies de la pro-

víncia. Per això, està establint contactes amb empreses desenvolu-

padores de software a les quals explica la problemàtica dels seus a-

�� ''�

��

filiats i els exposa els seus requeriments. La informació més impor-

tant que aporta el col·legi és:

De cada farmàcia es vol conèixer: un número d'identificació i la se-

va adreça complerta. Una farmàcia pot tenir un o més propietaris

que poden ser, o no, els mateixos que els farmacèutics responsa-

bles. Una persona pot ser propietària o farmacèutic responsable d'-

una o més farmàcies. De tothom cal conèixer, el nom i el DNI i

dels farmacèutics, també, el nº de col·legiat.

Les farmàcies disposen d'un conjunt de productes, d'aquest interes-

sa saber la seva identificació, el nom, el fabricant, el preu de cost i

el preu de venda i si està subvencionat per la Seguretat Social. Les

farmàcies disposaran de lectors òptics, tan per les vendes com per

les entrades a magatzem, per tant fora interessant que els productes

puguin identificar-se de forma que aquest hardware pugui ser utilit-

zat correctament. Per tal de poder analitzar els moments en que cal

realitzar les comandes caldrà mantenir informació sobre les unitats

en existència, el ritme de vendes, ....

Existeixen diferents distribuïdors que es dediquen a la venda d'a-

quests productes a les farmàcies, cada distribuïdora treballa sols en

unes ciutats determinades, encara que les ciutats més importants

poden ser fornides per diferents distribuïdores. Un mateix producte

pot tenir preus de compra diferents segons la distribuïdora. Les

comandes es fan a les distribuïdores i acostumen a incloure dife-

rents quantitats de diferents productes.

�

��%��5 Donat el gran enrenou que s'ha produït amb l'oferta pública

d'accions (OPA) de Tabacalera, sembla interessant realitzar una

Base de Dades per tal d'emmagatzemar informació pel seu negoci

més important, la venda de tabac.

A la majoria de ciutats hi han unes botigues dedicades a l'expedició

de tabac nomenades expenedories de tabac o més familiarment es-

tancs. Aquest establiment tenen assignat per Tabacalera un número,

el Ministeri d'Hisenda els identifica per un NIF, tenen un propietari

i estan localitzats a un adreça.

'5� � ��

��

Cada fabricant de cigarretes pot elaborar diferents marques. D’una

mateixa marca poden existir amb diferents continguts de contami-

nants (nicotina i quitrà) catalogat com: 6��7�, �2��6��7� i � ��.

6��7�; Si un tipus no ha tingut cap mena de tractament especial per

eliminar els contaminants reb el de *��.

Els diferents estancs volen conèixer, les vendes que han realitzat,

cada dia, de cadascun del diferents tipus de cigarreta. També es vol

tenir un control, centralitzat, de les comandes que fan els estancs.

Com el preu pot variar amb el temps, és important poder calcular el

total de les vendes i les compres realitzades entre unes dates deter-

minades.

��%�� 2.- El COM (Comitè Olímpic de Madrid) us ha demanat un petit sistema d’informació per tal de poder controlar les proves de ciclisme de les properes olimpíades Madrid-2096. Heu desco-bert que dins el ciclisme hi han diferents especialitats, algunes in-dividuals i altres en equip, i que el més normal és que els corredors participin en proves dels dos tipus. De cada especialitat es realitzen diferents proves, i cal guardar els resultats (personal o de l’equip) que s’han obtingut. El ciclistes tenen el mateix tipus d’identificació que els famosos del problema anterior.

��%�� Donat el gran èxit que s'espera pel Festival d'estiu de Bar-

celona GREC 96, la gestió de la venda de les entrades per les dife-

rents actuacions cada vegada es fa més difícil.

Les actuacions es realitzen en tretze recintes diferents, situats tots

ells en diferents llocs de la ciutat de Barcelona. A cada recinte es

realitzen diferents actes (cada acte sols està programat en un recin-

te), algun dels quals es repeteixen durant varis dies i, fins i tot al-

guns, més d'una vegada al dia, a unes hores determinades.

Donada l'heterogeneïtat dels recintes, trobem alguns d'ells tenen els

seients numerats i altres que, ni tant sols, tenen seients; encara que

tots tenen una capacitat màxima. Quan no hi han seients numerats

el preu de l'espectacle sols depèn del dia i de l'obra, mentre que en,

�� '��

��

l'altre cas, també depèn de la situació de la cadira (anfiteatre, pla-

tea, ...).

Les entrades per a qualsevol espectacle es poden comprar a les gui-

xetes dels recintes o en qualsevol caixer automàtic de la Caixa de

Catalunya.

��%�� Un magatzem disposa de 15000 articles diferents classifi-

cats en 100 famílies d'articles, cada família té assignat un cert valor

de l'IVA. Cada article té, en cada moment, un preu de venda i un

preu de compra al majorista. Els articles es venen en diverses pre-

sentacions: unitats, capses de cinc, de deu, ....; cadascuna d'elles a

un preu, tant de compra com de venda, diferents; s'han definit 100

formes diferents de presentació.

1500 clients disposen de compte al magatzem, els quals per cada

compra se'ls fa un albarà i cada cert temps es genera una factura

amb tots els albarans del període (per terme mig uns 4 albarans per

factura i 25000 factures/any) la qual es pagada via domiciliació

bancària, encara que la factura és enviada al seu domicili. Cadascun

d'aquest clients autoritza a realitzar compres a un o més dels seus

empleats (normalment uns 3 per client), encara que sols un d'ells el

representa. Segons les seves característiques els clients estan classi-

ficats en 25 tipus; cada tipus de client disposa d'un descompte sobre

cada família d'articles.

Els particulars també poden realitzar compres, en aquest cas es fa

un únic albarà-factura anònim, d'aquestes compres es fan unes

50000 a l'any.

A cada albarà de compra, sigui anònima o d'un client, apareixen, de

mitjana, 4 articles diferents, cadascun d'ells amb la quantitat com-

prada i llur presentació. Cada venda estarà feta per un venedor

(l'empresa en té 25), l'identificador del qual apareixerà a l'albarà.

Donat que tant el tipus d'IVA com els preus de compra i venda va-

rien tot sovint, és important, per tal de realitzar correctament les

factures, mantenir un històric d'aquests valors.

'��

��

��%�� Un gran grup industrial es dedica a la fabricació d'electro-

domèstics de línia blanca (neveres, rentadores, rentavaixelles, ...)

amb varies marques diferents. Cadascuna de les marques "conce-

deix" la distribució en exclusiva per a una, o varies zones del país a

una empresa distribuïdora. Cada marca pot treballar amb varis dis-

tribuïdors i cada distribuïdora pot representa a varies marques. A-

questes concessions es signen per un termini de temps determinat,

prorrogables sempre que així ho convinguin les dues parts; i són

vàlides per vendre tots els productes de la marca. A fi de poder rea-

litzar millor les tasques de marketing és important conèixer la po-

blació i extensió de cadascuna de les zones.

Cada marca, per a cada tipus d'aparell disposa de diferents models,

cadascun d'ells amb unes certes prestacions i preu. Les empreses

distribuïdores tenen magatzems que faciliten la distribució dels a-

parells als diferents clients (botigues, grans superfícies, ...), encara

que aquests magatzems no sempre estan ubicats a la zona de distri-

bució que ha pogut aconseguir, i fins i tot, alguns d'ells cobreixen

més d'una zona. Interessa saber l'estoc actual de cada producte a

cada magatzem.

Les empreses distribuïdores serveixen comandes als diferents cli-

ents, identificant la comanda per un número intern de comanda, a la

comanda també hi consta el nº de sèrie de cada producte lliurat. Els

diferents clients tenen assignat, segons cada marca, un descompte

sobre el preu oficial de cada producte, per a cada tipus d'electro-

domèstic (neveres, rentadores, rentavaixelles, ...).

��%�� Una empresa dedicada al lloguer de pel·lícules té 30 sucur-

sals. Cada sucursal s'identifica amb un codi numèric. A més, cadas-

cuna té un nom, està ubicada en un carrer d'una determinada ciutat i

té un telèfon. De cada sucursal és imprescindible conèixer el nom

del carrer i la ciutat. Gràcies a la professionalitat del servei de cor-

reus el codi postal és prescindible, encara que interessant. fora bo

saber sempre el telèfon, però algunes vegades això no és possible

perquè s'obre una sucursal i Telefònica encara no ha donat d'alta el

�� '��

��

seu telèfon. A cada sucursal hi ha una sèrie d'estanteries cadascuna

d'elles amb uns quants prestatges on s'hi deixen les cintes quan no

estan llogades.

Cada pel·lícula està identificada per un codi. És imprescindible,

sempre, saber-ne el títol. A més, també es vol guardar informació

sobre l'any en que va aparèixer (mai abans del 1895, per raons òb-

vies), la seva durada (que oscil·la entre 15 i 240 minuts, segons la

pel·lícula), el tema principal i el secundari; també ha de constar el

preu de lloguer per dia, sent aquest imprescindible. Els temes s'i-

dentifiquen per un codi i és necessari conèixer-ne la descripció (a-

ventures, terror, ...).

D'una pel·lícula hi pot haver més d'una còpia (una cinta per còpia).

Les cintes només contenen una pel·lícula i són identificades per un

codi. Sempre cal saber quina pel·lícula hi ha enregistrada en cada

cinta, i a quina sucursal es troba. Quan sigui possible, també és in-

teressant saber a quin estanteria i a quin prestatge la podrem loca-

litzar. També es vol conèixer la seva durada (que no s'ha de con-

fondre amb la de la pel·lícula) que oscil·la entre 30 i 240 minuts;

quan no es coneix, s'assumeix que és de 180 minuts. Pel que fa al

format, aquest pot ser VHS o BETA, però quan no se sap es suposa

que el VHS. Finalment, per saber quan s'ha de retirar una cinta, es

guarda la data en que s'ha enregistrat, data que mai és anterior a l'1

de gener del 1995, dia de la inauguració.

Tot allò que fa referència als clients i als llogues és molt important;

cada client s'identifica pel seu DNI, però també es considera im-

prescindible conèixer-ne el primer cognom i el nom (el segon no

pot ser imprescindible atès que hi ha persones que no en tenen), ai-

xí com el carrer i la ciutat on viuen. Sempre que sigui possible és

força interessant conèixer l'edat (entre setze i cent anys), el sexe, el

codi postal i el telèfon. Quan un client lloga una cinta s'anota el seu

DNI, la cinta i la data; quan la retorna s'anota la data en que això

passa.

�

5��

��

��%�� Una empresa dedicada al transport internacional de mer-

caderies, amb extensió a tot l'àmbit europeu, té els següents aspec-

tes importants:

A.- Organització territorial de l'empresa: l'empresa disposa d'un de-

terminat nombre (no massa gran) de Delegacions i d'una gran quan-

titat d'Oficines. Cada Delegació té la responsabilitat d'un bon nom-

bre d'Oficines, de la qual depenen. Tant les Delegacions com les

Oficines s'identifiquen per un nom. A una determinada ciutat poden

haver-hi varies Oficines, però mai més d'una Delegació. S'ha de

suposar que no hi han ciutats amb nom repetit (al menys dintre

l'àmbit d'aquest cas).

B.- Personal de l'empresa: el personal de l'empresa es pot diferenci-

ar en dos grans grups: a) administratius, dels quals interessa el ni-

vell d'estudis, codificat per lletra; b) conductors, dels quals interes-

sa l'any d'obtenció del carnet de conduir i tipus de carnet. De tot el

personal de l'empresa es vol saber el codi d'empleat (que l'identifi-

ca), el DNI, el nom, l'adreça, any de naixement i estat civil. Els

administratius es consideren assignats a una determinada Oficina,

mentre que els conductors es consideren assignats a una determina-

da Delegació. Evidentment, tant uns com altres, poden anar canvi-

ant d'Oficina o Delegació (respectivament), i es vol constància his-

tòrica d'aquest fet.

C.- Activitat comercial de l'empresa: l'objectiu de l'empresa és a-

conseguir el màxim nombre de clients, i efectuar els viatges perti-

nents per tal de transportar les mercaderies segons les peticions d'-

aquests clients. Els clients estan identificats per un codi. Es vol co-

nèixer a més, el NIF, el nom, l'adreça, el telèfon de contacte. Evi-

dentment l'empresa, per dur a terme la seva activitat, disposa de

molts camions, identificats per un codi; dels camions es vol saber

també la matrícula, marca, model i càrrega màxima. Els viatges els

organitza sempre una Delegació i s'identifica per un codi intern de

cada Delegació (que pot repetir-se en diferents Delegacions). Per

cadascun dels viatges que s'han fet, cal conèixer: a) quin camió ha

estat utilitzat (doncs cada viatge utilitza un únic camió); b) quin, o

quins, conductors hi han anat (ja que en viatges llargs pot anar-hi

més d'un conductor), es vol saber, també, l'import de les dietes pa-

�� 5��

��

gades a cada conductor (ja que pot no ser el mateix per als diferents

conductors d’un mateix viatge); c) paquets (identificats per un codi

i dels quals es vol tenir informació sobre el seu pes) carregats i des-

carregats a cada ciutat i per a cadascun dels clients, en un mateix

viatge es poden deixar i/o recollir paquets a diferents ciutats per

encàrrec d'un mateix client; d) recorregut del viatge, es a dir, dia i

hora en que el camió va parant (no simplement passant) a diferents

ciutats per carregar o descarregar, suposarem que un viatge no pas-

sa (ni para) mai dues vegades per una mateixa ciutat

�

��%�� Per a la gestió del personal d'una Caixa d'Estalvis implan-

tada amb moltes agències a tot un país, es consideren el següents

supòsits:

Els empleats estan identificats per un codi d'empleat; serà impor-

tant conèixer la seva ciutat de residència, així com saber a quines

ciutats estan ubicades les diferents agències de la Caixa. Aquestes

agències estan identificades per un codi numèric de 4 dígits. Un

empleat, en un determinat moment treballa en una agència però pot

ser traslladat a una altra; inclòs pot tornar a treballar en una agència

a on ja hi havia treballat anteriorment. Interessa conèixer l'historial

del pas de cada empleat a les diferents agències.

Els empleats poden tenir titulacions acadèmiques, i es vol tenir

constància d'aquest fet, concretament l'any i el Centre Acadèmic

que els hi ha concedit. Els empleats tenen una determinada catego-

ria laboral (auxiliar, oficial 2ª, oficial 1ª,...), categoria a la que van

accedir, sempre per millorar sense "degradacions", i que només

perden si marxen definitivament de la Caixa. Es vol conèixer les di-

ferents categories que ha assolit cada empleat. Considerarem que

una vegada un empleat ha deixat definitivament la Caixa no hi tor-

narà a treballar mai més. Segons un conveni de l'empresa a cada ca-

tegoria li correspon un determinat sou base, un preu d'hora extra i

un coeficient de la Seguretat Social.

Alguns empleats estan afiliats a una (sola) Central Sindical. S'ha ar-

ribat al pacte de descomptar de la nòmina mensual la quota sindical

5��

��

pels afiliats a cada Central. Aquesta quota és única per a tots els

afiliats a una determinada Central.

Els empleats de la Caixa gaudeixen del dret d'excedència, per a un

període de temps determinat, que pot ser exercit en diverses ocasi-

ons al llarg de la seva vida laboral i per diverses causes. També

gaudeixen de la possibilitat de demanar diferents tipus preestablerts

de préstecs (per exemple: per matrimoni, per adquisició d'habitatge,

per estudis, ...) que poder ser o no concedits. En principi no hi ha

cap limitació en demanar diferents tipus de préstec, inclòs al mateix

temps, i es vol constància de si aquests préstec han estat concedits

o no. Cada tipus de préstec té establertes diferents condicions, de

les quals, en particular, ens interessa el tipus d'interès i el període

de vigència del préstec.

��%��% Una empresa de venda per catàleg ha de guardar informa-

ció dels diferents catàlegs que ha realitzat i distribuït l'empresa, s'i-

dentifiquen per un número de catàleg i contenen informació de di-

ferents productes amb el seu preu de venda; es suposa que no es

canvia el preu de cap producte fins que no s'edita el nou catàleg.

Dels catàlegs també interessa conèixer la seva data d'edició, perío-

de de vigència, número de fulls i número d'exemplars. Dels produc-

tes interessa, també, el codi de producte, que els identifica i la des-

cripció.

L'empresa necessita dades dels clients: DNI, el nom i l'adreça. Els

clients es classifiquen en dos tipus: a) els clients potencials, que són

clients que mai han comprat res, però dels quals interessa el nom-

bre de vegades que se'ls ha enviat catàlegs; b) els clients reals, que

són els que alguna vegada han comprat i dels quals es vol saber el

número de telèfon i totes les comandes que ens han fet fins ara. Els

clients potencials passen a ser reals un cop han fet la primera co-

manda.

Les comandes s'identifiquen per un número de comanda. Sempre

fan referència a un únic catàleg, demanen diversos productes i es-

pecifiquen la quantitat desitjada de cada producte. totes aquestes

dades, i a més, la data de la comanda, s'enregistraran. El catàleg al

�� 5 �

��

qual fa referència la comanda és important perquè permetrà saber

quins preu de venda s'aplicarà als productes de la comanda.

La forma de pagament pot ser de dos tipus, segons la forma de pa-

gament que hagi escollit el client: en efectiu o amb tarja de crèdit.

De les comandes que es paguen amb tarja es vol saber també el

número de tarja (16 dígits), la data de caducitat i si ja ha estat co-

brat o no.

L'empresa té diferents magatzems repartits pel territori, els magat-

zems s'identifiquen per un nom i es vol guardar la seva adreça, telè-

fon i la quantitat que tenen actualment en estoc de cadascun dels

productes que l'empresa ven. Els clients reals de l'empresa estan as-

signats al magatzem més proper de la seva residència. Cada magat-

zem haurà de servir les comandes dels clients que té assignats.

L'empresa té conductors per realitzar el transport dels productes,

aquests conductors s'identifiquen pel seu DNI; cadascun està assig-

nat a un únic magatzem en un moment determinat però pot anar

canviant de magatzem i inclòs tornar a un magatzem on ja havia es-

tat anteriorment. Es vol conèixer l'historial d'assignacions de cada

conductor.

Els magatzems realitzen trameses per tal de servir les comandes,

cadascuna d'elles està identificada per un número dins del magat-

zem que l'organitza. Una única tramesa serveix moltes comandes i

suposarem que cada comanda es serveix íntegrament amb una sola

tramesa. De les trameses interessa la data i el conductor que l'ha re-

alitzat.

��%��' Una biblioteca privada de gran volum, constituïda per so-

cis-lectors que abonen una quota mensual, vol informatitzar el seu

funcionament.

El títol de cada obra de l'esmentada Biblioteca és únic, és a dir, o-

bres diferents tenen títols diferents. En general, una obra ha estat

escrita per un o més autors en un ordre que figura als primers fulls

de l'obra, la qual pot constar de diferents volums o toms; a més, de-

5%� � ��

��

gut al gran nombre de lectors assidus, disposa de diferents exem-

plars de les obres més populars, encara que de vegades no tots els

volums o toms.

Particularment en obres de caràcter científic s'han anat incorporant

noves edicions de determinades obres.

Alguns socis sol·liciten les obres especificant el títol exacte, però

altres sols recorden un autor o autors, que no sempre és el primer o

primers de la llista que figura als primers fulls del llibre en qüestió.

Hi ha també socis interessats en certs temes, des quals els interessa

saber quines obres hi ha a la Biblioteca. Degut al volum de llibres i

a l'especialització alguns socis, es desitja poder accedir també per

subtemes a diferents nivells.

Quan s'adquireix una obra, la Biblioteca assigna a cada exemplar

un número de referència, amb el que entre altres coses es facilita la

seva localització al dipòsit de llibres.

Cada soci té dret a retirar en préstec els llibres que vulgui, per un

termini de 15 dies, prorrogables a altres 15 sempre que els exem-

plars estiguin disponibles o no sol·licitats per altres socis. Si al

sol·licitat un obra en préstec aquesta no està disponible, el soci pot

situar-se en cua d'espera per tal d'ésser avisar quan la seva

sol·licitat pugui ser atesa, és a dir, quan altre soci retorni el llibre.

��%��5 Els Reis Mags de l'Orient davant la creixent competència

del Pare Noël i Santa Klaus, volen modernitzar-se i millorar la ges-

tió de la seva tasca. Als Reis els agrada conèixer molt bé totes les

joguines existents al mercat; entre elles, els interessa distingir, no-

més, dos tipus de joguines: les educatives i les esportives; encara

que moltes joguines no són de cap d'aquests tipus i algunes ho són

dels dos alhora. De les joguines esportives volen saber si es tracta o

no d'un esport d'equip; de les joguines educatives, quina és, pri-

mordialment, la capacitat del nen que eduquen. De totes les jogui-

nes en general volen conèixer el nom, la descripció i l'edat a partir

de la qual són adequades; també els interessa la informació de qui-

nes joguines són equivalents entre elles.

�� 5'�

��

Els Reis tenen catalogats tots els països del món i les poblacions on

hi viuen els nens: Les poblacions tenen el seu nom que les identifi-

ca dintre el seu país. De les poblacions volen saber el nombre d'ha-

bitants i les països l'extensió.

Els Reis donen un codi identificador a cadascun dels nens, i a mes,

volen conèixer el nom, la data de naixement, la població on viu ac-

tualment,.... També vol conèixer la el comportament del nen al

llarg de l'any, el qual es valora de 0 a 10.

Cada nen escriu cartes als Reis, els quals donen a cadascun un nú-

mero que permet distingir les diferents cartes d'un mateix nen, però

no cartes de nens diferents. De les cartes volen saber la forma d'en-

viament i quines, i quantes, joguines demanen. Els Reis assignen

cada any i per a cada nen les joguines que li regalaran, que no sem-

pre coincideixen amb les que els nens havien demanat a les cartes;

hi volen tenir constància d'aquesta assignació.

��%�� La policia de tràfic d’un determinat país, dividit en demar-

cacions de tràfic, vol informatitzat el seu funcionament per tal de

tenir un millor control i, també, poder obtenir certes dades estadís-

tiques especialment pel que fa a multes i accidents.

De cada demarcació, globalment, només es volen tenir les dades

actuals referents al seu nombre d’habitants, nombre de vehicles i

nombre de conductors amb carnet, però, en canvi, es vol disposar

en tots moment de les dades històriques referents a les multes, ac-

cidents, vehicles i als diferents propietaris que cada vehicle pugui

haver tingut.

Les multes i els accidents són identificats per un codi, que serà i-

dentificador només dins de cada demarcació. D’un accident inte-

ressa saber l’hora i el lloc on s’ha produït, així com el(s) vehicle(s)

que si ha(n) vist involucrat(s), i també el(s) ciutada(ns) afectat(s).

D’aquest(s) darrer(s) volem saber si ere(n) o no conductor(s) en

l’accident, i també el dany físic rebut, que es qualificarà d’1 a 5 se-

gons la gravetat, significant 1 que ha resultat mort. Dels vehicles

55� � ��

��

anotarem l’estat en que han restat, valorat d’1 a 5, significant ací 1

que no ha hagut danys.

En un moment determinat, un vehicle té un únic propietari, que pot

anar canviant en successives vendes. Interessa, en els diferents

moments de cada compra, el seu quilometratge, i el seu estat de

conservació, valorat d’A a E, en sentit decreixent.

Les multes es posen a un vehicle i al seu propietari corresponent, i

s’especifiquen el lloc, el tipus d’infracció , l’import, etc. Un vehicle

ve determinat per la seva matricula (que consta d’una abreviatura

de la demarcació corresponent, i d’un número identificador dins la

demarcació).

��%�� Heu trobat feina (un contracte temporal, no creieu) a la

Generalitat i heu estat assignats al programa "Som molts més de sis

milions", dedicat al estudi de la bio-diversitat a Catalunya, és a dir

a realitzar un estudi de les diferents espècies animals existents al

Principat. La feina que teniu és col·laborar, donant suport informà-

tic, amb l'equip de treball que es dedica a l'estudi dels animals plu-

ricel·lulars triploblàstics celomats, grup dels protostomats, branca

dels artròpodes, classe dels insectes, subclasse dels pterigogens, or-

dre dels lepidòpters (segons la classificació de Carl von Linné, més

conegudes per papallones).

La feina consisteix en catalogar totes les espècies de papallones que

hi ha i els espècimens que es trobin a diferents col·leccions arreu

del país.

Com indica la taxonomia natural, un exemplar de papallona pertany

a una sola espècie, una espècie pertany a un sol família i un família

pertany a un únic subordre. Al Principat es troben 2 subordres, 73

famílies i unes 4700 espècies.

El nom comú que té una espècie de papallona pot variar segons la

comarca on es trobi la papallona, però dintre d'una determinada

comarca el nom comú de l'espècie és únic; un exemple podria ser la

papallona que a la Garrotxa (entre altres comarques) nomenen "va-

nessa dels cards", que és tracta de l'espècie "Cynthia cardui", que

�� 5��

��

pertany a la família dels papilionoïdeus i al subordre dels hetero-

neures.

Totes les papallones que formen part d'una col·lecció, han estat

capturades per una persona, encara que moltes vegades no es té in-

formació sobre qui ho ha fet. Una determinada persona pot ser pro-

pietària d'una col·lecció, i els exemplars de papallona que perta-

nyen a ella poden haver estats capturats pel propietari o per una al-

tra persona.

Es vol mantenir informació de la subordres, famílies i espècies a les

que pertanyen els exemplars de papallones, independentment de

que hagi estat capturat cap exemplar dels mateixos.

5��

��

��

��

��

��

El model relacional va ser introduït per Codd al 1969 en un article

titulat "Derivability, redundancy, and Consistency of Relations sto-

red in Large Data Banks" encara que la frase model relacional apa-

reix per primera vega al 1970 a l'article "A Relational Model for

Large Shared Data Banks", en aquest document es proposa un mo-

del de dades basat en la teoria de les relacions, on les dades s'es-

tructuren lògicament en forma de relacions (taules).

El treball de Codd presenta un nou model de dades que persegueix

una sèrie d'objectius, sent els principals:

• �� , el modus en que s'enregistren les dades

no influeix en la seva manipulació lògica i per tant els usuaris

que accedeixen a aquestes dades no han de modificar els seus

programes per canvis en l'emmagatzematge físic;

• �� , afegir, eliminar o modificar objectes de

la base de dades no repercuteix sobre els usuaris que estan acce-

dint a subconjunts parcials dels mateixos;

• �� , l'usuari pot representar les dades en la forma que

prefereixi;

• !��, les estructures lògiques de les dades presenten un

aspecte uniforme;

• "�#��, les característiques anteriors són simples i produei-

xen un model de dades fàcil de comprendre i utilitzar per l'usua-

ri.

Per assolir els objectius proposats Codd introdueix el concepte de

relació (taula) com estructura bàsica del model, totes les dades d'u-

na base de dades es representen en forma de relacions, en les quals

L’article de Codd apareix en el primer número de Transac-tions on Database Systems (TODS).

$%� � � ��

��

el contingut varia amb el temps. Per treballar amb les dades es pro-

posen una sèrie d'operadors bàsics (molts d'ells provinents de la te-

oria de conjunts) que conformen l'àlgebra relacional definida per

Codd al 1972. La teoria de la normalització presenta per Codd en

els seus primer treballs, elimina dependències entre atributs que o-

riginen anomalies d'actualització de la Base de Dades i proporcio-

nen una estructura més regular en la representació de relacions,

constituint un suport pel disseny de Bases de Dades relacionals.

Tots els articles publicats per Codd entre el 1969 i el 1979 confor-

men un model de dades conegut com RM/V1 (Relational Model

Version 1); a la compilació d'aquest model es troben 50 caracterís-

tiques que defineixen el model. Al 1979 Codd presenta a la reunió

de l'Australian Computer Society a Tasmania un article titulat "Ex-

tending the Database Relational Model for Capture more Meaning"

que molt sovint es conegut com RM/T, que es considera la primera

ampliació del model teòric original. Al 1985 Codd publica 12 re-

gles que han de complir tots els productes que es vulguin nomenar

relacionals, comprovant que cap dels existents en aquell moment

les compleix totes.

Al 1990 Codd publica el llibre "Relational Model Version 2" en el

qual recull tots els avanços realitzats des de la darrera compilació,

resultant un total de 333 característiques com definitòries del model

relacional. Els elements nous més important són: un nou tractament

dels valors nuls, suport de les diferents restriccions d'integritat, de-

finició més detallada de l'actualització de vistes, nous principis de

disseny de Bases de Dades, definició més complerta del diccionari

de dades, gestió de Bases de Dades distribuïdes.

Paral·lelament a la definició del model va anar evolucionant el

llenguatge de consultes, un dels primers precedents és el "Structu-

red English Query Language", SEQUEL, proposat per Chamberlin

al 1974 i implementat per IBM en el prototipus SEQUEL/XRM,

una millora d'aquest el SEQUEL/2 va ser implementat en primer

sistema "comercial" el System R de IBM. Al 1981 es presenta el

primer producte estàndard, el SQL, el qual és agafat com a referèn-

cia per multitud de fabricants esdevenint, de facto, l'estàndard en el

món de les Bases de Dades relacionals. El reconeixement de acto

�� $�

��

ho fan ANSI (American National Standards Intitute) i ISO (Interna-

tional Organization for Standardization) al 1986, definint el

SQL/86 o SQL 1. Una primera ampliació de l'estàndard, reconeixen

les restriccions d'integritat es presentada al 1989, SQL/89. Final-

ment a mitjans de 1992 apareix el document "International Stan-

dard ISO/IEC 9075:1992 Database Language SQL" refrendat per

ANSI i ISO i conegut com a SQL 2.

A l'any 1999 apareix una nova normativa coneguda com

SQL:1999, en el que es contempla per primera vegada l'ori-

entació a objectes.

��&�'��(��

El model relacional reuneix de forma reeixida una precisa definició

matemàtica amb una representació simple basada en taules.

Una Base de Dades relacional ve representada per una colla de tau-

les, tal com es pot veure a la figura 3.1.

�")!*�+,)� ,-.�(/� ,/.� 0/1,/.�� 0/1,/.&� 0!("�

� 00234 Joan Ros Martí 2

� 00186 Pere Boix Cabot 1

� 00387 Lluís Mans Tinent 2

+""�1,+)!(+� 0/*�� ,/.�

� 005894 Programació

� 004328 Bases de Dades

.+)(20!'+� +""�1,+)!(+� +'!.,��

� 005894 00234

� 004328 00186

� 004328 00387 �

�

!��"��"#��$��%��

$&� � � ��

��

Cada taula té assignat un nom únic a la Base de Dades; una fila d'-

una taula representa una interrelació entre un conjunt de valors, la

capçalera de la columna conté diferents noms, i per a cadascuna de

les columnes existeix un conjunt de valors possibles, nomenat do-

mini. Observant les taules es pot comprovar que cadascuna de les

files és una n-tupla ordenada de valors <d1, d2, ... dn> tals que cada

valor dj pren valors en el domini de la j-èsima columna.

Segons la teoria matemàtica de conjunts, donada una seqüèn-

cia de conjunts D1, D2, ... Dn, no necessàriament diferents,

una relació és un subconjunt del producte cartesià D1xD2x ...

xDn, on D1, D2, ... Dn són els dominis de la relació, i n és el

grau de la relació.

Un exemple es pot veure a la figura 3.2

D1 = {a, b, c, d } D2 = {1, 2 , 3}

*��*&� ��

�� <a, 1> <b, 1> ��

&� <a, 2> ��

�� <a, 3> <b, 3> �� <d, 3>

R = { <a, 1>, <d, 1>, <b, 2>, <c, 2>, <d, 2>, <c, 3>}

!��"��"��&��'�� (� ��)� �%��

Es pot comprovar que existeix una correspondència molt estreta

amb la representació tabular, amb l'única diferència de l'absència

del nom de les columnes. El nombre de n-tuples a la relació és la

cardinalitat de la relació; en general so els dominis són infinits, la

cardinalitat de la relació també ho pot ser.

D'acord amb les definicions anteriors es pot veure que:

�� $�

��

• Una relació és un conjunt de n-tuples, i per tant l'ordre d'aques-

tes a la relació no té cap importància i totes les n-tuples són dife-

rents.

• Cada n-tuple de la relació és una llista ordenada de valors, tals

que el i-èsim valor pertany al i-èsim domini, és a dir, que l'ordre

dels dominis si que té importància.

Una forma alternativa a la utilització de la posició com a referent

del domini és l'assignació d'un rol a cada aparició del domini a la

relació, aquest rols es diferencien per medi de noms simbòlics no-

menats atributs, els quals estan íntimament relacionats amb els

noms de les columnes a la representació tabular. És possible que di-

ferents atributs tinguin el mateix domini, els atributs indiquen dife-

rents papers (rols) o interpretacions, pel domini; per exemple, el

domini de tots els cognoms, pot fer el rol de 1er cognom o 2on

cognom.

Es pot veure d'una forma intuïtiva que una relació és una represen-

tació de la informació actualment coneguda d'un àrea d'interès, pe-

rò pot passar que no tota la informació sigui coneguda, és raonable

admetre que una relació, en un moment donat, contingui valors no

especificats; per tal de tenir en compte aquest fet es poden estendre

els dominis de les relacions afegint els nomenats valors nuls, els

quals representen l'absència d'informació.

Un model de dades és una eina formal per descriure la informació

d'interès per a una aplicació; hi han dos possibles nivells de des-

cripció: a) ��3��, el qual involucra les propietats ge-

nerals de les classes de valors i les classes de correspondències en-

tre ells; b) ��3��, al qual pertanyen els valors actuals

i les correspondències entre ells. Al model relacional el nivell in-

tensional correspon a la descripció (invariant amb el temps) de les

relacions (esquemes) i el nivell extensional al contingut de les rela-

cions (instàncies) en un moment donat.

Unes definicions més precises poden ser. Esquema de relació: un

nom (nom de la relació) i un conjunt de noms d'atributs, per indicar

un esquema de relació de nom R amb els atributs A1, A2, ... An,

s'escriu R(A1, A2, ... An). Un esquema de Bases de Dades és un

Formalment, l'associació en-tre atributs i dominis és esta-blerta per medi d'una funció dom: X ---> D, entre el con-junt d'atributs X = {A1, A2, ... An} i el conjunt de dominis D; així una n-tuple sobre el conjunt d'atributs X és una funció t que associa amb cada atribut Ai ∈ X un valor del domini dom(Ai), aquest valor és indicat amb la notació t[Ai].

$4� � � ��

��

conjunt d'esquemes de relació amb diferents noms de relació. Ins-

tància de relació (o simplement relació): defineix en un esquema

R(X) un conjunt finit r de n-tuples sobre X. Una instància de Base

de Dades (o Base de Dades) en un esquema de Base de Dades ( =

{R1(X1), R2(X2), ..., Rn(Xn)} és un conjunt de relacions {r1, r2, ...,

rn}, on cada ri està definit sobre l'esquema corresponent Ri.

ESTUDIANT (nom, cognom1, cognom2, número, curs)

ASSIGNATURA (nom, codi)

Esquema de Base de Dades amb dos esquemes de relació

�")!*�+,)� ,-.�(/� ,/.� 0/1,/.�� 0/1,/.&� 0!("�

� 00234 Joan Ros Martí 2

� 00186 Pere Boix Cabot 1

� 00387 Lluís Mans Tinent 2

+""�1,+)!(+� 0/*�� ,/.�

� 005894 Programació

� 004328 Bases de Dades

Base de dades amb dues relacions

!��"��$��%��)��*��

�

Una relació es defineix com un conjunt de n-tuples, per definició

els elements d'un conjunt són tots ells diferents, i per tant cal que

totes les tuples de la relació també ho siguin; això vol dir que dues

tuples no poden tenir la mateixa combinació de valors per tots els

seus atributs, de totes formes és normal trobar subconjunts d'atri-

buts d'un esquema de relació R amb la propietat de que no es poden

trobar, a cap relació r de R, la mateixa combinació de valors per

aquests atributs; aquests conjunts d'atributs reben el nom de super-

claus de l'esquema de relació R; cada relació té al menys una su-

perclau (superclau trivial) formada per tots els atributs.

�� $5

��

Es nomena clau d'un esquema de relació R a una superclau

que té la propietat addicional de que treien qualsevol atribut

el conjunt restant no és superclau.

El valor d'un atribut clau es pot fer servir per a identificar de forma

única una tupla a la relació. Cal tenir en compte que la definició de

superclau i clau es basa en l'esquema de relació i per tant la restric-

ció cal que es compleixi per a qualsevol cas de relació, per tant a-

questa propietat cal que sigui invariant amb el temps.

Normalment, un esquema de relació pot tenir més d'una clau, en

aquest cas, cadascuna de les claus es nomena clau candidata. És

normal designar una de les claus candidates com la clau primària

de la relació, aquesta clau candidata serà la que s'utilitzi per a iden-

tificar les tuples a la relació, s'acostuma a expressar subratllant l'a-

tribut.�

��3��6��

Hi han moltes situacions en que no es poden utilitzar valors dels

dominis, en aquests casos es necessiten els valors nuls, a la figura

3.4 es presenta una taula amb els participants a la conferència de

Yalta.

7+')+� ,/.� .�18,/.� 0/1,/.�

� Franklin Delano Roosevelt

� Winston ∅ Churchill

� Charles ∅ deGaulle

� Joseph ∅ Stalin �

!��"+�&��'��%��'��

Si es considera els valors de l'atribut MIG_NOM, es pot veure que

sols està especificat per Roosevelt, mentre que el valor nul s'ha fet

servir pels altres, encara que per motius diferents a cadascun. De-

Gaulle era francès i per tant no tenia MIG_NOM; Churchill era un

La conferència de Yalta la van realitzar els aliats als fi-nal de la II Guerra Mundial.

$��

��

Lord britànic i, per tant, segur, que tenia un MIG_NOM, encara

que no el coneguem; Stalin era un georgià i probablement tenia un

patronímic com a MIG_NOM encara que ell l'havia abandonat

quan va canviar el seu nom original, Dzhugashvili, pel pseudònim.

La tupla referida a DeGaulle conté un valor no existent o atribut no

aplicable, com no té sentit no es pot especificar cap valor. La tupla

de Churchill conté un valor desconegut, en realitat existeix un valor

associat amb la tupla, però aquest encara no és conegut a la Base de

Dades. En el cas de Stalin conté un valor de no informació, no es té

noticia si existeix o no un valor associat amb la tupla i en el cas de

que existeixi no es coneix quin és.

D'aquesta forma es pot veure que els tres valors nuls a la relació re-

presenten tres casos diferents d'absència d'informació, es podien di-

ferenciar molts més.

La majoria d'implementacions comercials de Gestors de Bases de

Dades sols consideren un únic valor nul, ∅ (idèntic sigui quin sigui

el domini de l'atribut), en aquest cas cal considerà un nou valor lò-

gic, ? (UNKNOWN), que és la resposta a la pregunta A = ∅; les

taules de veritat corresponents a aquesta lògica de tres estats són

��

9� F

�� V

:� ?

�� 9� �� :�

9� V F ?

�� F F F

:� ? F ?

/� 9� �� :�

9� V V V

�� V F ?

:� V ? ? �

!��",�-.��

ANSI/SPARC en un informe presentat al 1975 diferencia 14 tipus diferents de valors nuls.

�� $$

��

�

�

��4�'�� ;��

Un SGBD ha de proporcionar tots els medis necessaris per mante-

nir consistent la informació, i no deixar a elecció dels que fan les

aplicacions el control de la coherència de les dades, els mecanismes

que utilitza el sistema per a realitzar aquesta funció reben el nom de

restriccions d'integritat.

Les restriccions d'integritat es poden classificar en quatre tipus di-

ferents: a) integritat de domini, restriccions dels valors que pot

prendre un atribut; b) integritat d'entitat, cap component d'una clau

primària pot tenir un valor nul de cap tipus; c) integritat referenci-

al, per a cada valor d'una clau forana ha d'existir un valor igual d'u-

na clau candidata dintre el mateix domini; d) integritat semàntica,

restriccions que governen la realitat del problema.

El domini forma part de la pròpia definició del model relacional i

cada vegada se'l dona més importància. El domini correspon als va-

lors que poden prendre els atributs.

En termes informals, es pot considerar una clau primària d'una re-

lació com un identificador únic per aquesta relació; cal millorar la

definició ja que en molts casos es poden trobar diferents conjunts

d'un o més atributs que identifiquen la relació; en aquest cas es par-

la de l'existència de varies claus candidates de les quals s'estriarà

una com a clau primària i les altres seran claus alternatives.

Una definició més formal fora, un descriptor K (conjunt d'un

o més atributs) és una clau candidata d'una relació R si i sols

si compleix, independentment del temps, aquestes dues pro-

pietats: a)�6�� , en qualsevol moment donat no existeixen

dues tuples de R amb el mateix valor de K; b) ��t, si

K és compost no es podrà eliminar cap atribut de K sense

destruir la propietat d'unicitat.

Les restriccions referencials i semàntiques hauran d'especi-ficar en quin moment s'ha de comprovar la condició, si immediatament després de que la comanda ha estat uti-litzada o al final de la trans-acció i immediatament abans de que es produeixi el canvi a la Base de Dades; també hau-ran d'incorporar una resposta amb el que faran en el cas de que s'intenti viola la restric-ció. les restriccions de domini i d'entitat no es podran violar mai.

$<� � � ��

��

La restricció d'entitat diu que cap dels atributs que formen la clau

primària d'una relació bàsica pot prendre valors nuls. D'una forma

més informal, a una base de dades mai es podrà enregistrar infor-

mació sobre quelcom que no es pugui identificar. A les claus alter-

natives es podrà o no permetre la presencia de valors nuls, però per

definició de clau candidata hauran de complir la condició d'unicitat.

Moltes vegades es dona el cas de que el mateix atribut està repre-

sentat en vàries taules, a la figura 3.1 es pot veure que a la taula

MATRICULA apareix l'atribut ALUMNE que correspon a l'atribut

NÚMERO de la taula ESTUDIANT, i ASSIGNATURA que cor-

respon a l'atribut NOM de la taula ASSIGNATURA. Aquests dos

atributs són exemples del que es coneix com a claus foranes.

Un descriptor FK d'una relació R1 és una clau forana de R1 si satis-

fà: a) els atributs de FK tenen el mateix domini que els atributs de

la clau candidata CK d'altre relació R2, els atributs de FK es diu

que referencien la relació R2; b) un valor de FK en qualsevol tupla

t1 de R1 coincidirà amb un valor de CK d'alguna tupla t2 de R2 o se-

rà nul (tots els atributs del descriptor). A partir de la definició ante-

rior es defineix la regla d'integritat referencial: a una Base de Dades

no poden existir valors de clau forana sense concordança.

Cadascuna de les referències podrà particularitzar-se amb com res-

pon al fet d’esborrar o modificar files de la taula referenciada, això

reb el nom d’accions referencials. La idea general subjacent darrera

de les accions referencials és que de vegades és possible mantenir

la integritat referencial no sols rebutjant una actualització o esbor-

rat que intenta violar-la sinó compensant la modificació d'alguna

altra forma, la forma de realitzar-la ve definida a l'acció referencial.

Si es suposa que T1 és la taula referenciada amb la clau candidata

T1.CK i T2 és la taula referenciadora amb la clau forana T2.FK.

Si la definició no porta associada les clàusules ON DELETE ni ON

UPDATE es rebutjarà:

• un INSERT en T2 o un UPDATE en T2.FK que provi d'introduir

un valor de T2.FK que no existeixi com un valor de T1.CK.

�� $�

��

• un DELETE en T1 o un UPDATE en T1.CK que intenti deixar

sense referències a T2.

La clàusula ON DELETE defineix el que fa el sistema quan s'inten-

ta esborrar una tupla de la taula T1 que té coincidència amb altre de

la taula T2, les possibles especificacions són:

• (�")(�0), és equivalent a ometre la clàusula ON DELETE.

• 0+"0+*�= esborra (en cas de múltiple integritat referencial l'-

aplicació fora de forma recursiva, en cascada) totes les files co-

incidents de T2.

• "�)�,!'', cada component de la clau forana prendria en valor

nul.

La clàusula ON UPDATE defineix el que fa el sistema quan s'in-

tenta modificat una tupla de la taula T1 que té coincidència amb al-

tre de la taula T2, les possibles especificacions són:

• (�")(�0)= és equivalent a ometre la clàusula ON DELETE;

• 0+"0+*�= modifica (en cas de múltiple integritat referencial

l'aplicació fora de forma recursiva, en cascada) totes les files co-

incidents de T2.

• "�)�,!'', cada component de la clau forana prendria en valor

nul.

En qualsevol organització existeixen multitud de restriccions i re-

gles que determinen la realitat del problema; són regles empresari-

als o organitzatives que defineixen l'entorn on es mou el problema.

La Base de Dades ha d'estar capaç de validar totes aquelles opera-

cions que poden venir afectades per les regles de l'organització,

Aquest tipus de restricció reben el nom genèric de regles semànti-

ques.

Un altre tipus de restricció semàntica són les afirmacions (asserti-

ons), una afirmació és un predicat que expressa una condició que la

Base de Dades sempre ha de complir, totes les restriccions anteriors

es poden considerar formes especials d'aquest tipus de restricció

encara que s'acostuma a reserva per aquelles restriccions que no

poden considerar-se incloses en cap tipus de les anteriors. Donat

que aquestes restriccions s'han de comprovar cada vegada que es

realitza un canvi a la Base de Dades i la definició pot arribar a ser

La regla semàntica més ele-mental afecta als valors que pot prendre un columna en concret, la restricció de do-mini sols permet una defini-ció estàtica, mentre que mol-tes vegades es farà necessari la utilització d'altres taules per a definir una condició complexa.

<%� � � ��

��

molt complexa no acostumen a incorporar-la els productes comer-

cials.

��5�'��

A la representació esquemàtica del model relacional cal indicar, la

clau primària, les claus alternatives, l’obligatorietat o no dels atri-

buts (poden prendre el valor nul?), les referències, les claus foranes

i les accions referencials, a la figura 3.6 es té un exemple d’aquesta

notació

!��"/��$��%��

A l’exemple anterior es tenen dues taules, la taula departament té

com a clau primària el codi, i com a clau alternativa el nom, tots els

seus atributs són obligatoris; la taula empleat té com a clau primà-

ria el DNI i com alternativa (nom, cognom 1, cognom 2), el depar-

tament és una clau forana, les columnes departament i telèfon po-

den prendre el valor nul. La referència existent entre les taules indi-

ca que la columna departament de la taula empleat sols pot prendre

valors que existeixin a la columna codi de la taula departament, no

es poden esborrar departaments que tinguin empleats i en el cas de

que es canvia el codi d’un departament es canviaran els departa-

ments de tots els empleats que en pertanyin.

��"1>*��

Actualment el mercat dels Sistemes Gestors de Bases de Dades

(SGBD) mou uns 9.000 milions d'euros, més totes les eines auxili-

Codi = Departamentupd(C); del(R)

�.�'�+)Dni <pk> not nullDepartament <fk> nullNom <ak> not nullCognom 1 <ak> not nullCognom 2 <ak> not nullAdreça not nullTelèfon null

*��+()+.�,)Codi <pk> not nullNom <ak> not nullLocalització not null

�� <�

��

ars que mouen més de doble. A continuació es presenten dos dels

més venuts: Oracle9i en el món dels grans servidors i Microsoft

Access 2000 en el món de l'ofimàtica.

Microsoft Access és el SGBD relacional més utilitzat de Microsoft,

es tracta d'un gestor basat en PC capaç de guardar, ordenar i recu-

perar dades per una gran varietat d'aplicacions. Access proporciona

una interfície gràfica d'usuari que permet crear taules, consultes,

formularis i informes, i un entorn de programació que permet crear

aplicacions en VBA (Visual Basic for Applications). També pro-

porciona ajudants (wizards) oer simplificar els diferents processos

de creació i utilització de Bases de Dades. Per tan és pot considerar

com una eina RAD que porta incorporat un gestor de Bases de da-

des.

Microsoft Acces es pot utilitzar com un sistema personal en un únic

PC o com un sistema multi-usuari per una xarxa de PC. Porta com

a motor de Base de Dades Jet Engine (encara que també pot portar

Microsoft Data Engine (MSDE), el qual és compatible amb el de

SQL Server), el qual guarda totes les dades, taules, índexs, consul-

tes, formularis i informes en un únic fitxer (amb sufix .MDB) el

qual està basat en una estructura ISAM.

Oracle9i està basat en l'arquitectura client-servidor, un servidor o-

racle està format la base de dades (les dades en brut, el diccionari

de dades i els fitxers de controls) i una instància (una sèrie de pro-

cessos i de memòria RAM en el servidor que proporciona accés a la

base de dades). dintre de la base de dades apart de taules, Oracle u-

tilitza altres objectes: clusters, índexs, vistes, sinònims, seqüències,

funcions, procediments, paquets, disparadors,....

Mentre que en Access tot la informació la tenim en un fitxer i es

possible crear un aplicatiu que parli directament (o utilitzant dife-

rents recursos del sistema Operatiu) amb aquest, en Oracle la única

forma d'arribar a la informació és utilitzant el Sistema Gestor de

Bases de dades.

<&� � � ��

��

�

�

��

��

��

��

Mentre que el model conceptual representa conceptes i està pensant

per ser utilitzant com eina de comunicació entre persones, el model

relacional és un tipus de model lògic que utilitza representacions de

la informació adequades per ser tractades de forma fàcil per un sis-

tema Gestor de Bases de Dades.

El procés de transformació d'un model a un altre és força algorís-

mic tal com es pot observar amb les regles que es presenten a con-

tinuació.

��

Les associacions del tipus un-a-molts són les que es presenten amb

més regularitat en els dissenys reals, totes elles es transformen al

model relacional efectuant una "propagació de claus", la clau pri-

mària de l'entitat "pare" passa, com a clau forana a l'entitat "filla".

A les figures següents 4.1, 4.2, 4.3 i 4.4 es poden veure exemples

d'aquestes transformacions

�

�

�� !�"�� #�#$��$%��%��

� !"�##! DniNom

��$ �$%�&�CodiNom

Codi = Departamentupd(C); del(R)

� !"�##! Dni <pk> not nullDepartament <fk> not nullNom not null

��$ �$%�&�Codi <pk> not nullNom <ak> not null

�� &�� '��(��

��

��

�� "�� #�#$��%��)��* ��

�� +�"�� #�#$��%��)��* ��

�� "�� #�#$��$%��* ��

A la vista dels exemples anteriors es pot constatar com s’ha perdut

la informació sobre la participació de l'entitat "pare" (tot pare ha de

$'�!%()*+MatrículaMarcaModel

�� #!&$DniNom

Dni = Propietariupd(C); del(R)

$'�!%()*+Matrícula <pk> not nullPropietari <fk> not nullMarca not nullModel not null

�� #!&$Dni <pk> not nullNom not null

,'$� �TítolAutor

%'#�'NomCiutat

Nom = Museuupd(C); del(R)

,'$� �Títol <pk> not nullAutor <pk> not nullMuseu <fk> null

%'#�'Nom <pk> not nullCiutat not null

-+*�&�DniNom

� !�'-��ReferènciaDescripcióPreu

Dni = Clientupd(C); del(R)

-+*�&�Dni <pk> not nullNom not null

� !�'-��Referència <pk> not nullClient <fk> nullDescripció not nullPreu not null

�� .

��

tenir fills?), aquesta informació caldrà implementar-la posterior-

ment.

��

Per a cada associació binària del tipus molts a molts es crearà una

nova taula S que la representi, a aquesta taula s'inclouran com a

claus foranes de S, les claus primàries de les taules que representin

les entitats que participen a l'associació, llur combinació formarà la

clau primària de S. Si les dues entitat tenen una participació obliga-

tòria, les figures 4.5, 4.6 i 4.7 representen transformacions per les

diferents cardinalitats, es pot veure, que el mateix que el cas anteri-

or hi ha pèrdua d'informació respecte a les cardinalitats.

�� ,�"�� $��#�#$��$%��%��

�

�

�� -�"�� $��#�#$��* ��)��%��#

��

� �)$++$

�%�+�$�DniNom

� !/�-��CodiNom

Codi = Projecteupd(C); del(R); cpa

Dni = Empleatupd(R); del(C); cpa

�%�+�$�Dni <pk> not nullNom not null

� !/�-��Codi <pk> not nullNom not null

� �)$++$ Projecte <pk,fk> not nullEmpleat <pk,fk> not null

%$� *-'+$

�#�'�*$&�DniNom

$##*0&$�' $CodiNom

Codi = Assignaturaupd(C); del(C); cpa

Dni = Estudiantupd(C); del(C); cpa

�#�'�*$&�Dni <pk> not nullNom not null

$##*0&$�' $Codi <pk> not nullNom not null

%$� *-'+$ Estudiant <pk,fk> not nullAssignatura <pk,fk> not null

�1� � &�� '��(��

��

��

�� .�"�� $��#�#$��$%��* ��

��2��

Una entitat associativa es pot considerar com una associació del ti-

pus molts-a-molts que té "atributs", per tal el resultat de la trans-

formació serà equivalent a l'anterior, però afegint a la nova taula els

atributs de l'entitat associativa, les figures 34.8, 4.9 i 4.10 són uns

exemples d'aquest cas �

�

�� /�� $%��%��

�

�� 0�� * ��)��%��

�#�'�*$&�DniNom

$##*0&$�' $CodiNom

%$� *-'+$ Any

Codi = Codiupd(C); del(C); cpa

Dni = Dniupd(C); del(C); cpa

�#�'�*$&�Dni <pk> not nullNom not null

$##*0&$�' $Codi <pk> not nullNom not null

%$� *-'+$ Codi <pk,fk> not nullDni <pk,fk> not nullAny null

$0 $�$

&!*DniNom

&!*$DniNom

Dni = Noiaupd(C); del(R); cpa

Dni = Noiupd(C); del(R); cpa

&!*Dni <pk> not nullNom not null

&!*$Dni <pk> not nullNom not null

$0 $�$ Noi <pk,fk> not nullNoia <pk,fk> not null

�%�+�$�DniNom

� !/�-��CodiNom

� �)$++$ Hores

Codi = Projecteupd(C); del(R); cpa

Dni = Empleatupd(R); del(C); cpa

�%�+�$�Dni <pk> not nullNom not null

� !/�-��Codi <pk> not nullNom not null

� �)$++$ Projecte <pk,fk> not nullEmpleat <pk,fk> not nullHores not null

�� 3

��

�

��

�� !�� $%��* ��

��.��4�2��

�

La única característica peculiar d'una associació reflexiva es que es

realitza entre una sola entitat, per realitzar la transformació el mi-

llor és considerar l'entitat dues vegades, cadascuna d'elles amb el

rol apropiat, fer la transformació i tornar a "unir" les dues taules "i-

guals", tal com mostra l'exemple de la figura 4.11 �

&!*DniNom

&!*$DniNom

$0 $�$ Intensitat

Dni = Noiaupd(C); del(C); cpa

Dni = Noiupd(C); del(C); cpa

&!*Dni <pk> not nullNom not null

&!*$Dni <pk> not nullNom not null

$0 $�$ Noia <pk,fk> not nullNoi <pk,fk> not nullIntensitat not null

�� &�� '��(��

��

��

�� !!�"�� 1��2��

��1��5��

Es nomena entitat feble a aquella que necessita un identificador ex-

tern, aquesta identificació ve donada per l'identificador d'una entitat

externa (entitat forta) amb la qual està relacionada per medi d'una

associació d'identificació. Per eliminar la feblesa de l'entitat cal in-

corporar a la taula resultant de l'entitat feble l'identificador de l'enti-

tat forta, tal com es mostra a la figura 4.12

Cal "enfortir" totes les entitats febles abans de continuar amb la transformació al model re-lacional.

Cap

Subordinat

MANA

�%�+�$�DniNom1er Cognom2on CognomSalariData naixement

Dni = Capupd(C); del(N)

�%�+�$�Dni <pk> not nullCap <fk> nullNom not null1er Cognom not null2on Cognom nullSalari not nullData naixement not null

MANA

�%�+�$�6-$�DniNom1er Cognom2on CognomSalariData naixement

�%�+�$�6#')! �*&$�DniNom1er Cognom2on CognomSalariData naixement

Dni = Capupd(C); del(N)

�%�+�$�6-$�Dni <pk> not nullNom not null1er Cognom not null2on Cognom nullSalari not nullData naixement not null

�%�+�$�6#')! �*&$�Dni <pk> not nullCap <fk> nullNom not null1er Cognom not null2on Cognom nullSalari not nullData naixement not null

�� 7

��

�� !��1�%��

��3��

Al model relacional hi han entitats i associacions, les quals s’hau-

ran de transformar en taules i referències, el més simple és la trans-

formació de les entitats ja que sols cal para cadascuna de les enti-

tats crear una taula que inclogui tots els atributs de l'entitat i agafa

l'identificador com a clau primària.

Les associacions un-a-un presenten una certa ambigüitat i pot resul-

tar difícil transformar-les al model relacional, la figura 4.13 presen-

ta diferents composicions lògica que són compatibles amb la com-

posició conceptual. Estriar-ne una o altra dependrà, de cada pro-

blema en concret. Per resoldre aquesta ambigüitat és possible utilit-

zar el concepte d'entitat dominant, a una associació un-a-un es con-

sidera que una entitat és dominant si té una participació més com-

plerta que l'altra a l'associació, o si una de les entitats participa amb

més associacions que l'altra.

Sempre que es tingui un as-sociació un-a-un, cal com-provar que no es tracta d'una única entitat.

��+�0$-*8CodiCiutatNIF

"$-�' $NúmeroData

Codi = Delegacióupd(C); del(R)

��+�0$-*8Codi <pk> not nullCiutat not nullNIF <ak> not null

"$-�' $Delegació <pk,fk> not nullNúmero <pk> not nullData not null

79� � &�� '��(��

��

�

�� !+�(�1��1��$� ��)�� #�#��

Si les dues entitats tenen una participació obligatòria, la figura 4.14

pot representar una possible solució vàlida

$a1a2

)b1b2

Model conceptual

a1 = a1upd(C); del(R)

$a1 <pk> not nulla2 not null

)b1 <pk> not nulla1 <fk,ak> not nullb2 not null

Model relacional amb dues taules, entitat A dominant

b1 = b1upd(C); del(R)

a1 = a1upd(C); del(R)

$a1 <pk> not nullb1 <fk,ak> not nulla2 not null

)b1 <pk> not nulla1 <fk,ak> not nullb2 not null

Model relacional amb dues taules, sense entitat dominant

b1 = b1upd(C); del(R)

$a1 <pk> not nullb1 <fk,ak> not nulla2 not null

)b1 <pk> not nullb2 not null

Model relacional amb dues taules, entitat B dominant

$a1 <pk> not nulla2 not nullb1 <ak> not nullb2 not null

Model relacional amb una taula, entitat A dominant

)b1 <pk> not nulla1 <ak> not nullb2 not nulla2 not null

Model relacional amb una taula, entitat B dominant

�� 7�

��

�� !��"�� $%�*�� *� ��%��1��$�#

��

Si una de les entitats té una participació opcional es pot considerar

que l'altra és dominant, la figura 4.15 presenta un exemple d'aquest

cas

�� !,�"�� #�#��$%��3 ��4��$��

Si les dues entitats tenen una participació opcional, cap d'elles,

considerant sols la solució domina a l'altra, la figura 4.16 represen-

ta una de les possibles solucions

� !"�##! DniNom

$##*0&$�' $CodiNom

� !"�##! Dni <pk> not nullCodi Assignatura <ak> not nullNom not nullNom Assignatura not null

-+*�&�CodiNom

�$ /$NúmeroTipusLímit

Codi = Clientupd(C); del(C)

-+*�&�Codi <pk> not nullNom not null

�$ /$Número <pk> not nullClient <fk,ak> not nullTipus not nullLímit not null

7�� &�� '��(��

��

�� !-�� #�#��$��

�

�

��:��

�

Per tal de transformar les generalitzacions del tipus subclasse-

superclasse es tenen diferents alternatives, les semàntiques especí-

fiques de cada problema, i sobre tot el fet de que les subclasses o

les superclasses participen en altres associacions permetrà per a ca-

da cas discernir quina és la transformació més adequada. Les figu-

res 4.17, 4.18 i 4.19 presenten exemples d'aplicació de les diferents

estratègies.

Donat que en molts casos les tres solucions són factibles, acostuma

a ser una bona idea, comprovar com queda el disseny global de la

Base de Dades en tots els casos i triar el més adequat.

;!%�DniNom

�!&$DniNom

Dni = Donaupd(C); del(R)

Dni = Homeupd(C); del(R)

;!%�Dni <pk> not nullDona <fk,ak> nullNom not null

�!&$Dni <pk> not nullHome <fk,ak> nullNom not null

�� 7�

��

�� !.�5�� 6*��1��6�

�

�� !/�5�� 61��6�

�� #!&$DniNomAdreçaData naixement

�#�'�*$&�CursEspecialitat

� !"�##! DepartamentTítol

Dni = Dniupd(C); del(C)

Dni = Dniupd(C); del(C)

�� #!&$Dni <pk> not nullNom not nullAdreça not nullData naixement not null

�#�'�*$&�Dni <pk,fk> not nullCurs not nullEspecialitat not null

� !"�##! Dni <pk,fk> not nullDepartament not nullTítol not null

�%�+�$�DniNomSalari

�* �-�*'Àrea

$�%*&*#� $�*'Nivell

!"*-*$+Especialitat

!"*-*$+Dni <pk> not nullNom not nullSalari not nullEspecialitat not null

�* �-�*'Dni <pk> not nullNom not nullSalari not nullÀrea not null

$�%*&*#� $�*'Dni <pk> not nullNom not nullSalari not nullNivell not null

7�� &�� '��(��

��

�� !0�5�� 6*��6�

En cas de dubte la més utilitzada és la de generar tant els "pares"

com els "fills" heretant aquests l'identificador del "pare.

��7�%��

Una vegada transformat el model conceptual en el lògic equivalent

caldrà realitzar una sèrie de millores.

La primera es tractarà de comprovar si és possible eliminar física-

ment files de les diferents taules, moltes vegades ens trobarem en

que semànticament és necessari poder eliminar files, però que "re-

lacionalment" hi han problemes, sobre tot per que la fila eliminada

és clau forana d'alguna altra taula. En aquest cas caldrà afegir una

nova columna a la taula amb un atribut del tipus "Actiu" que tingui

com a domini un valor booleà. Després sols caldrà fer un esborrat

lògic posant l'atribut anterior a "Fals".

$�+��$DniNomData naixementClub

<�+!-*#�$temps 100mtemps 200m

"!&�*#�$temps 1500mtemps 5000m

$�+��$Dni <pk> not nullNom not nullData naixement not nullClub not nullTipus not nulltemps 100m nulltemps 200m nulltemps 1500m nulltemps 5000m null

�� 7.

��

Una altre tema a comprovar és l'existència de claus alternatives,

aquestes segurament s'hauran descobert ja en el disseny conceptual,

caldrà indicar-les, numerar-les i comprovar si la que s'ha triat com

a clau primària és la més adequada.

De vegades cap de les claus candidates és una bona opció per triar-

la com a clau primària, en aquest casos es pot crear un nou atribut

(que es vagi incrementant de forma automàtica per a cada nova lí-

nia) i utilitzar-lo com a clau primària, deixant la resta de claus com

alternatives. Aquesta mena de claus rep el nom de clau artificial, (o

clau tècnica o clau subrogada, ....).

El darrer element a tenir en compte és l'acció referencial lligada a

cadascuna de les claus foranes, s'han de preveure les accions a

prendre davant l'intent d'esborrat o actualització d'una clau primària

que tingui claus foranes associades.

��9��

Per tal de poder veure la utilització de tots els elements metodolò-

gics anteriorment exposats es presenten a continuació dos casos re-

solts:

��= D'una empresa dedicada al lloguer d'automòbils es co-

neixen els següents fets:

• Un determinat client pot tenir en un moment donat diferents llo-

guers.

• Un lloguer el realitza un únic client, però pot involucrar dife-

rents cotxes.

• És important contemplar les dades de començament i final pre-

vist del lloguer.

• Tot cotxe pot estar assignat a un determinat garatge.

• Cada lloguer el realitza una determinada agència.

També es vol guardar informació sobre aquelles persones que han

demanat informació, malgrat no hagin, encara, llogat un cotxe.

Aquesta columna no conté cap mena d'informació i per tan l'usuari no ha de poder ni veure-la ni modificar-la.

71� � &�� '��(��

��

0$ $�0�Adreça

-!&� $-��NúmeroData inici

-!�>�MatrículaMarcaModelColor

-+*�&�DniNomAdreçaTelèfon

-!&#'+�$&�NomAdreçaData

$0?&-*$NomAdreça

$"�-�$ Data fi

�

�� *�� !�

0$ $�0�Adreça

-!&� $-��NúmeroAgènciaClientData inici

-!�>�MatrículaGaratgeMarcaModelColor

-+*�&�DniNomAdreçaTelèfon

-!&#'+�$&�NomAgènciaAdreçaData

$0?&-*$NomAdreça

$"�-�$ MatrículaNúmeroData fi

�� !�� !�

�� 73

��

Codi = Agènciaupd(C); del(R); cpa

Matrícula = Matrículaupd(R); del(R)

Número = Contracteupd(R); del(R)

Dni = Clientupd(R); del(R)

Codi = Agènciaupd(C); del(R); cpa

Codi = Garatgeupd(C); del(N); cpa

0$ $�0�Codi <pk> not nullAdreça <ak1> not null

-!&� $-��Número <pk> not nullClient <fk2> nullAgència <fk1> not nullData inici not null

-!�>�Matrícula <pk> not nullMarca not nullModel not nullColor not nullActiu not nullGaratge <fk1> null

-+*�&�Dni <pk> not nullNom not nullAdreça not nullTelèfon not nullActiu not null

-!&#'+�$&�Nom <ak1> not nullAdreça not nullData not nullActiu not nullAgència <fk1> not null

$0?&-*$Codi <pk> not nullNom <ak1> not nullAdreça not nullActiva not null

$"�-�$ Matrícula <pk,fk2> not nullContracte <pk,fk1> not nullData fi null

�� 1�� !�

�

#�� = Donada la gran quantitats d'Eleccions al Congrés de

Diputats que ha de supervisar l'Estat, el "Ministerio del Interior"

vol tenir un informació centralitzada per tal de realitzar el control

de les diferents Eleccions. En primer lloc es voldria tenir un arxiu

històric dels polítics de l'Estat, que contingui informació de les se-

ves afiliacions als diferents partits al llarg de la seva trajectòria po-

lítica, fins i tot, en moments no electorals.

Cada Elecció té una data de convocatòria (la qual l'identifica) que

és la del dia en que es fan les votacions. L'Estat està dividit en pro-

víncies, les quals poden tenir un nombre d'escons variables per a

cada Elecció.

Les persones, independents o d'un o més partits que es presenten a

les convocatòries d'Eleccions s'agrupen en forma de candidatures.

Interessa guardar els resultats de les diferents convocatòries per a

cadascuna de les províncies. Els partits poden presentar candidatu-

res a totes, o només algunes, de les províncies.

7�� &�� '��(��

��

�� #!&$DniNom

-$&�*�$�' $SiglaNomResultat

�+�--*8Data

$"*+*$-*8NúmeroData iniciData fi

�$ �*�SiglaNom

� !<*&-*$Nom

-! �#�!&� �Escons

�

�� +�� *��

�� #!&$DniNom

-$&�*�$�' $DataProvinciaSiglaNomResultat

�+�--*8Data

$"*+*$-*8PartitNúmeroPersonaData iniciData fi

�$ �*�SiglaNom

� !<*&-*$Nom

-! �#�!&� �DataProvinciaEscons

�� $&@� DniDataProvinciaSigla

��

�� 77

��

Data = Dataupd(C); del(R); cpa

Nom = Provinciaupd(R); del(R); cpa

Data = Dataupd(R); del(R); cpa

Nom = Provinciaupd(C); del(R); cpa

Sigla = Part itupd(C); del(R); cpa

Dni = Personaupd(R); del(R); cpa

Codi = Candidaturaupd(R); del(R); cpa

Dni = Dniupd(C); del(R); cpa

�� #!&$Dni <pk> not nullNom not nullViu not null

-$&�*�$�' $Codi <pk> not nullData <fk2,ak1,ak2> not nullProvincia <fk1,ak1,ak2> not nullSigla <ak1> not nullNom <ak2> not nullResultat nullActiva null

�+�--*8Data <pk> not null

$"*+*$-*8Partit <pk,fk2> not nullNúmero <pk> not nullPersona <fk1> not nullData inici not nullData fi null

�$ �*�Sigla <pk> not nullNom <ak1> not nullActiu not null

� !<*&-*$Nom <pk> not null

-! �#�!&� �Data <pk,fk2> not nullProvincia <pk,fk1> not nullEscons not null

�� $&@� Dni <pk,fk1> not nullCandidatura <pk,fk2> not null

�� ,�� 1��

��+��:��

Una qualitat important en el disseny és mirar de reduir al màxim la

redundància. si es té el disseny

EMPLEAT (Dni, Nom, Data-naix, Adreça, Codi-dept, Nom-

dept, dni-cap-dept)

PROJECTE (dni, codi-proj, hores, nom-emp, nom-proj)

es pot veure com es repeteix el nom del departament i el dni del cap

del departament per a cada número de departament a la primera re-

lació, i el nom del projecte i el nom de l'empleat a la segona de les

relacions.

Altra problema molt seriós que presenta el disseny anterior és el

conegut com anomalies d'actualització, les quals es poden classifi-

car en anomalies d'inserció, anomalies d'esborrat i anomalies de

modificació.

$��A��, es poden contemplar dos exemples diferents

d'anomalies: a) si es vol inserir un nou empleat a la relació EM-

�99� � &�� '��(��

��

PLEAT, s’ha d’incloure valors referits al departament en el qual

treballa (o valors nuls si encara no té cap departament assignat),

aquests valors han de ser consistents amb el nom del departament i

del cap que ja estigui assignats a aquest departament; b) si es vol

inserir un nou departament que encara no té empleats caldria intro-

duir una tupla amb els valors referits als empleats com a valors

nuls, però això és impossible ja que el dni és la clau i no pot ser

nul.

$�� A5��, si es vol esborrar la fila corresponent al

darrer empleat d'un departament, la informació corresponent a a-

quest departament desapareixerà de la Base de Dades.

$��, si es vol canviar el cap d'un departa-

ment donat, caldrà modificar les files corresponents a tots els em-

pleats que treballen a aquest departament, si resta alguna fila sense

modificar la Base de Dades esdevindrà inconsistent.

Per tal d'aconseguir un disseny que no presenti totes els problemes

presentats anteriorment, Codd (1972) va presentar un procés pel

medi del qual es pot "certifica" la bondat d'un disseny i el seu grau

de "normalitat", aquest procés rep el nom de teoria de la normalit-

zació i es basa en les dependències que existeixen entre els dife-

rents atributs d'una relació.

Existeixen diferents nivells de normalitzacions de FN1 a FN5, a la

majoria de dissenys s'intenta assolir el nivell FNBC (Forma normal

de Boyce-Codd), una definició informal fora, que les propietats re-

presentades a totes les columnes depenguin sols de la clau primària.

Al disseny anterior es pot veure, entre altres, com el nom del depar-

tament depèn del codi del departament i aquesta columna no és

clau primària. Si s'ha fet un disseny conceptual com cal els disseny

relacionats sempre surten completament normalitzats. �

�

��4��Transformeu els dissenys conceptuals dels exercicis 2.1.1-28 a dis-

senys relacionals.

��

��

��

��

En un entorn de Bases de Dades (no distribuït) es tindrà un Sistema Ges-

tor de Bases de Dades ( SGBD ) que gestionarà un o més "Bases de Da-

des independents", cadascuna d'elles treballarà a una zona diferent de

memòria de l'ordinador i tindrà les seves característiques pròpies, en el

llenguatge de l'estàndard oficial SQL reben el nom de catàleg es constru-

eix amb la sentència (apart de múltiples paràmetres físics)

��

�� !

��"#

� !$" %�&'�

�!��(!'

�!��!��

)��"#

*"�)$ ��%'��%

��%'��

��+�'"!

$%�

�$!��!''"#

� !�� "�� #�$��%�&�� #�� ' ��( ��

� � ��

��,� � ' ��( ��

��

El nom d'un catàleg no podrà tenir més de 8 caràcters. Els jocs de caràc-

ters defineixen com emmagatzemarà el SGBD les cadenes de caràcters i

les cadenes de caràcters nacionals. En aquest moment es creen els usuaris

administradors de la Base de Dades, INTERNAL, SYS i SYSTEM. Un

catàleg es pot considerar com una col·lecció d'esquemes, a la majoria

d'implementacions s'assimila l'esquema al conjunt d'objectes que són

propietat d'un usuari determinat, i per tant l'esquema i l'usuari tenen el

mateix nom, es crea un esquema al crear un usuari, la sentència utilitzada

és

La figura 5.1 presenta l'estructura "físic-lògica" d'un sistema de Bases de

Dades

Els objectes que es poden trobar dintre un esquema són: taules, vistes,

restriccions, seqüències, sinònims, procediments, funcions, paquets i dis-

paradors

Per donar nom a l'esquema i als seus components cal tenir en compte les

següents consideracions

• Els noms hauran de tenir de 1 a 30 caràcters.

• El nom sols podrà contenir caràcters alfanumèrics i els signes _, $ i #.

• Els noms no es diferenciaran per majúscules i minúscules.

• Els noms sempre començaran per un caràcter alfabètic.

• Un nom no podrà ser una paraula reservada.

• En un espai de noms dos objectes no podran tenir el mateix nom.

• Utilitzar noms descriptius i pronunciables.

• Utilitzar normes consistents de noms per tota la Base de Dades.

Els espais de noms són:

• A les Bases de Dades: els esquemes, els usuaris, els sinònims públics.

• Als esquemes hi ha diferents espais de noms:

− Les taules, les vistes, les seqüències, els sinònims privats, els pro-cediments, les funcions, els paquets i les instantànies.

− Les restriccions.

− Els disparadors.

− Els índexs.

− Els clusters. • A les vistes i taules: les columnes.

� ��

�� -�

��

• Als paquets: els procediments i funcions.

Si es vol eliminar un esquema i, opcionalment, tots els seus elements

Si es vol canviar les característiques d'un usuari, per exemple una nova

contrasenya

Quan usuari es connecta amb la Base de Dades obre una sessió, aquesta

sessió es podrà modificar utilitzant la comanda

Amb els paràmetres anteriors ( i molt més d'altres que en té) l'usuari pot

canviar les característiques de la seva sessió, aquestes estaran en vigor

fins que l'usuari tanqui la sessió.

��,��.��

Cada valor utilitzat a una base de dades ha de pertànyer a un tipus de da-

des definit, el qual indicarà quina mena de propietats té el valor i de quina

forma el tractarà el SGBD. Els tipus e dades definits internament poden

ser de tipus caràcter, numèric, data o bytes.

El tipus de dades de caràcters són:

� �� !��"�

� ��#�$�%�#��#&��

� � �� !�'��(��)��**�� "�� !��!��"�+�� '��**��(�� (��)�� !��,��+�� '��-��(��**��)�� !��%��.��.��+��#��"�� !��%��+��"�� !��%��%��*��+�/0��1��/�"�� !��%��%��.��.��+��#��"�� !��%��*��%��+�/��2�/�"�� !��%��%��+��"�� !��%��+�/��2�/�"�� !��%��+�'��3�#��4�(��)�"�� !��%��+��#3��"�

��/� � ' ��( ��

��

'0!$�12�3�1��4��5�'0!$�6�67 específica una cadena de caràcters de

llargada fixa de n caràcters o bytes. Si s'insereix una cadena més curta de

valor predefinit, el SGBD l'omple amb espais en blanc. Per defecte la

llargada és 1, i el valor màxim que pot prendre és de 2000 bytes.

�'0!$�12�3�1��4��5�'0!$�6�67 específica una cadena de caràcters de

llargada fixa de n caràcters o bytes codificat segons el joc de caràcters

nacionals. La mida màxima que pot tenir una dada d'aquest tipus és de

2000 bytes.

,��52�3�1��4��5�'0!$�6�7 específica una cadena de caràcters

de llargada variable fins a n caràcters o bytes. No hi ha valor per defecte i

el valor màxim que pot prendre és de 4000 bytes.

�,��52�3�1��4��5�'0!$�6�7 específica una cadena de caràcters

de llargada variable fins a n caràcters o bytes codificat segons el joc de

caràcters nacionals. No hi ha valor per defecte i la mida màxima que pot

prendre és de 4000 bytes.

Per valors tipus caràcters: es van comparant caràcter a caràcter segons

l'ordre que ocupen a la taula de caràcters, existeixen dues semàntiques de

comparació: si els dos valors són CHAR o NCHAR és compren comple-

tant amb blancs (blank-padded), en cas contrari és fan sense completar. A

la taula següent es presenten exemples d'ambdues semàntiques.

completat amb blancs sense completar

'ab' > 'aa' 'ab' > 'aa'

'ab' > 'a ' 'ab' > 'a '

'ab' > 'a' 'ab' > 'a'

'ab' = 'ab' 'ab' = 'ab'

'a ' = 'a' 'a ' > 'a'

'�%�7� específica una cadena de caràcters (els caràcters hauran d'estar

codificats en un únic byte per caràcter) de llargada variable fins a

4294967295 by (4 Gby) caràcters.

��%�)� específica una cadena de caràcters (els caràcters hauran d'estar

codificats en un nombre fix de byte per caràcter) de llargada variable fins

a 4294967295 by (4 Gby) caràcters, codificat segons el joc de caràcters

nacional.

El tipus de dades numèric és:

��

��

� ��$�1�2.�18��6�3�67 aquest tipus de dades permet emmagatzemar nú-

meros enters o reals des del 5.0*10-130 a 9.9*10125 amb 38 dígits de preci-

sió. * representa la precisió (el nombre total de dígits) i � representa l'es-

cala (nombre de dígits a la dreta del punt decimal). Si es vol definir un

nombre enter amb una precisió de p dígits es farà, +� '�,�-*., si es vol

definir un nombre real, +� '�,.

la següent taula indica com s'emmagatzemen el números depenen de la

precisió i de l'escala.

Dada Especificació Emmagatzemana

7 456 123.89 NUMBER 7 456 123.89

7 456 123.89 NUMBER (9) 7 456 1234

7 456 123.89 NUMBER (9, 2) 7 456 123.89

7 456 123.89 NUMBER (9, 1) 7 456 123.9

7 456 123.89 NUMBER (6) fora precisió

7 456 123.89 NUMBER (7, -2) 7 456 100

7 456 123.89 NUMBER (-7, 2) fora precisió

0.012 34 NUMBER (4, 5) 0.012 34

0.000 12 NUMBER (4, 5) 0.000 12

0.000 127 NUMBER (4, 5) 0.000 13

0.000 001 2 NUMBER (2, 7) 0.000 001 2

0.000 001 23 NUMBER (2, 7) 0.000 001 2

Existeixen diferents tipus de dades relacionades amb el temps, uns per-

meten guardat punts en el temps (DATE i TIMESTAMP) i altres inter-

vals de temps (INTERVAL....). Totes Ells estan formats per una sèrie de

camps:

'�9.� :��.��9.�� :��.��;��

YEAR -4712 fins 9999 Qualsevol enter

MONTH 01 fins 12 0 fins 11

DAY 01 fins 31 (segons el mes i

l'any)

Qualsevol enter

HOUR 00 fins 23 0 fins 23

MINUTE 00 fins 59 0 fins 59

SECOND 00 fins 59.9(n) (n és la preci-

sió)

0 fins 59.9(n) (n és la preci-

sió)

��<� � ' ��( ��

��

�!�7 serveix per emmagatzemar la data i l’hora (des de 1/1/4712 AC

fins els 31/12/9999 DC), en el cas de no especificar l’hora es considera les

00:00:00.

�"��!�(� 1� �� 6� 7 és una ampliació del tipus DATE, que permet

guardar fins a mil milionèsimes de segon. n indica la precisió a la fracció

de segons (per defecte 6).

"��$:!��4!$� 1�� 6��%��%��0� 7 indica un interval de temps,

serveix per anys i mesos. n indica el nombre de dígits en els anys (entre 0

i 9, per defecte 6).

"��$:!��!4�1�6��%��'%��1��6�7 indica un interval de temps,

serveix per dies fins segons. n indica el nombre de dígits en els dies i la

precisió a la fracció dels segons (entre 0 i 9, per defecte 6).

Normes de comparació entre dates: per valors tipus data: una data anteri-

or es considera més petita que una posterior; 21/3/1968 < 1/11/1986.

També cal recordar el tipus de resultat a l'efectuar algunes operacions:

[data] ± [data] = [interval]

[data] ± [interval] = [data]

[interval] ± [interval] = [interval]

[numero] * [interval] = [interval]

Les dades binàries es guarden en els tipus de dades:

��%�) Dades binàries sense estructura, de llargada variable fins un límit

de 4294967295 by (4 Gby).

�*"�7 dades binàries emmagatzemades en fitxers externs a la Base de

Dades, de llargada variable fins a 4294967295 by (4 Gby).

��-��

Dintre d'un esquema de Bases de Dades l'element principal d'agrupació

de la informació és la taula. Les taules es defineixen per medi de la sen-

tència CREATE TABLE que té una sintaxi

�� =�

��

Un exemple de creació de taula pot ser

La definició d'una taula temporal té la mateixa persistència que la d'una

taula normal, però les dades sols les dades sols existeixen dintre d'una

transacció (per defecte o indicant ON COMMIT DELETE ROWS), o

sessió (indicant ON COMMIT PRESERVE ROWS), és a dir en quin mo-

ment es produeix el truncament de la taula. Si es defineixen com a glo-

bals són visibles per totes les sessions. Per exemple

Una vegada creada la taula és possible modificar la seva estructura, això

es fa amb la comanda

Exemples d'aplicació són

� ��!�!.��"��* ��"�� !��6��1�7�"�#�1�� 877�(�#�1��1#��!��9��3�3��!��29��4"�� !��4��1#�":�77�� 777�(��4��;�� !��**��'��(� ��,��)�"�

CREATE TABLE Estudiant ( Nom VARCHAR2 (25), Cognoms VARCHAR2 (30), DataNeixement DATE, Nota NUMBER (3, 1) CONSTRAINT CH_EstudiantNota CHECK (Nota IS NULL OR Nota BETWEEN 0 AND 10), Professor VARCHAR2 (30) DEFAULT USER CONSTRAINT NN_EstudiantProfessor NOT NULL, CONSTRAINT PK_Estudiant PRIMARY KEY (Nom, Cognoms))

CREATE GLOBAL TEMPORARY TABLE Prova ( Codi CHAR(5) CONSTRAINT PK_Prova PRIMARY KEY, NouPreu NUMBER (7, 2)) ON COMMIT PRESERVE ROWS

� ��!��7�"#�1�� 777��'3�0�#��4��1#��(��4��1�#)�� (�*��3�0�#��4��1#�� (�*��#�1��1#�� '��9��3�3��(��29��4�(��4��1#��)�� (�� *��#�1��1�#�� (��#�1��1#�� (�� *�� (��*��#��#�1��

��>� � ' ��( ��

��

Per últim una taula també es pot eliminar, per això la comanda és

L'opció en cascada esborra totes les restriccions d'integritat referencial

que l'apunten.

Si es volen esborrar totes les files d'una taula mantenint la definició origi-

nal de la taula es fa

��/��

Un Sistema Gestor de Bases de Dades ha de proporcionar tots els medis

necessaris per mantenir consistent la informació, i no deixar a elecció

dels que fan les aplicacions el control de la coherència de les dades, els

mecanismes que utilitza el sistema per a realitzar aquesta funció reben el

nom de restriccions d'integritat.

Les restriccions d'integritat es poden classificar en quatre tipus diferents:

a) integritat de domini, restriccions dels valors que pot prendre un atribut;

b) integritat d'entitat, cap component d'una clau primària pot tenir un va-

lor nul de cap tipus; c) integritat referencial, per a cada valor d'una clau

forana ha d'existir un valor igual d'una clau candidata dintre el mateix

domini; d) integritat semàntica, restriccions que governen la realitat del

problema.

ALTER TABLE Estudiant MODIFY Professor VARCHAR2 (35)

ALTER TABLE Estudiant ADD Curs CHAR(1) CONSTRAINT CH_EstudiantCurs CHECK (Curs IN (’1’, ’2’, ’3’)

� �� !��7�"�#�1��!��"�

� ��!��7�"�#�1��

�� ?�

��

És molt important que cap dels llenguatges que permetin manipular la

Base de Dades permeti modificar les dades sense tenir en compte totes les

restriccions emmagatzemades al diccionari de dades.

Es pot definir un domini com un conjunt de valors escalars, tots del ma-

teix tipus, dintre del qual poden prendre valors uns atributs. La forma de

definir-los haurà de contemplar, de quin tipus de dades són, si existeix un

valor per defecte, i les condicions que hauran de complir

Per exemple

En termes informals, es pot considerar una clau primària d'una relació

com un identificador únic per aquesta relació; cal millorar la definició ja

que en molts casos es poden trobar diferents conjunts d'un o més atributs

que identifiquen la relació; en aquest cas es parla de l'existència de dife-

rents claus candidates de les quals s'estriarà una, com a clau primària i les

altres seran claus alternatives.

En SQL una restricció de clau primària formada per una única columna

es defineix afegint una nova restricció a la columna

si es tracta d'una clau formada per múltiples columnes, cal afegir una res-

tricció de taula

El domini forma part de la pròpia definició del model re-lacional i cada vegada se'l dona més importància, encara que la majoria de fabricant no l'incorporen en els seus pro-ductes. El domini correspon als valors que poden prendre els atributs.

� ��1%��1#��9��%3�3�� !��,��"�� !�!��4�"��"�� !�!��4�"��<�8�#3��4%��1#�;�"�

Provincia VARCHAR2(10) DEFAULT ’Barcelona’ CONSTRAINT NN_PersonaProvincia NOT NULL CONSTRAINT CH_PersonaProvincia CHECK (Provincia IN (’Barcelona’, ’Tarragona’, ’Lleida’, ’Girona’))

Moment VARCHAR2(10) DEFAULT SYSDATE

Usuari VARCHAR2 (30) DEFAULT USER

� !��4�"� ��*��<��

�� ' ��( ��

��

en el cas de que sigui una clau alternativa, les sintaxis són

cal recordar que en el cas d'una clau primària s'està indicant la impos-

sibilitat que tingui valors nuls, mentre que per les claus alternatives caldrà

especificar-lo explícitament. A continuació es presenten diferents exem-

ples

Una restricció d'integritat referencial designa una columna o combinació

de columnes com a clau forana i estableix una interrelació entre la clau

forana i una clau primària, o alternativa, d'una altra o la mateixa taula,

nomenada clau referenciada.

Un descriptor FK d'una relació R1 és una clau forana de R1 si satisfà:

� �!��4�"� ��*��<��8��%��1#��

�!��4�"��=��!��4�"��=��8��%��1#��;��

CREATE TABLE Empleat( Dni VARCHAR2 (10)CONSTRAINT PK_Empleat PRIMARY KEY, SegSocial VARCHAR2 (10)CONSTRAINT UN_EmpleatSeguretatSocial UNIQUE, Nom VARCHAR2 (40))

CREATE TABLE Estudiant ( Nom VARCHAR2 (15), Cognoms VARCHAR2 (30), LlocNaixement VARCHAR2 (30), Edat NUMBER(3) CONSTRAINT NN_EstudiantEdat NOT NULL, CONSTRAINT PK_Estudiant PRIMARY KEY (Nom, Cognom))

CREATE TABLE Persona ( Dni VARCHAR2 (9) CONSTRAINT PK_Persona PRIMARY KEY, Nom VARCHAR2 (15) CONSTRAINT NN_PersonaNom NOT NULL, Cognom1 VARCHAR2 (30) CONSTRAINT NN_PersonaCognom2 NOT NULL, Cognom2 VARCHAR2 (30), LlocNaixement VARCHAR2 (30), CONSTRAINT UN_Persona UNIQUE (Nom, Cognom1, Cognom2))

��

��

• Els atributs de FK tenen el mateix domini que els atributs de la

clau candidata CK d'altra relació R2, els atributs de FK es diu que

referencien la relació R2.

• Un valor de FK en qualsevol fila t1 de R1 coincidirà amb un valor

de CK d'alguna fila t2 de R2 o serà nul.

• En el cas de claus compostes els atributs components hauran de co-

incidir o ser nuls.

A partir de la definició anterior es defineix la regla d'integritat referenci-

al: a una Base de Dades no poden existir valors de clau forana sense con-

cordança. La referència sempre s'haurà de fer a una clau candidata

La sintaxi de les claus foranes per una columna és

per claus multi-columna

Un exemple podria ser

Un exemple de clau forana de més d'una columna

!��4�"�� !��7�"��8��%��1#��;�� 4��0��#��

!��4�"��.��<��8��%��1#��;�� !��7�"��8��%��1#��;�� 4��0��#��

CREATE TABLE Estudiant ( Codi VARCHAR2 (5) CONSTRAINT PK_Estudiant PRIMARY KEY, Nom VARCHAR2 (20), Cognoms VARCHAR2 (15), Curs VARCHAR2 (1) ) CREATE TABLE Assignatura ( Codi VARCHAR2 (6) CONSTRAINT PK_Assignatura PRIMARY KEY, Nom VARCHAR2 (20) CONSTRAINT UN_AssignaturaNom UNIQUE) CREATE TABLE Matricula ( Alumne CONSTRAINT FK1_Matricula REFERENCES Estudiant(Codi) ON DELETE CASCADE, Assignatura CONSTRAINT FK2_Matricula REFERENCES Assignatura(Codi), CONSTRAINT PK_Matricula PRIMARY KEY (alumne, assignatura) )

��,� � ' ��( ��

��

Per defecte quan es defineix una clau forana les accions referencials, per

defecte es consideren estrictes, és a dir, que no es pot esborrar ni modifi-

car una clau candidata que tingui claus foranes que la referencïin. Es pot

modificar aquest restricció respecte a l'esborrat, indicant que s'esborrin en

cascada o en posin (si és possible) les claus foranes a nul, la sintaxi és:

La resta d¡'accions referencials no es poden indicar de forma declarativa i

cal implementar-les amb disparadors (capítol 4).

En qualsevol domini d'aplicació, després d'aplicar totes les restriccions

anteriors, encara poden restar múltiples regles de negoci sense especificar

a la Base de Dades, les restriccions d'aquesta mena reben el nom de res-

triccions semàntiques, s'especifiquen utilitzant la sentència

La limitació més important és que la condició sols es pot referir a colum-

nes d'una única taula, en el cas que no sigui possible implementar-les

amb aquest mecanisme, caldrà recórrer als disparadors (capítol 4). Un e-

xemple d'aplicació es pot veure a la següent definició d'una taula

CREATE TABLE Oficina ( Entitat CHAR (4), Codi CHAR (4), Adreca VARCHAR2 (30), Telefon CHAR(9), CONSTRAINT PK_Oficina PRIMARY KEY (Entitat, Codi) ) CREATE TABLE Compte ( Entitat, Oficina, Numero CHAR(10), Saldo NUMBER (10,2) CONSTRAINT CH_CompteSaldo CHECK (Saldo >= 0) CONSTRAINT NN_CompteSaldo NOT NULL, CONSTRAINT FK_Compte FOREIGN KEY (Entitat, Oficina) REFERENCES Oficina (Entitat, Codi), CONSTRAINT PK_Compte PRIMARY KEY (Entitat, Oficina, Numero) )

� ��'��(��)�

�!��4�"��<�8�#3��4;�"�

�� -�

��

��

Les restriccions es poden comprovar en dos moments diferents o en el

moment de "modificar" la taula o diferir la comprovació fins quan es rea-

litza la confirmació ( /� 01 ); una restricció pot definir com diferible,

o no, amb la sintaxi

Per defecte les restriccions són no diferibles. En el cas de comprovació

diferida ( (�!�,,2'�� ) es tindran taules que violaran de forma tempo-

ral la restricció fins el moment en què finalitzi la transacció. Si una res-

tricció es defineix com diferible, es podrà definir en quin moment es vol

realitzar la comprovació

En un exemple anterior s'hauria pogut posar

Si es vol canviar l'estatus d'una restricció és pot utilitzar la sentència

Aplicat a l'exemple anterior

CREATE TABLE Empleat ( Codi CHAR(5) CONSTRAINT PK_Empleat PRIMARY KEY, Nom VARCHAR2 (50) CONSTRAINT NN_EmpleatNom NOT NULL, Salari NUMBER (7, 2) CONSTRAINT CH_EmpleatSalari CHECK (Salari > 0), Comissio NUMBER (7, 2) CONSTRAINT CH_EmpleatComissio CHECK (Comissio >= 0), CONSTRAINT CH_Empleat CHECK (Salari > Comissio OR Comissio IS NULL))

� !�!��"��"�

� !��'��**��(��)�"�

CREATE TABLE Matricula ( Alumne CONSTRAINT FK1_Matricula REFERENCES Estudiant(Codi) ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED, Assignatura CONSTRAINT FK2_Matricula REFERENCES Assignatura(Codi) DEFERRABLE INITIALLY DEFERRED, CONSTRAINT PK_Matricula PRIMARY KEY (alumne, assignatura) )

� ��!"�� '�!��7�"��4�!:�!��7�"��"�777�(��)�� '��**��(��)�

��/� � ' ��( ��

��

Al crear una restricció, aquesta pot estar en tres estats

Sols en el cas que una restricció estigui habilitada el SGBD la comprova-

rà, si aquesta habilitació és amb validació comprovarà si compleixen la

restricció totes les files que tingui la taula en el moment de la creació i no

ho farà si la restricció es crea amb l'estatus de no validar.

Si es volen canviar l'estatus d'una restricció, caldrà efectuar una modifi-

cació de la taula, segons la sintaxi

També és possible afegir una restricció a una taula (encara que sols afecti

a una columna)

Si es vol eliminar una restricció del diccionari de dades es pot fer amb la

sentència

per exemple, si es vol eliminar una restricció d'integritat referencial de

l'anterior taula Matricula

L'opció en cascada permet que quan s'elimina una clau primària s'elimi-

nen automàticament totes les restriccions d'integritat referencial que l'a-

punten.

SET CONSTRAINTS FK1_Matricula, FK2_Matricula DEFERRED

� '��'�,��(��,��)�(��)�

��!��7�"�� '��'�,��(��,��)�(��)�� '��=��1#��(�� *��<��(��4�)�

��!��7�"��4�

��!��7�"�� '�'� ��*��(��=��8��1#��;�)�!��"� �� (��4�)�

ALTER TABLE Matricula DROP CONSTRAINT FK1_Matricula

��

��

��<��@AB��

Les seqüències són generadors seqüencials de nombres, s'utilitzen nor-

malment per generar claus primàries artificials (subrogades), una seqüèn-

cia pot ser utilitzada per diferents usuaris. La sintaxi és

"�'$��4 indica l'interval entre dos nombres consecutius de la

seqüència, per defecte val 1, podent ser un nombre positiu o negatiu se-

gons es vulgui una seqüència creixent o decreixent.

"�'$��4 és el primer nombre de la seqüència, pot ser un enter

de fins a 28 dígits.

�!):!� � ��"�:!� � indiquen si existeix un valor màxim i/o

mínim de la seqüència, o +� 2342��i +� 0+42�� en cas con-

trari. /5/�� indica si cal tornar a començar desprès d'arribar al darrer

valor.

En el cas de que es vulgui assegurar que el nombres es van donant en el

mateix ordre que es van demanant s'ha d'utilitzar �,(�,.

Es poden tenir una sèrie de valor pre-ubicats a la memòria, per tal d'obte-

nir una millor eficiència amb la clàusula /2/6�.

Un exemple de creació serà

Si es vol canviar la definició d'una seqüència cal utilitzar la sentència

��=��!��7�"��6>?#��777�(�!��*��#��"�777�(�!��@��#��"�777�(�'!�*�A,��#��"�(�!��*�A,��"�)�777�(�'!�*��,��#��"�(�!��*��,��"�)�777�(�'!��"�(�!��"�)�777�(�'!��#��"�(�!��"�)�777�(�'!��"�(�!��"�)�

CREATE SEQUENCE s_Departament INCREMENT BY 2 START WITH 1000

ALTER SEQUENCE [ usuari. ] seqüència

��<� � ' ��( ��

��

Seguida de la clàusula que es vulgui canviar. Per eliminar una seqüència

Per tal de poder utilitzar una seqüència s'ha de ser el seu propietari o tenir

autorització del propietari de la seqüència. Una seqüència es pot referen-

ciar en sentències SQL utilitzant les pseudo-columnes +�3142� i

/�,,42�. Cada vegada que es fa referencia a +�3142� es genera un

nou valor de la seqüència, mentre que si es vol obtenir varies vegades el

darrer valor creat en una sessió, sense que canviï, s'ha d'utilitzar

/�,,42�.

��=��C��9��

Els sinònims són un segon nom, un àlias, que es pot donar a una taula,

una vista, una seqüència, un procediment, una funció o un paquet. Es fan

servir per raons de seguretat, emmascara el nom, el propietari i la localit-

zació de l'objecte; o de comoditat, simplifica les sentències SQL dels u-

suaris.

La sintaxi és

El sinònim podrà ser públic, i per tant utilitzat per tothom o privat de l'u-

suari; en el cas que no s'indiqui el propietari de l'objecte es considerarà l'-

usuari propietari de la sessió. El nom del sinònim haurà de ser únic dintre

dels noms dels objectes del seu propietari.

Si es vol crear un sinònim per la taula VersioIntegraVendes de l'usuari

màrqueting es pot fer

� �� =��!��7�"��6>?#��

SELECT s_Departament.NEXTVAL FROM DUAL

SELECT s_Departament.CURRVAL FROM DUAL

� ��!� ��"��*�!�9��9��7�"��#B#�1�� !9��9��7�"��C��

�� =�

��

Si es vol destruir el sinònim anterior

��>�'�9��

És possible Afegir comentaris a les taules i a les diferents columnes de

cada taula. La sintaxi és

Exemples d'aplicació són

��?�D��

��?�� Discutiu pels estudiants de la nostra assignatura de Bases de Dades,

que és la millor clau primària: a) el DNI; b) el nom i cognoms; c) el nú-

mero d'expedient de l'Escola; d) el número d'expedient de la Universitat.

��?�, Definir el domini, indicant la possibilitat de valors nuls i, si s'escau

el valor per defecte dels atributs de la taula EMPLEAT (dni, nom, cog-

nom1, cognom2, adreça, ciutat, telèfon, data_neixement, data_contracte,

salari, comissió).

��?�- Quines de les següents taules necessitarien una clau primària "sur-

rogate" (artificial): a) el tiquet de compra d'un supermercat; b) la factura

de compra d'un majorista; c) una taula amb el nom i cognoms dels estudi-

CREATE PUBLIC SYNONYM Vendes FOR marketing.VersioIntegraVendes

DROP PUBLIC SYNONYM Vendes

� ��**��!��7�"#�1��/��2�/�

� ��**��*��!��7�"#�1��7#�1��1�� /��2�/�

COMMENT ON TABLE Empleat IS 'Relació d''empleats actuals';

COMMENT ON COLUMN Empleat.Codi IS 'Codi Intern de l''empresa';

��>� � ' ��( ��

��

ants i la nota que han tret en un examen; d) una taula amb el nom i cog-

noms, adreça i telèfon dels estudiants en una Base de Dades Acadèmica

de l'Escola.

��?�/ Definiu el domini de claus artificials de taules de: a) 350 files; b)

5.000 files; c) 2.000.000 files; d) 865.000 files amb múltiples consultes;

e) 150.000.000 files sense utilització de la clau pels usuaris.

��?�� Donada la taula EMPLEAT (dni, nom, cognom1, cognom2, adreça,

ciutat, telèfon, data_neixement, data_contracte, salari, comissió) definiu

les següents regles de negoci: a) l'edat mínima de contractació ha de ser

de 18 anys; b) la data de contracte ha de ser posterior a la de creació de

l'empresa (25/4/1986); c) la comissió no pot superar el 50% del salari; d)

el salari ha de ser superior al salari mínim interprofessional (65.000 Ptes).

��?�< Afegir a la taula anterior: a) una restricció que indiqui que la data de

contracte ha de ser superior a la data de naixement; b) una columna amb

el nombre de fills; d) eliminar la columna comissió; e) fer que l'edat mí-

nima sigui de 16 anys; f) canviar el nom de la taula per OBRER.

��?�= Deshabilitar, momentàniament, totes les restriccions del problema

5.15.5. Eliminar les restriccions afegides a la taula EMPLEAT al proble-

ma 5.15.6

��?�> Crear seqüències que permetin implementar les claus proposades al

problema 5.15.4.

��?�? Crear un sinònim públic per assegurar l'accés a la taula de problema

2.

��

��

��

��

Tots els exemples dels apartats següents es realitzaran sobre les taules

descrites a continuació

Cap

Subordinat

��CodiNomLocalitatCategoriaData AltaSalariComissió

�� CodiNomLocalitat

!� ��"��#��!� ��"�!��

��Codi <pk> not nullCap <fk> nullDepartament <fk> nullNom not nullLocalitat not nullCategoria not nullData Alta not nullSalari not nullComissió null

�� Codi <pk> not nullNom not nullLocalitat not null

�� !� �� 10 Comptabilitat Calella 20 Recerca Mataró 30 Vendes Barcelona 40 Producció Llavaneres

CREATE TABLE Departament ( Codi CHAR(2) CONSTRAINT PK_Departament PRIMARY KEY, Nom VARCHAR2(15) CONSTRAINT NN_DepartamentNom NOT NULL CONSTRAINT UN_DepartamentNom UNIQUE, Localitat VARCHAR2(15) CONSTRAINT NN_DepartamentLocalitat NOT NULL )

�$%� � �� !��

��

��!� �� !��#��#��#��&��#��!��#�� 839 Dalmau Mataró President 17/11/94 5850 566 Calvet Mataró Cap 839 2/4/94 2585 30 698 García Barcelona Cap 839 28/9/94 3335 30 782 Blanch Masnou Cap 839 9/9/94 2870 10 902 Fernández Canet Analista 566 3/12/94 3510 20 369 Vila Badalona Oficial 902 17/12/93 935 20 499 Arnau Barcelona Venedor 698 20/2/94 1875 353.35 30 521 Casals Arenys Venedor 698 22/2/94 1460 586.7 20 654 Pruna Mataró Venedor 698 1/5/94 3490 1640.15 30 788 Vidal Arenys Analista 566 30/1/99 3510 20 844 Roca Masnou Venedor 698 8/9/94 1750 0 30 846 Cabrera Premià Oficial 788 3/1/99 1290 900 Martorell Barcelona Oficial 698 3/12/94 1115 30 847 Abad Canet Oficial 782 23/1/95 1520 10

�

��$��#��

Els termes literal i valor constant són sinònims i es refereixen a valors

fixat de dades, per exemple: 'hola', 'fa bon dia' són literals de caràcters i –

45, 3.456E-12 són literals numèrics. Algunes sentències i funcions SQL

requereixen que s'especifiquin valors literals.

Un literal de caràcters pot ocupar un màxim de 4000 by i es tractat com si

fos una dada de tipus CHAR. El caràcter d'escape és ', per exemple,

'Ronda O''Donnell'.

Un literal enter pot ser qualsevol enter, amb signe, de fins a 38 dígits de

precisió. Si es vol guardat un real, a més del 38 dígits de precisió, es

podran tenir exponents de –130 a 125, per exemple 4.567E-34.

CREATE TABLE Empleat ( Codi CHAR(3) CONSTRAINT PK_Empleat PRIMARY KEY, Nom VARCHAR2(10) CONSTRAINT NN_EmpleatNom NOT NULL, Localitat VARCHAR2(15) CONSTRAINT NN_EmpleatLocalitat NOT NULL , Categoria VARCHAR2(10) CONSTRAINT NN_EmpleatCategoria NOT NULL, Director CHAR(3), DataAlta DATE CONSTRAINT NN_EmpleatDataAlta NOT NULL, Salari NUMBER(6, 2) CONSTRAINT NN_EmpleatSalari NOT NULL CONSTRAINT CH_EmpleatSalari CHECK (Salari > 0), Comissio NUMBER(6, 2), Departament CONSTRAINT FK2_Empleat REFERENCES Departament (Codi) )

ALTER TABLE Empleat ADD CONSTRAINT FK1_Empleat FOREIGN KEY (Director) REFERENCES Empleat(Codi)

�� $��

��

Un literal interval indica un període de temps, aquest pot estar expressat

en termes d'anys i mesos, o en termes de dies, hores, minuts i segons. La

sintaxi dels intervals any-mes és

La precisió per defecte és 2. A continuació es presenten algun exemples

La segona especificació és dia-segon, la seva sintaxi és

Els temps s'especifica en el format ""#$��#$��#%�&&&� � ��#$��#%�&&%

Seguidament es presenten diferents literals

�

�

��

INTERVAL ’123-2’ YEAR(3) TO MONTH INTERVAL ’123 YEAR (3) INTERVAL ’300’ MONTH(3) INTERVAL ’50’ MONTH

�� !��"�� "��#�$��!��%&�'�� !��"��"��#�$��!��

INTERVAL ’ 4 5:12:10.222’ DAY(3) TO SECOND(3) INTERVAL ’4 5:12’ DAY TO MINUTE INTERVAL ’400 5’ DAY(3) TO HOUR INTERVAL ’400’ DAY (3) INTERVAL ’11:12:10.22222’ HOUR TO SECOND(7) INTERVAL ’11:20’ HOUR TO MINUTE INTERVAL ’10’ HOUR INTERVAL ’10:22’ MINUTE TO SECOND

�$$� � �� !��

��

��'�!��(#��)��

La sentència SELECT permet realitzar consultes sobre una taula, la

sintaxi complerta és

La clàusula, ALL o DISTINC, força que surtin totes les files que

compleixin les condicions o sols aquelles que són diferents, per defecte

l’opció és ALL. Amb el SELECT es poden veure les columnes

seleccionades o totes les columnes de la taula referenciada per la clàusula

FROM, també és possible seleccionar tota una taula. A continuació es

presenten diferents exemples

Llistar les columnes codi i nom de la taula DEPARTAMENT

Llistar totes les columnes de la taula DEPARTAMENT

Llistar totes les categories diferents de la taula EMPLEAT

Canviar la referència de la columna NOM de DEPARTAMENT a

denominació

#��$��!�#��$��((�� '��) '�#'(�'�� '*('�+� ,,,-��.�� '*('��*/�)��*( ' ,,,�0��)�1��'� ,,,�2��"34�((�� '��) '��)(* �'� ,,,��2�)�1��'� ,,,��(5*�*('1)�1��'��

SELECT Codi, Nom FROM Departament

SELECT * FROM Departament

SELECT DISTINCT Categoria FROM Empleat

SELECT Nom AS Denominació FROM Departament

�� $'�

��

Es poden fer consultes que calculin columnes. Comparar el salari actual

amb el de l’any que ve (increment del 3%) de tots els empleats

Es poden unir dues columnes en una única frase. Indiqueu on està cada

departament

La clàusula WHERE indica una condició booleana que hauran de complir

totes les files que se seleccionin, la sintaxi d’aquesta condició és:

Exemples de comparació:

Llistar tota la informació dels empleats del departament 30

Llistar els codis, noms i departaments de tots els oficials

SELECT Nom, Salari, 1.03 * Salari FROM Empleat

SELECT Nom || ' està situat a ' || Localitat FROM Departament

�)�1��'6 ��.��) �'�'��.�� .��) �'�'��*/�)��*( '��#�� .��) �'�'��*/�)��*( '� ��.��#��"�� .��7��.��#$�3��.�� .��4��0��.��!�.�� .��.��%,,,� ��.��*/�)��*( '� ��8�#�#��*/�)��*( '� ��)�1�� )�1��!�)�1�� )�1��)�1�� )�1�� )�1��%�� '��) �'�'�6 �9�:�;�:9�;9�;:�<9��9�

SELECT * FROM Empleat WHERE Departament = '30'

�$*� � �� !��

��

Trobar tots els departaments que tenen número de departament més gran

de '20'

Trobar el nom dels empleats tal que el seu salari sigui no més gran de

2000 euros

És possible unir amb operadors lògics AND, OR i NOT diferents

condicions

Trobar tots els venedors del departament 30 tal que el seu salari sigui més

gran o igual a 1850 euros.

Trobar tots els empleats tal que són caps o tenen un salari superior a

3300 euros

Llistar tota la informació dels caps i d'aquells que són oficials del

departament 30

SELECT Codi, Nom, Departament FROM Empleat WHERE Categoria = ’Oficial’

SELECT Codi, Nom FROM Departament WHERE Codi > ’20’

SELECT Nom FROM Empleat WHERE NOT (Salari > 2000)

SELECT Nom, Salari, Departament FROM Empleat WHERE Categoria = ’Venedor’ AND Departament = ’30’ AND Salari >= 1850

SELECT Nom, Categoria, Salari FROM Empleat WHERE Categoria = ’Cap’ OR Salari > 3300

SELECT * FROM Empleat WHERE Categoria = ’Cap’ OR (Categoria = ’Oficial’ AND Departament = ’30’�

�� $+�

��

Trobar tots els caps que no siguin del departament 30

Llistar informació sobre els empleats del departament 10 que no són ni

caps ni oficials

En múltiples consultes és necessari trobar informació que es troba entre

dos límits, per això s'utilitza l'operador BETWEEN A AND B, que

equival a >= A AND <= B.

Trobar tots els empleats que tenen un salari entre 1350 i 1600 euros

Trobar els empleats que no tenen un salari entre 1150 i 1650 euros

Trobar aquells venedors tal que la seva comissió no estigui entre el 20% i

el 50% del seu salari

Una forma més eficient de comparar amb els diferents valors d'una llista

que utilitzar múltiples comparacions d'igualtat i l'operador OR, és IN (

expressió ), aquest retorna cert si coincideix amb alguns dels valors de

l'expressió

SELECT nom, categoria, departament FROM empleat WHERE categoria = ’Cap’ AND departament != ’30’

SELECT * FROM Empleat WHERE Departament = ’10’ AND NOT (Categoria = ’Cap’ OR Categoria = ’Oficial’)

SELECT Nom, Salari FROM Empleat WHERE Salari BETWEEN 1350 AND 1600

SELECT Nom, Salari FROM Empleat WHERE Salari NOT BETWEEN 1150 AND 1650

SELECT Nom, Salari, Comissio FROM Empleat WHERE Categoria = ’Venedor’ AND Comissio NOT BETWEEN (0.2 * Salari) AND (0.5 * Salari)

�$�� !��

��

Trobar els empleats que són venedors, analistes o oficials

Trobar els empleats que no són ni venedors, ni analistes ni oficials

�

Si es vol comparar amb patrons s'utilitza l'operador LIKE que té per

sintaxi

El patró pot contenir caràcters de substitució, aquests són

' un únic caràcter qualsevol

( una cadena de zero o més caràcters

El caràcter d'ESCAPE es col·loca davant d'un _ o % si es vol que

aparegui dintre el patró, per treure el seu significat de metacaràcter.

Trobar tots els empleats tal que el seu nom comenci per C

Trobar tots els empleats tal que el seu nom tingui cinc lletres, comenci

per 'Arn' i finalitzi per 'u'

Utilització de la clàusula ESCAPE. Trobar treballadors que tinguin una

categoria que comenci per A%BC

� SELECT Nom, Categoria FROM Empleat WHERE Categoria IN (’Venedor’, ’Analista’, ’Oficial’)�

� SELECT Nom, Categoria FROM Empleat WHERE Categoria NOT IN (’Venedor’, ’Analista’, ’Oficial’)

,,,�.��7��' ��#$�3��.��=��'��

SELECT Nom FROM Empleat WHERE Nom LIKE ’C%’

SELECT Nom FROM Empleat WHERE Nom LIKE ’Arn_u’

�� $,�

��

Dintre una taula les files no estan en cap ordre en particular, si es vol que

la resposta a la consulta surti ordenada, haurà d'indicar-se amb una

clàusula d'ordenació, la sintaxi d'aquesta clàusula és

cada element de la clàusula resultarà ordenat en ordre ascendent ASC o

descendent DESC. És possible indicar en quyin lloc es vol que es

col·loquin les files que tenen un valor nul a la columna del criteri; NULL

LAST és el valor per defecte en ordre ascendent i NULL FIRST ho és en

ordre descendent.

Llistar tots els empleats i les seves categories del departament 30 en

ordre, segons els seu salari

També es pot assignar un àlias a una columna i utilitzar-lo per ordenar.

Trobar els guanys dels venedors

Llistar tots els empleats, les seves categories i salaris del departament 30

en ordre descendent segons els seu salari

�

SELECT Nom, Categoria FROM Empleat WHERE Categoria LIKE ’A#%BC%’ ESCAPE ’#’

��!��4��.��)��5(�'�� ,,,��#$�!�#$�� ,,,��"��#�-��#��#��

� SELECT Nom, Categoria, Salari FROM Empleat WHERE Departament = ’30’ ORDER BY Salari

SELECT Nom, Categoria, Salari FROM Empleat WHERE Departament = ’30’ ORDER BY 3

SELECT Nom, Salari + Comissio AS Guany FROM Empleat WHERE Categoria = ’Venedor’ ORDER BY Guany

�$-� � �� !��

��

Ordenar tots els empleats per categories, i dintre d’elles en ordre

descendent segons el seu salari

Ordenar tots els empleats segons la seva comiisió en ordre ascendent i

posant els que no tenen comissió al principi

SELECT Nom, Salari, comissio FROM Empleat ORDER BY 3 NULL FIRST

��*�!��(�� ./#��

La pròpia naturalesa del model relacional, en el qual la informació es

troba repartida entre múltiples taules "relacionades" entre elles per

referències, fa que per la majoria de les consultes la informació s'hagi

d'extreure de més d'una taula.

Per tal de combinar les taules existeixen diferents tipus de JOIN: inerna,

externa, creuada i natural. La sintaxi és

A continuació es veuen alguns exemples d'utilització

Trobar el lloc de treball d'En Calvet

� SELECT Nom, Categoria, Salari FROM Empleat WHERE Departament = ’30’ ORDER BY Salari DESC

SELECT Nom, Categoria, Salari FROM Empleat ORDER BY Categoria, Salari DESC

��*��) /��'��6 ��"�� -��2��-"��"��) � '*(' ��*��) /��'��)>�� )�1�� "#��2�((�� '��)(* �� $��##>��) � '*('

�� $��

��

Llistar tota la informació dels empleats que treballin en departament

situats a Mataró o Barcelona

Una mateixa taula és possible correlacionar-la amb diferents noms

Trobar els salaris i categories de tots els treballadors que guanyen més

que En Calvet

Llistar tots els empleats tal que el seu salari superi al del seu cap

També és possible realitzar el producte cartesià entre dues taules, o el que

és el mateix, una junció sense cap mena de condició, no és gaire usual la

seva utilització ja que no aporta cap semàntica i és de càlcul molt costós

SELECT Empleat.Nom, Departament.localitat FROM Empleat INNER JOIN Departament ON Empleat.Departament = Departament.Codi WHERE Empleat.Nom = ’Calvet’

SELECT E.Nom, D.Localitat FROM Empleat INNER JOIN Departament D ON E.Departament = D.Codi WHERE E.Nom = ’Calvet’

SELECT E.*, D.Localitat FROM Empleat E INNER JOIN Departament D ON E.Departament = D.Codi WHERE D.Localitat IN ('Mataró', 'Barcelona')

SELECT X.Nom, X.Salari, X.Categoria FROM Empleat X INNER JOIN Empleat Y ON X.Salari > Y.Salari WHERE Y.Nom = 'Calvet'�

SELECT Subordinat.Nom, Subordinat.Salari, Cap.Nom FROM Empleat Cap INNER JOIN Empleat Subordinat ON Subordinat.Director = Cap.Codi WHERE Subordinat.Salari > Cap.Salari

SELECT E.*, D.* FROM Empleat E CROSS JOIN Departament D

�'%� � �� !��

��

Les juncions externes, són equi-juncions que a més dels valors que

compleixen la condició retornen aquells valors que són UNKNOWN, per

exemple

Llistar tots els departaments amb els seus empleats, encara que no hi

hagin

Llistar el lloc de treball de tots els empleats (encara que no tinguin

departament assignat)

En el cas de que es vulguin els dos casos

Una clàusula força interessant en una consulta és CASE, la qual permet

retornar elements diferents segons la condició que compleixen. Per

exemple la següent consulta retornarà diferents valors segons el nivell de

salari

Calcular la mitjana de salaris del departament 20, suposant que si algí

guanya més de 3500 ��

SELECT D.Nom, E.Nom FROM Departament LEFT OUTER JOIN Empleat E ON D.Codi = E.Departament ORDER BY D.Nom

SELECT D.Nom, E.Nom FROM Departament RIGHT OUTER JOIN Empleat E ON D.Codi = E.Departament ORDER BY D.Nom

SELECT D.Nom, E.Nom FROM Departament FULL OUTER JOIN Empleat E ON D.Codi = E.Departament ORDER BY D.Nom

SELECT Nom, Salari, CASE WHEN Salari < 1500 THEN ’Petit’ WHEN Salari BETWEEN 1500 AND 3500 THEN ’Normal’ ELSE ’Gran’ END FROM Empleat ORDER BY 2

�� '��

��

��+�!��#��

Moltes consultes no requereixen el nivell de detall proporcionat per les

sentències anteriors, sinó un resum de la informació continguda a la Base

de Dades, per això es fa necessari poder agrupar segons alguna condició

les files, això s'aconsegueix amb el GROUP BY i el HAVING, el primer

permet agrupar en una única fila totes les compleixen la condició

continguda la consulta, mentre que el HAVING permet restringir

aquestes agrupacions.

A la majoria de consultes resum és fa necessària la utilització de funcions

agregades, és a dir, funcions que retornes un únic valor a partir de molts

valors, en SQL tenen la següent sintaxi

A continuació es detallen aquestes funcions

�� Retorna el nombre de files de cada grup.

�� Retorna el nombre de files de cada grup tal

que l'expressió no és nul·la.

�� Retorna la mitjana de cada grup de files; els valors

NULL no són tinguts en compte.

SELECT AVG(CASE WHEN Salari <= 3500 THEN Salari ELSE 3500 END) FROM Empleat WHERE Departament = ’20’

&*��='?��?'1'6 ��2��'�5 � ��='?��?'�� $�"��+� �$�"��'�5 � ��='?��?'�� 8��'�5 � ��='?��?'�� '�5 � ��='?��?'�� #"��'�5 � ��='?��?'��'�5 � ��='?��?'��6 �!�#��$��) =�)(* �' ��.��

�'$� � �� !��

��

�� ) Retorna el valor màxim trobat a cada grup de

files.

�� Retorna el valor mínim trobat a cada grup de

files.

�� Retorna la suma total de l'expressió per a cada

grup de files.

Seguidament es presenten uns exemples

Calcular la mitjana del salari dels oficials

Calcular el total dels salaris i les comissions de tots els venedors

Trobar la mitjana de guanys anyals (14 pagues) dels venedors

Trobar el màxim i el mínim dels salaris

Trobar el nombre d'empleats que poden cobrar comissions

Comptar el nombre de categories diferents que existeixen al departament

30

SELECT AVG(Salari) FROM Empleat WHERE Categoria = ’Oficial’

SELECT SUM(Salari), SUM(Comissio) FROM Empleat WHERE categoria = ’Venedor’

SELECT AVG(14 * (Salari + Comissio)) FROM Empleat WHERE Categoria = ’Venedor’

SELECT MAX(Salari), MIN(Salari) FROM Empleat

SELECT COUNT(Comissio) FROM Empleat

�� ''�

��

Comptar el nombre d’empleats del departament 30

Trobar la mitjana dels salaris de cada departament

La clàusula GROUP BY s'utilitza per agrupar les files que compleixen

una condició i retorna una única fila amb una informació resum,

exemples d'utilització són:

Contar els empleats de cada departament per cadascuna de les categories

indicant la mitjana dels salaris

Trobar la mitjana dels salaris anyals dels directius de cada departament

Presenteu la mitjana de salaris de cada departament, en ordre creixent

SELECT COUNT(DISTINCT Categoria) FROM Empleat WHERE Departament = ’30’

SELECT COUNT(*) FROM Empleat WHERE Departament = ’30’

SELECT Departament, AVG(Salari) FROM Empleat GROUP BY Departament

SELECT Departament, Categoria, COUNT(*), AVG(Salari) FROM Empleat GROUP BY Departament, Categoria ORDER BY Departament, Categoria

SELECT Departament, 14 * AVG(Salari) FROM Empleat WHERE Categoria IN (’President’, ’Cap’) GROUP BY Departament

SELECT Departament, AVG(Salari) FROM Empleat GROUP BY Departament ORDER BY 2

�'*� � �� !��

��

Si el que es vol és restringir la resposta a sols aquells grups que

compleixin una condició, aquesta es posa amb la clàusula HAVING.

Exemples

Llistar la mitjana dels salaris de totes les categories que tinguin més de

dos empleats

Llistar tots els departaments que tinguin al menys dos venedors

��0��1�� (��

Moltes vegades es fa necessari utilitzar el resulta d'una consulta com part

d'una altra, normalment apareix dintre les clàusules WHERE , HAVING o

FROM, per exemple

Trobar tots els empleats que tenen la mateixa categoria que l'empleat

'654'

Trobar tots els empleats que treballen en departaments que tinguin

venedors

SELECT Categoria, COUNT(*), AVG(Salari) FROM Empleat GROUP BY Categoria HAVING COUNT(*) > 2

SELECT Departament FROM Empleat WHERE Categoria = ’Venedor’ GROUP BY Departament HAVING COUNT(*) >= 2

SELECT Nom, Categoria FROM Empleat WHERE Categoria = (SELECT Categoria FROM Empleat WHERE Codi = ’654’)

�� '+�

��

Llistar totes les categories que el seu salari mitjà supera la mitjana dels

salaris dels caps

Les clàusules IN, ANY i ALL permeten, respectivament, comprovar si el

valor està en la subconsulta o comparar-lo amb tots o alguns dels resultats

de la subconsulta

Llistar els empleats del departament 10 que tenen la mateixa categoria

que algun empleat del departament 30

Per totes aquelles categories a les quals pertanyi més de dos empleat,

llistar la categoria i tots els empleats

Trobar informació sobre els empleats que guanyen més que algun

empleat del departament 30

SELECT Nom, Categoria FROM Empleat WHERE Departament IN (SELECT Departament FROM Empleat WHERE Categoria = ’Venedor’)

SELECT Categoria, AVG(Salari) FROM Empleat GROUP BY Categoria HAVING AVG(Salari) > (SELECT AVG(Salari) FROM Empleat WHERE Categoria = ’Cap’)

SELECT Nom, Categoria FROM Empleat WHERE Departament = ’10’ AND Categoria IN (SELECT Categoria FROM Empleat WHERE Departament = ’30’)

SELECT Categoria, Nom FROM Empleat WHERE Categoria IN (SELECT Categoria FROM Empleat GROUP BY Categoria HAVING COUNT(Categoria) > 2) ORDER BY Categoria, Nom

�'�� !��

��

Trobar informació sobre els empleats que guanyen més que qualsevol

empleat del departament 30

Llistar els empleats del departament 10 que no tenen la mateixa categoria

que cap empleat del departament 20

Llistar els empleats que tinguin la mateixa categoria que En Calvet, o el

salari més gran o igual que En Fernàndez, ordenats per categories i salaris

La majoria de consultes realitzades amb combinacions, també és possible

realitzar-les amb subconsultes, per exemple

Trobar els empleats del departament 10 que tinguin la mateixa categoria

que algú del departament de vendes

SELECT Nom, Categoria, Salari FROM empleat WHERE Salari > ANY (SELECT Salari FROM Empleat WHERE Departament = ’30’)

SELECT Nom, Categoria, Salari FROM empleat WHERE Salari > ALL (SELECT Salari FROM Empleat WHERE Departament = ’30’)

SELECT Nom, Categoria FROM Empleat WHERE Departament = ’10 ’ AND Categoria NOT IN (SELECT Categoria FROM Empleat WHERE Departament = ’20’)

SELECT Nom, Categoria, Salari, Departament FROM Empleat WHERE Categoria IN (SELECT Categoria FROM Empleat WHERE Nom = ’Calvet’) OR Salari > ALL (SELECT Salari FROM Empleat WHERE Nom = 'Fernández') ORDER BY Categoria, Salari

�� ',�

��

Trobar els empleats que tinguin la mateixa categoria que algun empleat

que treballi a Barcelona

Per combinar el resultat de dos consultes existeixen els operadors

UNION, INTERSECT i MINUS equivalents al seu sinònim matemàtic.

La sintaxi és

SELECT Nom, Categoria FROM Empleat WHERE Departament = ’10’ AND Categoria IN (SELECT Categoria FROM Empleat WHERE Departament = (SELECT Codi FROM Departament WHERE Nom = ’Vendes’ ))

SELECT DISTINCT X.Nom, X.Categoria FROM Empleat X, Empleat Y, Departament D WHERE Y.Departament = D.Codi AND D.Nom = ’Vendes’ AND X.Categoria = Y.Categoria AND X.Departament = ’10’

SELECT Nom, Categoria FROM Empleat WHERE Categoria IN (SELECT Categoria FROM Empleat WHERE Departament IN (SELECT Codi FROM Departament WHERE Localitat = ’Barcelona’))

SELECT DISTICT X.Nom, X.Categoria FROM Empleat X, Empleat Y, Departament D WHERE D.Localitat = ’Barcelona’ AND X.Categoria = Y.Categoria AND Y.Departament = D.Codi

��(��=��=)�1��'�"��(��=��=)�1��'� ,,,�"�� ,,,��#�$�� ,,,��"#��(��=��=)�1��'��,,, ,,,��!��4�� #$�!�#$�%,,,�

�'-� � �� !��

��

La unió elimina totes les files repetides, si no es vol aquesta eliminació

cal utilitzar la clàusula ALL. Per exemple

Llisteu totes les localitats a les quals hi ha un departament o resideix un

empleat


empleat, sense repeticions

La clàusula ORDER BY s'efectua sobre el resultat de la consulta


empleat, sense repeticions i ordenades alfabèticament

Llisteu totes les localitats a les quals hi ha un departament i resideix un

empleat

Llisteu totes les localitats a les quals resideix un empleat i no hi ha cap

departament

SELECT localitat FROM empleat UNION ALL SELECT localitat FROM departament

SELECT Localitat FROM Empleat UNION SELECT Localitat FROM Departament

SELECT Localitat FROM Empleat UNION SELECT Localitat FROM Departament ORDER BY 1

SELECT Localitat FROM Empleat INTERSECT SELECT Localitat FROM Departament

�� '��

��

A tots els exemples que s’han vist fins ara la subconsulta es realitza una

sola vegada, això no és sempre així, ja que, de vegades, és necessari

repetir la subconsulta per a cada fila de la consulta principal, aquest tipus

de subconsultes reben el nom de subconsultes correlacionades: Per

exemple

Trobar els empleats que guanyen més que la mitjana dels empleats del

seu departament, ordenats per departament

Un altre enfoc al tema de les subconsultes és la seva incorporació a la

clàusula FROM, en aquest cas caldrà definir un àlies per a cada

subconsulta i es podrà utilitzar com si fos una taula.

Trobar per a cada departament, el percentatge de treballadors i el

percentatge de salaris

També és possible obtenir el mateix utilitzant la clàusula de factorització

de consultes amb la sintasi

La consulta anterior resultaria

SELECT Localitat FROM Empleat MINUS SELECT Localitat FROM Departament

SELECT Departament, Nom, Salari, Categoria FROM Empleat X WHERE Salari > (SELECT AVG(Salari) FROM Empleat Y WHERE X.Departament = Y.Departament)

SELECT X.Departament, X.NE/Y.TE, X.SS/Y.TS, Z.Nom FROM (SELECT Departament, COUNT(*) NE, SUM(Salari) SS FROM Empleat GROUP BY Departament) X, (SELECT COUNT(*) TE, SUM(Salari) TS FROM Empleat) Y, Departament Z WHERE x.D = Z.Codi

0��) ��*/�)��*( '�#��*/�)��*( '�

�*%� � �� !��

��

��,�� 2�#/#3�3�� Una psudocoluma és semblant a una columna d'una taula, encara que no està

emmagatzemada en cap taula en concret. Es Pot seleccionar però no es possible

inserir, esborrar ni modificar valors.

Una d'aquestes pseudocolumes és la utilitzada per donar el valor següent

(NEXTVAL) o actual (CURRVAL) d'una sequència. Per exemple

La pseudocolumna ROWNUM indica el número d'ordre en que ha estat

seleccionada de la taula, no en el que apareix en el resultat, ja que aquest

ordre pot haver estat modificat per la clàusula ORDER BY. Si sols es

volen 5 valors

Si es volen els 5 empleats de salari més baix, s'hauria de fer

WITH X AS (SELECT Departament, COUNT(*) NE, SUM(Salari) SS FROM Empleat GROUP BY Departament), Y AS (SELECT COUNT(*) TE, SUM(Salari) TS FROM Empleat) Y SELECT X.Departament, X.NE/Y.TE, X.SS/Y.TS, Z.Nom FROM X, Y, Departament Z WHERE X.D = Z.Codi

SELECT EmpSeq.NEXTVAL FROM DUAL;

INSERT INTO Departament VALUES (DepSeq.CURRVAL, ’Enginyeria’, ’Montgat’);

SELECT Nom, Salari FROM Empleat WHERE ROWNUM < 5 ORDER BY Salari

�� *��

��

El ROWID representa l'adreça física de la fila en base 64 (A-Z, a-z, 0-9, +,

/), els 6 primers caràcters representen el segment, els 3 següents el fitxer,

els 6 següents el bloc i el 3 darrers la fila dintre del bloc. Per exemple

Fernández AAAA4BAADAAAANvAAE

Vila AAAA4BAADAAAANvAAF

Casals AAAA4BAADAAAANvAAH

Vidal AAAA4BAADAAAANvAAJ

Amb el ROWID es pot accedir de la forma més eficient possible a les files, veure

com està organitzada una taula e identificar de forma única cada fila.

Per a cada fila retornada per una consulta jeràrquica LEVEL indica el nivell de

profunditat, a partir de la l'arrel que és 1.

Si una taula conté dades jerarquitzades aquestes es poden recuperar en ordre

jeràrquic amb les clàusules

Exemples de consultes són: Indicar de forma "identada" la diferent

jerarquia de tots els empleats

Donar el nom i la categoria dels dos primers nivells de jerarquia

SELECT * FROM (SELECT Nom, Salari FROM Empleat ORDER BY Salari) WHERE ROWNUM < 5

SELECT Nom, ROWID FROM Empleat WHERE Departament = ’20’

#��0��)�1��'��( $��$�4�3��&�((9�'��

SELECT LPAD(’ ’, 5+(LEVEL –1) || Nom, Categoria FROM Empleat START WITH Categoria = 'President' CONNECT BY PRIOR Codi = Director

SELECT Nom, Categoria FROM Empleat START WITH Categoria = 'President' CONNECT BY PRIOR Codi = Director AND LEVEL <= 2

�*$� � �� !��

��

El SGBD realitza una lectura en pre-ordre de la informació de la taula, tal com es

veu reflectit al gràfic següent

1

2

3 4

5 6

7

8

9

10 12

11

LEVEL 1 LEVEL 2 LEVEL 3 LEVEL 4

��-��4#�3��

Les operacions disponibles per treballar amb números són les clàssiques: ��

Les principals funcions que permeten el tractament numèric són:

�4#��6�Retorna el valor absolut de n.

4��! ��% �6 realitza una operació AND bit a bit entre els dos

arguments

$��6 Retorna l'enter més petit que sigui més gran o igual que n.

-��6�Retorna l'enter més gran que sigui igual o més petit que n

��!� %��6 Retorna la resta de dividir m per n.

3�0�� %��6 Retorna m elevat a l'enèsima, si m és negatiu cal que n

sigui enter.

��"�!��% ��6 Retorna n arrodonit a m llocs decimals; m enter i per

defecte = 0.

#�2��6 Retorna -1 si n és negatiu, 1 si és positiu i 0 si és 0.

#@��6 Retorna l'arrel quadrada de n, n no pot ser negatiu.

�� *'�

��

��=�"�4��'1% �% & �% �(��'�' ��6�Converteix una cadena de

caràcters numèrics en el número que representa, segons el format donat.

��"�$ �� % ��6�Retorna n truncat a m llocs decimals; m enter i per

defecte = 0.�

A continuació es presenten uns quants exemples:

Llistar els guanys totals de tots els venedors

Llistar tots els empleats tal que la seva comissió superi el 25% del seu

salari

Calcular els guanys anyals (14 pagues) de tots els venedors

Calcular el salari diari, arrodonit a un decimal, dels empleats del

departament 30 (22 dies al mes)

Calcular el salari diari, truncat a enters, dels empleats del departament 30

(22 dies al mes)

Càlcul dels enters més propers a un número

SELECT Nom, Salari + Comissio FROM Empleat WHERE Categoria = ’Venedor’

SELECT Nom, Salari, Comissio FROM Empleat WHERE Comissio > 0.25 * Salari

SELECT Nom, 14 * (Salari + comissio) FROM Empleat WHERE Categoria = ’Venedor’

SELECT Nom, Salari, ROUND(Salari / 22, 1) FROM Empleat WHERE Departament = ’30’

SELECT Nom, Salari, TRUNC (Salari / 22, 1) FROM Empleat WHERE Departament = ’30’

�**� � �� !��

��

Arrodoniments i truncaments

Convertir la cadena '876.3456' a un valor numèric

Encara que existeixen 21 modificadors diferents per formats numèrics,

els més importants són

D Retorna el separador decimal a la posició donada

9 Retorna el valor amb el nombre específic de dígits

0 Ajusta el valor amb el nombre específic de zeros

B Ajusta el valor amb el nombre específic de blanc

��!��(��#/��#��

L'única operació disponible per treballar amb cadenes de caràcters és la

de concatenació��

Les principals funcions que permeten el tractament de cadenes de

caràcters retornant cadenes de caràcters són:

$��$��'1A%�'1B�6 Encadena les dues cadenes de caràcters.

��$�3 ��'1�6 Retorna la cadena amb el primer caràcter de cada

paraula en majúscules i les altres en minúscules.

��0��'1�6 Retorna la cadena amb tots els caràcters en minúscules.

�3�!��'1A%��%�'1B��6 Retorna la cadena cad1 ajustada a la llargada n

col·locant a l'esquerra repeticions de cad2.

��'1% �% �)�C*� ��6 Treu caràcters de l'esquerra de cad, fins que

tots el que apareixen a conjunts estiguin fora.

SELECT CEIL(13.6) "Excés", FLOOR(13.6) "Defecte" FROM DUAL

SELECT ROUND(763.25), ROUND(763.25,1), ROUND(763.25,-2) FROM DUAL

SELECT TRUNC(763.25), TRUNC(763.25,1), TRUNC(763.25,-2) FROM DUAL

SELECT TO_NUMBER('876,3456', '9999D99999') FROM DUAL

�� *+�

��

��3��$� ��'1% �'1=��' �% �'1=�� ('D' �� 6 Retorna cad amb

totes les aparicions de cad_cerca substituïdes per cad_remplaçament.

�3�!��'1A%��%�'1��6 Retorna la cadena cad1 ajustada a la llargada n

col·locant a la dreta repeticions de cad2.

��'1�%�)�C*� ��6 Treu caràcters de la dreta de cad, fins que tots

el que apareixen a conjunts estiguin fora.

#"4#��'1% �%��6 Retorna un tros de cad, començant al caràcter m

i de n caràcters de llargada.

#"4#��4��'1% �%��6 Retorna un tros de cad, començant al byte m i

de n bytes de llargada.

��=$��1�%& �%�(��'�' ��6 Converteix una data o un número en

una cadena de caràcters segons un format donat.

��#�� '1% 1�% '�6 Retorna cad amb totes les ocurrències del

caràcter de reemplaçat pel caràcter corresponent de a.

"33��'1�6�Retorna la cadena amb tots els caràcters en majúscules.�

Les principals funcions que a partir d'una cadena de caràcters retornen un

valor numèric són:

��#$��'1�6�Retorna la representació decimal en el joc de caràcters de la

Base deDades del primer caràcter de la cadena.

��#�� '1A% �'1B �% � �% ��6 Cerca cad1 començant per l'enèsim

caràcter de l'emèsima ocurrència de cad2 i retorna la posició del caràcter

en cad1 que és el primer caràcter d'aquesta ocurrència.

��2��'1�6�Retorna la llargada de la cadena en caràcters.

�

A continuació es presenten una sèrie d’exemples

Encadenar amb un guió el codi i el nom de cada departament

Construir frases que indiquin la categoria de cada empleat

Llistar el nom dels empleats en majúscules i la categoria en minúscules

SELECT CONCAT(Codi, CONCAT(’ - ’, Nom)) FROM Departament

SELECT Nom || ' és el ' || Categoria FROM Empleat

SELECT UPPER(Nom), LOWER (Categoria) FROM Empleat

�*�� !��

��

Posar el nom de tots els empleats del departament 30, 40 posicions més

enllà el salari i entre ells una línia de punts

Escriure els noms dels empleats substituint les "a" per "e" i les "r" per "l"

Trobar en quina posició de caràcter del nom apareix per primera vegada

"al"

Escriure el salari que guanya cada empleat

�

��%�!��(� ��

Les funcions que permeten el tractament de dates són:

�!!=��#�1%��6� Retorna la data d més n mesos.

$"��=!��6 Retorna la data actual, en l'horari de la sessió.

$"��=��#��36 Retorna la data i hora actual, en l'horari de

la sessió.

��#�=!��1�6 Retorna la data del darrer dia del mes de la data d.

��#=4��0��1A%1B�6 Nombre de mesos entre les dues dates.

��0=��1% EA% EB�6 Retorna la data i hora a la zona z2 quan és el

moment d a la zona z1.

��8�=!��1% �'1�6 Retorna la data del primer dia de la setmana cad

que ésposteriors a la data d.

��"�!�1 �% & ��6 Retorna d arrodonida a la unitat especificada pel

model de format fmt.

SELECT nom || LPAD (Salari, 40-LENGTH( Nom ), ’.’ ) FROM Empleat WHERE Departament = ’30’

SELECT TRANSLATE(Nom, ’ar’, ’el’) FROM Empleat

SELECT INSTR(Nom, ’al’) FROM Empleat

SELECT TO_CHAR(Salari) || ’ Euros’ FROM Empleat

�� *,�

��

#�#!��$ Retorna la data i hora del Sistema.

��=!��'1 �% & �% �(��'�' ��6 Converteix una cadena de

caràcters en una data segons un format donat.

��"�$�1�%& ��6 Retorna d truncada a la unitat especificada pel model

de format fmt.

A continuació es presenten un quants exemples de treball amb dates

Presentar el nom i la data d'alta en format estàndard de tots els

treballadors del departament 20

Llistar tots els empleats del Departament 20 i data de la seva primera

revisió salarial (a l'any de la contractació)

Presentar la data actual, del Sistema i de la sessió

Trobar el nombre de dies que resten del present any

Llistar els empleats contractats entre el 4 de gener de 1994 i el 15 d'abril

del mateix any en ordre d'antiguitat

Retorna el primer dia del mes actual

SELECT Nom, DataAlta FROM Empleat WHERE Departament = ’20’

SELECT Nom, ADD_MONTHS(DataAlta, 12) FROM Empleat WHERE Departament = ’20’

SELECT sysdate, CURRENT_DATE from dual

SELECT ROUND (TO_DATE (’31/12/99’, ’DD/MM/YY’) - SYSDATE, 0) FROM DUAL

SELECT nom, DataAlta FROM Empleat WHERE DataAlta BETWEEN TO_DATE(’04/01/94’, ’DD/MM/YY’)AND TO_DATE(’15/04/94’, ’DD/MM/YY’) ORDER BY DataAlta

�*-� � �� !��

��

Quan se suma o resta un valor numèric a una data, el sistema considera

que aquest valor representa un nombre de dies, si es vol saber l'hora que

serà dintre de 3 dies i 6 hores

Presentar la data d'alta dels empleats en el format 15 Gener 1998.

Existeixen diferents formats de dates (exactament 52) el més importants:

�� &56 575!��

D Dia de la setmana (1-7)

DAY Nom del dia de la setmana

DD Dia del mes (1-31)

DDD Dia de l'any (1-366)

HH Hora del dia (1-12)

HH24 Hora del dia (0-23)

IW Setmana de l'any (1-52,53) format ISO

IY IYY IYYY IYYYY Dígits de l'any en format ISO

MI Minuts (0-59)

MONTH Nom del mes

SS Segons (0-59)

SSSSS Segons després la mitjanit (0-86399)

WW Setmana de l'any

W Setmana del mes (1-5)

Y YY YYY YYYY Dígits de l'any

�

��0��1�� 8��#.��Actualment és possible utilitzar el nou tipus nadiu de dades INTERVAL,

amb ell s'amplia molt les popssi8bilitats de treballar amb el temps. No

SELECT TRUNC(SYSDATE, ’MM’) FROM DUAL

SELECT SYSDATE + 3.25 FROM DUAL

SELECT TO_CHAR(DataAlta, ’DD Month YYYY’) FROM Empleat

�� *��

��

s’ha de confondre DATE que indica un punt en el continu del temps amb

INTERVAL que indica la "distància" entre dos punts de l'eix del temps.

Per tal de veure les diferents possibilitats es crearà la taula amb els

"temps" d'una etapa contra-rellotge de ciclisme

Primerament s'introduirà l'hora de sortida

En el moment de l'arribada es van introduint els temps

Cal recordar l'aritmètica de dates i intrvals:

• Dada1 – Dada2 = Interval

• Dada1 ± Interval = Dada2

Si es vol trobar l'hora d'arribada de cada corredor

CREATE TABLE Arribada ( Dorsal CHAR(4) CONSTRAINT PK_Arribada PRIMARY KEY, Sortida TIMESTAMP(2) CONSTRAINT NN_ArribadaSortida NOT NULL, Marca INTERVAL DAY TO SECOND)

INSERT INTO Arribada VALUES (’1’, TO_TIMESTAMP(’18/11/2001 10:15:00’, ’DD/MM/YYYY HH:MI:SS’), NULL); INSERT INTO Arribada VALUES (’2’, TO_TIMESTAMP(’18/11/2001 10:17:00’, ’DD/MM/YYYY HH:MI:SS’), NULL); INSERT INTO Arribada VALUES (’3’, TO_TIMESTAMP(’18/11/2001 10:19:00’, ’DD/MM/YYYY HH:MI:SS’), NULL); INSERT INTO Arribada VALUES (’4’, TO_TIMESTAMP(’18/11/2001 10:21:00’, ’DD/MM/YYYY HH:MI:SS’), NULL); INSERT INTO Arribada VALUES (’5’, TO_TIMESTAMP(’18/11/2001 10:23:00’, ’DD/MM/YYYY HH:MI:SS’), NULL);

UPDATE Arribada SET Marca = INTERVAL ’1:27:15.37’ HOUR TO SECOND(2) WHERE Dorsal = ’1’; UPDATE Arribada SET Marca = INTERVAL ’1:25:36.78’ HOUR TO SECOND(2) WHERE Dorsal = ’2’; UPDATE Arribada SET Marca = INTERVAL ’1:28:3.11’ HOUR TO SECOND(2) WHERE Dorsal = ’3’; UPDATE Arribada SET Marca = INTERVAL ’1:27:12.86’ HOUR TO SECOND(2) WHERE Dorsal = ’4’; UPDATE Arribada SET Marca = INTERVAL ’1:26:46.36’ HOUR TO SECOND(2) WHERE Dorsal = ’5’;

�+%� � �� !��

��

Si es vol trobar el dorsal dels corredors que han arribar abans de les

11:45:00

�

�

��$�!��(��

Cada element de la base de dades pot estar en dos estats diferents: amb

valor o nul. Aquest estat de NULL pot tenir dos significats diferents: a)

valor desconegut, el camp podria tenir un valor, però aquest és, per ara,

desconegut; b) valor inaplicable, el camp no té sentit en aquesta fila en

particular. L'estat NULL introdueix una lògica de tres valors Cert

(TRUE), Fals (FALSE) i Desconegut (UNKNOWN). Cal recordar que la

condició WHERE sols retorna aquelles files per les quals la condició de

cerca pren el valor TRUE. Aquesta lògica dona lloc a les condicions

Les taules de veritat per a la lògica tri-valuada són

9��

��0�� FALSE

7��&�� TRUE

0 : 9; � UNKNOWN

� �� 0�� 7��&�� 0 : 9; �

��0�� TRUE FALSE UNKNOWN

7��&�� FALSE FALSE FALSE

0 : 9; � UNKNOWN FALSE UNKNOWN

9�� 0�� 7��&�� 0 : 9; �

��0�� TRUE TRUE TRUE

7��&�� TRUE FALSE UNKNOWN

0 : 9; � TRUE UNKNOWN UNKNOWN

A la següent taula es pot veure el resultat de diferents comparacions, si la

comissió està en l'estat NULL

SELECT Dorsal, TO_CHAR(Sortida + Marca, ’HH:MI:SS.SS’) Arriba FROM Arribada

SELECT Dorsal FROM Arribada WHERE Sortida + Marca < TO_TIMESTAMP(’18/11/2001 11:45:00’, ’DD/MM/YYYY HH:MI:SS’)

�� +��

��

!�� <��#��=��

comissió = NULL UNKNOWN

comissió != NULL UNKNOWN

NOT (comissió = NULL) UNKNOWN

NOT (comissió != NULL) UNKNOWN

comissió = 100 UNKNOWN

comissió IS NULL TRUE

comissió IS NOT NULL FALSE

Si la comissió té el valor de 100, la taula resultarà

!�� <��#��=��

comissió = NULL UNKNOWN

comissió != NULL UNKNOWN

NOT (comissió = NULL) UNKNOWN

NOT (comissió != NULL) UNKNOWN

comissió = 100 TRUE

comissió IS NULL FALSE

comissió IS NOT NULL TRUE

La funció més usual que implica la utilització d’un valor nul és

Les funcions de resum no tenen en compte les columnes per les quals

l’expressió pren el valor NULL.

A continuació es presenten uns quants exemples

Llistar els empleats que no tenen previst rebre comissions

Llistar el nom dels empleats tal que la seva comissió no sigui igual a

1640.15 �

��.��A%�.�B�6#��.��AF��"�� )��'�.��B%��)�.��A,

SELECT Nom FROM Empleat WHERE Comissio IS NULL

SELECT Nom FROM Empleat WHERE Comissio != 1640.15

�+$� � �� !��

��

Llistar els empleats que poden cobrar comissió

Empleats del departament 30 en ordre ascendent de comissions (els nuls

al final)

Llistar els empleats del departament 30 en ordre descendent de

comissions (els nuls al principi)

Llistar els noms, categories i guanys totals de tots els empleats del

departament 30 (la suma no sempre té sentit)

Trobar els guanys totals dels empleats del departament 30, considerant el

NULL com igual a zero

Comptar el nombre d'empleats del departament 30 que poden rebre

comissió

SELECT Nom FROM Empleat WHERE Comissio IS NOT NULL

SELECT Nom, Comissio FROM Empleat WHERE Departament = ’30’ ORDER BY Comissio

SELECT Nom, Comissio FROM Empleat WHERE Departament = ’30’ ORDER BY Comissio DESC

SELECT Nom, Categoria, Salari, Comissio, Salari + Comissio FROM Empleat WHERE Departament = ’30’

SELECT Nom, Categoria, Salari, Comissio, Salari + NVL(Comissio, 0) FROM Empleat WHERE Departament = ’30’

SELECT COUNT(Salari), COUNT(Comissio) FROM Empleat WHERE Departament = ’30’

�� +'�

��

Trobar els guanys medis dels empleats del departament 30

Llistar el nom de tots els departaments sense empleats

Llistar els empleats que tinguin al menys un altre empleat sota el seu

càrrec.

��'�� >��

Sobre una Base de Dades es poden realitzar les operacions d’inserir,

esborrar i actualitzar files d’una taula. Per inserir una única fila la sintaxi

és

si es volen inserir múltiples files a l’hora

A tall d’exemple

Afegir un nou empleat a la taula d’empleats

SELECT AVG(Salari+Comissio),AVG(Salari+NVL(Comissio, 0)) FROM Empleat WHERE Departament = ’30’

SELECT DISTINCT D.Codi, D.Nom FROM Departament D RIGHT OUTER JOIN Empleat E ON D.Codi = E.Departament WHERE E.Codi IS NULL

SELECT Nom, Categoria, Departament, Salari FROM Empleat X WHERE EXISTS (SELECT * FROM Empleat Y WHERE X.codi = Director)

��#��) = '*('��) =�)(* �'%,,,,�� ,,,��"�#��.��!�-�"��%,,,�

��#��) = '*('��) =�)(* �'%,,,,�� ,,,�� G��'=��(��

�+*� � �� !��

��

Inseriu, després de crear-la, a la taula cap el codi, el nom, la categoria i el

salari d’aquelles persones que tinguin algú sota la seva responsabilitat

El procés anterior s'hauria pogut fer amb una única sentència

Molt sovint és interessant indicar qui ha de realitzar la inserció, o alguna

de les seves característiques, per això s'utilitzen les funcions

"�!6 Retorna un enter que identifica de forma única a l'usuari actual.

"#��$ Retorna una cadena de caràcters amb el "login" de l'usuari.

"#��)��6 Retorna una cadena de caràcters amb informació

sobre la sessió,

INSERT INTO Empleat (Codi, Nom, Localitat, Categoria, Director, DataAlta, Salari, Departament) VALUES ('638', 'Ventura', 'Mataró', 'oficial', '782', '10/01/1999', 900, '10')

INSERT INTO Empleat VALUES ('638', 'Ventura', 'Mataró', 'oficial', '782', '10/01/1999', 900, NULL, '10')

CREATE TABLE Cap ( Numero CHAR(3) CONSTRAINT PK_Cap PRIMARY KEY, Cognom VARCHAR2(10) CONSTRAINT NN_CapCognom NOT NULL, Nivell VARCHAR2(10) CONSTRAINT NN_CapNivell NOT NULL, Sou NUMBER(6, 2) CONSTRAINT NN_CapSou NOT NULL)

INSERT INTO Cap (Numero, Cognom, Nivell, Sou) SELECT Codi, Nom, Categoria, Salari FROM Empleat X WHERE EXISTS (SELECT * FROM Empleat Y WHERE X.Codi = Director)

CREATE TABLE Cap (Numero, Cognom, Nivell, Sou) AS SELECT Codi, Nom, Categoria, Salari FROM Empleat X WHERE EXISTS (SELECT * FROM Empleat Y WHERE X.Codi = Director)

�� ++�

��

Opcions$��! )��*)+,�),��-�.��+)*��+�!��+-./�!��

*)+,��+�-)+0�

� � � �

Quin usuari, en quin llenguatge i en quin terminal està treballant

A les insercions (i també a les modificacions) el SGBD convertirà de

forma implícita cadenes numèriques a números i viceversa, per tal de

forçar l'adaptació de tipus.

Per esborrar files d’una taula s’utilitza la sentència

La segona clàusula FROM permet fer esborrats basats en una junció, la

clàusula WHERE qualifica les files del segon FROM, mentre que el

primer FROM indica la taula que s’ha d’esborrar. Per exemple

Esborrar totes les files de la taula cap

Esborrar l’empleat 369 de la taula empleat

Esborrar tots els empleats contractats després de 1995

Per modificar valors de les taules s’utilitza la sentència UPDATE, la

sintaxi és

SELECT USER, USERENV(’LANGUAGE’), USERENV(’TERMINAL’) FROM DUAL

!��-��) = '*(' ,,,�-��((�� '= '*(' ,,,�0��)�1��=��'�

DELETE FROM Cap

DELETE FROM Empleat WHERE Codi = ’369’

DELETE FROM Empleat WHERE DataAlta > TO_DATE(’1995’, ’YYYY’)

�+�� !��

��

Per exemple

Traspassar a l’empleat 566 del departament 30 al 20

Incrementar en un 10% el salari dels membres del departament 30

És possible utilitzar subconsultes per tal de realitzar actualitzacions

complexes, la següent actualitza el departament, el codi i la comissió

d'aquells empleats que treballen a Calella o Barcelona, traspassant-los al

departament de Mataró, i posant-los un sou que sigui un 10% superior al

del departament del qual provenien i una comissió un 20% superior a la

mitjana de sous del departament d'origen

��*��.��

En SQL es poden definir dos tipus diferents de taules, les taules bàsiques

i les taules de vista, o més simplement, vistes. Una taula bàsica és una

taula amb existència real, és a dir, que està típicament emmagatzemat als

"3!��((�� '= '*(' ,,,#��) =�)(* �'9�.��%,,, ,,,0��)�1��=��'

UPDATE Empleat SET Departament = ’20’ WHERE Codi = ’566’

UPDATE Empleat SET Salari = 1.1 * Salari WHERE Departament = ’30’

UPDATE Empleat X SET Departament = (SELECT Codi FROM Departament WHERE Localitat = 'Mataró'), (Salari, Comissio) = (SELECT 1.1 * AVG(Salari), 1.5 * AVG(Salari) FROM Empleat Y WHERE X.Departament = Y.Departament) WHERE Departament IN (SELECT Codi FROM Departament WHERE Localitat IN ('Calella', 'Barcelona');

�� +,�

��

registres; al contrari, una vista és una taula que no té existència real, una

taula virtual, encara que l'usuari l'utilitza com si existís.

Les vistes són creades, o millor dit definides, en termes d'altres taules,

guardant-se la seva definició al diccionari de dades el qual converteix les

consultes que l'utilitzen. La sintaxi general és

La clàusula FORCE indica que cal crear la vista tot i que les taules que

referencia no estiguin encara definides. READ ONLY indica que no es

poden realitzar cap mena de modificació de les taules utilitzant la vista,

mentre que CHECK OPTION [CONSTRAINT restricció ] comprovarà

que les modificacions realitzades utilitzant la vista sols afecten a files que

pot consultar la vista, poden deshabilitar més tard aquesta restricció.

Les vistes es poden utilitzar per diferents propòsits:

• Proporcionar un nivell addicional de seguretat sobre una taula,

restringint l'accés a un determinar conjunt de files o columnes.

• Fer transparent la complexitat de les dades, presentar en una

única taula informació que es troba repartida entre múltiples

taules.

• Presentar les dades des d'altra perspectiva, es pot canviar el nom

de les columnes sense necessitat de modificar la taula.

Exemples de definició de vistes

Crear una vista amb el nom categoria i salari dels mataronins

Quan es fa servir una vista en una consulta, el DBMS tradueix la consulta

en terme de la consulta, per exemple

$��3��$��-��$�� 0H�� '��((�� '��) '��)(* �'�� #�.�� '*(' �0��!�� $��$7�3��$��#��

CREATE VIEW Mataroni (Nom, Categoria, Salari) AS SELECT Nom, Categoria, Salari FROM Empleat WHERE Localitat = 'Mataró'

�+-� � �� !��

��

s’interpretaria com

una taula es pot eliminar per medi de la sentència

Sobre totes les vistes es poden realitzar consultes, el que succeeix és que

no totes són actualitzables (modificar, esborrar o inserir), una vista és

actualitzable si compleix totes les condicions següents:

• L'expressió de taula que defineix l'àmbit de la vista serà una expressió

de selecció, és a dir, no contindrà directament cap de les paraules

claus UNION, INTERSECT o MINUS.

• La clàusula SELECT de l'expressió de selecció no contindrà

directament la paraula clau DISTINCT.

• Cada ítem seleccionat a la clàusula SELECT consistirà en un nom de

columna qualificat que representarà una referència a una columna de

la taula inferior.

• La clàusula FROM de l'expressió de selecció contindrà, exactament,

sols una referència de taula.

• L'expressió de selecció no inclourà una clàusula WHERE amb una

expressió de taula niuada que inclogui una clàusula FROM que

referenciï a la mateixa taula que la primera clàusula FROM.

• L'expressió de selecció no inclourà cap clàusula GROUP BY.

• L'expressió de selecció no inclourà cap clàusula HAVING.

�

��+��#��

��+�� Les taules següents es refereixen a una petita empresa de

distribució, les taules són: a) CLIENT, els quals compres els productes de

l'empresa; b) COMANDA, efectuades pels clients; c) VENEDOR, els

quals venen els productes als clients; d) OFICINA, llocs on treballen els

SELECT Nom, Categoria FROM Mataroni WHERE Salari > 250000

SELECT Nom, Categoria FROM Empleat WHERE Salari > 1500 AND Localitat = 'Mataró'

!��3��0�)

�� +��

��

venedors; e) PRODUCTE, tots els productes que ven l’empresa. Les

taules han estat creades amb les sentències

CREATE TABLE Venedor ( Codi CHAR(2) CONSTRAINT PK_Venedor PRIMARY KEY, Nom VARCHAR2(25)CONSTRAINT NN_VenedorNom NOT NULL, Oficina CHAR(2) , Quota NUMBER(7,2) CONSTRAINT CH_VenedorQuota CHECK (Quota > 0), Vendes NUMBER(7,2) CONSTRAINT NN_VenedorVendes NOT NULL CONSTRAINT CH_VenedorVendes CHECK (Vendes >= 0), Edat NUMBER(3) CONSTRAINT NN_VenedorEdat NOT NULL CONSTRAINT CH_VenedorEdat CHECK (Edat > 0), DataAlta DATE CONSTRAINT NN_VenedorDataAlta NOT NULL, Director CHAR(2), Categoria VARCHAR2(20) CONSTRAINT NN_VenedorCategoria NOT NULL)

CREATE TABLE Comanda ( Codi CHAR(5) CONSTRAINT PK_Comanda PRIMARY KEY, Client CHAR(3) CONSTRAINT NN_ComandaClient NOT NULL, Data DATE CONSTRAINT NN_ComandaData NOT NULL, Venedor CHAR(2) CONSTRAINT NN_ComandaVenedor NOT NULL, Producte CHAR(5) CONSTRAINT NN_ComandaProducte NOT NULL, Fabricant CHAR(3) CONSTRAINT NN_ComandaFabricant NOT NULL, Quantitat NUMBER(4) CONSTRAINT NN_ComandaQuantitat NOT NULL CONSTRAINT CH_ComandaQuantitat CHECK (Quantitat>0), Import NUMBER(7,2) CONSTRAINT NN_ComandaImport NOT NULL CONSTRAINT CH_ComandaImport CHECK (Import > 0))

CREATE TABLE Client ( Codi CHAR(3)CONSTRAINT PK_Client PRIMARY KEY, Nom VARCHAR2(25) CONSTRAINT NN_ClientNom NOT NULL CONSTRAINT UN_ClientNom UNIQUE, Venedor CHAR(2) CONSTRAINT NN_ClientVenedor NOT NULL, Credit NUMBER(7,2) CONSTRAINT NN_ClientCredit NOT NULL CONSTRAINT CH_ClientCredit CHECK (Credit > 0))

CREATE TABLE Producte ( Codi CHAR(5), Fabricant CHAR(3), Descripcio VARCHAR2(75) CONSTRAINT NN_ProducteDescripcio NOT NULL, Preu NUMBER(7,2) CONSTRAINT NN_ProductePreu NOT NULL CONSTRAINT CH_ProductePreu CHECK (Preu > 0), Estoc NUMBER(4) CONSTRAINT NN_ProducteEstoc NOT NULL CONSTRAINT CH_ProducteEstoc CHECK (estoc >= 0), CONSTRAINT PK_Producte PRIMARY KEY (Codi, fabricant))

��%� � �� !��

��

975!5 �� !� �� !�� #�.�� 9(2�� <�� !�� 11 Alfarràs Lleida 34000 24000 6 12 Olot Girona 46000 16305 4 14 Amposta Tarragona 21000 25221 5 21 Alcobendas Madrid 42000 48724 8 22 Mataró Barcelona 18000 20616 8

CREATE TABLE Oficina ( Codi CHAR(2) CONSTRAINT PK_Oficina PRIMARY KEY, Ciutat VARCHAR2(25) CONSTRAINT NN_OficinaCiutat NOT NULL CONSTRAINT UN_OficinaCiutat UNIQUE, Provincia VARCHAR2(25), Objectiu NUMBER(7,2) CONSTRAINT NN_OficinaObjectiu NOT NULL CONSTRAINT NN_OficinaObjectiu CHECK (Objectiu > 0), Vendes NUMBER(7,2) CONSTRAINT NN_OficinaVendes NOT NULL CONSTRAINT CH_OficinaVendes CHECK (Vendes >= 0), Cap CHAR(2) CONSTRAINT NN_OficinaCap NOT NULL)

ALTER TABLE Client ADD CONSTRAINT FK_Client FOREIGN KEY(Venedor) REFERENCES Venedor(Codi)

ALTER TABLE Comanda ADD CONSTRAINT FK1_Comanda FOREIGN KEY(Client) REFERENCES Client(codi)

ALTER TABLE Comanda ADD CONSTRAINT FK2_Comanda FOREIGN KEY(Venedor) REFERENCES Venedor(codi)

ALTER TABLE Comanda ADD CONSTRAINT FK3_Comanda FOREIGN KEY(Producte, Fabricant) REFERENCES Producte(Codi,Fabricant)

ALTER TABLE Venedor ADD CONSTRAINT FK1_Venedor FOREIGN KEY(Oficina) REFERENCES Oficina(codi)

ALTER TABLE Venedor ADD CONSTRAINT FK2_Venedor FOREIGN KEY(Director) REFERENCES Venedor(codi)

ALTER TABLE Oficina ADD CONSTRAINT FKoficina FOREIGN KEY(Cap) REFERENCES Venedor(codi)

��

��

COMANDA !� �� Client �� Venedor �#� �� 7�(#�� ?�� 5��#�� 10036 107 30/1/97 10 4100Z ACI 9 13473 12961 117 17/12/96 6 2A44L REI 7 18865 12963 103 17/12/96 5 41004 ACI 28 1960 12968 102 12/10/96 1 41004 ACI 34 2380 12975 111 12/10/96 10 2A44G REI 6 1260 12979 114 12/10/96 2 4100Z ACI 6 8982 12983 103 27/12/96 5 41004 ACI 6 420 12987 103 31/12/96 5 4100Y ACI 11 18117 12989 101 3/1/97 6 114 FEA 6 876 12992 118 4/11/96 8 41002 ACI 10 460 12993 106 4/1/96 2 2A45C REI 24 1128 12997 124 8/1/97 7 41003 BIC 1 390 13003 108 25/1/97 9 779C IMM 3 3369 13007 112 8/1/97 8 773C IMM 3 1752 13012 111 11/1/97 5 41003 ACI 35 2240 13013 118 14/1/97 8 41003 BIC 1 390 13024 114 20/1/97 8 XK47 QSA 20 4260 13027 103 22/1/97 5 41002 ACI 54 2484 13034 107 29/1/97 10 2A45C REI 8 376 13042 113 2/2/97 1 2A44R REI 5 13475 13045 112 2/2/97 8 2A44R REI 10 26950 13048 120 10/2/97 2 779C IMM 2 2246 13049 118 10/2/97 8 XK47 QSA 2 426 13051 118 10/2/97 8 XK47 QSA 4 852 13055 108 15/2/97 1 4100X ACI 6 90 13057 111 18/2/97 3 4100X ACI 24 360 13058 108 23/2/97 9 112 FEA 10 890 13062 124 24/2/97 7 114 FEA 10 1460 13065 106 27/2/97 2 XK47 QSA 6 1278 13069 109 2/3/97 7 775C IMM 22 18766

<� ��9�� !� �� 9�� ?�� <�� DataAlta ��#��#� !��#�� 1 Daniel Bas 12 18000 15945 45 20/10/93 4 Representant 10 Joan Armengol 15109 41 13/1/97 1 Representant 2 Susana Prats 21 21000 13634 48 10/12/93 8 Representant 3 Pau Cases 12 16000 360 29 1/3/94 4 Representant 4 Robert Pérez 12 12000 0 33 19/5/94 6 Cap d'equip 5 Joan Mas 14 21000 25221 37 12/2/95 4 Representant 6 Samuel Pont 11 16000 19741 52 14/1/95 Cap Departament 7 Neus Pera 22 18000 20616 49 14/11/95 8 Representant 8 Albert Vila 21 21000 35090 62 12/10/96 6 Cap d'equip 9 Maria Mons 11 18000 4259 31 12/10/96 6 Representant

��$� � �� !��

��

��9�0!� Codi 7�(#�� #�� #�� 112 FEA Coberta 89 115 114 FEA Bancada motor 146 15 2A44G REI Passador 210 14 2A44L REI Frontisa esq. 2695 12 2A44R REI Frontisa dta. 2695 12 2A45C REI Trinquet vàstag 47 210 41001 ACI Article tipus 1 33 277 41002 ACI Article tipus 2 46 167 41003 ACI Article tipus 3 64 207 41003 BIC Maneta 390 3 41004 ACI Article tipus 4 70 139 4100X ACI Ajustador 15 37 4100Y ACI Extractor 1647 25 4100Z ACI Montador 1497 28 41089 BIC Retenedor 135 78 41672 BIC Plat 108 0 773C IMM Riostra 0.5 Tm 584 28 775C IMM Riostra 1 Tm 853 5 779C IMM Riostra 2 TM 1123 9 887H IMM Suport riostra 32 223 887X IMM Retenedor 284 32 XK47 QSA Reductor 213 38 XK48 IMM Reductor 80 203 XK48A QSA Reductor 70 37

CLIENT Codi �� Venedor !#4 �� 101 CMB 6 39000 102 Joan Associats 1 39000 103 ACMR 5 30000 105 Inversions Pujol 1 27000 106 Joan Sala Corporation 2 39000 107 Pep SL 10 21000 108 Joan & Pere 9 33000 109 El barat 7 15000 111 JPC SA 3 30000 112 Construccions Maresme 8 30000 113 Neus i Pilar 4 12000 114 Orion 2 12000 115 Pere Corporation 1 12000 117 Moda jove 6 21000 118 Sistemes Associats 8 36000 119 Vila Moda 9 15000 120 Empresa ric 2 30000 121 QMC SAL 3 27000 122 La comercial 5 18000 123 Tomeu i fills 2 24000 124 Germans Mars 7 24000

�� '�

��

A partir de les taules anteriors, construir sentències SQL que permetin

donar resposta a les següents consultes.

1.- Llista de les oficines de venda, els seus objectius i les seves vendes

reals.

2.-Llista de les oficines de venda de la província de Barcelona amb els

seus objectius i vendes reals.

3.- Llista de les oficines de venda de la província de Barcelona, tal que

les seves vendes superin els seus objectius, ordenades alfabèticament per

ciutats.

4.- Les mitjanes d'objectius i vendes per les oficines de venda de

Barcelona.

5.- Nom, oficines i data de contracte per tots els venedors.

6.- Nom, quota i vendes del venedor 17.

7.- Mitjana de vendes dels venedors.

8.- Nom i data de contracte de qualsevol venedor que hagi realitzat

vendes per valor superior a 25.000 �

9.- Nom dels venedors, quotes i codi del seu director.

10.- Per a cada oficina, ciutat, província i diferència, per sobre o per sota,

de les vendes sobre els objectius.

11.- Per a cada producte valor de l'inventari (existències per preu unitari).

12.- Nom, mes i any de contracte per a cada venedor.

13.- Llista de vendes per a cada ciutat.

14.- Codi de tots els directors.

15.- Oficines tal que les vendes superin els objectius.

16.- Nom de tots els venedors dirigits pel venedor 14.

17.- Nom de tots els venedors contractats abans de 1988.

18.- Oficines tal que les seves vendes estiguin per sota del 80% dels seus

objectius

19.- Oficines no dirigides pel venedor 21.

20.- Nom i límit de crèdit del client 439.

21.- Nom dels venedors que no estan entre el 80% i el 120% del seu

objectiu.

22.- Llista dels venedors que treballen a Barcelona, València o Bilbao.

23.- Venedors que encara no tenen assignada una oficina.

24.- Venedors que tenen oficina.

25.- Venedors que estan per sota de la quota o amb vendes inferiors a

20.000 ��

26.- Venedors que estan per sota de la quota i amb vendes inferiors a

20.000 �

27.- Venedors que estan per sota de la quota, però que les seves vendes

no són inferiors a 20.000 ��

��*� � �� !��

��

28.- Vendes de cada oficina, ordenades alfabèticament per províncies i

dintre de les províncies per ciutats.

29.- Llista d'oficines ordenades descendentment per vendes.

30.- Llista d'oficines ordenades descendentment pel percentatge

d'acompliment de la quota.

31.- Llista de tots els productes tal que el seu preu excedeixi les 180 ��

32.- Llista de tots els productes pels quals més de 2.750 ��

hagin estat demanats en una sola comanda.

33.- Llista de tots els productes tal que el seu preu excedeixi les 180 ��

pels quals més de 42.750 �� hagin estat demanats en una sola

comanda.

34.- Llista de totes les comandes, mostrant el seu codi, import, codi de

client i el límit de crèdit del client.

35.- Llista, per tots els venedors, la ciutat i província on treballen.

36.- Llista el nom del director de totes les oficines que tinguin un objectiu

superior a 35.000 �

37.- Mostreu totes les comandes, amb els imports i descripcions dels

productes.

38.- Llista de totes les comandes superiors a 2.400 ��

venedor que va realitzar la venda i del client.


venedor que va realitzar la venda, del client i el nom del venedor assignat

al client.


venedor que va realitzar la venda, del client i el nom del venedor assignat

al client i l'oficina on, aquest treballa.

41.- Llista el nom de tots els venedors i el dels seus caps.

42.- Llista dels venedors amb una quota superior a la del seu cap.

43.- Llista dels venedors que treballen en oficines diferents de les dels

seus caps, mostrant l'oficina en què treballa cadascun.

44.- Nom de l'empresa i totes les comandes del client 983.

45.- Llista de tots els venedors (encara que no tinguin oficina) i lloc on

treballen.

46.- Quin és la mitjana del rendiment de quota de tots els venedors.

47.- Quina és la quota global i el total de vendes dels venedors.

48.- Quant sumen les comandes acceptades per En Joan Pera.

49.- Quina és la quota màxima i mínima assignada als venedors.

50.- Quina és la comanda més antiga.

51.- Quin és el millor rendiment de quota de tots els empleats

52.- Quants clients hi ha.

53.- Quants venedors superen la quota.

54.- Trobar la mitjana de les comandes, el total de totes les comandes, la

mitjana de la comanda com percentatge del límit de crèdit del client i la

�� +�

��

mitjana de la comanda com percentatge de la quota del venedor que l’ha

realitzat.

55.- Quantes categories diferents tenen els venedors.

56.- Quantes oficines de vendes tenen venedors que superin les seves

quotes.

57.- Quina és la mitjana de les comandes per a cada venedor.

58.- Quin és el rang de quotes assignades a cada oficina.

59.- quants venedors estan assignats a cada oficina.

60.- Quants clients diferents són atesos per cada venedor.

61.- Calcula les comandes totals per a cada client de cada venedor,

ordenats per clients i dintre de cada client per venedor.

62.- Quina és la mitjana de les comandes d'aquells venedors tal que les

seves comandes totalitzen més de 3.000 ��

63.- Per a cada oficina, que tingui dos o més persones, calcular la quota

total i les vendes totals per a tots els venedors que treballen a l'oficina.

64.- Mostrar el preu, l'estoc i la quantitat total de comandes per aquells

productes pels quals la quantitat demana sigui superior al 75% de l'estoc.

65.- Llistar les oficines on l'objectiu de vendes de l'oficina excedeix a la

suma de les quotes dels venedors individuals.

66.- Llisteu els venedors tal que les seves quotes siguin iguals o superiors

a l'objectiu de vendes de Logroño.

67.- Llista de tots els clients atesos per En Joan Pera.

68.- Llista tots els productes del fabricant ACM pels quals les existències

superin l'estoc del producte ACM 5425.

69.- Llistar els venedors que treballin en oficines que superin el seu

objectiu.

70.- Llistar tots els venedors que no treballin a les oficines dirigides per

l'Albert Pi.

71.- Llista dels productes pels quals s'ha rebut una comanda de 2.400 ��

més.

72.- Llista dels clients assignats a Montserrat Camps que han de realitzar

cap comanda de més de 2.400 ��

73.- Llista de les oficines on hi hagi un venedor tal que la seva quota

representi més del 55% de l'objectiu de l'oficina.

74.- Llista dels venedors que hagin acceptat una comanda que representi

més del 10% de la seva quota.

75.- Llista de les oficines i els seus objectius on tots els venedors tenen

vendes que superin el 50% de l'objectiu de l'oficina.

76.- Llisteu els noms i les edats dels venedors que treballen en oficines de

la província de Girona.

77.- Llista dels noms i les edats dels venedors que tenen quotes per sobre

la mitjana de quotes.

�� !��

��

78.- Llisteu les oficines tal que les seves vendes estan per sota de la

mitjana dels objectius de les oficines.

79.- Llisteu totes les oficines tal que els seus objectius superin la suma de

les quotes dels venedors que treballen en elles.

80.- Llista dels venedors que tenen més de 40 anys i que dirigeixen a un

venedor que està per sobre de la quota.

81.- Llista dels venedors que tenen més de 40 anys i que dirigeixen a un

venedor que està per sobre de la quota i que no treballi a la mateixa

oficina que el seu director.

82.- Llisteu els venedors tal que la seva mida mitjana de comanda pels

productes fabricats per ACM sigui superior a la mida mitjana de

comanda.

83.- Llista dels venedors tal que la seva mida mitjana de comanda pels

productes fabricats per ACM sigui, al menys, tan gran com la mida de la

comanda mitjana d'aquest venedor.

84.- Afegir com a nou venedor a En Pere Pou, de 25 anys, a l'oficina 21,

venedor junior, i com a cap tindrà al venedor 45.

85.- Crear una nova taula amb la mateixa estructura que comandes i

inserir tots les comandes d'abans del 1/1/1990.

86.- Elimina a En Pere Pou.

87.- Elimina totes les comandes efectuades abans del 1/1/1990.

88.- Esborra totes les comandes.

89.- Esborra totes les comandes acceptades per En Joan Pi.

90.- Suprimeix tots els clients assignats a venedors tal que les seves

vendes siguin inferiors al 80% de la seva quota.

91.- Suprimeix tots els clients que no han realitzat cap comanda des de

1/1/1990.

92.- Elimina tots els venedors contractats abans de l'1/1/1995 que encara

no tinguin assignada quota.

93.- Aixeca el límit de crèdit a Pep SA en un 10% i assigna'l com a

venedor al 46.

94.- Transfereix totes els venedors de l'oficina 34 a l'oficina 21 i rebaixa

les seves quotes en un 10%.

95.- Reassigna tots els clients atesos pels venedors 23, 56, 87 al venedor

43.

96.- Assigna una quota de 9.000 ��

tenen quota.

97.- Eleva totes les quotes en un 5%.

98.- Eleva en 450 �� èdit de qualsevol client que hagin

realitzat una comanda de més de 2.400 ��

99.- Reassigna al venedor 21 tots aquells clients que tinguin assignats

venedors que estiguin per sota del 80% de les seves quotes.

�� ,�

��

100.- Fes que tots els venedors que tinguin assignats més de tres clients

estiguin sota les ordres del venedor 30.

��+�$ Donat un Sistema format per un grup comercial, del ram del tèxtil,

que disposa de diferents botigues, les quals fan comandes a diferents

proveïdors d'articles confeccionats. Les taules resultants del disseny són:

Realitzar en SQL les següents consultes:

1.- Trobar els codis de totes les botigues

2.- Trobar el nom de totes les botigues situades a Barcelona

3.- Codi dels proveïdors que han subministrat a la botiga 22

4.- Codi dels proveïdors que han subministrat a la botiga de codi 4

l'article de codi 100

5.- Nom de les Botigues a les quals ha subministrat el proveïdor 9

CREATE TABLE Proveidor ( Codi CHAR(2) CONSTRAINT PK_Proveidor PRIMARY KEY, Nom VARCHAR2(25) CONSTRAINT NN_ProveidorNom NOT NULL CONSTRAINT UN_ProveidorNom UNIQUE, Ciutat VARCHAR(15) CONSTRAINT NN_ProveidorCiutat NOT NULL)

CREATE TABLE Article ( Codi CHAR(3) CONSTRAINT PK_Articcle PRIMARY KEY, Descripcio VARCHAR2(25) CONSTRAINT NN_ArticleDescripcio NOT NULL, Color VARCHAR2(10) CONSTRAINT NN_ArticleColor NOT NULL, Talla NUMBER(2) CONSTRAINT NN_ArticleTalla NOT NULL CONSTRAINT CH_ArticleTalla CHECK (Talla > 0))

CREATE TABLE Botiga ( Codi CHAR(2) CONSTRAINT PK_Botiga PRIMARY KEY, Nom VARCHAR2(25) CONSTRAINT NN_BotigaNom NOT NULL CONSTRAINT UN_BotigaNom UNIQUE, Ciutat VARCHAR(15) CONSTRAINT NN_BotigaCiutat NOT NULL)

CREATE TABLE Comanda ( Codi CHAR(5) CONSTRAINT PK_Comanda PRIMARY KEY, Article CONSTRAINT NN_ComandaArticle NOT NULL CONSTRAINT FK1_Comanda REFERENCES Article(Codi), Proveidor CONSTRAINT NN_ComandaProveidor NOT NULL CONSTRAINT FK2_Comanda REFERENCES Proveidor(codi), Botiga CONSTRAINT NN_ComandaBotiga NOT NULL CONSTRAINT FK3_Comanda REFERENCES Botiga(Codi), Quantitat NUMBER(3) CONSTRAINT NN_ComandaQuantitat NOT NULL CONSTRAINT CH_ComandaQuantitat CHECK (Quantitat>0))

��-� � �� !��

��

6.- Colors dels articles que ha subministrat el proveïdor de codi 65

7.- Codi dels proveïdors que han subministrat a la botiga de codis 22 i,

també, a la 49

8.- El Codi dels proveïdors que han subministrat articles blaus a la botiga

de codi 7

9.- Codi de tots els articles que han estat subministrats a qualsevol de les

botigues de Mataró

10.- Codi dels proveïdors que han subministrat algun article blau a les

botigues de Barcelona o Mataró

11.- Codi dels proveïdors que han subministrat algun article blau a les

botigues de Barcelona i Mataró

12.- Descripció i color de tots els articles tal que cap d'altre tingui una

talla més petita, per ordre de descripció

13.- Codi dels articles que han estat subministrats per proveïdors tal que a

la seva ciutat hi ha, com a mínim, una botiga

14.- Codi dels articles comprats a sols un proveïdor

15.- Codi dels articles que han estat subministrats a les botigues de

Barcelona per proveïdors de Barcelona

16.- Nom de les Botigues que han estat fornides per, al menys, un

proveïdor de fora de la seva ciutat

17.- Codi de les botigues que han comprat articles blaus sols als

proveïdors de fora de Barcelona

18.- Codi dels proveïdors que han subministrat, com a mínim, un article

subministrat per algun proveïdor que hagi subministrat, al menys, un

article blau

19.- Botigues que han comprat, al menys, un article dels que alguna

botiga ha comprat al proveïdor 49

20.- Parelles de ciutats tal que una botiga de la primera ha comprat a un

proveïdor de la segona

21.- Parelles de ciutats tal que una botiga de la primera ha comprat a un

proveïdor de la segona, sent les dues ciutats diferents

22.- Proveïdors (i article subministrat) que han subministrat, com a poc,

un mateix article a més d'una tercera part de les botigues

23.- Botigues que sols han comprat al Proveïdor 49

24.- Articles que han estat comprats per totes les botigues de Barcelona

25.- Botigues que han comprat, al menys, tots els articles subministrats

pel proveïdor 9

26.- Quin és l'article del qual s'ha venut una quantitat més gran.

27.- Quin ha estat el color dels articles dels quals s'han realitzats més

comandes

��


��

��

En un entorn de Bases de Dades, les diferents aplicacions i usuaris de

l'organització utilitzen un únic conjunt de dades amb el SGBD. Mentre

que, d'una banda, això resol problemes de redundància, inconsistència i

independència entre les dades i els programes; per altra banda, fa que la

seguretat esdevingui un dels problemes més importants en aquests en-

torns.

Per aconseguir seguretat en un entorn de Base de Dades és neces-

sari identificar les amenaces i estriar les polítiques (que s'espera del

sistema de seguretat) i els mecanismes (com farà el sistema de se-

guretat per assolir els objectius).

Una amenaça es pot definir con un agent hostil que, de forma casual o

utilitzant una tècnica especialitzada, pot revelar o modificar la informació

gestionada pel sistema. Les violacions de la base de Dades consisteix en

lectures, modificacions o esborrats incorrecte de les dades. els esdeveni-

ments que violen la Base de Dades són nomenats amenaces; les conse-

qüències de les violacions es poden agrupar en tres categories:

• Alliberament incorrecte de la informació causat per la lectura de dades

degut a un accés intencionat o accidental per usuaris impropis; dintre

d'aquesta categoria s'inclouen les violacions del secret derivades de les

deduccions d'informació secreta a partir de lectures d'informació auto-

ritzada.

• Modificació impròpia de les dades, que correspon a totes les violaci-

ons de la integritat de les dades realitzades per tractaments o modifi-

cacions fraudulentes de les dades; aquestes modificacions no necessà-

riament involucren lectures no autoritzades, ja que les dades poden ser

falsificades sense ser llegides.

• Denegació de serveis, que correspon a aquelles accions que pugui im-

pedir als usuaris accedir a les dades o utilitzar recursos.

��


��

��

��

�!��

��

��

Esmena no autorit-

zada de les dades

Interceptar la línia Interceptar la línia Interferència electrò-

nica i radiació

Interferència elec-

trònica i radiació

Interceptar la línia Entrada il·legal d'un

hacker

Utilització d'identi-

ficadors i contra-

senyes d'altre per-

sona

Corrupció de dades

degut a la manca d'e-

nergia elèctrica

Incendi

Alteració de pro-

grames

Utilització d'identifi-

cadors i contrasenyes

d'altre persona

Xantatge Foc elèctric o tensió

no adequada

Atac amb bombes

Entrada il·legal d'un

hacker

Xantatge Fallades de softwa-

re donant un accés

superior a l'autorit-

zat

Ensinistrament inade-

quat del personal

Foc elèctric o tensió

no adequada

Utilització d'identi-

ficadors i contrase-

nyes d'altre persona

Procediments inade-

quats que barregen la

informació confiden-

cial amb la normal

Ensinistrament in-

adequat del perso-

nal

Danys físics dels e-

quips

Inundació

Xantatge Fallades de software

donant un accés supe-

rior a l'autoritzat

Visió no autoritza-

da de les dades i

revelar-les

Trencada o desconne-

xió de cables

Caiguda d'aeronaus

Intent de realitzar

frau

Insuficiència de per-

sonal o vaga

Introducció de virus Fallades del hardwa-

re i caigudes del disc

desenvolupar pro-

grames que es saltin

els mecanismes de

seguretat

Ensinistrament inade-

quat del personal

Danys físics dels e-

quips

Accés utilitzant pri-

vilegis no autorit-

zats

Visió no autoritzada

de les dades i revelar-

les

Trencada o descon-

nexió de cables

Robatori Introducció de virus

Fallades de softwa-

re donant un accés

superior a l'autorit-

zat

Insuficiència de

personal o vaga

Ensinistrament ina-

dequat del personal

��

Les amenaces a la seguretat poden ser classificades d’acord amb la forma

en que poden ocórrer: a) amenaces no fraudulentes, accidentals; b) ame-

naces fraudulentes, accidentals.

��


Les amenaces no fraudulentes són accidents casuals, entre ells es poden

distingir:

• Desastres accidentals o naturals, tal com terratrèmols, inundaci-

ons o foc; aquests accidents danyen el hardware del sistema .

• Errors en el hardware o el software, els qual poden conduir a

accessos no autoritzats.

• Errors humans, causats de forma no intencionada, al introduir

dades o utilitzar aplicacions.

Les violacions intencionades o fraudulentes són causades per dos tipus

diferents d'usuaris:

• Usuaris autoritzats, que abusen dels seus privilegis o autoritat.

• Agents hostils, usuaris impropis (interns o externs) que execu-

ten accions de vandalisme sobre el software i/o hardware del

sistema, o lectures o escriptures de dades; en ambdós casos els

usos legals de les dades i les aplicacions poden emmascarar el

propòsit fraudulent real.

La figura 7.1 representa un resum de les diferents amenaces que pot re-

bre un sistema d'Informació classificades segons el resultat i els danys

que pot provocar en el sistema.

��"��

Els Sistemes d'Informació i les dades que emmagatzemen i processen són

recursos molt valuosos que cal protegir. Una de les primeres passes cap la

seguretat en un Sistema d'Informació és la capacitat de verificar la identi-

tat del seus usuaris, aquest procés es nomenat identificació (veure qui és)

i autenticació (comprovar que és qui diu que és).

La identitat ha de ser única per tal que el sistema la pugui diferenciar en-

tre els diferents usuaris. Depenent dels requeriments operacionals, una i-

dentitat pot descriure a un individu, més d'un individu, o a un o més indi-

vidus sols una part del temps.

L'autenticació és el procés d'associar a un individu amb la seva identitat

única, és a dir, la forma en que un individu estableix la validesa de la seva

pretesa identitat. Hi han tres recursos d'identificació bàsics per tal de po-

der demostrar qui és realment un:

La identificació implica la forma en que un usuari pro-porciona la seva identitat úni-ca al sistema, aquesta identi-tat pot ser un nom o un nom-bre.

��"� � ��


• Quelcom que una persona �� #, una contrasenya, un número d'i-

dentificació persona.

• Quelcom que un persona� ��#, una tarja, una clau.

• Quelcom que una persona $�, l'empremta dactilar, la veu..

Una diferencia important entre la identificació i la autenticació és que les

identitats són públiques mentre que la informació d'autenticació es guarda

en secret i això proporciona el recurs pel qual una persona prova que és

realment qui diu que és.

La seguretat d'un esquema de contrasenyes és depenent de la capacitat de

mantenir les contrasenyes secretes; una contrasenya s'ha d'estriar de for-

ma que sigui fàcil de recordar i difícil d'endevinar. Alguns criteris per a

la selecció de la contrasenya més adequada són:

• Seleccionar contrasenyes llargues: 8 caràcters és una mida adequada.

• Combinar diferents tipus de caràcters: majúscules, minúscules, nom-

bres, espais en blanc i caràcters de puntuació.

• No utilitzar paraules amb significat.

• Utilitzar contrasenyes diferents per accedir a sistemes diferents.

• Canviar la contrasenya de forma periòdica: mínim una vegada al mes.

• No escriure la contrasenya en llocs a on un altre pugui accedir.

• Canviar la contrasenya la primera vegada que iniciï una sessió.

Una major seguretat les donen les targes, aquestes poden ser simples tros-

sos de plàstic amb una banda magnètica o, fins i tot, incorporar xips, com

fan les targes intel·ligents. Amb totes elles cal recordar una contrasenya

personal que ha de coincidir amb la que està escrita amb la tarja, o aques-

ta més alguna informació que té la tarja ha de coincidir amb la que té

l'ordinador.

En sistemes d'alta seguretat és usual la utilització de sistemes externs

(màquines diferents a la que ens volen connectar) com serveis d'autenti-

cació, el més conegut és Kerberos, el qual utilitzant diferents tècniques

d'encriptació i emissió de certificats (tickets) dona una seguretat més que

adequada per la majoria de Sistemes.

Els sistemes biomètrics són mètodes automatitzats de reconeixement d'u-

na persona basant-se en una característica fisiològica o de comportament.

Alguns exemples de trets humans utilitzats en el reconeixement biomètric

inclouen empremtes dactilars, veu, cara, retina, iris, signatura escrita, ge-

ometria de la mà i les venes del canell. El sistema biomètric pot ser utilit-

Aquest mètodes bàsics poden ser empleats individualment, o combinant-los per tal de poder obtenir un nivell de se-guretat més alt.

�� %�


zar com a mètode d'identificació, on el sistema biomètric identifica a una

persona dintre una població sencera registrada, cercant a una Base de Da-

des per tal de trobar la coincidència. El sistema també pot ser utilitzat en

mode de verificació, on el sistema biomètric autentica la identitat recla-

mada d'una persona amb el seu patró prèviament enregistrat.

Per validar un usuari es poden utilitzar quatre mètodes: a) autenticació pel

SGBD; b) autenticació pel Sistema Operatiu; c) autenticació pel servei de

xarxa; d) autenticació per una capa intermitja (en un sistema multicapa).

En tots els casos sempre es pot (si així s'indica a la configuració) fer la

transmissió del login/password encriptada. �

��%�&� ��$�� '��(��

El control d'accés discrecional utilitza la restricció d'accés a objectes ba-

sant-se en la identitat dels usuaris o grups als qual pertanyen. El control

discrecional és el tipus de mecanisme de control més comú que s'imple-

menta en els Sistemes d'informació actuals.

Les sentències d'autorització que el DBA utilitzarà tenen la sintaxi

Els privilegis, més importants, sobre el sistema que es poden autoritzar

són:

ADMINISTER DATABASE TRIGGER ALTER ANY CLUSTER ALTER ANY DIMENSION ALTER ANY INDEX ALTER ANY PROCEDURE ALTER ANY ROLE ALTER ANY SEQUENCE ALTER ANY SNAPSHOP ALTER ANY TABLE ALTER ANY TRIGGER ALTER ANY TYPE ALTER DATABASE ALTER PROFILE ALTER RESOURCE COST ALTER ROLLBACK SEGMENT ALTER SESSION ALTER SYSTEM ALTER TABLESPACE ALTER USER ANALIZE ANY AUDIT ANY AUDIT SYSTEM BACKUP ANY TABLE BECOME USER

COMMENT ANY TABLE CREATE ANY CONTEXT CREATE ANY CLUSTER CREATE ANY DIMENSION CREATE ANY DIRECTORY CREATE ANY INDEX CREATE ANY INDEXTYPE CREATE ANY LIBRARY CREATE ANY MATERIALIZED VIEW CREATE ANY OUTLINE CREATE ANY PROCEDURE CREATE ANY ROLE CREATE ANY SEQUENCE CREATE ANY SNAPSHOT CREATE ANY SYNONYM CREATE ANY TABLE CREATE ANY TRIGGER CREATE ANY TYPE CREATE ANY VIEW CREATE CLUSTER CREATE DATABASE LINK CREATE DIMENSION CREATE INDE CREATE INDEXTYPE

CREATE LIBRARY CREATE MATERIALIZED VIEW CREATE OUTLINE CREATE PROCEDURE CREATE PROFILE CREATE PUBLIC DATABASE LINK CREATE PUBLIC SYNONYM CREATE ROLE CREATE ROLLBACK SEGMENT CREATE SEQUENCE CREATE SESSION CREATE SNAPSHOT CREATE SYNONYM CREATE TABLE CREATE TABLESPACE CREATE TRIGGER CREATE TYPE CREATE USER CREATE VIEW DELETE ANY TABLE DROP ANY CONTEXT DELETE ANY CLUSTER DROP ANY DIMENSION DROP ANY DIRECTORY

A una base de Dades sempre ha d’existir un usuari (o grup d’usuaris) que l’administri, aquest usuari es nomena Data Base Administrator (DBA) i serà l’encarregat de crear i donar autoritzacions als dife-rents usuaris de la Base de Dades.

�� !��"��#�

��)� � ��


DROP ANY INDEX DROP ANY LIBRARY DROP ANY MATERIALIZED VIEW DROP ANY OUTLINE DROP ANY PROCEDURE DROP ANY ROLE DROP ANY SEQUENCE DROP ANY SNAPSHOT DROP ANY SYNONYM DROP ANY TABLE DROP ANY TRIGGER DROP ANY TYPE DROP ANY VIEW DROP LIBRARY

DROP PROFILE DROP PUBLIC DATABASE LINK DROP PUBLIC SYNONYM DROP ROLLBACK SEGMENT DROP TABLESPACE DROP USER EXECUTE ANY INDEXTYPE EXECUTE ANY PROCEDURE EXECUTE ANY TRANSACTION EXECUTE ANY TYPE FORCE ANY TRANSACTION FORCE TRANSACTION GLOBAL QUERY REWIRTE GRANT ANY PRIVILEGE

GRANT ANY ROLE INSERT ANY TABLE LOCK ANY TABLE MANAGE TABLESPACE QUERY REWRITE RESTRICTED SESSION SELECT ANY SEQUENCE SELECT ANY TABLE SYSDBA SYSOPER UNLIMITED TABLESPACE UPDATE ANY TABLE

L'opció �� !�� permet transmetre els privilegis que es té

a un altre. Si el que es vol és treure un privilegi es farà

La clàusula PUBLIC es refereix a la totalitat dels usuaris. Donada la gran

complexitat de privilegis que es poden donar sobre el Sistema, el més u-

sual és crear un rol i després assignar a aquest rol un conjunt de privile-

gis. la sintaxi és

La identificació és necessària per habilitar el rol amb la sentència

Normalment el sistema ja ve amb una sèrie de rols predefinits, els més

usuals són

• &*++,&-, connectar-se a la Base de Dades

• �,�*.�&,, crear objectes a la Base de Dades

• ('/, administrador de la Base de Dades

Un rol pot ser destruït o modificat les seves identificacions amb les sen-

tències

�$%�&$�� '��(��

��$��$��$��)$��'�$)��)$��'�$)�� *�+��$,�$��*��*��

��$��$�� )$��'�$)��*�+��#� �� $,�$��#��$��

)��$��

��$��$��)$��'�$)��)$��'�$)�� *�+��$,�$��*��*��

"�� #��$� ��#�� 0�

�� %�&''&� � ��(��) *��+��!��,� ��-��

Per crear un usuari es fa servir la sentència

També es possible canviar les característiques d'un usuari

o esborrar l'usuari

D'aquesta forma el procediment per crear un usuari serà

a partir d’aquest moment l’usuari podrà connectar amb el sistema, crear

taules, procediments i triggers,... però sols podrà consultar i utilitzar els

seus propis objectes; en el cas de que es vulgui que pugui utilitzar altres

objectes caldrà autoritzar-li de forma específica, l'usuari també podrà uti-

litzar realitzar autoritzacions sobre els seus propis objectes, això es fa

amb al sentència.

� ��$��$��$��)$��'�$)��)$��'�$)�� *�+��$,�$��*��*��-�� .� -�� !��)�$,��$�� &��&��

��$��$��)$��'�$)��)$��'�$)�� *�+��$,�$��*��*��-�� .� -�� !��)�$,��$�� &��&��

)��$��

CREATE ROLE Estudiant IDENTIFIED BY clau1; GRANT ALTER SESSION, CREATE CLUSTER, CREATE PROCEDURE, CREATE SEQUENCE, CREATE SESSION, CREATE SYNONYM, CREATE TABLE, CREATE TRIGGER, CREATE TYPE, CREATE VIEW TO Estudiant; CREATE USER Pepito IDENTIFIED BY clau2; GRANT Estudiant TO Pepito;

� �� /0 +� �� %��$�$�#�� +��- ��#�� 1�#��/0 +� �� !��"��

��

�� %�&''&� � (��) *��+��!��,� ��-��

El diferents privilegis que es poden adquirir sobre cada mena d’objectes

venen representats a la taula següent

PRIVILEGIS -�� 1�� 23� ��

ALTER X X

DELETE X X

INDEX X

INSERT X X

REFERENCES X

SELECT X X X

UPDATE X X

quan s’inclou l’opció WITH GRANT OPTION, a l’usuari autoritzat li se-

rà possible transmetre el seus permisos a altres usuaris.

Per restringir privilegis a usuaris es fa servir

Amb .��.��(�. �� destrueix les restriccions d'integritat re-

ferencial que l'usuari autoritzat hagi construït sobre l'objecte. Amb

� �.( desfà totes les autoritzacions que l'usuari tingui sobre procedi-

ments associat a l'objecte.

Si es vol donar privilegis a un usuari

��)��4��4��5��

La Legislació espanyola recull una sèrie de drets i deure relatius a la uti-

lització de les dades personal dintre de l'àmbit dels Sistemes d'Informa-

ció, les principals fonts de drets són: la llei orgànica 5/1992, del 29 d'oc-

tubre, de regulació del tractament automatitzat de les dades de caire per-

sonal (LORTAD) i el real decret 1332/1994 del 30 de juny, que desenvo-

lupa la llei anterior, aquesta llei ha estat derogada per la llei orgànica

15/199, de 13 de desembre, de Protecció de Dades de Caràcter Persona..

�$%�&$�� /0 +� �� %��$�$�#�� 1�#��/0 +� �� )$��#� '��$#�

GRANT SELECT, UPDATE ON Santi.Taula1 TO Pepito

"�� #��$� ��#��

�� %�&''&� � ��(��) *��+��!��,� ��-��

Aquestes lleis s’han fet en compliment del mandat constitucional

contingut a l'article 18.4 on diu que "la llei limitarà l'ús de la in-

formàtica per garantir l'honor i la intimitat personal i familiar dels

ciutadans i el ple exercici dels seus drets".

Les normatives actuals també segueixen la directiva 95/46 de 24 d'octu-

bre, del Parlament europeu relativa a la protecció de les persones físiques

en tot allò que respecta al tractament de dades personals i a la lliure dis-

tribució d'aquestes dades.

A continuació es passen a descriure els principis generals de la protecció

de les de dades:

• 6��: Les dades de caràcter personal només podran ser

recollides pel seu tractament, així com sotmeses a aquest tractament,

quan sigui adequat, pertinent y no excessiu en relació amb l'àmbit i

las finalitats per les quals s’hagin obtingut. Cal destacar que les dades

de caràcter personal objectes del tractament no podran ser utilitzades

per finalitats incompatibles amb aquelles per les que les mateixes

haurien sigut recollides.

• (��7� �� : Els interessats als quals

se'ls sol·licitin les dades personals tindran que ser prèviament infor-

mats: a) de la existència d’un fitxer o tractament de dades de caràcter

personal; b) el caràcter obligatori o facultatiu la resposta donada a les

preguntes que li siguin plantejades; c) de las conseqüències de

l’obtenció de les dades o la negativa a subministrar-les; d) de la pos-

sibilitat de exercitar els drets d'accés, rectificació, cancel·lació i opo-

sició; e) e la identitat i direcció del responsable del tractament o se-

gons del cas, del seu representant.

• &� �� : A no ser que la llei disposi d’una altre co-

sa, per el tractament de les dades de caràcter personal, es requeriran

el consentiment inequívoc dels afectats.

• (�� : D’acord amb el article 16.2 de la

Constitució, ningú pot estar obligat a declarar sobre la seva ideologia,

religió o creences. En relació al mateix, la Llei que estudiem esta-

bleix que, només amb el consentiment, exprés i per escrit, del afectat

podrà ser objecte de tractament de les dades de caràcter personal que

revelin la ideologia, afiliació sindical, religió i creences, per una altre

��8� � ��

�� %�&''&� � (��) *��+��!��,� ��-��

banda, cal destacar que només en el cas d’interès general, quan així

ho disposi la llei o el afectat ho consisteixi expressament, les dades

de caràcter personal que facin referència al origen racial, a la salut i a

la vida sexual només podran ser rebuscats, tractats i cedits. Final-

ment, afegir que les dades de caràcter personal relatives a la comissió

d’infraccions penals o administratives, podran ser incloses en fitxers

de las Administracions públiques competents en els supòsits previstos

en las respectives normes reguladores.

• (��!��: Les institucions i els centres sanitaris pú-

blics i privats i els professionals corresponents podran procedir al

tractament de les dades de caràcter personal relatives a la salut de les

persones sempre i quan siguin facilitats pel titular per motiu

d’assistència sanitària.

• ��: Tan el responsable del fitxer

com, en el seu cas, el encarregat del tractament tindran que adoptar

les mesures tècniques i organitzatives necessàries que garanteixin la

seguretat de les dades de caràcter personal i evitin la seva alteració,

pèrdua, tractament o accés no autoritzat. Estan obligats al secret pro-

fessional respecte de les dades de caràcter personal i al deure de

guardar-les, el responsable del fitxer i els que intervinguin en qualse-

vol fase del tractament dels mateixos.

• &�� : Les dades de caràcter personal objecte de

tractament només podran ser comunicades a un tercer, amb l’anterior

consentiment del interessat, per el compliment de finalitats directa-

ment relacionades amb les funcions llegítimes del cedent i del cessio-

nari. Aquest consentiment no serà necessari: a) quan la cessió està au-

toritzada en una llei; b) quan es tracti de dades recollides de fonts ac-

cessibles al públic; c) quan el tractament respongui a la lliure i llegí-

tima acceptació d’una relació jurídica en el que el seu desenvolupa-

ment, compliment i control impliqui necessàriament la connexió

d’aquest tractament amb fitxers de tercers; d) quan la comunicació

que s'efectuï tingui per destinatari al Defensor del poble, el Ministeri

Fiscal o els Tribunals o el Tribunal de comptes, en el exercici de les

funcions que tenen atribuïdes; e) quan la cessió es produeixi entre

Administracions públiques i tinguin per objecte el tractament posteri-

or de les dades amb finalitats històriques, estadístiques o científiques;

f) quan la cessió de dades de caràcter personal relatives a la salut si-

guin necessàries per a solucionar una urgència.

"�� #��$� ��#��

�� %�&''&� � ��(��) *��+��!��,� ��-��

• /��$�� : La realització de tracta-

ments per terceres persones tindrà que estar regulada en un contracte

per escrit o en alguna altre forma que permeti acreditar la seva cele-

bració i contingut. No es considerarà comunicació de dades el accés

d’un tercer a aquestes dades quan el accés sigui necessari per la pres-

tació d’un servei al responsable del tractament.

Les persones tenen els següents drets:

• �� !�� : Els ciutadans tenen dret a no veuràs

sotmesos a una decisió, amb efectes jurídics que es fonamentin úni-

cament en un tractament de dades destinades a avaluar determinats

aspectes de la seva personalitat. Cal destacar que el afectat podrà im-

pugnar els actes administratius o decisions privades que impliquin

una valoració del seu comportament.

• (�� 9� �� (��: El

Registre General serà de consulta pública i gratuïta.

• (��$�: El interessat tindrà dret a sol·licitar i obtenir gratuïta-

ment informació de les seves dades de caràcter personal sotmeses a

tractament, l'origen d’aquestes i les comunicacions realitzades o que

es previnguin fer de les mateixes.

• (�� :��; Les dades de caràcter personal en

el qual el seu tractament no s’ajusti a la Llei que tractem i, en particu-

lar, quan aquestes dades resultin inexactes o incompletes, seran recti-

ficades o cancel·lades. Es el responsable del tractament el que té la

obligació de fer efectiu el dret de rectificació o cancel·lació el interes-

sat. Els procediment per exercitar el dret d’oposició , accés, rectifica-

ció o cancel·lació, seran establerts reglamentàriament.

• -��; Les actuacions contraries a la present Llei poden

ser objectes de reclamació per els interessats davant de la Agencia de

Protecció de Dades.

• (�� <��: Si el responsable o el encarregat del trac-

tament incompleixen la Llei i, com a conseqüència de

l’incompliment, els interessats tinguin algun perjudici o lesió en els

seus bens o drets, aquests tindran dret a ser indemnitzats.

Es podran crear fitxers de titularitat privada que continguin dades de ca-

ràcter personal quan resulti necessari per l’aconseguiment de l’activitat u

�8��

�� %�&''&� � (��) *��+��!��,� ��-��

objecte legítim de la persona, empresa o entitat titular i es respectin les

garanties establertes per la Llei de protecció de les persones. S'han de te-

nir en compte els següents fets:

• Sempre que es procedeixi a la creació de fitxers de dades de caràcter

personal es tindrà que notificar prèviament a la Agencia de Protecció

de Dades.

• El responsable del fitxer, en el moment en que s'efectuï la primera

cessió de dades, tindrà que informar d'allò als afectats, indicant la fi-

nalitat del fitxer, la naturalesa de les dades que han sigut cedides i el

nom i adreça del cessionari.

• Les dades personals que figurin en el cens promocional tindran que

ser únicament aquelles que siguin estrictament necessàries per a

complir la finalitat a la qual es destini cada llistat.

• Els interessats tindran dret a que la entitat responsable del manteni-

ment dels llistats dels col·legis professionals, indiqui gratuïtament

que les seves dades personals no poden utilitzar-se per a finalitats de

publicitat o prospecció comercial. Els interessats tindran dret a exigir

gratuïtament l’exclusió de la totalitat de les seves dades personals que

consti en el cens promocional per les entitats encarregades del man-

teniment d’aquestes fonts.

• Els que es dediquin a la prestació de serveis d’informació sobre la sol-

vència patrimonial i el crèdit només podran tractar dades de caràcter

personal obtinguts dels registres i las fonts accessibles al públic esta-

blertes al efecte o procedents d’informacions facilitades pel interessat

o amb el seu consentiment.

• Podran tractar-se també dades de caràcter personal relatives al com-

pliment o incompliment d’obligacions dineràries facilitades per cre-

ditors o per qui actuï pel seu compte o interès.

• Aquells que es dediquin a la recopilació d’adreces, repartiment de do-

cuments, publicitat, venta a distància, prospecció comercial i altres

activitats anàlogues, podran utilitzar els nom i direccions i altres da-

des de caràcter personal quan els mateixos figurin en fonts accessi-

bles al públic a quan hagin sigut facilitats pels propis interessats u ob-

tinguts amb el seu consentiment.

"�� #��$� ��#�� 8��

�� %�&''&� � ��(��) *��+��!��,� ��-��

• Podran sol·licitar una copia del cens promocional, format amb les da-

des de nom, cognoms i domicili que consten en el cens electoral, a-

quells que vulguin realitzar permanentment o esporàdicament la acti-

vitat de recopilació d’adreces, repartiment de documents, publicitat,

venta a distància, prospecció comercial i altres activitats anàlogues.

En la present llei es contemplen diferent tipus d'infraccions i sancions.

Els responsables dels fitxers i els encarregats dels tractaments estaran

subjectes al règim sancionador establert a la present Llei. Les infraccions

es qualificaran com lleus, greus i molt greus.

• �� : a) no atendre, per motius formals, la sol·licitud

de l’interessat de rectificació o cancel·lació de les dades personals ob-

jecte de tractament; b) no proporcionar a la informació que sol·licita

la “Agencia de Protección de Datos” en el exercici de les competèn-

cies que tenen legalment atribuïdes, en relació amb aspectes no subs-

tantius de la protecció de dades; c) no sol·licitar la inscripció del fit-

xer de dades de caràcter personal en el “Registro General de Protec-

ción de Datos”, quan no sigui constitutiu de infracció greu; d) proce-

dir a la recollida de dades de caràcter personal dels propis afectats

sense proporcionar-lis la informació exigida; e) incomplir el deure de

secret.

• �� ; a) procedir a la creació de fitxers de titularitat

pública o iniciar la recollida de dades de caràcter personal per els ma-

teixos, sense autorització de disposició general publicada en el “Bole-

tín Oficial del Estado” o diari oficial corresponent; b) procedir a la

creació de fitxers de titularitat privada o iniciar la recollida de dades

de caràcter personal per els mateixos amb finalitats distintes de les

que constitueixen l’objecte legítim de l’empresa o entitat; c) procedir

a la recollida de dades de caràcter personal sense cercar el consenti-

ment exprés de les persones afectades, en els casos en que aquest si-

gui exigible; d) tractar les dades de caràcter personal o usuaris poste-

riorment amb conculcació dels principis i garanties establerts en la

present Llei o amb el incompliment dels preceptes de protecció que

imposin les disposicions reglamentàries de desenvolupament, quan

no constitueixi infracció molt greu; e) el impediment o la obstaculit-

zació de l’exercici del drets d’accés i oposició i la negativa de facili-

tar la informació que sigui sol·licitada; f) mantenir dades de caràcter

personal inexactes o no efectuar las rectificacions o cancel·lacions

dels mateixos que legalment procedeixen quan resultin afectats els

drets de les persones; g) Vulneració del deure de guardar secret sobre

les dades de caràcter personal incorporats a fitxers que continguin

�8"� � ��

�� %�&''&� � (��) *��+��!��,� ��-��

dades relatives a la comissió d’infraccions administratives i penals,

“Hacienda Pública”, serveis financers, prestació de serveis de solvèn-

cia patrimonial i crèdit, així com aquells altres fitxers que continguin

un conjunt de dades de caràcter personal suficients per a obtenir una

avaluació de la personalitat de l’individu; h) mantenir els fitxers, lo-

cals, programes i equips que continguin dades de caràcter personal

sense les degudes condicions de seguretat; i) no remetre a la “Agen-

cia de Protección de Datos” les notificacions previstes en aquesta Llei

o en llurs disposicions de desenvolupament, així com no proporcionar

termini a la mateixa quants documents i informacions ha de rebre o

siguin requerits per això a tal efecte; j) la obstrucció a l’exercici de la

funció inspectora; k) no inscriure el fitxer de dades de caràcter perso-

nal en el “Registro General de Protección de Datos”, quan hagi sigut

requerit per això per el “Director de la Agencia de Protección de Da-

tos”; l) incomplir el deure de la informació.

• �� : a) la recollida de dades de forma enga-

nyosa i fraudulenta; b) la comunicació o cessió de les dades de caràc-

ter personal, fóra dels casos en que siguin permeses; c) cercar i tractar

les dades de caràcter personal que revelen la ideologia, afiliació sin-

dical, religió i creences quan no hi hagi el consentiment exprés de

l’afectat; cercar i tractar les dades de caràcter personal que facin refe-

rència a l’origen racial, a la salut i a la vida sexual quan no el disposi

una llei o l’afectat no hagi consentit expressament, o violentar la pro-

hibició referida a la creació de fitxers amb la finalitat exclusiva d'en-

registrar dades de caràcter personal que revelin la ideologia, afiliació

sindical, religió, creences, origen racial o ètnic, o vida sexual; d) no

cessar en el ús il·legítim dels tractaments de dades de caràcter perso-

nal quan sigui requerit per això per el “Director de la Agencia de Pro-

tección de Datos” o per les persones titulars del dret d’accés; e) la

transferència temporal o definitiva de dades de caràcter personal que

hagin sigut objecte de tractament o hagin sigut recollits per sotme-

tre'ls a aquest tractament, amb destí a països que no proporcionen un

nivell de protecció equiparable sense autorització de caràcter personal

de forma il·legítima o amb menyspreu dels principis i garanties que

els siguin d’aplicació, quan amb això s’eviti o s’atempti contra

l’exercici dels drets fonamentals; f) la vulneració del deure de guar-

dar secret sobre les dades de caràcter personal que revelin la ideolo-

gia, afiliació sindical, religió i creences; així com dades que facin re-

ferència a l’origen racial, a la salut i a la vida sexual; g) no atendre, o

obstaculitzar de forma sistemàtica l’exercici dels drets d’accés, recti-

ficació, cancel·lació o oposició; h) no atendre de forma sistemàtica el

"�� #��$� ��#�� 8%�

�� %�&''&� � ��(��) *��+��!��,� ��-��

deure legal e notificació de la inclusió de dades de caràcter personal

en un fitxer.

Les infraccions lleus seran sancionades amb multes de 100.000 a 10 mili-

ons de pessetes. Les infraccions greus seran sancionades amb multes de

10 milions a 50 milions de pessetes. Les infraccions molt greus seran

sancionades amb multes de 50 milions a 100 milions de pessetes.

Segons el Real Decret 994/1.999 s’estableixen tres nivells de seguretat, el

bàsic, l’entremig i l’alt. La aplicació d’un i l’altre dependrà de la natura-

lesa de la informació que emmagatzemin. Per l’aplicació de les mesures

de seguretat dels fitxers amb dades de caràcter personal s’ha d’observar:

a) tots els fitxers que continguin dades de caràcter personal han de seguir

les mesures de seguretat del nivell bàsic; b) els fitxers que continguin da-

des relatives a la comissió de infracció penals i/o administratives, Hisen-

da Pública i serveis financers hauran de seguir les mesures del nivell

d’entremig; c) els fitxers amb informació relativa a la prestació de serveis

d’informació sobre la solvència patrimonial i crèdit, els fitxers relatius al

compliment o incompliment de les obligacions monetàries, hauran

d’observar les mesures del nivell d’entremig; d) seguiran unes mesures

del nivell alt, aquells fitxer amb continguts de dades relacionades amb la

ideologia, religió, creences, d’origen racial, salut o vida sexual; e) quant

el fitxer contingui dades que permetin obtenir una avaluació de la perso-

nalitat de la persona afectada s’hauran de contemplar les mesures del ni-

vell mitjà relatives amb l’auditoria, identificació i autentificació, control

d’accés físic i gestió de suports; f) les mesures de seguretat per accedir a

les dades de caràcter personal a través de la xarxa informàtica i de tele-

comunicacions hauran de seguir mesures equivalent al corresponent ac-

cés en mode local; g) els tractaments de dades de les dades de caràcter

personal fora dels locals de la ubicació del fitxer hauria d’estar expressa-

ment autoritzada per el responsable del fitxer y no eximir el compliment

dels nivells de seguretat aplicables; h) els nivells de seguretat exigibles

als fitxers temporals són els mateixos que els que s’han descrit anterior-

ment, i a més a més han de ser eliminats una vegada s’acabi el motiu de

la seva creació.

,�� !��5��etat inclourà el següents apartats:

• (�� : L’ha d’elaborar e implementar el responsa-

ble del fitxer. Serà d’obligat compliment per tot el personal amb ac-

cés a les dades de caràcter personal i/o als sistemes d’informació ( per

sistemes d’informació s’entén conjunt de fitxers automatitzats, pro-

grames, suports i equips utilitzats per l’emmagatzematge i tractament

�8)� � ��

�� %�&''&� � (��) *��+��!��,� ��-��

de dades de caràcter personal). Contingut mínim del Document de

Seguretat: a) àmbit d’aplicació del document amb especificació deta-

llada dels recursos protegits; b) mesures, normes, procediments, re-

gles i estàndards encaminats a garantir a garantir el nivell de segure-

tat exigit pel Real Decret 994/1.999; c) funcions i obligacions del

personal; d) estructura dels fitxers que continguin dades de caràcter

personal i descripció dels sistemes d’informació que les tracten (a-

questa obligació no eximeix en cap moment del registre dels fitxers

davant de l’Agència de Protecció de Dades); e) procediment de noti-

ficació, gestió i resposta de les incidències (tant tecnològiques com

funcionals i d’accés); f) procediments de realització de còpies de re-

colzament i de recuperació de dades. g) periodicitat amb la que s’han

de substituir les contrasenyes dels usuaris ( si aquest es el mètode

d’autentificació utilitzat); h) personal autoritzat per concedir, modi-

ficar i/o alterar els accessos autoritzats a les dades i/o recursos, així

com els criteris per realitzar aquestes accions. i) personal autoritzat

per accedir al lloc on s’emmagatzemen dades de caràcter personal. El

document s’haurà de mantenir sempre actualitzat i s’haurà de revisar

sempre i quan es produeixi canvis rellevants en el sistema

d’informació o en l’organització del mateix. El document s’haurà

d’adequar sempre a la normativa vigent en matèria de protecció de

dades de caràcter personal.

• = �� : Les funcions i obligacions del

personal han de quedar clarament recollides en el Document de Segu-

retat. El responsable del fitxer ha d’adoptar totes les mesures necessà-

ries perquè el personal conegui les mesures de seguretat que afecten

al desenvolupament de les seves funcions, així con les conseqüències

del incompliment de les mateixes.

• �� 7� �� ;� el procediment de notificació i gestió

d’incidències ha de incloure un registre en el que hi faci constar com

a mínim: a) tipus d’incidència; b) moment en el que s’ha produït la

incidència; c) persona que realitza la notificació; d) persona a qui es

notifica la incidència; e) efectes derivats de la mateixa.

• �� : El responsable del fitxer s’ha

d’encarregar que existeixi una llista actualitzada de les persones que

tenen accés al sistema d’informació i d’establir un sistema

d’identificació i autentificació de dites persones, així com l’accés au-

toritzat a cadascun d’ells. Quan el sistema d’accés a la informació es

basi en contrasenyes existirà un procediment d’assignació, distribució

i emmagatzematge que garanteixi la seva confidencialitat e integritat.

"�� #��$� ��#�� 80�

�� %�&''&� � ��(��) *��+��!��,� ��-��

Les contrasenyes es guardaran de forma inintel·ligible mentre esti-

guin vigents i s’hauran de substituir amb la periodicitat que determini

el Document de Seguretat.

• &� ��7��$�: Els usuaris únicament tindran accés a aquelles dades

i/o recursos que precisin per el desenvolupament de les seves funci-

ons. (El RC defineix “Recursos” com qualsevol part component d’un

sistema de informació. El responsable del fitxer ha d’establir el me-

canisme necessari per garantir que el usuaris no accedeixin al fitxer

amb drets diferents al autoritzat. Únicament podran accedir, modifi-

car o anul·lar l’accés autoritzat a dades i recursos el personal legiti-

mat per el Document de Seguretat i conforme als criteris que en ell

estan determinats.

• 9�� ; Els suports informàtics que continguin dades de ca-

ràcter personal hauran de permetre identificar el tipus d’informació

emmagatzemada, ser inventariada i emmagatzemar-les en lloc amb

accés restringit al personal autoritzat en el Document de Seguretat. El

responsable del fitxer és la única persona que podrà autoritzar la sor-

tida fora dels locals on estigui ubicat el fitxer.

• &> �� <�� ; El responsable del fitxer

s’encarregarà de verificar la definició i la correcta aplicació dels pro-

cediments de realització de còpies de recolzament i de recuperació de

dades. Els procediments de realització de còpies de recolzament i de

recuperació de dades ha de garantir en tot moment la reconstrucció de

la informació en el estat en que es trobava en el moment de produir-

se la pèrdua o la destrucció. Hauran de realitzar-se còpies de recol-

zament, al menys setmanalment , a no ser que en aquest període no

s’hagués produït cap actualització de les dades.

Les �� !��?5 inclouen les del nivell bàsic i a

més s’exigeix el compliment dels següents punts:

• (�� ; haurà d’incloure els mateixos continguts

que el Document de Seguretat de mesures del nivell bàsic i a més: a)

identificació del responsable o responsables de seguretat; b) controls

periòdics per verificar el compliment del que està establert en el propi

Document de Seguretat; c) mesures que siguin necessàries adoptar

quant un suport que contingui dades de caràcter personal estigui a

punt de ser destruït o reutilitzat; d) personal autoritzat per accedir als

locals a on es trobin físicament ubicats els Sistemes d’informació

amb dades de caràcter personal.

�8��

�� %�&''&� � (��) *��+��!��,� ��-��

• �� ;�el responsable del fitxer ha de anomenar

a un responsable o a varis responsables de seguretat. Aquesta desig-

nació no significa cap delegació de les responsabilitats del responsa-

bles d’aquest fitxer.

• /��; Els sistemes de seguretat es sotmetran a una auditoria in-

terna o externa que verifiqui el compliment de lo disposat en la legis-

lació vigent. La auditoria s’haurà de realitzar al menys cada dos anys.

La informació d’auditoria haurà de determinar el grau de compliment

de la legislació vigent, identificar les deficiències i proposar les me-

sures correctores o complementàries. Haurà d’incloure, també, les

observacions, fets i dades en que es basen els dictàmens obtinguts i

recomanacions proposades. Els informes d’auditoria seran analitzats

per el responsable de seguretat competent, que elevarà les conclusi-

ons al responsable del fitxer per que adopti les mesures correctores

necessàries. Els informes d’auditoria hauran de dipositar-se a

l’Agencia de Protecció de Dades.

• �� ; El responsable del fitxer establirà un

mecanisme que permeti la identificació inequívoca i personalitzada

de tot usuari que tracti d’accedir als sistemes d’informació i la verifi-

cació d’estar autoritzat. No es permetrà els intents d’accés reiterats y

no permesos.

• &� �� 7��$�� @��; únicament el personal autoritzat en el Docu-

ment de Seguretat podrà accedir als locals a on es trobin físicament

els sistemes d’informació amb les dades de caràcter personal.

• 9�� ; haurà d’establir-se un sistema de recepció de su-

ports informàtics que permeti: a) conèixer el tipus de suport; b) data i

hora del suport; c) emissor; d) número de suports; e) tipologia de la

informació que contingui; f) forma d’enviament; g) persona respon-

sable de la recepció. Haurà d’establir-se un sistema de registrament

de sortida de suports informàtics que permeti: a) conèixer el tipus de

suport; b) data i hora del suport; c) emissor; d) número de suports; e)

tipologia de la informació que contingui; f) forma d’enviament; g)

persona responsable del lliurament, la qual haurà d'estar degudament

autoritzada. Quant un suport hagi de ser eliminat o reutilitzat

s’hauran d’adoptar mesures necessàries per impossibilitar la recupe-

ració posterior de la informació que està emmagatzemada en ell, pre-

vi baixa en el inventari. Quant algun suport hagi de sortir fora dels

locals en el que es troben físicament ubicats els fitxers, per motius de

"�� #��$� ��#�� 8��

�� %�&''&� � ��(��) *��+��!��,� ��-��

manteniment, s’adoptaran mesures necessàries per impedir qualsevol

recuperació indeguda de la informació emmagatzemada.

• ��7� �� : A més de tot lo exigit per les mesures de se-

guretat bàsiques, en el registre d’incidències haurà de constar els

procediments realitzats de recuperació de dades indicant la persona

que va executar el procés, les dades restaurades i les dades emmagat-

zemades manualment. És necessari la autorització per escrit del res-

ponsable del fitxer per procedir a executar el procés de recuperació

de dades.

• ��!��: les proves no es podran realitzar amb dades

reals a no ser que es garanteixi el nivell de seguretat corresponent al

tipus de fitxer tractat.

Les �� !�� inclouen les del nivell mitjà i a

més a més s’exigeix el compliment dels següents punts:

• (�� ; la distribució de suports que continguin da-

des de caràcter personal es realitzaran xifrant les dades o utilitzant

qualsevol altre sistema que faci inintel·ligible dita informació durant

el transport.

• ��7��;�de cada accés es guardarà com a mínim: a) iden-

tificació de l’usuari; b) data i hora en que es va realitzar l’accés; c)

nom del fitxer accedit; d) tipus d’accés; e) accés autoritzat o denegat.

Si l’accés ha estat autoritzat es guardarà la informació necessària que

identifiqui el registre accedit. El responsable de seguretat tindrà el

control dels mecanismes de seguretat descrits anteriorment i no es

podran desactivar sota cap concepte. El període mínim de conserva-

ció de les dades registrades serà de dos anys. El responsable de segu-

retat haurà de revisar periòdicament la informació de control regis-

trada i elaborarà un informe de les revisions realitzades i els proble-

mes detectats, al menys un cop al mes.

• &> ��<�� : haurà de guardar-se un cò-

pia de recolzament i dels procediments de recuperació de les dades en

un lloc diferent d’on es trobin físicament els sistemes d’informació.

Les nivells de seguretat exigits hauran de ser almenys els exigits en el

RC 994/1.999.

• -�� : la transmissió de dades de caràcter personal a

través de la xarxa de telecomunicacions es realitzarà xifrant les dades

�88� � ��

�� %�&''&� � (��) *��+��!��,� ��-��

o utilitzant qualsevol altre sistema que faci totalment inintel·ligible

dita informació durant el transport.

La Agència de Protecció de Dades és una Institució de Dret Públic, amb

personalitat jurídica pròpia i plena capacitat pública i privada. Exerceix

les seves funcions amb plena independència de les Administracions pú-

bliques. La seva principal finalitat és fer que es compleixi la legislació

sobre protecció de dades personals informatitzades i controlar la seva a-

plicació, especialment en els drets d’informació, accés, rectificació i can-

cel·lació de dades. Per el compliment d’aquesta missió l’Agència està

realitzant campanyes de divulgació i informació als ciutadans perquè pu-

guin defensar millor els seus drets. Ha elaborat una guia pràctica per in-

formar als ciutadans dels drets per a la protecció de les seves dades per-

sonals.

Es poden trobar les darreres actualitzacions de totes les normatives, i fer

les notificacions i registres d'inscripció dels fitxers de dades personals a

l'adreça d'Internet de l'Agència de Protecció de Dades:

http://www.agenciaprotecciondatos.org/

La pàgina disposa de les FAQ (preguntes més freqüents) amb la finalitat

que el ciutadà pugui exercir els seus drets i amb la d'aclarir com les orga-

nitzacions han de complir amb els seus deures.

��

��

�

��

��

Les dades són els fets, en brut, que poden ser enregistrats a una Ba-

se de Dades, des del moment en que la recol·lecció, enregistrament

i recuperació de dades són activitats centrals per a qualsevol orga-

nització, el disseny de la Base de Dades s'esdevé crucial. Els fets en

brut molt poques vegades es poden utilitzar per prendre decisions,

per prendre aquestes el que cal és informació, definida com les da-

des arranjades d'una forma comprensible. La paraula transformació

és utilitzada per descriure qualsevol procés que canvia dades en in-

formació.

Bàsicament, una Base de Dades és un dipòsit de fets molt ben dis-

senyat i construït, aquest dipòsit de fets forma part d'un gran con-

junt conegut com Sistema d'Informació. Un Sistema d'Informació

proporciona la possibilitat de recollir, enregistrar i recuperar dades,

facilitant la transformació de les dades en informació i la gestió tant

de les dades com de la informació.. Així un sistema d'Informació

complert està composat de persones, hardware, software, la Base de

Dades, els programes d'aplicació i els procediments. L'anàlisi de

Sistemes és el procés que estableix les necessitat i l'extensió d'un

Sistema d'Informació. El procés de creació d'un sistema d'Informa-

ció es conegut com Desenvolupament del Sistema.

El rendiment d'un Sistema d'Informació depèn de tres factor: a) dis-

seny i implementació de la Base de Dades; b) disseny i implemen-

tació de les aplicacions; c) procediments administratius. En sentit

ampli el terme Desenvolupament de Bases de Dades es fa servir per

�� !�� " ��# ��

��

descriure el procés de disseny i implementació de la Base de Da-

des. L'objectiu primari del disseny de Bases de Dades és crear un

complet, normalitzat, no redundant i totalment integrat model con-

ceptual, lògic i físic de la Base de Dades. La implementació de la

Base de Dades inclou la creació de l'estructura d'emmagatzematge

de la Base de Dades, la càrrega de les dades requerides pels usuaris

a la Base de Dades, i la gestió de les dades.

��

El cicle de vida d'una Base de Dades forma part del cicle de vida

del Sistema d'Informació de l'organització; A la figura 8.1 es pre-

senten les diferents etapes d'aquest cicle. Es pot veure que el procés

no és seqüencial, si no que pot involucrar la repetició de diferents

etapes.

A la �� es realitzaran totes aquelles activitats de

gestió que permetin que la construcció de la base de dades sigui re-

alitzada de la forma més eficaç i eficient possible. les principals

són:

• Identificar els plans i objectius de l'organització per tal de

determinar les necessitats del Sistema d'Informació.

• Avaluar els sistemes d'Informació actuals per tal de determinar

les tensions i febleses actuals.

• Avaluat les avantatges de les Tecnologies de la Informació que

permetin avantatges competitives.

En aquesta fase caldrà redactar la declaració d'objectius que es vo-

len assolir amb la base de dades, i com es mesurarà l'èxit o fracàs

de cada objectiu.

La següent fase és la de �� , on es descriurà l'àm-

bit i els límits de la base de dades i les visions dels principals usua-

ris; indicant que és el que aquests esperen, tant pel seu treball

particular com per l'àrea d'aplicació en què treballen. Aquesta visió

s'haurà de fer en termes de les dades que requereixen els diferents

usuaris,

8 El procés de creació d'una base de dades 191

Santiago Ortego, 2002 Escola Universitària Politècnica de Mataró

Planificació de labase de dades

Definició delsistema

Captura derequeriments i

anàlisi

Dissenyconceptual de labase de dades

Disseny lògic de labase de dades

Disseny físic de labase de dades

Selecció delSGBD Disseny de

l’aplicació

Prototipat Implementació

Migració i càrregade dades

Prova

Manteniment

Fig. 8.1 Cicle de vida d'una Base de Dades

A la fase de captura de requeriments i anàlisi caldrà recollir i a-nalitzar tota la informació sobre la part de l'organització que hagi d'estar suportada per la base de dades, i utilitzar aquesta informació per tal d'identificar els requeriments que els usuaris demanaran al nou sistema. En aquesta fase caldrà documentar, per a cada visió del sistema: Una descripció de totes les dades que són usades o generades. Els detalls de com lesa dades són utilitzades o generades. Qualsevol requeriment addicional per la nova base de dades.

Per tal d'analitzar la situació de l'organització el dissenya-dor ha de descobrir quin són els components operacionals de l'organització, quina és la seva funció i com interactuen.

L'àmbit i les limitacions són els factors que forcen que el disseny sigui fet d'un mode particular, i fan que el treball dels dissenyadors es restrin-geixi a trobar la millor solu-ció dintre d'aquest mode.

�� !�� " ��# ��

��

El� ��# de la base de dades, que es pot definir com el procés de

creació d'un disseny de Base de Dades que suporti les operacions i

objectius de l'organització. El capítol següent es dedicarà a aquest

tema.

La �� $��, en aquesta etapa caldrà triar el SGBD apro-

piat per suportar la gestió de la base de dades de l'organització. Per

tal d'avaluar els diferents productes del mercat es pot fer una valo-

ració ponderada dels diferents aspectes necessaris per acomplir els

objectius proposats a la primera etapa

En aquest moment es podrà començar a col·laborar amb el procés

de ��#�� de l'aplicació, una de les tasques principals

relacionades amb la base de dades serà el ��#� ��.

S'haurà de crear un document que defineixi: les dades que seran

utilitzades a cadascuna d'elles; les característiques funcionals; les

sortides de la transacció; la importància pels usuaris i la freqüència

d'actualització.

Seguidament caldrà realitzar la �� física de la base de

dades, començant per la instal·lació i tuning del SGBD triat i per la

implementació del disseny realitzat.

No és gaire usual crear un sistema d'informació per una organitza-

ció que no en disposi de cap dada anterior, i amb totes aquestes cal

realitzar la ��%��"��%� en el nou sistema, transformant les

dades al nou format i estructura.

Abans de posar en producció la base de dades caldrà realitzar ��&

�� exhaustives, tant d'eficàcia com d'eficiència. I una vegada fet la

posta en marxa caldrà realitzar les diferents operacions de ��&

�� necessàries per: arreglar problemes, ajustar-se als canvis

que experimenti l'organització o millorar les solucions utilitzades.

��'�� #� ��

Abans d'estudiar amb detall tot el disseny cal recordar els següents

punts:

La definició més complerta i acurada possible del proble-ma no comporta que es pugui arribar a la solució ideal, el món real introdueix múltiples restriccions, cadascuna de les quals demana temps i diners per resoldre-les, el dissenya-dor ha d'aprendre a distingir entre el perfecte i el possible.

�� '

��

• El procés de disseny de la Base de Dades està íntimament rela-

cionat amb l'anàlisi i disseny de tot el Sistema, ja que forma part

d'ell.

• S'ha de recordar que altres dissenyadors estan a càrrec d'altres

parts del Sistema, les seves aplicacions han d'interactuar amb la

Base de Dades.

• El disseny d'una Base de Dades no constitueix un procés se-

qüencial, sinó un d'iteratiu, en el qual cada etapa dona un feed-

back que repercuteix sobre totes les etapes anteriors.

En el disseny conceptual, la modelització de dades s'utilitza per

crear una estructura abstracta que representa els objectes del món

real de la forma més realista possible; aquesta modelització obliga

a un coneixement profund de tota l'organització i les seves àrees

funcionals.

La regla principal de la modelització conceptual, nomenada

de vegades la regla de la minimalitat de les dades, és: "tot a-

llò que és necessari està aquí i tot el que està aquí és necessa-

ri".

La primera fase del disseny conceptual és descobrir els detalls de

totes les dades, una Base de Dades eficaç és una "fàbrica d'infor-

mació" que produeix ingredients claus per prendre les decisions

amb èxit. Per assolit aquest objectiu el dissenyador es pot fer dife-

rents preguntes:

• (�� , quin tipus d'informació és necessari?

quines sortides haurà de generar el Sistema?

• )�� , On es troba la informació? com es podrà

extreure la informació una vegada trobada?

• *�� , qui farà servir la informació? com es

farà servir la informació? quines són les diferents visions de les

dades per part dels usuaris?

• +�� , quines dades són necessàries per

produir informació? quines relacions existeixen entre les dades?

quin és el volum de dades? amb quina freqüència s'utilitzen les

��,� � !�� " ��# ��

��

dades? quines transformacions s’han de fer a les dades per gene-

rar la informació demanada?

El dissenyador pot trobar resposta a aquestes preguntes de diferents

fonts:

• �� &

��, el dissenyador i l'usuari final hauran de treballar conjunta-

ment per desenvolupar una descripció precisa de les dades que

utilitza l'usuari, aquesta visió ajudarà a identificar els elements

principals de la Base de Dades.

• -.�� &/�� 0� ��, l'usuari final acostuma a disposar d'un sis-

tema (manual o automàtic), el dissenyador haurà de revisar a-

quest Sistema, tant la part d'entrades al Sistema com les sortides,

per identificar les dades i les seves característiques.

• 1��&��.��%�� #� �� &

��, si les tasques de disseny de la Base de Dades recauen

en una, o vàries, persones diferents a les que desenvolupen el

Sistema d'Informació, caldrà que aquestes segueixin les especi-

ficacions generals del Sistema.

Per tal de desenvolupar un model de dades acurat, el dissenyador

haurà de tenir un complert i meticulós coneixement de les dades de

l'organització; però aquestes no són res més que uns objectes sobre

els que actuen les regles de l'organització (business rules, regles del

negoci); una regla de l'organització és una descripció d'una política,

procediment o principi dintre d'un entorn específic, les regles creen

i forcen accions dintre d'aquest entorn. Per ser efectives aquestes

regles han de ser clares i entenedores, i àmpliament difoses per tal

que totes les persones de l'organització tinguin una interpretació

comuna de la regla.

Les regles de l'organització descriuen, en llenguatge natural, el sig-

nificat i característiques diferencials de les dades tal com les veu

l'organització. Exemples de regles són: a) una persona no pot treba-

llar més de cinc hores sense descans; b) els increments de sou seran

sempre proporcionals; c) cada 100 hr de vol caldrà revisar els mo-

tors; d) un directiu no pot tenir menys de cinc ni més de vint subor-

�� 2

��

dinats directament sota el seu control;... El coneixement de les re-

gles de l'organització permet important beneficis en el disseny de

nous Sistemes:

• Ajuda a estandarditzar el punt de vista de l'organització de les

dades.

• Constitueix una eina de comunicació entre el dissenyador i els

usuaris.

• Permet al dissenyador conèixer la naturalesa, paper i àmbit de

les dades.

• Permet al dissenyador comprendre els procediments de

l'organització.

• Permet al dissenyador desenvolupar normes apropiades de inter-

relació-associació i restriccions de clau forana.

Abans de crear el model Conceptual, el dissenyador haurà de defi-

nir de forma clara quins seran els estàndards utilitzats a la docu-

mentació, aquests inclouran els diagrames i símbols, l'estil i estruc-

tura de la documentació escrita i qualsevol altra convenció que s'u-

tilitzi. Com que les normes de l'organització normalment definei-

xen la naturalesa de les interrelacions entre les entitats, el dissenya-

dor haurà d'incorporar aquestes al model conceptual. El procés de

definició de les normes de l'organització i de desenvolupament del

model conceptual utilitzant diagrames conceptuals està format per

les següents etapes:

• 3�"�� de les propostes de normes de l'organització;

• Fer que els usuaris principals ��!�� les normes

de l'organització;

• � �� principals que cal que l'organització conegui,

els quals esdevindran les entitats del Sistema.

• ��entre entitats;

• ��.�� i de l'identificador de cada entitat;

• (��4�� per assegurar la integritat de les dades.

La selecció del SGBD és una etapa crítica pel bon funcionament

del Sistema d'Informació, per tant les avantatges i desavantatges

del SGBD proposat han de ser estudiades amb molta cura, els fac-

tors més comuns d'estudi són:

��5� � !�� " ��# ��

��

• cost: compra, manteniment, operació, llicències, instal·lació,

formació del personal i costos de conversió;

• característiques i eines del SGBD: totes les eines que facilitin

tant el desenvolupament d'aplicacions, com les tasques d'admi-

nistració del Sistema;

• model suportat: relacional, jeràrquic, xarxa, orientat a objectes..;

• portabilitat: entre plataformes, sistemes i llenguatges;

• requeriments de hardware.

El disseny lògic segueix a la decisió d'utilitzar un model de Bases

de Dades específic (relacional, orientat a objectes, ...), una vegada

elegit, cal transformar el disseny conceptual en un disseny lògic es-

triat, per tant aquesta fase és dependent del software. A un nivell

més de detall, depèn també del fabricant i producte estriat.

El disseny físic és el procés de seleccionar l'emmagatzematge de

les dades i les característiques de l'accés a la Base de Dades, aques-

tes dependran dels dispositius suportats pel hardware del qual es

disposi; el disseny físic no sols afecta a la col·locació de les dades,

sinó també al rendiment del Sistema.

La implementació de la Base de Dades requerirà activitats diferents

segons el producte que s'utilitzi, un esquema força usual és:

• Crear el grup d'emmagatzematge de la Base de Dades

• Crear la Base de Dades al seu grup.

• Assignar els drets d'accés al DBA.

• Crear els espais de taula (tablespace).

• Crear les diferents taules de cada espai de taula.

• Assignar els drets d'accés a cada taula.

A continuació es presenta un quadre esquemàtic indicant les dife-

rents tasques que cal realitzar per dissenyar una base de dades:

��#�� .��

)�� Construir un model de dades local per a cada vista

)��Identificar les entitats.

)�� Identificar les associacions i agregacions.

�� 6

��

)��' Identificar i associar els atributs amb les entitats o

associacions.

)��,�Determinar els dominis dels atributs.

)��2 Determinar els tributs identificadors i candidats.

)��5 Considerar la utilització de generalitzacions.

)��6�Comprovar que no hi ha redundància.

)��Validar el model conceptual local contra les trans-

accions dels usuaris.�

)��1� �� .��

�

��#��7%�� .��

)�� Construir i validar el model lògic de dades per a cada

vista

)�� Treure les característiques no compatibles amb el

model relacional.

)�� Derivar relacions pel model lògic relacional.

)��' Validar les relacions utilitzant la normalització.

)��,�Validar les relacions contra les transaccions.

)��2 Definir les restriccions d'integritat.

)��5�Revisar el model de dades lògic amb l'usuari

)��'�Construir i validar el model de dades lògic global�

)��'�� Fusionar els diferents models de dades locals en un

de global.

)��'�� Validar el model de dades lògic global

)��'�'�Comprovar el disseny per a futurs creixements

)��'�, Revisar el model de dades global amb els usuaris

��#��8�� .��

)��,�Convertir el model de dades global a les especificacions

del SGBD triat

)��,�� Dissenyar les taules bàsiques

)��,�� Dissenyar la representació de les dades derivades

)��,�' Dissenyar les regles de negoci de l'organització

)��2 Dissenyar la representació física

)��2�� Analitzar les transaccions

)��2�� Triar l'organització física adequada

)��2�' Triar els índexs

)��2�, Estimar les necessitats d'espai en disc

)��5 Dissenyar les vistes d'usuari

�� !�� " ��# ��

��

)��6 Dissenyar els mecanismes de seguretat

)�� Considerar la introducció de redundància controlada

)�� Fer el tuning del SGBD triat

��

�� !�

��

• �� (2002) Database Systems. Readding: Addison-Wesley

Publishing.

• �� (2001). Introducción a los sistemas de Bases de Datos. Wilmington: Addison-Wesley

Iberoamericana.

• �� (1997). Fundamentos y modelos de Bases de Datos. Madrid: RA-MA

Editorial.

• �� . (1999). Diseño de Bases de Datos. Madrid: RA-MA

Editorial

• ��. (2000). Diseño de Bases de Datos.Problemas resueltos. Madrid: RA-MA Editorial

• �!�� "�� #�$��%�� . (2002). Sistemas de Bases de Datos, conceptos fundamentales.

Wilmington: Addison-Wesley Iberoamericana.

• ��&��&�� (1999). SQL:99 Complete, Really. Gilroy: R & D Books

• '��(��'��)� (1997). Diseño y administración de Bases de Datos. Madrid: Prentice-

Hall.

• *�+��,�� (2001). Bases de datos: desde Chen hasta Codd con Oracle. Madrid: RA-MA Editorial.

• ��%��&��-�.��%��'�/��%�� (2002). Fundamentos de Bases de Datos. Aravaca:

McGraw-Hill.

011� � ��"��

�� !� �

Introduccio Bases Dades

Documents

Transcript of Introduccio Bases Dades