Disseny de Bases (Catalán)

Disseny de bases
de dades
Dolors Costal Costa
P06/M2009/02150
FUOC P06/M2009/02150
Disseny de bases de dades
ndex
Introducci.................................................................................................
Objectius......................................................................................................
1. Introducci al disseny de bases de dades ......................................
1.1. Etapes del disseny de bases de dades................................................
2. Disseny conceptual: el model ER .....................................................
10
2.1. Construccions bsiques ....................................................................
11
2.1.1. Entitats, atributs i interrelacions ............................................
11
2.1.2. Grau de les interrelacions.......................................................
13
2.1.3. Interrelacions binries ............................................................
16
2.1.4. Exemple: base de dades de cases de colnies.........................
18
2.1.5. Interrelacions n-ries ..............................................................
21
2.1.6. Interrelacions recursives .........................................................
23
2.1.7. Entitats dbils .........................................................................
25
2.2. Extensions del model ER ..................................................................
26
2.2.1. Generalitzaci/especialitzaci ................................................
26
2.2.2. Entitats associatives ................................................................
28
2.3. Exemple: base de dades del personal duna entitat

bancria .............................................................................................
30
3. Disseny lgic: la transformaci del model ER

al model relacional..............................................................................
34
3.1. Introducci a la transformaci dentitats i interrelacions ...............
34
3.2. Transformaci dentitats ...................................................................
34
3.3. Transformaci dinterrelacions binries ...........................................
35
3.3.1. Connectivitat 1:1 ....................................................................
35
3.3.2. Connectivitat 1:N ...................................................................
36
3.3.3. Connectivitat M:N..................................................................
37
3.3.4. Influncia de la dependncia dexistncia

en la transformaci de les interrelacions binries .................
38
3.4. Transformaci dinterrelacions ternries ..........................................
39
3.4.1. Connectivitat M:N:P...............................................................
39
3.4.2. Connectivitat M:N:1...............................................................
40
3.4.3. Connectivitat N:1:1 ................................................................
41
3.4.4. Connectivitat 1:1:1 .................................................................
42
3.5. Transformaci dinterrelacions n-ries .............................................
43
3.6. Transformaci dinterrelacions recursives ........................................
43
3.7. Transformaci dentitats dbils ........................................................
45
3.8. Transformaci de la generalitzaci/especialitzaci ..........................
46
3.9. Transformaci dentitats associatives ...............................................
47
FUOC P06/M2009/02150
3.10. Resum de la transformaci del model ER al model relacional ......
48
3.11. Exemple: base de dades del personal duna entitat bancria ........
48
Resum...........................................................................................................
50
Exercicis dautoavaluaci.......................................................................
51
Solucionari .................................................................................................
53
Glossari ........................................................................................................
57
Bibliografia ................................................................................................
58
FUOC P06/M2009/02150
Introducci
En altres unitats sestudien les bases de dades relacionals i tamb el
llenguatge relacional, SQL, que ens proporciona mecanismes per a crear,
actualitzar i consultar aquestes bases de dades.
Cal complementar aquests coneixements amb un aspecte que s fonamental per
a poder utilitzar adequadament la tecnologia de les bases de dades relacionals: el
disseny. Aquest ser lobjecte destudi daquesta unitat, que tractar del disseny
de bases de dades per al cas especfic del model relacional.
Concretament, en aquesta unitat explicarem en qu consisteix el disseny
duna base de dades, analitzarem les etapes en qu es pot descompondre, i
descriurem amb detall les etapes del disseny conceptual i lgic duna base de
dades relacional.
Objectius
En els materials didctics daquesta unitat trobareu les eines indispensables per a
assolir els objectius segents:
1. Conixer les etapes que integren el procs del disseny duna base de dades.
2. Conixer les estructures del model ER.
3. Saber fer el disseny conceptual de les dades dun sistema dinformaci
mitjanant el model ER.
4. Saber fer el disseny lgic duna base de dades relacional partint dun disseny
conceptual expressat amb el model ER.
FUOC P06/M2009/02150
1. Introducci al disseny de bases de dades
En altres unitats hem aprs com s una base de dades relacional i hem estudiat
un llenguatge, lSQL, que ens proporciona mecanismes per a crear aquestes bases de dades, per a actualitzar-les i consultar-les.
Encara ens falta, per, resoldre algunes qestions fonamentals per a poder
emprar la tecnologia de les bases de dades relacionals, per exemple: com es pot
decidir quines relacions ha de tenir una base de dades determinada o quins atributs han de tenir les relacions, quines claus primries i quines claus
foranes shan de declarar, etc. La tasca de prendre aquest conjunt de decisions
sanomena dissenyar la base de dades.
Una base de dades serveix per a emmagatzemar la informaci que sutilitza
en un sistema dinformaci determinat. Les necessitats i els requisits dels
futurs usuaris del sistema dinformaci shan de tenir en compte per a poder
prendre adequadament les decisions anteriors.
En resum, el disseny duna base de dades consisteix a definir lestructura de les dades que ha de tenir la base de dades dun sistema dinformaci
determinat. En el cas relacional, aquesta estructura ser un conjunt desquemes de relaci amb els seus atributs, dominis datributs, claus primries, claus foranes, etc.
Si recordeu els tres mons presentats el real, el conceptual i el de les

representacions, observareu que el disseny duna base de dades consisteix en
lobtenci duna representaci informtica concreta a partir de lestudi del mn
real dinters.
1.1. Etapes del disseny de bases de dades

El disseny duna base de dades no s pas un procs senzill. Habitualment, la complexitat de la informaci i la quantitat de requisits dels sistemes dinformaci fan
que sigui complicat. Per aquest motiu, quan es dissenyen bases de dades, s interessant aplicar la vella estratgia de dividir per a vncer.
Per tant, conv descompondre el procs del disseny en diverses etapes, en cadascuna de les quals sobt un resultat intermedi que serveix de punt de partida de
letapa segent, i a la darrera etapa sobt el resultat desitjat. Daquesta manera
no cal resoldre de cop tota la problemtica que planteja el disseny, sin
que a cada etapa safronta un sol tipus de subproblema. Daquesta manera es
divideix
el problema i alhora se simplifica el procs.
Recordeu que les bases de dades

relacionals i el llenguatge SQL shan
estudiat a les unitats El model relacional
i llgebra relacional i El llenguatge
SQL, respectivament.
FUOC P06/M2009/02150
Descompondrem el disseny de bases de dades en tres etapes:

1) Etapa del disseny conceptual: en aquesta etapa sobt una estructura de la
informaci de la futura BD independent de la tecnologia que cal emprar. No es
t en compte encara quin tipus de base de dades sutilitzar relacional, orientada a objectes, jerrquica, etc.; en conseqncia, tampoc no es t en compte amb
quin SGBD ni amb quin llenguatge concret simplementar la base de
dades. Aix, doncs, letapa del disseny conceptual ens permet concentrar-nos
nicament en la problemtica de lestructuraci de la informaci, sense haver-
El resultat del disseny

conceptual
Si reprenem la idea dels tres
mons, podem afirmar que
letapa del disseny
conceptual obt un resultat
que se situa al mn de les
concepcions, i no pas al mn
de les representacions.
nos de preocupar alhora de resoldre qestions tecnolgiques.

El resultat de letapa del disseny conceptual sexpressa mitjanant algun model
de dades dalt nivell. Un dels ms emprats s el model entitat-interrelaci
La manera delaborar un disseny

conceptual expressat amb el model ER
sexplica a lapartat 2 daquesta unitat.
(entity-relationship), que abreviarem amb la sigla ER.

2) Etapa del disseny lgic: en aquesta etapa es parteix del resultat del disseny
conceptual, el qual es transforma de manera que sadapti a la tecnologia que sha
demprar. Ms concretament, cal que sajusti al model de lSGBD amb el qual es
desitja implementar la base de dades. Per exemple, si es tracta dun SGBD relacional, aquesta etapa obtindr un conjunt de relacions amb els seus
El resultat del disseny

lgic
El resultat del disseny lgic
se situa ja al mn de les
representacions.
atributs, claus primries i claus foranes.

Aquesta etapa parteix del fet que ja sha resolt la problemtica de lestructuraci
de la informaci a un nivell conceptual i ens permet concentrar-nos en les qestions tecnolgiques relacionades amb el model de base de dades.
Ms endavant explicarem com es fa el disseny lgic duna base de dades relacional prenent com a punt de partida un disseny conceptual expressat amb el
model ER, s a dir, veurem com es pot transformar un model ER en un
El disseny lgic duna base de dades

relacional sexplica a lapartat 3 daquesta
unitat.
model relacional.
3) Etapa del disseny fsic: en aquesta etapa es transforma lestructura obtinguda a letapa del disseny lgic amb lobjectiu daconseguir una major eficincia i,
a ms, es completa amb aspectes dimplementaci fsica que dependran de
lSGBD.
Per exemple, si es tracta duna base de dades relacional, la transformaci de lestructura pot consistir en els fets segents: tenir emmagatzemada alguna relaci
que sigui la combinaci de diverses relacions que shan obtingut a letapa del disseny lgic, partir una relaci en diverses relacions, afegir algun atribut calculable
a una relaci, etc. Els aspectes dimplementaci fsica que cal completar consisteixen normalment en lelecci destructures fsiques dimplementaci de les relacions, la selecci de la mida de les memries intermdies (buffers) o de les pgines, etc.
A letapa del disseny fsic amb lobjectiu daconseguir un bon rendiment de la
base de dades, shan de tenir en compte les caracterstiques dels processos que
El resultat del disseny fsic

El resultat de letapa del
disseny fsic se situa al mn
de les representacions, igual
que el resultat de letapa del
disseny lgic. La diferncia
respecte a letapa anterior s
que ara es tenen en compte
aspectes de carcter ms fsic
del mn de les
representacions.
FUOC P06/M2009/02150
consulten i actualitzen la base de dades com ara els camins daccs que utilitzen
i les freqncies dexecuci. Tamb cal considerar els volums que sespera tenir
de les diferents dades que es volen emmagatzemar.
10
FUOC P06/M2009/02150
2. Disseny conceptual: el model ER
En aquest apartat tractarem del disseny conceptual duna base de dades

mitjanant el model ER. El que explicarem s aplicable al disseny de qualsevol
tipus de base de dades relacional, jerrquica, etc., ats que, com ja hem dit, a
letapa del disseny conceptual no es t en compte encara la tecnologia
concreta que semprar per a implementar la base de dades.
El model ER s un dels enfocaments de modelitzaci de dades que ms
es fa servir actualment per la seva simplicitat i llegibilitat. La seva llegibilitat
es veu afavorida
perqu
proporciona
una
notaci
diagramtica
molt
entenedora. s una eina til tant per a ajudar el dissenyador a reflectir en un

model conceptual els requisits del mn real dinters, com per a comunicarse amb lusuari final sobre el model conceptual obtingut i, aix, poder
verificar si satisf els seus requisits.
El model ER resulta fcil daprendre i dutilitzar en la majoria daplicacions. A
ms a ms, existeixen eines informtiques dajuda al disseny (eines CASE*) que
* La sigla CASE correspon

al terme angls Computer Aided
Software Engineering.
fan servir alguna variant del model ER per a fer el disseny de les dades.
El nom complet del model ER s entity-relationship, i prov del fet que els principals elements que inclou sn les entitats i les interrelacions (entities i
El model entitatinterrelaci
relation- ships). Traduirem aquest nom per entitat-interrelaci.

Lorigen del model ER es troba en treballs efectuats per Peter Chen el 1976. Posteriorment, molts altres autors han descrit variants i/o extensions daquest
model. Aix, a la literatura es troben moltes formes diferents del model ER que
poden variar simplement en la notaci diagramtica o en alguns dels conceptes
en qu es basen per a modelitzar les dades.
Alguns autors anomenen

entitat-relaci el model ER,
per en el nostre cas hem
preferit traduir relationship
per interrelaci i no per
relaci, a fi devitar
confusions entre aquest
concepte i el de relaci
que sempra en el model
relacional.
Quan es vol fer servir el model ER per a comunicar-se amb lusuari, s recomanable emprar una variant del model que inclogui noms els seus elements ms
simples entitats, atributs i interrelacions i, potser, algunes construccions addicionals, com ara entitats dbils i dependncies dexistncia. Aquests eren els elements inclosos en el model original proposat per Chen. En canvi, per a portar a
terme la tasca de modelitzar prpiament dita, sol ser til fer servir un model ER
ms complet que inclogui construccions ms avanades que estenen el
model original.
Segons la noci de model de dades que hem utilitzat en els altres mduls,
un model de dades t en compte tres aspectes de les dades: lestructura, la
manipulaci i la integritat. El model ER, per, habitualment es fa servir
per a reflectir aspectes de lestructura de les dades i de la seva integritat,
per no de la seva manipulaci.
Recordeu el model relacional, que sha

estudiat a la unitat El model relacional
i llgebra relacional.
11
FUOC P06/M2009/02150
2.1. Construccions bsiques

2.1.1. Entitats, atributs i interrelacions
Per entitat entenem un objecte del mn real que podem distingir de

la resta dobjectes i del qual ens interessen algunes propietats.
Exemples dentitat
Alguns exemples dentitat sn un empleat, un producte o un despatx. Tamb sn entitats
altres elements del mn real dinters, menys tangibles per igualment distingibles de
la resta dobjectes, com ara una assignatura impartida en una universitat, un prstec
bancari, una comanda dun client, etc.
Les propietats dels objectes que ens interessen sanomenen atributs.
Exemples datribut
Duna entitat empleat, ens pot interessar, posem per cas, tenir-ne enregistrats el DNI, lNSS,
el nom, el cognom i el sou com a atributs.
El terme entitat es fa servir tant per a anomenar objectes individuals com per
a fer referncia a conjunts dobjectes similars dels quals interessen els mateixos atributs; s a dir, que, per exemple, sutilitza per a designar tant un empleat
concret duna empresa com el conjunt de tots els empleats de lempresa.
Ms
concretament,
el
terme
entitat
es
pot
referir
instncies
ocurrncies concretes (empleats concrets) o a tipus o classes dentitats

