El pas del model Entitat-Relació al model relacional és el pont entre el disseny conceptual (el diagrama ER que hem creat per entendre el problema) i la implementació física (les taules SQL que crearem al SGBD). Es tracta d'un procés sistemàtic: cada element del diagrama ER es transforma seguint unes regles concretes.
La notació segueix la convenció de Chen: els rectangles representen entitats, i els atributs s'escriuen en el·lipses connectades al rectangle via línies. L'atribut identificador (clau primària) apareix subratllat.
Com navegar els diagrames animats
Cada regla té un diagrama interactiu. Fes clic a Següent → per veure cada pas de la transformació, o als punts de navegació per saltar directament a un pas. Pots tornar enrere amb ← Anterior.
Pas previ: Transformació d'atributs especials
Abans de transformar entitats i relacions, cal saber com es tracten els atributs que no són simples.
Atributs especials: compostos, derivats i multivaluats
Punt de partida. L'entitat PERSONA té quatre tipus d'atributs: simple (id_persona), compost (nom_complet), derivat (edat, en línia discontínua) i multivaluat (telefon, doble el·lipse).
Model E/R
id_persona
PERSONA
nom_complet
edat
telefon
Regles de transformació. (1) L'atribut compost es descompon en atributs simples. (2) L'atribut derivat s'omet o es guarda la dada base. (3) L'atribut multivaluat genera una taula nova amb FK cap a l'entitat original.
Model E/R
id_persona
PERSONA
nom_complet
edat
telefon
→transforma
Model Relacional
PERSONA
PK id_persona
nom
cognoms
data_naix
Resultat final. El multivaluat telefon genera la taula TELEFON_PERSONA. La seva PK és composta per (id_persona, telefon) per garantir unicitat.
Model Relacional
PERSONA
PK id_persona
nom
cognoms
data_naix
TELEFON_PERSONA
PK+FK id_persona*
PK telefon
Regla 1: Entitats fortes
Cada entitat forta es transforma directament en una taula. Els atributs es converteixen en columnes i l'atribut identificador (subratllat) es converteix en la clau primària.
Regla 1: Entitats fortes → taules
Punt de partida. L'entitat CINE té tres atributs: codi_cine (identificador, subratllat), nom i adreca.
Model E/R
codi_cine
CINE
nom
adreca
La transformació. El nom de l'entitat → nom de la taula. Cada atribut → una columna. L'atribut identificador (subratllat al diagrama) → clau primària (PK).
Model E/R
codi_cine
CINE
nom
adreca
→transforma
Model Relacional
CINE
PK codi_cine
nom
adreca
Resultat final. La taula CINE amb la seva clau primària declarada. La notació textual subratlla l'atribut identificador.
Model Relacional
CINE
PK codi_cine
nom
adreca
CINE(codi_cine, nom, adreca)
Regla 2: Entitats dèbils
Una entitat dèbil no pot identificar-se per si mateixa: necessita la clau de l'entitat forta de la qual depèn. La clau primària resultant és composta: clau parcial + PK de l'entitat forta.
Regla 2: Entitats dèbils → PK composta amb FK
L'entitat forta. CINE és una entitat forta amb codi_cine com a identificador únic.
Model E/R
codi_cine
CINE
nom
L'entitat dèbil. SALA és dèbil (doble rectangle): el seu num_sala (subratllat puntejat = clau parcial) no és únic per si sol — la sala 3 pot existir a múltiples cinemes. La relació identificadora es representa amb doble diamant.
Model E/R
codi_cine
CINE
nom
(1,1)
té
(1,N)
num_sala
SALA
aforament
La PK de CINE migra a SALA. La clau primària de l'entitat forta (codi_cine) s'incorpora com a FK a SALA i forma part de la seva PK composta juntament amb la clau parcial (num_sala).
Model E/R
codi_cine
CINE
→
num_sala
SALA
+ codi_cine*
→transforma
Model Relacional
SALA
PK+FK codi_cine*
PK num_sala
aforament
Resultat final. Dues taules: CINE amb PK simple, i SALA amb PK composta (codi_cine, num_sala) on codi_cine és alhora FK cap a CINE.
Model Relacional
CINE
PK codi_cine
nom
adreca
SALA
PK+FK codi_cine*
PK num_sala
aforament
SALA(codi_cine*, num_sala, aforament)
Regla 3: Relacions 1:N
La clau primària de l'entitat del costat 1 migra com a clau forana (FK) a la taula del costat N. Si la cardinalitat mínima del costat N és 1, la FK ha de ser NOT NULL.
Regla 3: Relacions 1:N → FK al costat N
Punt de partida. Un CLIENT pot fer zero o moltes COMANDES, però cada COMANDA pertany obligatòriament a un CLIENT. Cardinalitats: Card(CLIENT, realitza) = (1,1) i Card(COMANDA, realitza) = (0,N).
Model E/R
id_client
CLIENT
nom
email
(1,1)
realitza
(0,N)
id_comanda
COMANDA
data
total
Identificar els costats. El costat 1 és CLIENT (max=1). El costat N és COMANDA (max=N). La FK sempre va al costat N.
Model E/R — identificant els costats
id_client
CLIENT
costat 1
realitza
costat N
id_comanda
COMANDA
La PK del costat 1 migra al costat N.id_client (PK de CLIENT) s'afegeix com a FK a COMANDA. Com que Card(COMANDA, realitza) = (0,N), min=0 → la FK pot ser NULL.
Model E/R
id_client
CLIENT
→
id_comanda
COMANDA
+ id_client*
→transforma
Model Relacional
COMANDA
PK id_comanda
FK id_client*
data
total
Resultat final. Dues taules. La FK id_client a COMANDA referència CLIENT. Si la cardinalitat mínima hagués estat (1,N), la FK hauria de ser NOT NULL.
Model Relacional
CLIENT
PK id_client
nom
email
COMANDA
PK id_comanda
FK id_client*
data
total
COMANDA(id_comanda, id_client*, data, total)
Regla 4: Relacions 1:1
La FK pot anar a qualsevol de les dues taules, però cal afegir una restricció UNIQUE per garantir la relació d'un a un. La recomanació és posar la FK a l'entitat que té participació obligatòria (min=1).
Regla 4: Relacions 1:1 → FK + UNIQUE
Punt de partida. Una PERSONA pot tenir zero o un PASSAPORT (min=0). Un PASSAPORT pertany obligatòriament a una PERSONA (min=1). La relació és 1:1.
Model E/R
id_persona
PERSONA
nom
dni
(0,1)
té
(1,1)
id_passaport
PASSAPORT
numero
data_exp
Triar on posar la FK. PASSAPORT té participació obligatòria (min=1): cada passaport SEMPRE té una persona. Posem la FK id_persona a PASSAPORT: serà NOT NULL perquè min=1. Afegim UNIQUE per garantir que cap persona tingui dos passaports.
Decisió de col·locació de la FK
❌FK a PERSONA (id_passaport): podria ser NULL — no totes les persones tenen passaport
✅FK a PASSAPORT (id_persona): NOT NULL perquè min=1, i UNIQUE perquè max=1
La FK migra amb restriccions.id_persona s'afegeix a PASSAPORT com a FK amb NOT NULL (min=1) i UNIQUE (max=1 garanteix 1:1).
Model E/R
id_persona
PERSONA
→
id_passaport
PASSAPORT
+ id_persona* NN UK
→transforma
Model Relacional
PASSAPORT
PK id_passaport
FKNNUK id_persona*
numero
data_exp
Resultat final. PASSAPORT conté la FK id_persona amb NOT NULL i UNIQUE. PERSONA no té cap referència a PASSAPORT.
Les relacions N:M no és poden representar directament amb claus foranes. Cal crear una taula pont (taula d'associació). La seva clau primària és la combinació de les dues FK. Els atributs propis de la relació passen a ser columnes d'aquesta nova taula.
Regla 5: Relacions N:M → taula pont
Punt de partida. Un ALUMNE pot cursar moltes ASSIGNATURES, i una ASSIGNATURA pot ser cursada per molts ALUMNES. La relació cursa té un atribut propi: la nota_final.
Model E/R
id_alumne
ALUMNE
nom
(0,N)
cursa
(0,N)
id_assignatura
ASSIGNATURA
nom
Atribut de la relació: nota_final
Per què cal taula pont? Si posem la FK a ALUMNE, cada alumne podria tenir UNA sola assignatura. Si la posem a ASSIGNATURA, cada assignatura podria tenir UN sol alumne. Cap opció representa N:M. La solució és una taula intermèdia.
El problema N:M
❌ FK a ALUMNE
ALUMNE(..., id_asig*)
Només una assignatura per alumne
❌ FK a ASSIGNATURA
ASSIGNATURA(..., id_alum*)
Només un alumne per assignatura
✅ Taula pont
MATRICULA(id_alum*, id_asig*)
Cada fila = una matriculació
Creació de la taula pont. MATRICULA conté les PK de les dues entitats com a FK. La PK de MATRICULA és composta per (id_alumne, id_assignatura). L'atribut nota_final de la relació s'afegeix com a columna normal.
Model E/R
id_alumne
ALUMNE
→
id_alumne*
id_assignatura*
MATRICULA
nota_final
←
id_assignatura
ASSIGNATURA
→transforma
Model Relacional
MATRICULA
PK+FK id_alumne*
PK+FK id_assignatura*
nota_final
Resultat final. Tres taules. MATRICULA és la taula pont amb PK composta. Cada fila de MATRICULA representa una matriculació d'un alumne en una assignatura concreta.
Una entitat es relaciona amb ella mateixa. Per a una relació reflexiva 1:N, s'afegeix una FK a la mateixa taula que apunta a la seva pròpia PK.
Regla 6: Relació reflexiva 1:N → FK autorreferenciada
Punt de partida. Un EMPLEAT pot supervisar molts altres empleats (max=N), però cada empleat és supervisat per com a molt un altre (max=1). Un empleat pot no tenir supervisor (min=0).
Model E/R
id_empleat
EMPLEAT
nom
salari
(0,1)
supervisa
(0,N)
↺
La FK autorreferenciada. S'afegeix la columna id_supervisor a la mateixa taula EMPLEAT. Aquesta FK apunta a la PK id_empleat de la mateixa taula. Com que min=0, pot ser NULL.
Model E/R
id_empleat
EMPLEAT
↺ supervisa
→transforma
Model Relacional
EMPLEAT
PK id_empleat
FK id_supervisor*
nom
salari
Resultat final. Una sola taula amb FK autorreferenciada. id_supervisor pot ser NULL (empleats de primer nivell sense supervisor).
Model Relacional
EMPLEAT
PK id_empleat
FK id_supervisor*
nom
salari
EMPLEAT(id_empleat, id_supervisor*, nom, salari)
Regla 7: Jerarquies de generalització/especialització
Quan tenim una relació IS-A (herència), hi ha tres estratègies possibles.
Opció A — Una taula per entitat (explícita)
Opció A: Una taula per entitat
Punt de partida. PERSONA és la superclasse. ESTUDIANT i TREBALLADOR en són subclasses (IS-A). Cada subclasse té atributs propis.
Model E/R — Jerarquia IS-A
dni
PERSONA
nom
adreca
IS-A
ESTUDIANT
nivell
hores
IS-A
TREBALLADOR
num_ss
salari
Tres taules independents. Cada entitat (superclasse i subclasses) es converteix en una taula. Les subclasses usen la PK de la superclasse com a PK i alhora FK.
Estructura IS-A
PERSONA
↓ IS-A
ESTUDIANT
TREBALLADOR
→transforma
Model Relacional
PERSONA
PK dni
nom · adreca
Resultat final. Tres taules. Per obtenir les dades completes d'un estudiant cal fer JOIN entre ESTUDIANT i PERSONA. La PK de les subclasses és alhora FK cap a PERSONA.
Model Relacional
PERSONA
PK dni
nom
adreca
ESTUDIANT
PK+FK dni*
nivell
hores
TREBALLADOR
PK+FK dni*
num_ss
salari
✅ Sense nuls · ✅ Semàntica clara · ⚠️ Cal JOIN per dades completes
Opció B — Una sola taula (col·lapsada)
Opció B: Una sola taula amb columna discriminador
Mateixa jerarquia. PERSONA → ESTUDIANT, TREBALLADOR. En l'enfocament col·lapsat, totes les entitats s'uneixen en una sola taula.
Model E/R — Jerarquia IS-A
dni
PERSONA
nom
adreca
ESTUDIANT
nivell · hores
TREBALLADOR
num_ss · salari
Col·lapsem tot en una taula. Tots els atributs de totes les entitats s'uneixen en una sola taula. S'afegeix una columna tipus (discriminador) que indica a quina subclasse pertany cada fila. Els camps que no apliquen a un tipus tindran NULL.
Tots els atributs
dni, nom, adreca +
nivell, hores +
num_ss, salari
→col·lapsa
Una sola taula
PERSONA
PK dni
DISC tipus
nom · adreca
nivell · hores
num_ss · salari
Resultat final. Una sola taula. El camp tipus pot tenir valors 'ESTUDIANT' o 'TREBALLADOR'. Sense JOINs, però amb molts NULLs.
Model Relacional
PERSONA
PK dni
DISC tipus
nom
adreca
nivell NULL si no estudiant
hores NULL si no estudiant
num_ss NULL si no treballador
salari NULL si no treballador
✅ Sense JOINs · ⚠️ Molts NULLs · ❌ Semàntica perduda
Opció C — Una taula per subclasse (horitzontal)
Opció C: Una taula per subclasse (sense taula pare)
Mateixa jerarquia. En l'enfocament horitzontal no és crea taula per a la superclasse PERSONA. Els atributs comuns es copien a cada subclasse.
Model E/R — no és crea taula per PERSONA
dni
PERSONA
nom · adreca
↓ atributs heretats es copien a cada subclasse
dni
ESTUDIANT
nom · adreca
nivell · hores
dni
TREBALLADOR
nom · adreca
num_ss · salari
Dues taules independents. Cada subclasse incorpora tots els atributs de PERSONA (heretats) més els seus propis. Sense taula pare, sense JOINs, però amb redundància d'atributs comuns.
Herència d'atributs
PERSONA: dni, nom, adreca
↓ copia
ESTUDIANT
TREBALLADOR
→transforma
Dues taules
ESTUDIANT
PK dni
nom, adreca (heretats)
nivell · hores
TREBALLADOR
PK dni
nom, adreca (heretats)
num_ss · salari
Resultat final. Dues taules independents. Eficients per a consultes per subclasse, però amb redundància d'atributs comuns i problemes si una persona pot ser alhora estudiant i treballadora.
Model Relacional
ESTUDIANT
PK dni
nom
adreca
nivell
hores
TREBALLADOR
PK dni
nom
adreca
num_ss
salari
✅ Sense JOINs · ✅ Sense NULLs · ⚠️ Redundància d'atributs comuns
Resum de les regles de transformació
Element ER
Regla
Resultat al model relacional
Entitat forta
R1
Una taula; atribut identificador → PK
Entitat dèbil
R2
Una taula; PK = clau parcial + PK pare; FK al pare
Atribut compost
Previ
Es descompon en columnes simples
Atribut derivat
Previ
S'omet o es guarda la dada base
Atribut multivalor
Previ
Nova taula amb FK a l'entitat; PK composta
Relació 1:N
R3
PK del costat 1 → FK al costat N
Relació 1:1
R4
FK + UNIQUE a la banda amb participació obligatòria
Relació N:M
R5
Nova taula pont amb PK composta (FK1 + FK2)
Relació reflexiva 1:N
R6
FK autorreferenciada a la mateixa taula
Jerarquia (opció A)
R7
Una taula per entitat; PK subclasse = FK superclasse
Jerarquia (opció B)
R7
Una sola taula + columna discriminador
Jerarquia (opció C)
R7
Una taula per subclasse amb atributs heretats
Quan s'aplica NOT NULL a una FK?
Quan la cardinalitat mínima de l'entitat que rep la FK és 1. Exemple: si Card(COMANDA, realitza) = (1,N), llavors la FK a COMANDA hauria de ser NOT NULL perquè tota comanda ha de tenir un client.
AC0372/02/05 — Miniactivitat
RA2 · CA2.3, CA2.4, CA2.5, CA2.6, CA2.7, CA2.9
Transforma al model relacional el diagrama E/R de la clínica veterinària de la sessió anterior. Documenta:
Quin tipus de transformació has aplicat a cada element (quina regla).
Les taules resultants amb totes les seves columnes.
Claus primàries (PK), foranes (FK), UNIQUE i NOT NULL on escaigui.
Per a les jerarquies (si n'hi ha), justifica quina opció (A, B o C) has triat i per què.