(el conjunt de tots els empleats).
El model ER proporciona una notaci diagramtica per a representar grficament les entitats i els seus atributs:
EMPLEAT
Les entitats es representen amb un rectangle. El nom de lentitat sescriu en
dni
nss
nom
cognom
sou
majscules a dins del rectangle.
Els atributs es representen mitjanant el seu nom en minscules unit amb un

guionet al rectangle de lentitat a la qual pertanyen. Moltes vegades, com que
hi ha molts atributs per a cada entitat, es llisten tots a part del diagrama per
a no complicar-lo.
Notaci diagramtica
dentitats i atributs
La figura mostra la notaci
diagramtica per al cas duna
entitat empleat amb els
atributs dni, nss, nom,
cognom i sou.
Cadascun dels atributs duna entitat pren valors dun cert domini o conjunt de
valors. Els valors dels dominis han de ser atmics, s a dir, no han de ser
des- componibles. A ms, tots els atributs han de ser univaluats. Un atribut s
univaluat si t un sol valor per a cada ocurrncia duna entitat.
Recordeu que els valors dels atributs

de les relacions tamb han de ser atmics,
tal com sha explicat a la unitat El model
relacional i llgebra relacional.
FUOC P06/M2009/02150
12
Exemple datribut univaluat

Latribut sou de lentitat empleat, per exemple, pren valors del domini dels reals i noms pren
un valor per a cada empleat concret i, per tant, cap empleat no pot tenir ms dun valor per
al sou.
Com ja hem comentat anteriorment, una entitat ha de ser distingible de la

resta dobjectes del mn real. Aix fa que per a tota entitat sigui possible trobar
un conjunt datributs que permetin identificar-la. Aquest conjunt datributs
formen una clau de lentitat.
Exemple de clau
Lentitat empleat t una clau que consta de latribut dni perqu tots els empleats tenen nmeros de DNI diferents.
Una determinada entitat pot tenir ms duna clau, s a dir, diverses claus candidates.
Els conceptes de clau candidata i clau

primria duna entitat sn similars als
conceptes de clau candidata i clau primria
duna relaci, que hem estudiat a la unitat
El model relacional i llgebra relacional.
Exemple de clau candidata

Lentitat empleat t dues claus candidates, la que s formada per latribut dni i la que s constituda per latribut nss, ats que lNSS tamb ser diferent per a cadascun dels empleats.
El dissenyador escull una clau primria entre totes les claus candidates. En
la notaci diagramtica, la clau primria se subratlla per a distingir-la de la resta
de claus.
Exemple de clau primria
dni
nss
nom
cognom
sou
EMPLEAT
En el cas de lentitat empleat, podem escollir dni com a clau primria. A la figura del marge
veiem que la clau primria se subratlla per a distingir-la de la resta.
Es defineix interrelaci com una associaci entre entitats.
Les interrelacions es representen en els diagrames del model ER mitjanant un

rombe. Al costat del rombe sindica el nom de la interrelaci amb lletres majscules.
EMPLEAT
Exemple dinterrelaci
Considerem una entitat empleat i una entitat despatx i suposem que als empleats sels assignen despatxos on treballar. Aleshores hi ha una interrelaci entre lentitat empleat i lentitat
despatx.
Aquesta interrelaci, que podrem anomenar assignaci, associa els empleats amb els
despatxos on treballen. La figura del marge mostra la interrelaci assignaci entre les
entitats empleat i despatx.
El terme interrelaci es pot fer servir tant per a anomenar associacions concretes
o ocurrncies dassociacions com per a designar conjunts o classes dassociacions
similars.
ASSIG NACI
DESPATX
13
FUOC P06/M2009/02150
Exemple
Una interrelaci saplica tant a una associaci concreta entre lempleat de DNI 50.455.234 i
el despatx Diagonal, 20 com a lassociaci genrica entre lentitat empleat i lentitat despatx.
De vegades interessa reflectir algunes propietats de les interrelacions. Per

aquest motiu, les interrelacions poden tenir tamb atributs. Els atributs de
les interrelacions, igual que els de les entitats, tenen un cert domini, han
de prendre valors atmics i han de ser univaluats.
Els atributs de les interrelacions es representen mitjanant el seu nom en minscules unit amb un guionet al rombe de la interrelaci a la qual pertanyen.
Exemple datribut duna interrelaci
Observem lentitat estudiant i lentitat assignatura que es mostren a la figura segent:
Interrelaci avaluaci
a nivell de classe
ESTUDIANT
AVALUACI
nota
ASSIGNATURA
Interrelaci avaluaci a nivell

docurrncies
E1
E2
A1
E3
7 8
A2
E4
A3
Entre aquestes dues entitats hi ha la interrelaci avaluaci per a indicar de quines assignatures han estat avaluats els estudiants. Aquesta interrelaci t latribut nota, que serveix per
a especificar quina nota han obtingut els estudiants de les assignatures avaluades.
Conv observar que latribut nota ha de ser forosament un atribut de la interrelaci avaluaci,
i que no seria correcte considerar-lo un atribut de lentitat estudiant o un atribut de lentitat
assignatura. Ho explicarem analitzant les ocurrncies de la interrelaci avaluaci que es mostren
a la figura anterior.
Si nota es considers un atribut destudiant, aleshores per a lestudiant E1 de la figura necessitarem dos valors de latribut, un per a cada assignatura que t lestudiant i, per tant, no
seria univaluat. Similarment, si nota fos atribut dassignatura, tampoc no podria ser univaluat perqu, per exemple, lassignatura A1 requeriria tres valors de nota, una per a
cada estudiant que shi ha matriculat. Podem concloure que latribut nota est lligat alhora a
una assignatura i a un estudiant que la cursa i que, per aix, ha de ser un atribut de la
interrelaci que associa ambdues entitats.
2.1.2. Grau de les interrelacions
Una interrelaci pot associar dues o ms entitats. El nombre dentitats que

associa una interrelaci s el grau de la interrelaci.
14
FUOC P06/M2009/02150
Interrelacions de grau dos

Les interrelacions avaluaci i assignaci dels exemples anteriors tenen grau dos:
La interrelaci avaluaci associa lentitat estudiant i lentitat assignatura, s a dir, associa
dues entitats.
Anlogament, la interrelaci assignaci associa empleat i despatx.
Les interrelacions de grau dos sanomenen tamb interrelacions binries.

Totes les interrelacions de grau ms gran que dos sanomenen, en
conjunt, interrelacions n-ries. Aix, doncs, una interrelaci n-ria pot tenir
grau tres i ser una interrelaci ternria, pot tenir grau quatre i ser una
interrelaci qua- ternria, etc.
A continuaci presentarem un exemple que ens illustrar el fet que, de vegades,
les interrelacions binries no ens permeten modelitzar correctament la realitat i
s necessari utilitzar interrelacions de grau ms gran.
a nivell de classe
a nivell docurrncies
ESTUDIANT
AVALUACI
nota
E1
ASSIGNATURA
E2
A1
E3
7 8
A2
E4
A3
Considerem la interrelaci avaluaci de la figura anterior, que t un atribut

nota. Aquest atribut nota permet enregistrar la nota obtinguda per cada
estudiant a cada assignatura de la qual ha estat avaluat. Una interrelaci
permet establir
una
nica
associaci
entre
unes
entitats
individuals
determinades. En altres paraules, noms es pot interrelacionar una vegada

lestudiant E1 i lassignatura A1 a travs de la interrelaci avaluaci.
Observeu que, si hi pogus haver ms duna interrelaci entre lestudiant E1
i lassignatura A1, no podrem distingir aquestes diferents ocurrncies de la
interrelaci. Aquesta restricci fa que senregistri una nica nota per estudiant
i assignatura.
Suposem que desitgem enregistrar diverses notes per cada assignatura i
estudiant corresponents als diversos semestres en qu un mateix estudiant ha
cursat una assignatura determinada (malauradament, alguns estudiants han de
fer una assignatura diverses vegades abans daprovar-la). La interrelaci
anterior no ens permetria reflectir aquest cas. Caldria augmentar el grau de la
interrelaci, tal com es mostra a la figura segent:
15
FUOC P06/M2009/02150
a nivell de classe
ESTUDIANT
AVALUACISEMESTRAL
E1
S1
nota
4
SEMESTRE
ASSIGNATURA
S2
A1
La interrelaci ternria avaluaci-semestral associa estudiants, assignatures i una

tercera entitat que anomenem semestre. El seu atribut nota ens permet
reflectir totes les notes corresponents a diferents semestres que un estudiant
t duna assignatura.
De fet, el que succeeix en aquest cas s que, segons els requisits dels usuaris
daquesta BD, una nota pertany alhora a un estudiant, a una assignatura i a un
semestre i, lgicament, ha de ser un atribut duna interrelaci ternria entre
aquestes tres entitats.
Aquest exemple demostra que una interrelaci binria pot no ser suficient per a
satisfer els requisits dels usuaris i pot ser necessari aplicar una interrelaci de grau
ms gran. Conv observar que aix tamb pot passar en interrelacions que
no tenen atributs.
Exemple dinterrelaci ternria sense atributs
Considerem un cas en el qual desitgem saber per a cada estudiant quines assignatures
ha cursat cada semestre, tot i que no volem enregistrar la nota que nha obtingut. Llavors
aplicarem tamb una interrelaci ternria entre les entitats estudiant, assignatura i
semestre que no tindria atributs, tal com es mostra a la figura segent:
ESTUDIANT
CURSAR
SEMESTRE
ASSIGNATURA
Hem analitzat casos en qu calia usar interrelacions ternries per a poder modelitzar correctament certes situacions del mn real dinters. Cal remarcar
que, similarment, de vegades pot ser necessari utilitzar interrelacions de grau
encara ms gran: quaternries, etc.
16
FUOC P06/M2009/02150
En el subapartat segent analitzarem amb detall les interrelacions binries i, ms

endavant, les interrelacions n-ries.
2.1.3. Interrelacions binries

Connectivitat de les interrelacions binries
La connectivitat duna interrelaci expressa el tipus de correspondncia

que hi ha entre les ocurrncies dentitats associades amb la interrelaci. En
el cas de les interrelacions binries expressa el nombre docurrncies duna
de les entitats amb les quals una ocurrncia de laltra entitat pot estar associada segons la interrelaci.
Una interrelaci binria entre dues entitats pot tenir tres tipus de connectivitat:
Connectivitat un a un (1:1). La connectivitat 1:1 es denota posant un 1
a banda i banda de la interrelaci.
Connectivitat un a molts (1:N). La connectivitat 1:N es denota posant un 1

a una banda de la interrelaci i una N a laltra.
Connectivitat molts a molts (M:N). La connectivitat M:N es denota posant

una M a una de les bandes de la interrelaci i una N a laltra.
Exemples de connectivitat en una interrelaci binria
A continuaci analitzarem un exemple de cadascuna de les connectivitats possibles per
a una interrelaci binria:
a) Connectivitat 1:1
Interrelaci situaci
a nivell de classe
DELEGACI
Interrelaci situaci
D1
D2
D3
C1
C2
C3
1
SITUACI
1
CIUTAT
La interrelaci anterior t connectivitat 1:1. Aquesta interrelaci associa les delegacions

duna empresa amb les ciutats on estan situades. El fet que sigui 1:1 indica que una ciutat
t noms una delegaci i que una delegaci est situada a una nica ciutat.
Les relacions n-ries sanalitzen en el

subapartat 2.1.4 daquesta unitat.
17
FUOC P06/M2009/02150
b) Connectivitat 1:N
Interrelaci assignaci
a nivell de classe
DESPATX
D1
D2
1
GNACI
ASSI
N
EMPLEAT
E1
E2
E3
E4
E5
La interrelaci assignaci entre lentitat empleat i lentitat despatx t connectivitat 1:N, i

la N s a la banda de lentitat empleat. Aix significa que un empleat t un sol despatx assignat, per que, en canvi, un despatx pot tenir diversos empleats, s a dir, pot tenir un o ms
empleats assignats.
c) Connectivitat M:N
a nivell de classe
ESTUDIANT
E1
E2
E3
E4
M
nota
AVALUACI
7 8
N
ASSIGNATURA
A1
A2
A3
Per a analitzar la connectivitat M:N, considerem la interrelaci avaluaci de la figura anterior. Ens indica que un estudiant pot ser avaluat de diverses assignatures i, alhora, que una
assignatura pot tenir diversos estudiants per avaluar.
s molt habitual que les interrelacions binries M:N i totes les n-ries tinguin atributs. En canvi, les interrelacions binries 1:1 i 1:N no tenen perqu tenir-ne. Sempre es poden assignar aquests atributs a lentitat del costat N, en el cas de les 1:N,
i a qualsevol de les dues entitats interrelacionades en el cas de les 1:1.
Aquest canvi de lloc de latribut es pot fer perqu no origina un atribut multivaluat.
Dependncies dexistncia a les interrelacions binries
En alguns casos, una entitat individual noms pot existir si hi ha com a

mnim una altra entitat individual associada amb aquesta mitjanant
una interrelaci binria determinada. En aquests casos, es diu que la
darrera entitat s una entitat obligatria a la interrelaci. Quan aix no
succeeix,
es diu que s una entitat opcional a la interrelaci.
18
FUOC P06/M2009/02150
En el model ER, un cercle a la lnia de connexi entre una entitat i una interrelaci indica que lentitat s opcional a la interrelaci. Lobligatorietat
duna entitat a una interrelaci sindica amb una lnia perpendicular. Si no es
consig- na ni un cercle ni una lnia perpendicular, es considera que la
dependncia dexistncia s desconeguda.
Exemple de dependncies dexistncia

La figura segent ens servir per a entendre el significat prctic de la dependncia
dexistncia. Lentitat empleat s obligatria a la interrelaci direcci. Aix indica que no pot
existir un departament que no tingui un empleat que fa de director del departament.
Lentitat departament, en canvi, s opcional a la interrelaci direcci. Pot ser que hi hagi un
empleat que no est interrelacionat amb cap departament: hi pot haver i s el cas ms
freqent empleats que no sn directors de departament.
Interrelaci direcci
a nivell de classe
Interrelaci direcci
D1
DEPARTAMENT
D2
D3
1
DIRECCI
1
EMPLEAT
E1
E2
E3
E4
E5
E6
E7
Aplicarem la dependncia dexistncia a les interrelacions binries, per no a les

n-ries.
2.1.4. Exemple: base de dades de cases de colnies

En aquest punt, i abans de continuar explicant construccions ms complexes del
model ER, pot resultar molt illustratiu veure laplicaci prctica de les construccions que hem vist fins ara. Per aquest motiu, analitzarem un cas prctic de disseny amb el model ER que correspon a una base de dades destinada a la gesti
de les inscripcions dun conjunt de cases de colnies. El model ER
daquesta base de dades ser fora senzill i inclour noms entitats, atributs i
interrelacions binries (no inclour interrelacions n-ries ni altres tipus
destructures).
La descripci segent explica amb detall els aspectes dels requisits dels usuaris que
cal tenir en compte en fer el disseny conceptual de la futura base de dades:
a) Cada casa de colnies t un nom que la identifica. De cadascuna es desitja saber,
a part del nom, la capacitat (el nombre de nens que shi poden allotjar
com
a mxim), la comarca on est situada i les ofertes dactivitats que
proporciona. Una casa pot oferir activitats com ara nataci, esqu, rem, pintura,
fotografia, msica, etc.
19
FUOC P06/M2009/02150
b) Cal tenir en compte que en una casa de colnies es poden practicar diverses
activitats (de fet, cada casa nha doferir com a mnim una) i tamb pot passar
que una mateixa activitat es pugui dur a terme a diverses cases. Per tota activitat que senregistri a la base de dades ha de ser oferta com a mnim a una de les
cases.
c) Interessa tenir una avaluaci de les ofertes dactivitats que proporcionen les
cases. Sassigna una qualificaci numrica que indica el nivell de qualitat que t
cadascuna de les activitats ofertes.
d) Les cases de colnies allotgen nens que shi han inscrit per a passar-hi unes
petites vacances. Es vol tenir constncia dels nens que sallotgen a cadascuna de
les cases en el moment actual. Sha de suposar que hi ha cases que estan buides
(no shi allotja cap nen) durant algunes temporades.
e) Dels nens que sallotgen actualment en alguna de les cases interessa saber un
codi que sels assigna per a identificar-los, el nom, el cognom, el telfon dels seus
pares i la seva comarca de residncia.
f) De les comarques on hi ha cases o b on resideixen nens, es vol tenir enregistrats la superfcie i el nombre dhabitants. Sha de considerar que hi pot haver
comarques on no resideix cap dels nens que sallotgen en un moment determinat a les cases de colnies, i comarques que no disposen de cap casa.
La figura segent mostra un diagrama ER que satisf els requisits anteriors.
Els atributs de les entitats no figuren al diagrama i es llisten a part.
COMARCA
1
RESIDNCIA
1
SITUACI
N
N
NEN
CASA-COLNIES
ALLOTJAMENT
nivell
ACTIVITAT
OFERTA
Els atributs de les entitats que figuren al diagrama sn els segents (les claus
primries sn les subratllades):
CASA-COLNIES
nom-casa, capacitat
ACTIVITAT
nom-activitat
s possible,...
... per exemple, que una
activitat com ara lesqu
tingui una qualificaci de 10
a loferta de la casa Grvol
i que la mateixa activitat
tingui una qualificaci de 8
a la casa Esquirol.
20
FUOC P06/M2009/02150
NEN
codi-nen, nom, cognom, telfon
COMARCA
nom-comarca, superfcie, nombre-habitants
A continuaci comentem els aspectes ms rellevants daquest model ER:

1) Una de les dificultats que de vegades es presenta durant la modelitzaci conceptual s decidir si una informaci determinada ha de ser una entitat o un atribut. Al nostre exemple, pot resultar difcil decidir si comarca sha de modelitzar
com una entitat o com un atribut.
A primera vista podria semblar que comarca ha de ser un atribut de
lentitat casa-colnies per a indicar on est situada una casa de colnies, i tamb
un atri- but de lentitat nen per a indicar la residncia del nen. Per aquesta
soluci no seria adequada, perqu es volen tenir informacions addicionals
associades a la comarca: la superfcie i el nombre dhabitants. Cal que comarca
sigui una entitat per a poder reflectir aquestes informacions addicionals
com a atributs de lentitat.
Lentitat comarca haur destar, evidentment, interrelacionada amb les
entitats nen i casa-colnies. Observeu que aix, a ms, es fa pals que les
comarques de residncia dels nens i les comarques de situaci de les cases
sn informacions dun mateix tipus.
2) Una altra decisi que cal prendre s si el concepte activitat sha de modelitzar
com una entitat o com un atribut. Activitat no t informacions addicionals associades; no t, per tant, ms atributs que els que formen la clau. Tot i aix,
s necessari que activitat sigui una entitat a fi que, mitjanant la interrelaci
oferta,
es pugui indicar que una casa de colnies ofereix activitats.
Observeu que les activitats ofertes no es poden expressar com un atribut de casacolnies perqu una casa pot oferir moltes activitats i, en aquest cas, latribut no
podria prendre un valor nic.
3) Una altra elecci difcil, que sovint es presenta en dissenyar un model ER, s
la de si una informaci determinada sha de modelitzar com una entitat o com
una interrelaci. Per exemple, podrem haver establert que oferta, en comptes de
ser una interrelaci, fos una entitat de la manera segent:
CO
OA
OFERTA
CASA-COLNIES
1
ACTIVITAT
N
21
FUOC P06/M2009/02150
Lentitat oferta representada a la figura anterior t els atributs que presentem a

continuaci:
OFERTA
nom_casa, nom_activitat, nivell
Aquesta soluci no reflecteix del tot adequadament la realitat. Si analitzem

la clau doferta podem veure que sidentifica amb nom-casa, que s la clau de
lentitat casa-colnies, i amb nom-activitat, que s la clau de lentitat activitat.
Aix ens ha de fer sospitar que oferta, de fet, correspon a una associaci o
interrelaci entre cases i activitats. En conseqncia, reflectirem la realitat amb
ms exactitud
si modelitzem oferta com una interrelaci entre aquestes entitats.
4) Finalment, un aspecte que cal cuidar durant el disseny conceptual s el
fet devitar les redundncies. Per exemple, si hagussim interrelacionat comarca
amb activitat per a saber quines activitats es fan a les cases de cadascuna de les
comarques, haurem tingut informaci redundant. La interrelaci oferta
juntament amb la interrelaci situaci ja permeten saber, de manera indirecta,
quines activitats es fan a les comarques.
2.1.5. Interrelacions n-ries

Les interrelacions n-ries, igual que les binries, poden tenir diferents tipus
de connectivitat. En aquest subapartat, analitzarem primer el cas particular
de les interrelacions ternries i, a continuaci, tractarem de les connectivitats de
les interrelacions n-ries en general.
Connectivitat de les interrelacions ternries
Cadascuna de les tres entitats associades amb una interrelaci ternria pot
estar connectada amb connectivitat un o b amb connectivitat molts.
Segons aix, les interrelacions ternries poden tenir quatre tipus de connectivitat: M:N:P, M:N:1, N:1:1 i 1:1:1.
Analitzarem com es decideix la connectivitat adequada duna interrelaci ternria mitjanant lexemple segent. Considerem una interrelaci que anomenem
classe i que associa les entitats assignatura, aula i hora-setmanal. Aquesta interrelaci permet enregistrar classes presencials. Una classe correspon a una assignatura determinada, simparteix en una aula determinada i a una hora de la setmana
determinada. Per exemple, podem enregistrar que es fa classe de lassignatura IBD
a laula D222 els dimarts a les 9, tal com es mostra a la figura segent. Latribut
durada ens permet saber quantes hores dura la classe.
Observeu que usem M, N i P

per a representar molts
i 1 per a representar un.
22
FUOC P06/M2009/02150
Interrelaci classe
a nivell de classe
Interrelaci classe
ASSIGNATURA
IBD
dm, 9
CLASSE
HORA-SETMANAL
durada
AULA
D222
D333
Per a decidir si la banda de lentitat assignatura es connecta amb un o amb

molts, cal preguntar-se si, donades una aula i una hora-setmanal, es pot fer
classe de noms una o b de moltes assignatures en aquella aula i hora. La
resposta seria que noms es pot fer classe duna assignatura en una mateixa aula i
hora. Aix ens indica que assignatura es connecta amb un, tal com reflectim a la
figura segent:
ASSIGNATURA
1
CLASSE
HORA-SETMANAL
durada
AULA
Com ens indica aquest exemple, per a decidir com sha de connectar una de les entitats, cal preguntar-se si, fixades ocurrncies concretes de les altres dues, s possible
connectar-hi noms una o b moltes ocurrncies de la primera entitat.
Usarem el mateix procediment per a determinar com es connecten les altres dues
entitats de lexemple. Com que, fixades una assignatura i una aula, s possible
que es faci classe daquella assignatura a aquella aula a diverses hores de la setmana, aleshores hora-setmana es connecta amb molts. Finalment, lentitat aula
es connecta amb un, ats que, fixades una assignatura i hora de la
setmana, noms es pot fer una classe daquella assignatura a aquella hora. La
connectivitat resultant, doncs, s N:1:1.
ASSIGNATURA
1
durada
CLASSE
N
1
AULA
HORA-SETMANAL
23
FUOC P06/M2009/02150
Cas general: connectivitat de les interrelacions n-ries

El que hem explicat sobre la connectivitat per a les interrelacions ternries s
fcilment generalitzable a interrelacions n-ries.
Una interrelaci n-ria pot tenir n 1 1 tipus de connectivitat, ats que

cadascuna de les n entitats pot estar connectada amb un o amb molts
a la interrelaci*.
Per a decidir si una de les entitats es connecta amb un o amb molts, cal preguntar-se si, fixades ocurrncies concretes de les altres n 2 1 entitats, s possible
connectar-hi noms una o b moltes ocurrncies de la primera entitat:
Si la resposta s que noms una, lentitat es connecta amb un.
Si la resposta s que moltes, lentitat es connecta amb molts.
2.1.6. Interrelacions recursives
Una interrelaci recursiva s una interrelaci a la qual alguna entitat est

associada ms duna vegada.
Exemple dinterrelaci recursiva

Si, duna entitat persona, volem tenir constncia de quines persones estan actualment casades
entre elles, caldr definir la interrelaci segent, que associa dues vegades lentitat persona:
1
PERSONA
CASAMENT
1
Una interrelaci recursiva pot ser tant binria com n-ria:

1) Interrelaci recursiva binria: interrelaci on les ocurrncies associen dues
instncies de la mateixa entitat*. Les interrelacions binries recursives
poden tenir connectivitat 1:1, 1:N o M:N, com totes les binries. Tamb shi pot
expressar la dependncia dexistncia igual que a la resta dinterrelacions
binries.
Exemple dinterrelaci recursiva binria
La interrelaci casament t connectivitat 1:1 perqu un marit est casat amb una sola muller
i una muller est casada amb un sol marit. Tamb t un cercle a les dues bandes (segons la
dependncia dexistncia) perqu hi pot haver persones que no estiguin casades.
* Recordeu que per

a les interrelacions ternries
hi ha quatre tipus de
connectivitat possibles.
* Aquest s el cas de la interrelaci

casament anterior.
24
FUOC P06/M2009/02150
En una interrelaci recursiva, pot interessar distingir els diferents papers que una
mateixa entitat t a la interrelaci. Amb aquest objectiu, es pot etiquetar
cada lnia de la interrelaci amb un rol. A les interrelacions no recursives
normalment no sespecifica el rol perqu, com que totes les entitats
interrelacionades sn de classes diferents, les seves diferncies de rol se
sobreentenen.
Rols diferents
Una ocurrncia de la interrelaci casament associa dues persones concretes. Per a reflectir el
paper diferent que t cadascuna delles a la interrelaci, una de les persones tindr el rol de
marit i laltra tindr el rol de muller.
marit
1
PERSONA
CASAMENT
1
muller
Algunes interrelacions recursives no presenten diferenciaci de rols; llavors les

lnies de la interrelaci no setiqueten.
No-diferncia de rols
Considerem una interrelaci amistat que associa persones concretes que sn amigues. A
diferncia del que passava a la interrelaci casament, on una de les persones s el marit i laltra
la muller, en aquest cas no hi ha diferenciaci de rols entre les dues persones
interrelacionades. A continuaci es mostra aquesta interrelaci. Observeu que la seva
connectivitat s M:N, ats que una persona pot tenir molts amics i, alhora, hi pot haver
moltes persones que la tenen per amiga.
N
PERSONA
AMISTAT
M
2) Interrelaci recursiva n-ria: interrelaci recursiva on les ocurrncies associen ms de dues instncies.
Exemple dinterrelaci recursiva ternria
Considerem una interrelaci que enregistra tots els casaments que shan produt en un conjunt de persones determinat al llarg del temps. Aquesta interrelaci permet tenir constncia
no tan sols dels casaments vigents, sin de tots els casaments que shan produt en un cert
perode de temps.
marit
1
PERSONA
1
muller
N
CASAMENT
DATA
25
FUOC P06/M2009/02150
Aquesta interrelaci s recursiva i ternria. Una ocurrncia de la interrelaci associa una persona que s el marit, una altra persona que s la muller i la data del seu casament. La connectivitat s N:1:1. A les bandes del marit i de la muller els correspon un 1 perqu un marit
o una muller, en una data determinada, es casa amb una sola persona. A la banda de lentitat data, li correspon una N perqu es podria donar el cas que hi hagus ms dun casament,
en dates diferents, entre les mateixes persones.
2.1.7. Entitats dbils

Les entitats que hem considerat fins ara tenen un conjunt datributs que
formen
les
seves
claus
primries
que
permeten
identificar-les
completament. Aquestes entitats sanomenen, de manera ms especfica,

entitats fortes. En aquest subapartat considerarem un altre tipus dentitats
que anomenarem entitats dbils.
Una entitat dbil s una entitat els atributs de la qual no la identifiquen

completament, sin que noms la identifiquen de manera parcial. Aquesta entitat ha de participar en una interrelaci que ajuda a identificar-la.
Una entitat dbil es representa amb un rectangle doble i la interrelaci que ajuda
a identificar-la es representa amb una doble ratlla.
Exemple dentitat dbil
Considerem les entitats edifici i despatx de la figura segent. Suposem que hi pot haver despatxos amb el mateix nmero a edificis diferents. Aleshores, el seu nmero no
identifica completament un despatx. Per a identificar completament un despatx, cal tenir
en compte en quin edifici est situat. De fet, podem identificar un despatx mitjanant la
interrelaci situaci, que lassocia a un nic edifici. El nom de ledifici on est situat
juntament amb el nmero de despatx lidentifiquen completament.
Interrelaci situaci
a nivell de classe
EDIFICI
Interrelaci situaci
nom
adrea
Sants
Sarri
1
SITUACI
N
DESPATX
nmero
superfcie
101
102
105
102
202
A lexemple anterior, la interrelaci situaci ens ha perms completar la identificaci dels despatxos. Per a tota entitat dbil, sempre hi ha dhaver una
nica interrelaci que en permeti completar la identificaci. Aquesta interrelaci
ha de ser binria amb connectivitat 1:N i lentitat dbil ha de ser al costat N.
Aix, una
FUOC P06/M2009/02150
26
ocurrncia de lentitat dbil est associada amb una nica ocurrncia de lentitat
del costat 1 i ser possible completar-ne la identificaci de manera nica. A ms,
lentitat del costat 1 ha de ser obligatria a la interrelaci perqu, si no fos aix,
alguna ocurrncia de lentitat dbil podria no estar interrelacionada amb cap de
les seves ocurrncies i no es podria identificar completament.
2.2. Extensions del model ER

En aquest subapartat estudiarem algunes construccions avanades que estenen el
model ER estudiat fins ara.
2.2.1. Generalitzaci/especialitzaci
En alguns casos, hi ha ocurrncies duna entitat que tenen caracterstiques prpies especfiques que ens interessa modelitzar. Per exemple, pot passar que dels
empleats duna empresa que sn directius es vulgui tenir constncia de
quin cotxe de lempresa tenen assignat; que dels empleats tcnics interessi
tenir una interrelaci amb una entitat projecte que indiqui en quins projectes
treballen i es vulgui conixer la seva titulaci, i, finalment, que dels empleats
administratius convingui enregistrar lantiguitat. Hi haur, per, algunes
caracterstiques comunes a tots els empleats: tots sidentifiquen per un DNI,
tenen un nom, un cognom, una adrea i un telfon.
La generalitzaci/especialitzaci permet reflectir el fet que hi ha

una entitat general, que anomenem entitat superclasse, que es pot
especialitzar en entitats subclasse:
a) Lentitat superclasse ens permet modelitzar les caracterstiques comunes de lentitat vista a un nivell genric.
b) Les entitats subclasse ens permeten modelitzar les caracterstiques
prpies de les seves especialitzacions.
Cal que es compleixi que tota ocurrncia duna entitat subclasse sigui
tamb una ocurrncia de la seva entitat superclasse.
Denotem la generalitzaci/especialitzaci amb una fletxa que surt de les entitats

subclasse i que es dirigeix a lentitat superclasse.
Exemple dentitats superclasse i subclasse
En la figura de la pgina segent hi ha representades lentitat superclasse, que correspon a
lempleat de lexemple anterior, i les entitats subclasse, que corresponen al directiu, al tcnic i a ladministratiu del mateix exemple.
27
FUOC P06/M2009/02150
EMPLEAT
DIRECTIU
cotxe
TCNIC
dni
nom
cognom
adrea
telfon
ttol
ADMINISTRATIU
antiguitat
M
TREBALLA
N
PROJECTE
En la generalitzaci/especialitzaci les caracterstiques (atributs o interrelacions)

de lentitat superclasse es propaguen cap a les entitats subclasse. s el que sanomena herncia de propietats.
En el disseny duna generalitzaci/especialitzaci es pot seguir un dels dos processos segents:
1) Pot passar que el dissenyador primerament identifiqui la necessitat de lentitat superclasse i, posteriorment, reconegui les caracterstiques especfiques
que fan necessries les entitats subclasse. En aquests casos es diu que ha
seguit un procs despecialitzaci.
2) Lalternativa s que el dissenyador modelitzi en primer lloc les entitats subclasse i, desprs, sadoni de les seves caracterstiques comunes i identifiqui lentitat superclasse. Llavors es diu que ha seguit un procs de generalitzaci.
La generalitzaci/especialitzaci pot ser de dues maneres:
a) Disjunta. En aquest cas no pot passar que una mateixa ocurrncia aparegui a
dues entitats subclasse diferents. Es denota grficament amb letiqueta D.
b) Encavalcada. En aquest cas no hi ha la restricci anterior. Es denota grficament amb letiqueta S.
A ms, la generalitzaci/especialitzaci tamb es pot classificar de la manera
segent:
1) Total. En aquest cas tota ocurrncia de lentitat superclasse ha de pertnyer a
alguna de les entitats subclasse. Es denota amb letiqueta T.
2) Parcial. En aquest cas no cal que aix passi. Es denota amb letiqueta P.
El nostre exemple
dels empleats...
... correspon a una
generalitzaci/especialitzaci
disjunta perqu cap empleat
no pot ser de ms dun tipus.
Es denota amb letiqueta D.
28
FUOC P06/M2009/02150
La generalitzaci/especialitzaci dels empleats

La generalitzaci/especialitzaci dels empleats s total perqu suposem que tot empleat ha
de ser directiu o tcnic o administratiu. Es denota amb letiqueta T.
EMPLEAT
D, T
DIRECTIU
TCNIC
ADMINISTRATIU
2.2.2. Entitats associatives

En aquest subapartat veurem un mecanisme que ens permet considerar una interrelaci entre entitats com si fos una entitat.
Lentitat resultant de considerar una interrelaci entre entitats com si fos

una entitat s una entitat associativa, i tindr el mateix nom que la interrelaci sobre la qual es defineix.
La utilitat duna entitat associativa s que es pot interrelacionar amb altres entitats
i, de manera indirecta, ens permet tenir interrelacions en qu
intervenen interrelacions. Una entitat associativa es denota requadrant el rombe

de la interrelaci de la qual prov.
Exemple dentitat associativa
La figura segent mostra un exemple dentitat associativa:
CIUTAT
M
REPARTIMENT
M
RECORREGUT
N
paq-car
CLIENT
paq-desc
VIATGE
Recorregut s una interrelaci de connectivitat M:N que enregistra les ciutats per on han passat els diferents viatges organitzats per una empresa de repartiment de paquets. Considerem
recorregut una entitat associativa per tal de poder-la interrelacionar amb lentitat client i
reflectir per ordre de quins clients shan fet repartiments en una ciutat del recorregut dun
viatge, i el nombre de paquets carregats i descarregats per indicaci daquell client.
El mecanisme de les entitats associatives subsumeix el de les entitats dbils

i resulta encara ms potent. s a dir, sempre que usem una entitat dbil
podrem substituir-la per una entitat associativa, per no a linrevs.
29
FUOC P06/M2009/02150
Exemple de substituci duna entitat dbil per una dassociativa

A continuaci es mostra lentitat dbil despatx, que t la interrelaci assignaci amb lentitat
empleat.
A nivell de classe
EDIFICI
EMPLEAT
1
SITUACI
ASSIGNACI
DESPATX
A nivell docurrncies
Sants
Sarri
E1
101
102
102
E2
E3
E4
202
Podrem modelitzar aquest cas fent que despatx fos una entitat associativa si considerem una
nova entitat nmero-despatx que cont simplement nmeros de despatxos. Aleshores lentitat associativa despatx sobt de la interrelaci entre edifici i nmero-despatx.
A nivell de classe
EDIFICI
M
1
DESPATX
EMPLEAT
ASSIGNACI
N
NMERO-DESPATX
A nivell docurrncies
Sants
101
Sarri
102
202
E1
E2
E3
E4
FUOC P06/M2009/02150
30
Encara que les entitats dbils es puguin substituir pel mecanisme de les entitats
associatives, s adequat mantenir-les al model ER perqu resulten menys
complexes i sn suficients per a modelitzar moltes de les situacions que es
produei- xen al mn real.
2.3. Exemple: base de dades del personal

duna entitat bancria
En aquest subapartat veurem un exemple de disseny conceptual duna base de
dades mitjanant el model ER.
Es tracta de dissenyar una base de dades per a la gesti del personal duna entitat bancria determinada que disposa de molts empleats i duna mplia
xarxa dagncies. La descripci segent resumeix els requisits dels usuaris de la
futura base de dades:
a) Els empleats sidentifiquen per un codi dempleat, i tamb desitgem conixer el
seu DNI, el seu NSS, el seu nom i el seu cognom. Ser important enregistrar la seva
ciutat de residncia, considerant que hi ha ciutats on no resideix cap empleat.
b) Interessa saber a quines ciutats estan ubicades les diverses agncies de lentitat bancria. Aquestes agncies bancries sidentifiquen per la ciutat on sn i per
un nom que permet distingir les agncies duna mateixa ciutat. Es vol tenir constncia del nombre dhabitants de les ciutats, i de ladrea i el telfon de les agncies. Sha de considerar que la base de dades tamb inclou ciutats on no
hi ha cap agncia.
c) Un empleat, en un moment determinat, treballa en una sola agncia, la qual
cosa no impedeix que pugui ser traslladat a una altra o, fins i tot, tornar a treballar en una agncia on ja havia treballat anteriorment. Es vol tenir constncia de
lhistorial del pas dels empleats per les agncies.
d) Els empleats poden tenir ttols acadmics (encara que no tots en tenen).
Es vol saber quins ttols tenen els empleats.
e) Cada empleat t una categoria laboral determinada (auxiliar, oficial de
segona, oficial de primera...). A cada categoria li correspon un sou base determinat i un preu de lhora extra determinat. Es vol tenir constncia de la categoria actual de cada empleat, i del sou base i el preu de lhora extra de
cada categoria.
f) Alguns empleats (no tots) estan afiliats a alguna central sindical. Sha arribat
al pacte de descomptar de la nmina mensual la quota sindical als afiliats a cada
central. Aquesta quota s nica per a tots els afiliats a una central determinada.
s necessari emmagatzemar les afiliacions a una central dels empleats i les quotes corresponents a les diferents centrals sindicals.
31
FUOC P06/M2009/02150
g) Hi ha dos tipus dempleats diferents:

Els que tenen contracte fix, dels quals volem conixer lantiguitat.
Els que tenen contracte temporal, dels quals ens interessa saber les dates dinici i finalitzaci del seu darrer contracte.
Si un empleat temporal passa a ser fix, se li assigna un nou codi dempleat; considerarem que un empleat fix mai no passa a ser temporal. Tot el que sha
indicat fins
ara
(trasllats,
titulacions,
categories,
afiliaci
sindical...)
aplicable tant a empleats fixos com a temporals.

h) Els empleats fixos tenen la possibilitat de demanar diferents tipus
preesta- blerts de prstecs (per matrimoni, per adquisici dhabitatge, per
estudis, etc.), que poden ser concedits o no. En principi, no hi ha cap
limitaci a demanar diversos prstecs alhora, sempre que no es demani ms
dun prstec del mateix tipus al mateix temps. Es vol enregistrar els prstecs
demanats pels empleats, i fer constar si han estat concedits o no. Cada tipus de
prstec t establertes diferents condicions, de les quals, en particular, ens
interessar saber el tipus dinters i el perode de vigncia del prstec.
La figura segent mostra un diagrama ER que satisf els requisits anteriors:
Personal duna entitat bancria

TIPUS-PRSTEC
DATA
PETICI
concedit/no
TEMPORAL
TRASLLAT
FIX
data-fi
D,T
AGNCIA
AFILIACI
1
N
SITUACI
EMPLEAT
N
N
1
TITULACI
CAT-EMP
CIUTAT
CENTRAL-SINDICAL
1
TTOL
CATEGORIA
RESIDNCIA
FUOC P06/M2009/02150
32
Els atributs de les entitats que figuren al diagrama sn els segents (les claus
primries shan subratllat):
EMPLEAT
codi-empleat, dni, nss, nom, cognom
FIX (entitat subclasse dempleat)
codi-empleat, antiguitat
TEMPORAL (entitat subclasse dempleat)
codi-empleat, data-inici-cont, data-final-cont
CIUTAT
nom-ciutat, nombre-hab
AGNCIA (entitat dbil: nom-agncia la identifica parcialment,
sidentifica completament amb la ciutat de situaci)
nom-agncia, adrea, telfon
TTOL
nom-ttol
CATEGORIA
nom-categ, sou-base, hora-extra
CENTRAL-SINDICAL
central, quota
TIPUS-PRSTEC
codi-prstec, tipus-inters, perode-vigncia
DATA
data
A continuaci, comentarem els aspectes que poden resultar ms complexos daquest model ER:
1) Lentitat agncia sha considerat una entitat dbil perqu el seu atribut nomagncia noms permet distingir les agncies situades en una mateixa ciutat, per
per a identificar de manera total una agncia, cal saber a quina ciutat est situada. Aix, la interrelaci situaci s la que ens permet completar la identificaci de
lentitat agncia.
2) La interrelaci petici s ternria i associa empleats fixos que fan peticions de
prstecs, tipus de prstec demanats pels empleats i dates en qu es fan aquestes
peticions.
3) El costat de lentitat data es connecta amb molts perqu un mateix empleat pot demanar un mateix tipus de prstec diverses vegades en dates diferents.
Lentitat fix es connecta amb molts perqu un tipus de prstec determinat pot
ser demanat en una mateixa data per diversos empleats. Tamb lentitat
tipus- prstec es connecta amb molts perqu s possible que un empleat en
una data determinada demani ms dun prstec de tipus diferent.
FUOC P06/M2009/02150
33
4) Latribut concedit/no indica si el prstec sha concedit o no. s un atribut de la

interrelaci perqu el seu valor depn alhora de lempleat fix que fa la petici,
del tipus de prstec demanat i de la data de la petici.
5) La interrelaci trasllat tamb s una interrelaci ternria que permet enregistrar el pas dels empleats per les diverses agncies. Un trasllat concret associa un
empleat, una agncia on lempleat treballa i una data que indica la data inicial
en qu lempleat comena a treballar a lagncia. Latribut de la interrelaci datafi indica en quina data lempleat finalitza la seva assignaci a lagncia (data-fi
tindr el valor nul quan un empleat treballa en una agncia en el moment actual
i no se sap quan sel traslladar). Observeu que data-fi ha de ser un atribut de la
interrelaci. Si es colloqus a una de les tres entitats interrelacionades, no podria
ser un atribut univaluat.
Conv observar que aquesta interrelaci no enregistra totes i cadascuna de les
dates en qu un empleat est assignat a una agncia, sin noms la data inicial i
la data final de lassignaci. s molt habitual que, per a informacions que
sn certes durant tot un perode de temps, senregistri a la base de dades
nicament linici i el final del perode.
Fixeu-vos que lentitat agncia sha connectat amb un a la interrelaci trasllat
perqu no pot passar que, en una data, un empleat determinat sigui traslladat a
ms duna agncia.
6) Finalment, comentarem la generalitzaci/especialitzaci de lentitat empleat.
Els empleats poden ser de dos tipus; es volen enregistrar propietats diferents per
a cadascun dels tipus i tamb es requereixen algunes propietats comunes a tots
els empleats. Per aquest motiu, s adequat fer servir una generalitzaci/especialitzaci.
FUOC P06/M2009/02150
34
3. Disseny lgic: la transformaci del model ER

al model relacional
En aquest apartat tractarem del disseny lgic duna base de dades relacional. Partirem del resultat de letapa del disseny conceptual expressat mitjanant el
model ER i veurem com es pot transformar en una estructura de dades del model
relacional.
3.1. Introducci a la transformaci dentitats i interrelacions
Els elements bsics del model ER sn les entitats i les interrelacions:

a) Les entitats, quan es tradueixen al model relacional, originen relacions.
b) Les interrelacions, en canvi, quan es transformen, poden donar lloc a
claus foranes dalguna relaci ja obtinguda o poden donar lloc a
una nova relaci.
En el cas de les interrelacions, cal tenir en compte el seu grau i la seva connectivitat per a poder decidir quina s la transformaci adequada:
1) Les interrelacions binries 1:1 i 1:N donen lloc a claus foranes.
2) Les interrelacions binries M:N i totes les n-ries es tradueixen en noves relacions.
Als subapartats segents explicarem de manera ms concreta les transformacions
necessries per a obtenir un esquema relacional a partir dun model ER.
Ms endavant proporcionem una taula que resumeix els aspectes ms
importants de cadascuna de les transformacions per tal de donar-ne una
visi global. Final- ment, descrivim la seva aplicaci en un exemple.
3.2. Transformaci dentitats
Comenarem el procs transformant totes les entitats dun model

ER adequadament. Cada entitat del model ER es transforma en una
relaci del model relacional. Els atributs de lentitat seran atributs
de la relaci i, anlogament, la clau primria de lentitat ser la clau
primria de
la relaci.
Trobareu la taula resum de les

transformacions al subapartat 3.10
daquesta unitat; al subapartat 3.11 en
veurem lexemple daplicaci.
35
FUOC P06/M2009/02150
Exemple de transformaci duna entitat

Segons aix, lentitat de la figura del marge es transforma en la relaci que tenim a continuaci:
EMPLEAT
EMPLEAT(DNI, NSS, nom, cognom, sou)
dni
nss
nom
cognom
sou
Un cop transformades totes les entitats en relacions, cal transformar totes

les interrelacions en qu aquestes entitats intervenen.
Si una entitat interv en alguna interrelaci binria 1:1 o 1:N, pot ser necessari
afegir nous atributs a la relaci obtinguda a partir de lentitat. Aquests atributs
formaran claus foranes de la relaci.
3.3. Transformaci dinterrelacions binries

Per a transformar una interrelaci binria cal tenir en compte la seva connectivitat, i si les entitats sn obligatries o opcionals a la interrelaci.
3.3.1. Connectivitat 1:1
El punt de partida s que les entitats que intervenen en la interrelaci 1:1

ja shan transformat en relacions amb els seus corresponents atributs.
Aleshores noms caldr afegir a qualsevol daquestes dues relacions una
clau forana que referenci laltra relaci.
Exemple de transformaci duna interrelaci binria 1:1
Interrelaci situaci
a nivell de classe
DELEGACI
Interrelaci situaci
D1
D2
D3
C1
C2
C3
1
SITUACI
1
CIUTAT
Veurem les transformacions de les

interrelacions binries al subapartat
segent.
36
FUOC P06/M2009/02150
Per a la interrelaci de la figura anterior, tenim dues opcions de transformaci:

Primera opci:
DELEGACI(nom-del, ..., nom-ciutat)

on {nom-ciutat} referencia CIUTAT
CIUTAT(nom-ciutat, ...)
Segona opci:
DELEGACI(nom-del, ...)
CIUTAT(nom-ciutat, ..., nom-del)
on {nom-del} referencia DELEGACI
Totes dues transformacions ens permeten saber a quina ciutat hi ha una delegaci i quina
delegaci t una ciutat. Aix, doncs, reflecteixen correctament el significat de la interrelaci
situaci del model ER.
A la primera transformaci, com que una delegaci est situada en una nica ciutat, latribut nom-ciutat t un nic valor per a cada valor de la clau primria {nom-del}. Observeu que,
si pogus tenir diversos valors, la soluci no seria correcta segons la teoria relacional.
A la segona transformaci, ats que una ciutat t una sola delegaci, latribut nom-del tamb
pren un sol valor per a cada valor de la clau primria {nom-ciutat}.
Tamb cal tenir en compte que, en totes dues transformacions, la clau forana que shi afegeix es converteix en una clau alternativa de la relaci perqu no admet valors repetits. Per
exemple, a la segona transformaci, no hi pot haver ms duna ciutat amb la mateixa delegaci i, aix, nom-del ha de ser diferent per a totes les tuples de CIUTAT.
3.3.2. Connectivitat 1:N
Partim del fet que les entitats que intervenen en la interrelaci 1:N
ja shan transformat en relacions amb els seus corresponents atributs.
En aquest cas noms cal afegir a la relaci corresponent a lentitat del
costat
N una clau forana que referenci laltra relaci.
Exemple de transformaci duna interrelaci binria 1:N
a nivell de classe
DESPATX
D1
D2
1
GNACI
ASSI
N
EMPLEAT
E1
E2
E3
E4
E5
37
FUOC P06/M2009/02150
La interrelaci de la figura anterior es transforma en:
DESPATX(desp, ...)
EMPLEAT(emp, ..., desp)
on {desp} referencia DESPATX
Aquesta soluci ens permet saber a quin despatx est assignat cada empleat i tamb ens permet consultar, per a cada despatx, quins empleats hi ha. s a dir, que reflecteix correctament
el significat de la interrelaci assignaci.
Ats que un empleat est assignat a un nic despatx, latribut desp t un valor nic per a cada
valor de la clau primria {emp}. Si hagussim posat la clau forana {emp} a la relaci DESPATX,
la soluci hauria estat incorrecta, perqu emp hauria pres diversos valors, un per a cadascun
dels diversos empleats que poden estar assignats a un despatx.
3.3.3. Connectivitat M:N
Una interrelaci M:N es transforma en una relaci. La seva clau primria estar formada pels atributs de la clau primria de les dues
entitats interrelacionades. Els atributs de la interrelaci seran atributs de
la nova relaci.
Exemple de transformaci duna interrelaci binria M:N
a nivell de classe
ESTUDIANT
E1
E2
E3
E4
M
nota
AVALUACI
7 8
N
ASSIGNATURA
A1
A2
A3
La interrelaci de la figura anterior es transforma en:
ESTUDIANT(est, ...)
ASSIGNATURA(assig, ...)
AVALUACI(est, assig , nota)
on {est} referencia ESTUDIANT
i {assig} referencia ASSIGNATURA
Observeu que la clau davaluaci ha de constar tant de la clau destudiant com de la clau dassignatura per a identificar completament la relaci.
La soluci que hem presentat reflecteix correctament la interrelaci avaluaci i el seu atribut
nota. Permet saber, per a cada estudiant, quines notes t de les diverses assignatures i, per a
cada assignatura, quines notes tenen els diferents estudiants daquella assignatura.
38
FUOC P06/M2009/02150
En el cas M:N no es poden utilitzar claus foranes per a transformar la interrelaci perqu obtindrem atributs que poden prendre diversos valors, i aix no es
permet al model relacional.
3.3.4. Influncia de la dependncia dexistncia en la transformaci

de les interrelacions binries
La dependncia dexistncia o, ms concretament, el fet que alguna de les entitats sigui opcional en una interrelaci sha de tenir en compte en fer la transformaci dalgunes interrelacions binries 1:1 i 1:N.
Si una de les entitats s opcional a la interrelaci, i la transformaci

ha consistit a posar una clau forana a la relaci que correspon a laltra
entitat, aleshores aquella clau forana pot prendre valors nuls.
Exemple de transformaci duna entitat opcional a la interrelaci

A lexemple segent, lentitat departament s opcional a direcci i, per tant, hi pot haver
empleats que no siguin directors de cap departament:
Interrelaci direcci
a nivell de classe
Interrelaci direcci a nivell

docurrncies
D1
DEPARTAMENT
D2
D3
1
DIRECCI
1
EMPLEAT
E1
E2
E3
E4
E5
E6
E7
En principi, hi ha dues opcions de transformaci:

Primera opci:
DEPARTAMENT(dept, ..., emp-cap)
on {emp-cap} referencia EMPLEAT
EMPLEAT(emp, ...)
Segona opci:
DEPARTAMENT(dept, ...)
EMPLEAT(emp, ..., dept)
on {dept} referencia DEPARTAMENT
i dept pot prendre valors nuls
La segona transformaci dna lloc a una clau forana que pot prendre valors nuls (perqu hi
pot haver empleats que no sn directors de cap departament). Aleshores ser preferible la
primera transformaci perqu no provoca laparici de valors nuls a la clau forana i, aix,
ens estalvia espai demmagatzematge.
39
FUOC P06/M2009/02150
A les interrelacions 1:N, el fet que lentitat del costat 1 sigui opcional tamb provoca que la clau forana de la transformaci tingui valors nuls. En aquest
cas, per, no es poden evitar aquests valors nuls perqu hi ha una nica
transformaci possible.
3.4. Transformaci dinterrelacions ternries

La
transformaci
de
les
interrelacions
ternries
presenta
similituds
importants amb la transformaci de les binries M:N. No s possible

representar la interrelaci mitjanant claus foranes, sin que cal usar una nova
relaci. Perqu la nova relaci reflecteixi tota la informaci que la interrelaci
modelitza, cal que con- tingui les claus primries de les tres entitats
interrelacionades i els atributs de la interrelaci.
Aix, doncs, la transformaci duna interrelaci ternria sempre dna lloc a

una nova relaci, la qual tindr com a atributs les claus primries de les tres
entitats interrelacionades i tots els atributs que tingui la interrelaci. La clau
primria de la nova relaci depn de la connectivitat de la interrelaci.
A continuaci analitzarem quina ha de ser la clau primria de la nova relaci segons

la connectivitat. Comenarem pel cas M:N:P i acabarem amb el cas 1:1:1.
3.4.1. Connectivitat M:N:P
Quan la connectivitat de la interrelaci s M:N:P, la relaci que sobt de

la seva transformaci t com a clau primria tots els atributs que formen
les claus primries de les tres entitats interrelacionades.
Exemple de transformaci duna interrelaci ternria M:N:P

Nanalitzarem la transformaci amb un exemple:
ESTUDIANT
M
AVALUACISEMESTRAL
nota
P
ASSIGNATURA
SEMESTRE
40
FUOC P06/M2009/02150
La interrelaci anterior es transforma en:
ESTUDIANT(est, ...)
SEMESTRE(sem, ...)
AVALUACI-SEMESTRAL(est, assig, sem, nota)
on {est} referencia ESTUDIANT,
{assig} referencia ASSIGNATURA
i {sem} referencia SEMESTRE
Per a identificar completament la relaci, la clau ha de constar de la clau destudiant, de la

clau dassignatura i de la clau de semestre. Si en falts una de totes tres, la clau de la relaci
podria tenir valors repetits. Considerem, per exemple, que no hi hagus la clau de semestre.
Com que semestre est connectada amb molts a la interrelaci, hi pot haver estudiants que
han estat avaluats duna mateixa assignatura en ms dun semestre. Llavors, per a aquests
casos hi hauria valors repetits a la clau de la relaci AVALUACI-SEMESTRAL.
Observeu que, de la mateixa manera que s necessria la clau de semestre, tamb ho sn la
destudiant i la dassignatura.
3.4.2. Connectivitat M:N:1
Quan la connectivitat de la interrelaci s M:N:1, la relaci que sobt de

la seva transformaci t com a clau primria tots els atributs que formen
les claus primries de les dues entitats dels costats de la interrelaci
eti- quetats amb M i amb N.
Exemple de transformaci duna interrelaci ternria M:N:1

Ho illustrarem amb un exemple:
MESTRE
M
N
DESTINACI
CURS
ESCOLA
Aquesta interrelaci reflecteix les destinacions que es donen als mestres descola en els diferents cursos. L1 que figura a la banda descola significa que un mestre no pot ser destinat a
ms duna escola en un mateix curs.
Lexemple de la figura es transforma en:
MESTRE(codi-mestre, ...)
CURS(codi-curs, ...)
ESCOLA(codi-esc, ...)
41
FUOC P06/M2009/02150
DESTINACI(codi-mestre, codi-curs , codi-esc)

on {codi-mestre} referencia MESTRE,
{codi-curs} referencia CURS
i {codi-esc} referencia ESCOLA
No cal que la clau inclogui codi-esc per a identificar completament la relaci. Si es fixen un
mestre i un curs, no hi pot haver ms duna escola de destinaci i, per tant, no hi haur claus
repetides.
3.4.3. Connectivitat N:1:1
Quan la connectivitat de la interrelaci s N:1:1, la relaci que sobt de la

seva transformaci t com a clau primria els atributs que formen la clau
primria de lentitat del costat N i els atributs que formen la clau primria
de qualsevol de les dues entitats que estan connectades amb 1.
Aix, doncs, hi ha dues possibles claus per a la relaci que sobt. Sn dues claus
candidates entre les quals el dissenyador haur descollir la clau primria.
Exemple de transformaci duna interrelaci ternria N:1:1
Vegem-ne un exemple:
ASSIGNATURA
1
CLASSE
durada
HORA-SETMANAL
AULA
1) Una possible transformaci s la segent:
HORA-SETMANAL(codi-hora, ...)
AULA(codi-aula, ...)
CLASSE (codi-hora, codi-aula , assig, durada)
on {codi-hora} referencia HORA-SETMANAL,
{codi-aula} referencia AULA
En aquest cas, tot i que la clau no inclou latribut assig, identifica completament la relaci
perqu per a una hora-setmanal i aula determinades hi ha una nica assignatura de la qual
es fa classe a aquella hora i aula.
42
FUOC P06/M2009/02150
2) La segona transformaci possible s aquesta altra:
HORA-SETMANAL(codi-hora, ...)
AULA(codi-aula, ...)
CLASSE (codi-hora, assig, codi-aula, durada)
on {codi-hora} referencia HORA-SETMANAL,
{codi-aula} referencia AULA
Ara la clau inclou latribut assig i, en canvi, no inclou latribut codi-aula. La relaci queda
tamb completament identificada perqu, per a una assignatura i hora-setmanal
determinades, es fa classe a una nica aula daquella assignatura a aquella hora.
3.4.4. Connectivitat 1:1:1
Quan la connectivitat de la interrelaci s 1:1:1, la relaci que sobt de la

seva transformaci t com a clau primria els atributs que formen la clau
primria de dues entitats qualssevol de les tres interrelacionades.
Aix, doncs, hi ha tres claus candidates per a la relaci.

Exemple de transformaci duna interrelaci ternria 1:1:1
Vegem-ne un exemple:
TRIBUNAL
1
1
DEFENSA
data-defensa
PROJECTE FI
DE CARRERA
ESTUDIANT
Aquesta interrelaci enregistra informaci de lectures de defenses de projectes de fi de carrera.

Hi interv lestudiant que presenta el projecte, el projecte presentat i el tribunal avaluador.
La transformaci de lexemple anterior es mostra tot seguit:
TRIBUNAL(trib, ...)
ESTUDIANT(est, ...)
PROJECTE_FI_CARRERA(pro, ...)
Per a la nova relaci DEFENSA tenim les tres possibilitats segents:

Primera opci:
DEFENSA(trib, est , pro, datadefensa)

on {trib} referencia TRIBUNAL,
43
FUOC P06/M2009/02150
{est} referencia ESTUDIANT,

{pro} referencia PROJECTEFICARRERA
Segona opci:
DEFENSA(trib, pro, est, datadefensa)

on {trib} referencia TRIBUNAL,
{est} referencia ESTUDIANT,
{pro} referencia PROJECTEFICARRERA
Tercera opci:
DEFENSA(est, pro, trib, datadefensa)

on {est} referencia ESTUDIANT,
{pro} referencia PROJECTEFICARRERA,
{trib} referencia TRIBUNAL
En tots tres casos, s possible comprovar que la clau identifica completament la relaci si es t
en compte la connectivitat de la interrelaci defensa.
3.5. Transformaci dinterrelacions n-ries

La transformaci de les interrelacions n-ries es pot veure com una generalitzaci del que hem explicat per a les ternries.
En tots els casos, la transformaci duna interrelaci n-ria consistir en

lobtenci duna nova relaci que cont tots els atributs que formen les
claus primries de les n entitats interrelacionades i tots els atributs de la
interrelaci.
Podem distingir els casos segents:

a) Si totes les entitats estan connectades amb molts, la clau primria de
la nova relaci estar formada per tots els atributs que formen les claus de
les n entitats interrelacionades.
b) Si una o ms entitats estan connectades amb un, la clau primria de la nova
relaci estar formada per les claus de n 2 1 de les entitats interrelacionades, amb
la condici que lentitat, la clau de la qual no shi ha incls, ha de ser una de les
que est connectada amb un.
3.6. Transformaci dinterrelacions recursives

Les transformacions de les interrelacions recursives sn similars a les que
hem vist per a la resta dinterrelacions.
44
FUOC P06/M2009/02150
Aix, doncs, si una interrelaci recursiva t connectivitat 1:1 o 1:N, dna

lloc a una clau forana i, si t connectivitat M:N o s n-ria, origina
una nova relaci.
Mostrarem la transformaci dalguns exemples concrets dinterrelacions recursives per a illustrar els detalls de lafirmaci anterior.
Exemple de transformaci duna interrelaci recursiva binria 1:1
marit
1
PERSONA
CASAMENT
1
muller
La interrelaci de la figura anterior s recursiva, binria i t connectivitat 1:1. Les interrelacions 1:1 originen una clau forana que es posa a la relaci corresponent a una de les entitats interrelacionades. Al nostre exemple, noms hi ha una entitat interrelacionada, lentitat
persona. Aleshores, la clau forana haur destar a la relaci PERSONA. Aquesta clau
forana haur de referenciar la mateixa relaci perqu reflecteix una interrelaci entre una
ocurrncia de persona i una altra ocurrncia de persona. Aix, obtindrem:
PERSONA(codi-per, ..., codi-conjuge)

on {codi-conjuge} referencia PERSONA
i codi-conjuge admet valors nuls
La clau forana {codi-cnjuge} referencia la relaci PERSONA a la qual pertany.

Conv tenir en compte que, en casos com aquest, els atributs de la clau forana no poden
tenir els mateixos noms que els atributs de la clau primria que referencien perqu, segons
la teoria relacional, una relaci no pot tenir noms datributs repetits.
Exemple de transformaci duna interrelaci recursiva M:N

Vegem a continuaci un exemple en qu interv una interrelaci recursiva i amb
connectivitat M:N.
N
PERSONA
AMISTAT
M
Les interrelacions M:N es tradueixen en noves relacions que tenen com a clau primria les
claus de les entitats interrelacionades.
Al nostre exemple, la interrelaci lliga ocurrncies de persona amb altres ocurrncies de persona.
En aquest cas, la clau primria de la nova relaci estar formada per la clau de
lentitat persona dues vegades. Convindr donar noms diferents a tots els atributs de la
nova relaci. Aix, la traducci de lexemple anterior ser:
45
FUOC P06/M2009/02150
PERSONA(codi-per, ...)
AMISTAT (codi-per, codi-per-amiga)
on {codi-per} referencia PERSONA
i {codi-per-amiga} referencia PERSONA
Exemple de transformaci duna interrelaci recursiva n-ria N:1:1

Finalment, analitzarem un exemple en qu la interrelaci recursiva s n-ria:
marit
1
N
PERSONA
DATA
CASAMENT
1
muller
La interrelaci casament anterior s recursiva, ternria i t connectivitat N:1:1. Les interrelacions N:1:1 originen sempre una nova relaci que cont, a ms dels atributs de
la interrelaci, tots els atributs que formen la clau primria de les tres entitats
interrelacionades.
Al nostre exemple, la interrelaci associa ocurrncies de persona amb altres ocurrncies de
persona i amb ocurrncies de data. Aleshores, la clau de persona haur de figurar dues vegades a la nova relaci, i la clau de data, noms una.
La clau primria de la relaci que sobt per a interrelacions N:1:1 est formada per la clau
de lentitat del costat N i per la clau duna de les entitats dels costats 1.
Al nostre exemple, a tots dos costats 1 de la interrelaci tenim la mateixa entitat: persona. La
clau primria estar formada per la clau de lentitat data i per la clau de lentitat persona.
Segons tot aix, la transformaci ser la segent:
PERSONA(codi-per, ...)
DATA(data-cas, ...)
CASAMENT(data-cas, codi-per, codi-conjuge)
on {data-cas} referencia DATA,
{codi-per} referencia PERSONA
i {codi-conjuge} referencia PERSONA
3.7. Transformaci dentitats dbils
Les entitats dbils es tradueixen al model relacional igual que la resta dentitats, amb una petita diferncia. Aquestes entitats sempre estan al costat
N duna interrelaci 1:N que completa la seva identificaci.
Aix, doncs, la clau forana originada per aquesta interrelaci 1:N ha
de formar part de la clau primria de la relaci corresponent a
lentitat dbil.
46
FUOC P06/M2009/02150
Exemple de transformaci dentitat dbil

Ho explicarem amb un exemple:
EDIFICI
nom
adrea
1
SITUACI
N
DESPATX
numero
superficie
Aquest exemple es transforma tal com es mostra tot seguit:
EDIFICI(nom, adrea)
DESPATX(nom, numero , superficie)
on {nom} referencia EDIFICI
Observeu que la clau forana {nom} forma part tamb de la clau primria de DESPATX. Si no
fos aix, i la clau primria contingus noms latribut nmero, els despatxos no
quedarien totalment identificats, ats que hi pot haver despatxos situats en edificis
diferents que tinguin el mateix nmero.
3.8. Transformaci de la generalitzaci/especialitzaci
Cadascuna de les entitats superclasse i subclasse que formen part duna

generalitzaci/especialitzaci es transforma en una relaci:
a) La relaci de lentitat superclasse t com a clau primria la clau de lentitat superclasse i cont tots els atributs comuns.
b) Les relacions de les entitats subclasse tenen com a clau primria la clau
de lentitat superclasse i contenen els atributs especfics de la subclasse.
Exemple de transformaci de la generalitzaci/especialitzaci

Vegem-ne un exemple (vegeu el grfic a la pgina segent) que cont una generalitzaci/especialitzaci i, tamb, una interrelaci M:N en qu interv una de les entitats subclasse. Aquest exemple es tradueix al model relacional com sindica tot seguit:
EMPLEAT(DNI, nom, adrea, telefon)
DIRECTIU(DNI, cotxe)
on {DNI} referencia EMPLEAT
ADMINISTRATIU (DNI, antiguitat)
TECNIC (DNI, titol)
PROJECTE(pro, ...)
TREBALLAR(DNI, pro , superficie)
on {DNI} referencia TECNIC
i {pro} referencia PROJECTE
47
FUOC P06/M2009/02150
EMPLEAT
DIRECTIU
cotxe
TCNIC
dni
nom
cognom
adrea
telefon
titol
ADMINISTRATIU
antiguitat
M
TREBALLA
N
PROJECTE
Conv observar que els atributs comuns shan situat a la relaci EMPLEAT i que els atributs
especfics shan situat a la relaci de la seva entitat subclasse. Aix, cotxe s a DIRECTIU, ttol
a TCNIC i antiguitat a ADMINISTRATIU.
Daltra banda, la interrelaci especfica per als empleats tcnics anomenada treballa es transforma en la relaci TREBALLA. Observeu que aquesta relaci t una clau forana que
referencia noms els empleats tcnics, i no els empleats directius o administratius.
3.9. Transformaci dentitats associatives
Una entitat associativa t el seu origen en una interrelaci. En

conseqncia, succeeix que la transformaci de la interrelaci originria s,
alhora, la transformaci de lentitat associativa.
Exemple de transformaci duna entitat associativa

Vegem-ne un exemple que inclou una entitat associativa interrelacionada amb una altra
entitat:
CIUTAT
M
REPARTIMENT
M
RECORREGUT
N
paq-car
VIATGE
La transformaci de lexemple anterior ser:
CIUTAT(nom-ciutat, ...)
VIATGE(id-viatge, ...)
N
paq-desc
CLIENT
48
FUOC P06/M2009/02150
RECORREGUT(nom-ciutat, id-viatge )
i {id-viatge} referencia VIATGE
CLIENT (codi-client, ...)
REPARTIMENT(nom-ciutat, id-viatge, codi-client , paq-car, paq-desc)
on {nom-ciutat, id-viatge} referencia RECORREGUT
i {codi-client} referencia CLIENT
Tal com es pot veure, la traducci de la interrelaci recorregut s, alhora, la traducci de la

seva entitat associativa.
La relaci REPARTIMENT ens illustra la transformaci duna interrelaci en qu participa una
entitat associativa. Com que es tracta duna interrelaci M:N entre recorregut i ciutat, una part
de la clau primria de REPARTIMENT referencia la clau de RECORREGUT, i la resta, la clau
de CIUTAT.
3.10. Resum de la transformaci del model ER

al model relacional
La taula que mostrem a continuaci resumeix els aspectes ms bsics de les transformacions que hem descrit a les seccions anteriors amb lobjectiu de donar-ne
una visi rpida:
Element del model ER
Transformaci al model relacional
Entitat
Relaci
Interrelaci 1:1
Clau forana
Interrelaci 1:N
Clau forana
Interrelaci M:N
Relaci
Interrelaci n-ria
Relaci
Interrelaci recursiva
Com a les interrelacions no recursives:

Clau forana per a binries 1:1 i 1:N
Relaci per a binries M:N i n-ries
Entitat dbil
La clau forana de la interrelaci identificadora forma part

de la clau primria
Generalitzaci/especialitzaci
Relaci per a lentitat superclasse

Relaci per a cadascuna de les entitats subclasse
Entitat associativa
La transformaci de la interrelaci que lorigina s alhora

la seva transformaci
3.11. Exemple: base de dades del personal duna entitat bancria

En aquest apartat aplicarem les transformacions que hem explicat en el cas prctic de la base de dades del personal duna entitat bancria. Abans hem presentat
el disseny conceptual daquesta base de dades. A continuaci, en veurem la
transformaci al model relacional.
Comenarem per transformar totes les entitats en relacions i totes les interrelacions 1:1 i 1:N en claus foranes daquestes relacions.
Hem fet el disseny conceptual

de la base de dades del personal de
lentitat bancria al subapartat 2.3
daquesta unitat.
FUOC P06/M2009/02150
49
EMPLEAT(codi-empleat, DNI, NSS, nom, cognom, nom-categ, central, ciutat-res)

on {nom-categ} referencia CATEGORIA,
{central} referencia CENTRAL-SINDICAL,
latribut central admet valors nuls
i {ciutat-res} referencia CIUTAT
FIX(codi-empleat, antiguitat)
on {codi-empleat} referencia EMPLEAT
TEMPORAL(codi-empleat, data-inici-cont, data-final-cont)
CIUTAT(nom-ciutat, nombre-hab)
AGNCIA(nom-ciutat, nom-agencia, adrea, telefon)
TTOL(nom-titol)
CATEGORIA(nom-categ, sou-base, hora-extra)
CENTRAL-SINDICAL(central, quota)
TIPUS-PRSTEC(codi-prestec, tipus-interes, periode-vigencia)
DATA(data)
Observeu que, a la transformaci de la generalitzaci/especialitzaci corresponent a lentitat empleat, hem situat els atributs comuns a la relaci EMPLEAT i els
atributs especfics a les relacions FIX i TEMPORAL.
A la relaci AGNCIA, latribut nom-ciutat s una clau forana i alhora forma part
de la clau primria perqu agncia s una entitat dbil que requereix la interrelaci situaci per a ser identificada.
Vegem ara les relacions que sobtenen a partir de la transformaci de les interrelacions binries i n-ries:
TITULACI(codi-empleat, nom-titol )
i {nom-ttol} referencia TTOL
TRASLLAT(codi-empleat, data , nom-ciutat, nom-agencia, data-fi)
on {codi-empleat} referencia EMPLEAT,
{nom-ciutat, nom-agncia} referencia AGNCIA
i {data} referencia DATA
PETICI(codi-empleat, codi-prestec, data , concedit/no)
on {codi-empleat} referencia FIX,
{codi-prstec} referencia TIPUS-PRSTEC
Per a escollir les claus primries adequades per a aquestes relacions sha hagut de
tenir en compte la seva connectivitat.
FUOC P06/M2009/02150
50
Resum
Aquesta unitat s una introducci a un tema de gran inters: el disseny de bases

de dades.
Primerament, hem explicat qu sentn per dissenyar una base de dades i hem analitzat les etapes en qu es pot descompondre el procs de disseny:
Etapa del disseny conceptual.
Etapa del disseny lgic.
Etapa del disseny fsic.
A la resta de la unitat hem tractat del disseny conceptual i del disseny lgic de
bases de dades. No hem estudiat el disseny fsic perqu requereix uns coneixements previs destructures dimplementaci fsica que fan inadequat explicar-lo
en aquest curs.
Per al disseny conceptual hem adoptat lenfocament del model ER, un model de
dades molt utilitzat i entenedor. Hem descrit les diverses construccions que proporciona i hem donat exemples daplicaci a casos prctics.
Pel que fa al disseny lgic, lhem centrat en el cas dutilitzaci de la tecnologia relacional. Aix, hem explicat com es pot transformar un model
conceptual expressat mitjanant el model ER en una estructura de dades
del model relacional.
FUOC P06/M2009/02150
51
Exercicis dautoavaluaci
1. Feu un disseny conceptual duna base de dades mitjanant el model ER que satisfaci els requisits que es resumeixen a continuaci:
a) Un directiu dun club de futbol vol disposar duna base de dades que li permeti
controlar dades que li interessen sobre competicions, clubs, jugadors, entrenadors... dmbit
estatal.
b) Els clubs cada temporada disputen diverses competicions (lliga, copa...) entre si. El nostre
directiu desitja informaci histrica de les classificacions obtingudes pels clubs en les
diferents competicions al llarg de totes les temporades. La classificaci sespecificar
mitjanant un nmero de posici: 1 significa campi, 2 significa subcampi, etc.
c) Els diversos clubs estan agrupats en les federacions regionals corresponents. Tota federaci t
com a mnim un club. De les federacions vol conixer el nom i la data de creaci, i dels clubs,
el nom i el nombre de socis.
d) s molt important la informaci sobre jugadors i entrenadors. Sidentificaran per un codi, i
vol saber el nom, ladrea, el telfon i la data de naixement de tots. Cal esmentar que alguns
entrenadors poden haver estat jugadors en la seva joventut. Dels jugadors, a ms, en vol saber
el pes, lalada, lespecialitat o les especialitats i quin domini en tenen (grau despecialitat). Tot
jugador ha de tenir com a mnim una especialitat, per hi pot haver especialitats en les quals
no hi hagi cap jugador. Dels entrenadors li interessa la data en qu van iniciar la seva carrera
com a entrenadors de futbol.
e) De totes les persones que figuren a la base de dades (jugadors i entrenadors), en vol conixer
lhistorial de contractacions per part dels diversos clubs, incloent-hi limport i la data de baixa
de cada contractaci. En un moment determinat, una persona pot estar contractada per un nic
club, per pot canviar de club posteriorment i, fins i tot, pot tornar a un club en el qual ja havia
treballat.
f) Tamb vol enregistrar les ofertes que les persones que figuren a la base de dades han rebut dels
clubs durant la seva vida esportiva (i de les quals sha pogut assabentar). Considera important
tenir constncia de limport de les ofertes. Sha de tenir en compte que en un moment determinat una persona pot rebre moltes ofertes sempre que vinguin de clubs diferents.
a) Es vol dissenyar una base de dades per a facilitar la gesti duna empresa dedicada al transport internacional de mercaderies que opera a tot lmbit europeu.
b) Lempresa disposa de diverses delegacions repartides per tota la geografia europea. Les delegacions sidentifiquen per un nom, i es vol enregistrar tamb el seu telfon. En una determinada ciutat no hi ha mai ms duna delegaci. Es desitja conixer la ciutat on est
situada cada delegaci. Sha de suposar que no hi ha ciutats amb el nom repetit (almenys en
lmbit daquesta base de dades).
c) El personal de lempresa es pot separar en dos grans grups:
Administratius, dels quals interessa saber quin nivell destudis tenen.
Conductors, dels quals interessa saber lany que van obtenir el carnet de conduir i el tipus de
carnet que tenen.
De tot el personal de lempresa es vol conixer el codi dempleat (que lidentifica), el nom, el
telfon i lany de naixement. Tots els empleats estan assignats a una delegaci determinada. Es
vol tenir constncia histrica daquest fet tenint en compte que poden anar canviant de delegaci (fins i tot poden tornar a una delegaci on ja havien estat anteriorment).
d) Lactivitat de lempresa consisteix a efectuar els viatges pertinents per tal de transportar les
mercaderies segons les peticions dels seus clients. Tots els clients sidentifiquen per un codi de
client. Sen vol conixer, a ms, el nom i el telfon de contacte.
e) Lempresa, per a dur a terme la seva activitat, disposa de molts camions identificats per un
codi de cami. Es vol tenir constncia de la matrcula, la marca i la tara dels camions.
f) Els viatges els organitza sempre una delegaci i sidentifiquen per un codi de viatge, que s
intern de cada delegaci (i que es pot repetir en delegacions diferents). Per a cadascun
dels viatges que shan fet, cal saber:
Quin cami sha utilitzat (ja que cada viatge es fa amb un nic cami).
FUOC P06/M2009/02150
52
Quin (o quins) conductors hi han anat (considerant que en viatges llargs hi poden anar diversos conductors). Es vol saber tamb limport de les dietes pagades a cada conductor (ats que
les dietes poden ser diferents per als diferents conductors dun mateix viatge).
El recorregut del viatge, s a dir, la data i lhora en qu el cami arriba a cadascuna de les ciutats on haur de carregar o descarregar. Suposarem que un viatge no passa mai dues vegades
per una mateixa ciutat.
El nombre de paquets carregats i paquets descarregats en cada ciutat, i per a cadascun
dels clients. En un mateix viatge es poden deixar i/o recollir paquets a diferents ciutats per
encrrec dun mateix client. Tamb, en un mateix viatge, es poden deixar i/o recollir
paquets en una mateixa ciutat per encrrec de diferents clients.
a) Cal dissenyar una base de dades per a una empresa immobiliria amb lobjectiu de gestionar la
informaci relativa a la seva cartera de pisos en venda.
b) Cadascun dels pisos que tenen pendents de vendre t assignat un codi de pis que lidentifica. A ms daquest codi, es vol conixer ladrea del pis, la superfcie, el nombre dhabitacions i
el preu. Tenen aquests pisos classificats per zones (perqu als seus clients de vegades noms els
interessen els pisos duna zona determinada) i es vol saber a quina zona est situat cada pis. Les
zones tenen un nom de zona que s diferent per a cada zona duna mateixa poblaci, per que
pot coincidir en zones de poblacions diferents. De vegades es dna el cas que en alguna de les
zones no hi tenen cap pis pendent de vendre.
c) De les poblacions es vol tenir el nombre dhabitants. De les zones es vol saber quines
sn limtrofes (perqu, en cas de no disposar de pisos en una zona que desitja un client, se li
puguin oferir els que es tinguin en altres zones limtrofes amb la primera). Cal considerar
que hi pot haver zones sense cap altra zona limtrofa en algunes poblacions petites que
consten duna sola zona.
d) Dels pisos tenen codificades diverses caracterstiques, com ara tenir ascensor, ser
exterior, tenir terrassa, etc. Cada caracterstica sidentifica per un codi i t una descripci.
Per a cada caracterstica i pis es vol saber si el pis satisf aquella caracterstica o no. A
ms, volen tenir constncia del propietari o propietaris de cada pis.
e) Tamb necessiten disposar dinformaci relativa als seus clients actuals que busquen pis (si
dues o ms persones busquen pis conjuntament noms es guarda informaci duna delles com
a client de lempresa). En particular, interessa saber les zones on busca pis cada client (noms
en cas que tingui alguna zona de preferncia).
f) A cadascun daquests clients li assignen un venedor de lempresa perqu socupi datendrel.
De vegades, aquestes assignacions varien amb el temps i es canvia el venedor assignat a
un determinat client. Tamb s possible que a un client se li torni a assignar un venedor
que ja havia tingut anteriorment. Es vol tenir constncia de les assignacions dels clients
actuals de lempresa.
g) Els venedors, clients i propietaris sidentifiquen per un codi de persona. De tots ells es
vol enregistrar el nom, ladrea i el telfon. A ms, dels venedors es vol tenir el nmero de
Segure- tat Social i el sou, i dels propietaris, el NIF. Hi pot haver persones que siguin alhora
clients i propietaris, o b venedors i propietaris, etc.
h) Finalment, per a ajudar a programar i consultar les visites que els clients fan als pisos
en venda, es vol guardar informaci de totes les visites corresponents als clients i als pisos
actuals de lempresa. De cada visita cal saber el client que la fa, el pis que es va a veure i lhora
concreta en qu sinicia la visita. Entenem que lhora de la visita s formada per la data, lhora del dia
i el minut del dia (per exemple, 25-FEB-98, 18:30). Cal considerar que un mateix client pot visitar un mateix pis diverses vegades per a assegurar-se de si li agrada o no, i tamb que, per tal devitar conflictes, no es programen mai visites de clients diferents a un mateix pis i a la mateixa
hora.
4. Transformeu a relacional el disseny conceptual que heu obtingut a lexercici 1.
53
FUOC P06/M2009/02150
Solucionari
Exercicis dautoavaluaci
1. La figura segent mostra un diagrama ER que satisf els requisits que shan descrit:
COMPETICI
M
num-posicio
FEDERACI
CLASSIFICACI
TEMPORADA
PERTINENA
CLUB
1
import-cont
data-baixa
DATA
OFERTA
CONTRACTE
import-oferta
N
PERSONA
S,T
JUGADOR
ENTRENADOR
M
grau
HABILITAT
ESPECIALITAT
Els atributs de les entitats que figuren al diagrama sn els segents (les claus primries shan
subratllat):
COMPETICI
nom-comp
TEMPORADA
codi-temp
FEDERACI
nom-fed, data-creacio
CLUB
nom-club, nombre-socis
PERSONA
codi-persona, nom, adrea, telefon, data-naixement
JUGADOR (entitat subclasse de persona)
codi-persona, pes, alada
ENTRENADOR (entitat subclasse de persona)
54
FUOC P06/M2009/02150
codi-persona, data-inici-carrera
ESPECIALITAT
nom-esp
DATA
data
CIUTAT
1
CLIENT
M
paquet-desc
paquet-car
REPARTIMENT
SITUACI
M
RECORREGUT
data
hora
DELEGACI
N
1
ORGANITZACI
ASSIGNACI
N
data-fi
M
import-dietes
UTILITZACI
CONDUCCI
CAMI
EMPLEAT
D,T
CONDUCTOR
ADMINISTRATIU
subratllat):
CIUTAT
nom-ciutat
DELEGACI
nom-del, telefon
EMPLEAT
codi-empleat, nom, telefon, any-naixement
CONDUCTOR (subclasse dempleat)
codi-empleat, any-carnet, tipus-carnet
ADMINISTRATIU (subclasse dempleat)
codi-empleat, nivell-estudis
DATA
data
VIATGE (entitat debil: codi-viatge lidentifica parcialment, sidentifica
completament amb la delegacio dorganitzacio)
codi-viatge
CAMI
codi-camio, matricula, marca, tara
CLIENT
codi-client, nom, telefon-contacte
DATA
55
FUOC P06/M2009/02150
PERSONA
S,T
ASSIGNACI
N
CLIENT
VENEDOR
PROPIETARI
data-fi
M
DATA
M
1
1
PROPIETAT
PERTINENA
N
PREFERNCIA
HORA
PIS
VISITA
M
N
1
ZONA
LIMTROFA
M
SATISFACCI
SITUACI
satisf/no
N
LOCALITZACI
1
POBLACI
subratllat):
POBLACI
nom-pobl, nombre-hab
ZONA (entitat dbil: nom-zona lidentifica parcialment, sidentifica
completament amb la poblaci de localitzaci)
nom-zona
PIS
codi-pis, adrea, superfcie, nombre-habitacions, preu
CARACTERSTICA
codi-car, descripci
PERSONA
codi-persona, nom, adrea, telfon
VENEDOR (entitat subclasse de persona)
codi-persona, nss, sou
CLIENT (entitat subclasse de persona)
codi-persona
PROPIETARI (entitat subclasse de persona)
codi-persona, nif
CARACTERSTICA
FUOC P06/M2009/02150
56
DATA
data
HORA (entitat dbil: hora-minut lidentifica parcialment, sidentifica
completament amb la data de pertinena)
hora-minut
4. El resultat de la transformaci a relacional del model ER proposat com a soluci de lexercici

1 consta de les relacions segents:
COMPETICI(nom-comp)
TEMPORADA(codi-temp)
FEDERACI(nom-fed, data-creaci)
CLUB(nom-club, nombre-socis, nom-fed)
on {nom-fed} referencia FEDERACI
PERSONA(codi-persona, nom, adrea, telfon, data-naixement)
JUGADOR(codi-persona, pes, alada)
on {codi-persona} referencia PERSONA
ENTRENADOR(codi-persona, data-inici-carrera)
ESPECIALITAT(nom-esp)
DATA(data)
HABILITAT(codi-persona, nom-esp , grau)
on {codi-persona} referencia JUGADOR
i {nom-esp} referencia ESPECIALITAT
CLASSIFICACI(nom-comp, codi-temp, nom-club, num-posici)
on {nom-comp} referencia COMPETICI,
{codi-temp} referencia TEMPORADA
i {nom-club} referencia CLUB
CONTRACTE(codi-persona, data , nom-club, import-cont, data-baixa)
on {codi-persona} referencia PERSONA,
{data} referencia DATA
OFERTA(codi-persona, data, nom-club, import-oferta)
on {codi-persona} referencia PERSONA,

CIUTAT(nom-ciutat)
DELEGACI(nom-del, telfon, nom-ciutat)
EMPLEAT(codi-empleat, nom, telfon, any-naixement)
CONDUCTOR(codi-empleat, any-carnet, tipus-carnet)
ADMINISTRATIU(codi-empleat, nivell-estudis)
DATA(data)
VIATGE(nom-del, codi-viatge , codi-cami)
on {nom-del} referencia DELEGACI
i {codi-cami} referencia CAMI
CAMI(codi-cami, matrcula, marca, tara)
CLIENT(codi-client, nom, telfon-contacte)
ASSIGNACI(codi-empleat, data , nom-del, data-fi)
on {codi-empleat} referencia EMPLEAT,
{nom-del} referencia DELEGACI
CONDUCCI(codi-empleat, nom-del, codi-viatge , import-dietes)
on {codi-empleat} referencia CONDUCTOR
i {nom-del, codi-viatge} referencia VIATGE
RECORREGUT(nom-ciutat, nom-del, codi-viatge , data, hora)
i {nom-del, codi-viatge} referencia VIATGE
REPARTIMENT(nom-ciutat, nom-del, codi-viatge, codi-client , paquetscar, paquets-desc)
on {nom-ciutat, nom-del, codi-viatge} referencia RECORREGUT
i {codi-client} referencia CLIENT
57
FUOC P06/M2009/02150

POBLACI(nom-pobl, nombre-hab)
ZONA(nom-pobl, nom-zona)
on {nom-pobl} referencia POBLACI
PIS(codi-pis, adrea, superfcie, nombre-habitacions, preu, nom-pobl, nom-zona)
on {nom-pobl, nom-zona} referencia ZONA
CARACTERSTICA(codi-car, descripci)
PERSONA(codi-persona, nom, adrea, telfon)
VENEDOR(codi-persona, nss, sou)
CLIENT(codi-persona)
PROPIETARI(codi-persona, nif)
DATA(data)
HORA(data, hora-minut )
on {data} referencia DATA
ASSIGNACI(codi-client, data , codi-venedor, data-fi)
on {codi-client} referencia CLIENT,
i {codi-venedor} referencia VENEDOR
PREFERNCIA(codi-persona, nom-pobl, nom-zona )
on {codi-persona} referencia CLIENT
i {nom-pobl, nom-zona} referencia ZONA
SATISFACCI(codi-pis, codi-car , satisf/no)
on {codi-pis} referencia PIS
i {codi-car} referencia CARACTERSTICA
LIMTROFA(nom-pobl, nom-zona, nom-pobl-lim, nom-zona-lim )
on {nom-pobl, nom-zona} referencia ZONA
i {nom-pobl-lim, nom-zona-lim} referencia ZONA
PROPIETAT(codi-pis, codi-persona )
on {codi-pis} referencia PIS
i {codi-persona} referencia PROPIETARI
Per a la interrelaci visita, hi ha dues transformacions possibles:

1)
VISITA(data, hora-minut, codi-pis , codi-persona)
on {data, hora-minut} referencia HORA,
{codi-persona} referencia CLIENT
i {codi-pis} referencia PIS
2)
VISITA(data, hora-minut, codi-persona , codi-pis)
on {data, hora-minut} referencia HORA,
{codi-persona} referencia CLIENT
i {codi-pis} referencia PIS
Glossari
atribut duna entitat
Propietat que interessa duna entitat.
atribut duna interrelaci
Propietat que interessa duna interrelaci.
connectivitat duna interrelaci
Expressi del tipus de correspondncia entre les ocurrncies dentitats associades amb la interrelaci.
disseny conceptual
Etapa del disseny duna base de dades que obt una estructura de la informaci de la futura BD
independent de la tecnologia que es vol emprar.
FUOC P06/M2009/02150
58
disseny fsic
Etapa del disseny duna base de dades que transforma lestructura obtinguda a letapa del disseny lgic amb lobjectiu daconseguir una major eficincia i que, a ms, la completa amb aspectes dimplementaci fsica que dependran de lSGBD que sha dutilitzar.
disseny lgic
Etapa del disseny duna base de dades que parteix del resultat del disseny conceptual i el transforma de manera que sadapti al model de lSGBD amb el qual es desitja implementar la base de
dades.
entitat
Objecte del mn real que podem distingir de la resta dobjectes i del qual ens interessen algunes propietats.
entitat associativa
Entitat resultant de considerar una interrelaci entre entitats com una nova entitat.
entitat dbil
Entitat els atributs de la qual no la identifiquen completament, sin que noms la identifiquen
de manera parcial.
entitat obligatria en una interrelaci binria
Entitat tal que una ocurrncia de laltra entitat que interv en la interrelaci noms pot existir
si es dna com a mnim una ocurrncia de lentitat obligatria a que hi est associada.
entitat opcional en una interrelaci binria
Entitat tal que una ocurrncia de laltra entitat que interv en la interrelaci pot existir encara que
no hi hagi cap ocurrncia de lentitat opcional a que hi est associada.
generalitzaci/especialitzaci
Construcci que permet reflectir que existeix una entitat general, que anomenem entitat superclasse, que es pot especialitzar en entitats subclasse. Lentitat superclasse ens permet modelitzar
les caracterstiques comunes de lentitat vista a un nivell genric, i amb les entitats
subclasse podem modelitzar les caracterstiques prpies de les seves especialitzacions.
grau duna interrelaci
Nombre dentitats que associa la interrelaci.
interrelaci
Associaci entre entitats.
interrelaci recursiva
Interrelaci a la qual alguna entitat est associada ms duna vegada.
Bibliografia
Batini, C.; Ceri, S.; Navathe, S.B. (1992). Conceptual Database Design: An Entity-Relationship
Approach. Reading, Massachusetts: Addison Wesley.
Teorey, T.J. (1999). Database Modeling & Design. The Fundamental Principles (3a ed.). San Francisco: Morgan Kaufmann Publishers, Inc.

Disseny de Bases (Catalán)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Disseny de Bases (Catalán)

Uploaded by

Copyright:

Available Formats

Disseny de bases

Disseny de bases de dades

1. Introducci al disseny de bases de dades ......................................

1.1. Etapes del disseny de bases de dades................................................

2. Disseny conceptual: el model ER .....................................................

2.1. Construccions bsiques ....................................................................

2.1.1. Entitats, atributs i interrelacions ............................................

2.1.2. Grau de les interrelacions.......................................................

2.1.3. Interrelacions binries ............................................................

2.1.4. Exemple: base de dades de cases de colnies.........................

2.1.5. Interrelacions n-ries ..............................................................

2.1.6. Interrelacions recursives .........................................................

2.1.7. Entitats dbils .........................................................................

2.2. Extensions del model ER ..................................................................

2.2.1. Generalitzaci/especialitzaci ................................................

2.2.2. Entitats associatives ................................................................

2.3. Exemple: base de dades del personal duna entitat

3. Disseny lgic: la transformaci del model ER

3.1. Introducci a la transformaci dentitats i interrelacions ...............

3.2. Transformaci dentitats ...................................................................

3.3. Transformaci dinterrelacions binries ...........................................

3.3.1. Connectivitat 1:1 ....................................................................

3.3.2. Connectivitat 1:N ...................................................................

3.3.3. Connectivitat M:N..................................................................

3.3.4. Influncia de la dependncia dexistncia

3.4. Transformaci dinterrelacions ternries ..........................................

3.4.1. Connectivitat M:N:P...............................................................

3.4.2. Connectivitat M:N:1...............................................................

3.4.3. Connectivitat N:1:1 ................................................................

3.4.4. Connectivitat 1:1:1 .................................................................

3.5. Transformaci dinterrelacions n-ries .............................................

3.6. Transformaci dinterrelacions recursives ........................................

3.7. Transformaci dentitats dbils ........................................................

3.8. Transformaci de la generalitzaci/especialitzaci ..........................

3.9. Transformaci dentitats associatives ...............................................

Disseny de bases de dades

3.10. Resum de la transformaci del model ER al model relacional ......

Disseny de bases de dades

Disseny de bases de dades

Disseny de bases de dades

1. Introducci al disseny de bases de dades

Si recordeu els tres mons presentats el real, el conceptual i el de les

1.1. Etapes del disseny de bases de dades

Recordeu que les bases de dades

Disseny de bases de dades

Descompondrem el disseny de bases de dades en tres etapes:

El resultat del disseny

nos de preocupar alhora de resoldre qestions tecnolgiques.

La manera delaborar un disseny

(entity-relationship), que abreviarem amb la sigla ER.

El resultat del disseny

atributs, claus primries i claus foranes.

El disseny lgic duna base de dades

El resultat del disseny fsic

Disseny de bases de dades

Disseny de bases de dades

2. Disseny conceptual: el model ER

En aquest apartat tractarem del disseny conceptual duna base de dades

entenedora. s una eina til tant per a ajudar el dissenyador a reflectir en un

* La sigla CASE correspon

relation- ships). Traduirem aquest nom per entitat-interrelaci.

Alguns autors anomenen

Recordeu el model relacional, que sha

Disseny de bases de dades