Model Entitat-Relació (ER)
El model Entitat-Relació (ER) és una tècnica de modelatge conceptual introduïda per Peter Chen el 1976. Permet representar gràficament les dades d'un domini d'aplicació i les seves interrelacions de forma independent de qualsevol tecnologia de base de dades. El resultat és un diagrama ER que serveix com a "plànol" de la base de dades, comprensible tant per tècnics com per clients.
Les tres fases del disseny d'una BD
Abans d'implementar una base de dades, cal passar per tres fases de disseny ben diferenciades:
flowchart LR
A["1. Disseny conceptual\nModel ER\n(independent del SGBD)"]
B["2. Disseny lògic\nModel relacional\n(taules, claus)"]
C["3. Disseny físic\nDDL al SGBD concret\n(CREATE TABLE...)"]
A -->|"Transformació"| B
B -->|"Implementació"| C
style A fill:#4f46e5,color:#fff,stroke:#3730a3
style B fill:#0891b2,color:#fff,stroke:#0e7490
style C fill:#059669,color:#fff,stroke:#047857
| Fase | Model | Eina | Resultat |
|---|---|---|---|
| Conceptual | ER | Diagrama ER | Esquema independent del SGBD |
| Lògica | Relacional | Normalització | Taules, claus primàries i foranes |
| Física | Implementació | DDL (SQL) | CREATE TABLE, índexs, etc. |
El model ER es situa en la fase de disseny conceptual: no parla de taules ni de SQL, sinó d'entitats del món real i de com es relacionen.
Nomenclatura
Per mantenir la coherència en els dissenys ER, cal seguir unes convencions de noms:
| Element | Convenció | Exemple |
|---|---|---|
| Entitats | Substantiu singular, MAJÚSCULES | CLIENT, PRODUCTE |
| Atributs | Substantiu singular, minúscules | nom, data_naixement |
| Relacions | Verb, MAJÚSCULES | REALITZA, CONTÉ |
| Paraules compostes | camelCase | codiPostal, dataAlta |
Evita accents i espais
En els noms d'entitats, atributs i relacions, evita els accents i els espais per facilitar la posterior transformació al model físic. Escriu codiPostal en lloc de codi postal o codiPostal.
Entitats
Una entitat és qualsevol cosa (objecte, persona, concepte, event) sobre la qual volem emmagatzemar informació. Es representen amb rectangles.
flowchart LR
CLIENT[CLIENT]
PRODUCTE[PRODUCTE]
style CLIENT fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style PRODUCTE fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
Dins d'un tipus d'entitat, cada membre individual s'anomena ocurrència o instància. Per exemple, el tipus d'entitat CLIENT agrupa totes les ocurrències (Joan Garcia, Maria Puig, etc.).
Exemples d'entitats:
CLIENT— una persona que compraPRODUCTE— un article del catàlegCOMANDA— una compra realitzadaPROFESSOR— un docent del centreASSIGNATURA— un curs impartit
Entitats fortes i dèbils
Entitat forta (regular): Existeix de manera independent i té una clau pròpia que identifica unívocament cada ocurrència. Es representa amb un rectangle simple.
Entitat dèbil: La seva existència depèn d'una entitat forta; no pot existir sense ella. Es representa amb un rectangle doble. La seva clau inclou, totalment o parcialment, la clau de l'entitat forta.
flowchart LR
COMANDA[COMANDA\nentitat forta]
LINIA[["LINIA_COMANDA\nentitat dèbil"]]
style COMANDA fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style LINIA fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
| Entitat forta | Entitat dèbil | |
|---|---|---|
| Existència | Independent | Depèn d'una entitat forta |
| Clau | Pròpia | Parcial o total de l'entitat forta |
| Representació | Rectangle simple | Rectangle doble |
| Exemple | COMANDA (té el seu propi id) |
LINIA_COMANDA (no existeix sense COMANDA) |
Tipus de dependència en entitats dèbils
- Dependència d'existència (E): L'entitat dèbil no pot existir sense la forta; si s'esborra la forta, s'esborren en cascada les dèbils.
- Dependència d'identificació (ID): A més de la dependència d'existència, la identificació de l'entitat dèbil requereix els atributs de l'entitat forta. Sovint usa una numeració seqüencial que és reinicia per a cada ocurrència de l'entitat forta.
Atributs
Un atribut és una propietat o característica d'una entitat o relació. En la notació de Chen es representen amb el·lipses connectades a l'entitat.
flowchart TD
PERSONA[PERSONA]
PERSONA --- id(["<u>dni</u>"])
PERSONA --- s([nom])
PERSONA --- c([adreca])
c --- c1([carrer])
c --- c2([poblacio])
PERSONA --- m([telefons])
PERSONA --- d([edat])
style PERSONA fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style id fill:#f57f17,stroke:#e65100,color:#fff,stroke-width:1.5px
style s fill:#f57f17,stroke:#e65100,color:#fff,stroke-width:1.5px
style c fill:#f57f17,stroke:#e65100,color:#fff,stroke-width:1.5px
style c1 fill:#f57f17,stroke:#e65100,color:#fff,stroke-width:1.5px
style c2 fill:#f57f17,stroke:#e65100,color:#fff,stroke-width:1.5px
style m fill:#f57f17,stroke:#e65100,color:#fff,stroke-width:3px
style d fill:#f57f17,stroke:#e65100,color:#fff,stroke-dasharray:5 5,stroke-width:1.5px
| Símbol | Tipus d'atribut |
|---|---|
| El·lipse simple | Simple / monoavaluat |
El·lipse amb text subratllat (<u>dni</u>) |
Identificador (clau) |
| El·lipse encadenada a sub-el·lipses | Compost |
| El·lipse amb vora gruixuda | Multiavaluat |
| El·lipse amb vora discontínua | Derivat |
Tipus d'atributs
| Tipus | Descripció | Representació | Exemple |
|---|---|---|---|
| Simple | Valor únic i indivisible | El·lipse simple | edat, preu |
| Compost | Es pot dividir en subatributs | El·lipses encadenades | adreca (carrer + numero + població + CP) |
| Monovaluat | Un únic valor per ocurrència | El·lipse simple | nom, DNI |
| Multivaluat | Múltiples valors per ocurrència | El·lipse doble | telefons (mòbil, fix, feina) |
| Derivat | Es calcula a partir d'un altre | El·lipse discontinua | edat (calculada de dataNaixement) |
| Opcional | Pot contenir valor nul | El·lipse amb asterisc | segonCognom |
| No nul | Obligatori, mai buit | El·lipse marcada | nom, email |
| Relacional | El valor depèn de la relació, no de l'entitat | A la relació (rombo) | dataMatriculacio a la relació MATRICULAT |
Atributs compostos i multivalorats en SQL
En la implementació relacional:
- Els atributs compostos es desglossen en columnes simples (
adreca_carrer,adreca_numero,adreca_poblacio,adreca_cp). - Els atributs multivalorats originen taules addicionals. Si un client pot tenir múltiples telèfons, cal crear
TELEFON_CLIENT(id_client, telefon).
Tipus d'identificadors
Tot entitat ha de tenir almenys un atribut identificador (clau). En la notació de Chen, es subratlla.
| Tipus | Descripció | Exemple |
|---|---|---|
| Simple | Un sol atribut identifica l'entitat | dni per a PERSONA |
| Compost | Múltiples atributs junts identifiquen l'entitat | (codiVol, data) per a VOL |
| Candidat | Múltiples atributs podrien ser clau; se n'escull un com a primari | dni i email per a USUARI |
| Complementat | Identifica l'entitat combinat amb la clau d'una altra entitat (entitat dèbil) | (id_comanda, num_linia) per a LINIA_COMANDA |
Relacions
Una relació (o interrelació) descriu una associació entre dues o més entitats. Es representen amb rombos en la notació de Chen.
flowchart LR
CLIENT[CLIENT] --- REALITZA{REALITZA} --- COMANDA[COMANDA]
style CLIENT fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style COMANDA fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style REALITZA fill:#2e7d32,stroke:#1b5e20,color:#fff,stroke-width:2px
Propietats d'una relació:
- Nom: Verb o frase verbal que descriu l'associació (ex:
REALITZA,CONTÉ,IMPARTEIX). - Grau: Nombre d'entitats que hi participen.
- Cardinalitat: Quantes ocurrències d'un costat es corresponen amb quantes de l'altre.
- Rol: Funció que exerceix cada entitat dins la relació.
Grau de la relació
| Grau | Nom | Descripció | Exemple |
|---|---|---|---|
| 1 | Reflexiva (unària) | Una entitat es relaciona amb si mateixa | EMPLEAT supervisa EMPLEAT |
| 2 | Binària | Dues entitats (la més freqüent) | CLIENT realitza COMANDA |
| 3 | Ternària | Tres entitats | PROVEIDOR subministra PEÇA a PROJECTE |
| N | N-ària | Quatre o més entitats | (poc freqüent) |
Relació reflexiva
Una entitat es relaciona amb ella mateixa en rols diferents. Cal indicar el rol de cada participació.
Exemple: un EMPLEAT pot ser supervisor d'altres empleats.
flowchart LR
EMPLEAT[EMPLEAT] -->|"supervisor\n(1,N)"| SUPERVISA{SUPERVISA}
SUPERVISA -->|"subordinat\n(0,N)"| EMPLEAT
style EMPLEAT fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style SUPERVISA fill:#2e7d32,stroke:#1b5e20,color:#fff,stroke-width:2px
Cardinalitat: notació (min, max)
La cardinalitat es defineix amb un parell (mínim, màxim) per a cada entitat participant en la relació: Card(Entitat, Relació) = (min, max).
| Valor | Significat |
|---|---|
| min = 0 | Participació opcional — l'entitat pot no participar en la relació |
| min = 1 | Participació obligatòria — l'entitat sempre hi participa |
| max = 1 | Cada ocurrència es relaciona amb com a màxim una ocurrència de l'altra entitat |
| max = N | Cada ocurrència es relaciona amb moltes ocurrències de l'altra entitat |
Les combinacions possibles per a cada extrem són: (0,1), (1,1), (0,N), (1,N).
Com llegir la cardinalitat en un diagrama
Les cardinalitats s'anoten a l'extrem oposat de l'entitat a la qual fan referència, seguint el patró: Entitat — Cardinalitat — Relació — Cardinalitat — Entitat.
Relació 1:1 (u a u)
Una ocurrència d'A es relaciona amb com a màxim una ocurrència de B, i viceversa.
| Card(A,R) | Card(B,R) | Interpretació |
|---|---|---|
| (0,1) | (0,1) | Cap dels dos és obligatori |
| (1,1) | (0,1) | A sempre hi participa, B no |
| (0,1) | (1,1) | B sempre hi participa, A no |
| (1,1) | (1,1) | Tots dos obligatoris — evitar (crea dependència circular) |
Exemple: PERSONA té PASSAPORT — Card(PERSONA, TÉ) = (0,1); Card(PASSAPORT, TÉ) = (1,1).
flowchart LR
PERSONA[PERSONA] ---|"(0,1)"| TE{TE}
TE ---|"(1,1)"| PASSAPORT[PASSAPORT]
style PERSONA fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style PASSAPORT fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style TE fill:#2e7d32,stroke:#1b5e20,color:#fff,stroke-width:2px
erDiagram
PERSONA {
string dni PK
string nom
}
PASSAPORT {
string num_passaport PK
string dni FK
date data_expedicio
}
PERSONA |o--|| PASSAPORT : "te"
|o--|| — Una PERSONA pot tenir zero o un passaport; cada passaport pertany a exactament una persona.
Relació 1:N (u a molts)
El tipus de relació més freqüent. Una ocurrència d'A es relaciona amb moltes de B, però cada B només es relaciona amb una A.
| Card(A,R) | Card(B,R) | Interpretació |
|---|---|---|
| (0,N) | (0,1) | Cap dels dos és obligatori |
| (1,N) | (0,1) | A ha de tenir almenys un B |
| (0,N) | (1,1) | B sempre pertany a un A |
| (1,N) | (1,1) | Tots dos obligatoris — relaxar a (0,N) si cal |
Exemple: categoria conté PRODUCTES — Card(categoria, CONTÉ) = (1,N); Card(PRODUCTE, CONTÉ) = (1,1).
flowchart LR
categoria[categoria] ---|"(1,N)"| CONTE{CONTE}
CONTE ---|"(1,1)"| PRODUCTE[PRODUCTE]
style categoria fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style PRODUCTE fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style CONTE fill:#2e7d32,stroke:#1b5e20,color:#fff,stroke-width:2px
erDiagram
CATEGORIA {
int id_categoria PK
string nom
}
PRODUCTE {
int id_producte PK
int id_categoria FK
string nom
decimal preu
}
CATEGORIA ||--o{ PRODUCTE : "conte"
||--o{ — Una categoria conté zero o molts productes; cada producte pertany a exactament una categoria.
Relació N:M (molts a molts)
Cada ocurrència d'A es relaciona amb moltes de B i viceversa.
Exemple: ALUMNE cursa ASSIGNATURA — Card(ALUMNE, CURSA) = (0,N); Card(ASSIGNATURA, CURSA) = (0,N).
flowchart LR
ALUMNE[ALUMNE] ---|"(0,N)"| CURSA{CURSA}
CURSA ---|"(0,N)"| ASSIGNATURA[ASSIGNATURA]
style ALUMNE fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style ASSIGNATURA fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style CURSA fill:#2e7d32,stroke:#1b5e20,color:#fff,stroke-width:2px
erDiagram
ALUMNE {
int id_alumne PK
string nom
}
ASSIGNATURA {
int id_assignatura PK
string nom
}
MATRICULA {
int id_alumne FK
int id_assignatura FK
date data_matricula
}
ALUMNE }o--o{ ASSIGNATURA : "cursa"
ALUMNE ||--o{ MATRICULA : ""
ASSIGNATURA ||--o{ MATRICULA : ""
}o--o{ — Un alumne pot cursar zero o moltes assignatures; una assignatura pot tenir zero o molts alumnes. La relació N:M es descompon en la taula pont MATRICULA.
N:M a la implementació
Les relacions N:M no és poden implementar directament en el model relacional. S'han de transformar en una taula intermèdia (taula pont) amb les claus foranes de totes dues entitats participants.
Cardinalitats exactes
En alguns casos cal especificar valors mínims o màxims exactes. Per exemple: "una classe ha de tenir entre 5 i 30 alumnes" es representa com Card(ALUMNE, PERTANY) = (5,30).
Rol
El rol indica la funció que exerceix una entitat en una relació. S'escriu en minúscules sobre la línia de connexió. És especialment útil en les relacions reflexives.
Exemple: en la relació EMPLEAT supervisa EMPLEAT, els rols serien supervisor i subordinat.
Notacions gràfiques
Notació de Chen (tradicional)
La notació original de Peter Chen utilitza:
- Rectangles per a entitats (dobles per a les dèbils)
- El·lipses per a atributs (dobles per a multivalors, discontinus per a derivats, subratllats per a claus)
- Rombes per a relacions (dobles per a les que connecten entitats dèbils)
- Les cardinalitats es representen com a parells (min, max) a l'extrem oposat de l'entitat
Taula de referència visual:
| Símbol Chen | Forma | Component |
|---|---|---|
| Rectangle simple | [ENTITAT] |
Entitat forta |
| Rectangle doble | [[ENTITAT]] |
Entitat dèbil |
| El·lipse simple | ([atribut]) |
Atribut simple / monovalor |
| El·lipse subratllada | ([<u>clau</u>]) |
Atribut identificador (clau primària) |
| El·lipse amb sub-el·lipses | El·lipse connectada a fills | Atribut compost |
| El·lipse vora gruixuda | El·lipse amb doble contorn | Atribut multivalor |
| El·lipse discontínua | El·lipse amb línia de punts | Atribut derivat |
| Rombo simple | {RELACIO} |
Relació entre entitats fortes |
| Rombo doble | Rombo amb doble contorn | Relació identificadora (entitat dèbil) |
flowchart TD
subgraph Entitats
EF[Entitat forta]
ED[["Entitat dèbil"]]
end
subgraph Relació
R{RELACIO}
end
subgraph Atributs
A1(["<u>clau</u>"])
A2([simple])
A3([compost])
A3 --- A31([sub1])
A3 --- A32([sub2])
A4([multivaluat])
A5([derivat])
end
EF --- R
R --- ED
EF --- A1
EF --- A2
EF --- A3
EF --- A4
EF --- A5
style EF fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style ED fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style R fill:#2e7d32,stroke:#1b5e20,color:#fff,stroke-width:2px
style A1 fill:#f57f17,stroke:#e65100,color:#fff,stroke-width:1.5px
style A2 fill:#f57f17,stroke:#e65100,color:#fff,stroke-width:1.5px
style A3 fill:#f57f17,stroke:#e65100,color:#fff,stroke-width:1.5px
style A31 fill:#f57f17,stroke:#e65100,color:#fff,stroke-width:1.5px
style A32 fill:#f57f17,stroke:#e65100,color:#fff,stroke-width:1.5px
style A4 fill:#f57f17,stroke:#e65100,color:#fff,stroke-width:3px
style A5 fill:#f57f17,stroke:#e65100,color:#fff,stroke-dasharray:5 5,stroke-width:1.5px
Notació de peus de gall (Crow's Foot)
La notació més usada en el món professional. Representa la cardinalitat directament sobre les línies de relació. La cardinalitat màxima s'indica més a prop de l'entitat i la mínima més lluny.
| Símbol | Significat |
|---|---|
Cercle ○ |
Zero (opcional) |
Ratlla perpendicular \| |
Un (exactament un) |
Dues ratlles \|\| |
Un i només un (obligatori) |
Peu de gall (tres línies) { |
Molts (zero o més) |
Exemples de combinacions:
\|\|--o{→ Un CLIENT pot tenir zero o moltes COMANDES (obligatori a l'esquerra, opcional molts a la dreta)\|\|--|{→ Una COMANDA té una o moltes LINIES (tots dos obligatoris, com a mínim una)
Diagrames ER amb Mermaid
Mermaid permet crear diagrames ER directament en Markdown usant la notació de Crow's Foot:
erDiagram
CLIENT {
int id_client PK
varchar nom
varchar email
varchar telefon
}
COMANDA {
int id_comanda PK
int id_client FK
date dataComanda
varchar estat
decimal total
}
LINIA_COMANDA {
int id_linia PK
int id_comanda FK
int id_producte FK
int quantitat
decimal preuUnitari
}
PRODUCTE {
int id_producte PK
varchar nom
varchar descripcio
decimal preu
int estoc
}
CLIENT ||--o{ COMANDA : "realitza"
COMANDA ||--|{ LINIA_COMANDA : "conte"
PRODUCTE ||--o{ LINIA_COMANDA : "apareix en"
En aquest diagrama:
||--o{— Un CLIENT pot tenir zero o moltes COMANDES.||--|{— Una COMANDA té una o moltes LINIES_COMANDA (no pot estar buida).||--o{— Un PRODUCTE pot aparèixer en zero o moltes LINIES_COMANDA.
Model ER Estès (EER)
El Model Entitat-Relació Estès afegeix mecanismes de jerarquia de classes i agregació, acostant el model ER al paradigma orientat a objectes.
Generalització i especialització
Permeten organitzar entitats en jerarquies superclasse / subclasse on les subclasses hereten tots els atributs de la superclasse i n'afegeixen de propis.
- Superclasse: conté els atributs comuns a totes les subclasses.
- Subclasse: conté atributs específics i hereta els de la superclasse.
- Relació IS-A: indica que una subclasse és un tipus de superclasse.
Diferència entre generalització i especialització:
- Generalització (bottom-up): partim de diverses entitats similars i en extraiem els atributs comuns a una superclasse.
- Especialització (top-down): partim d'una entitat general i la dividim en subclasses amb característiques pròpies.
Exemple: EMPLEAT com a superclasse, amb subclasses GERENT, CAP_SECCIO i VENEDOR.
flowchart TD
EMPLEAT[EMPLEAT\nid_empleat, nom, salari]
ISA{IS-A}
GERENT[GERENT\ndepartament, bonus]
VENEDOR[VENEDOR\ncomissio, zona]
EMPLEAT --- ISA
ISA --- GERENT
ISA --- VENEDOR
style EMPLEAT fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style GERENT fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style VENEDOR fill:#1565c0,stroke:#0d47a1,color:#fff,stroke-width:2px
style ISA fill:#2e7d32,stroke:#1b5e20,color:#fff,stroke-width:2px
Tipus d'especialització
Segons la cobertura (participació):
- Total (||): Tota ocurrència de la superclasse ha de pertànyer a alguna subclasse. Exemple: tot
VEHICLEés oCOTXEoMOTOCICLETA. - Parcial (|): Hi pot haver ocurrències de la superclasse que no pertanyin a cap subclasse. Exemple: un
EMPLEATpot serGERENTo simplement un empleat sense especialització.
Segons l'exclusivitat:
- Disjunta (d): Una ocurrència de la superclasse pertany a com a màxim una subclasse.
- Superposada (o): Una ocurrència pot pertànyer a diverses subclasses simultàniament. Exemple: una
PERSONApot ser alhoraESTUDIANTiEMPLEAT.
Combinant cobertura i exclusivitat tenim quatre casos: Total-Disjunta, Total-Superposada, Parcial-Disjunta, Parcial-Superposada.
Agregació
L'agregació permet que una relació es comporti com si fos una entitat, associant-se al seu torn amb altres entitats. S'usa per evitar relacions ternàries quan la participació en la tercera entitat és opcional.
Exemple: un DOCENT imparteix una ASSIGNATURA en una AULA. La relació IMPARTIR (DOCENT-ASSIGNATURA) es pot agregar per crear l'entitat associativa SESSIO, que llavors es relaciona amb INCIDENCIA a través de la relació REGISTRA.
Quan usar agregació vs relació ternaria
Usa una relació ternària quan les tres entitats participen de manera obligatòria i conjunta. Usa agregació quan la tercera entitat s'associa de manera opcional amb la relació existent.
Restriccions semàntiques i pèrdua expressiva
El model ER té limitacions: no sempre permet expressar totes les regles de negoci. Quan un requisit no és pot representar directament al diagrama, cal:
- Documentar-lo com a nota de disseny al costat del diagrama.
- Indicar-ho explícitament en la documentació del projecte.
- Implementar-ho posteriorment com a restricció CHECK o trigger al SGBD.
Exemples de restriccions que el model ER no pot expressar directament:
- "Un empleat no pot treballar al departament on és directiu."
- "Una comanda no pot tenir data de lliurament anterior a la data de creació."
Procés de disseny pas a pas
Segueix aquest procés sistemàtic per crear un diagrama ER a partir d'uns requisits:
- Llegir i comprendre el problema amb atenció.
- Identificar les entitats (els substantius del problema) i envolta'ls amb rectangles.
- Identificar les relacions (els verbs del problema) i representa-les amb rombes.
- Extreure els atributs de cada entitat, sense duplicar informació entre entitats.
- Verificar que cada entitat té un identificador (atribut clau).
- Moure atributs a relacions quan el valor depèn de la combinació d'entitats, no d'una sola.
- Definir les cardinalitats: primer les màximes (1 o N), després les mínimes (0 o 1).
- Revisar relacions redundants i atributs derivats innecessaris.
AC0372/02/01 — Miniactivitat — Servei de lloguer de bicicletes
RA2 · CA2.1, CA2.2, CA2.5
Dissenyeu un diagrama ER per a un servei de lloguer de bicicletes. El sistema ha de registrar:
- Els usuaris registrats (nom, cognoms, telèfon, email, saldo).
- Les bicicletes disponibles (codi, estat, estació on estan aparcades).
- Els lloguers: cada lloguer registra quin usuari va agafar quina bicicleta, la data/hora d'inici, la data/hora de fi, el lloc de recollida i el lloc de devolució.
Seguiu el procés de disseny pas a pas:
- Identifiqueu les entitats i els seus atributs (incloent-hi la clau de cada una).
- Identifiqueu la relació i els seus atributs relacionals.
- Definiu les cardinalitats amb la notació (min, max).
- Dibuixeu el diagrama Mermaid.
Exemple complet: Gestió d'una biblioteca
Dissenyem la BD d'una biblioteca. La biblioteca té socis que fan préstecs d'exemplars de llibres. Un mateix llibre pot tenir múltiples exemplars físics. Un soci pot tenir múltiples préstecs actius, però un exemplar només pot estar prestat a un soci en un moment donat. Els autors escriuen els llibres (un llibre pot tenir coautors).
Identificació d'entitats i relacions:
| Entitat | Atributs clau | Relació amb |
|---|---|---|
SOCI |
id_soci, dni |
Fa préstecs |
PRESTEC |
id_prestec |
Entitat pont SOCI-EXEMPLAR |
EXEMPLAR |
id_exemplar |
Pertany a un LLIBRE |
LLIBRE |
id_llibre, isbn |
Escrit per AUTORS |
AUTOR |
id_autor |
Escriu LLIBRES |
erDiagram
SOCI {
int id_soci PK
varchar nom
varchar cognoms
varchar dni
date dataAlta
varchar email
}
PRESTEC {
int id_prestec PK
int id_soci FK
int id_exemplar FK
date dataPrestec
date dataDevolucioPrevista
date dataDevolucioReal
}
EXEMPLAR {
int id_exemplar PK
int id_llibre FK
varchar numInventari
varchar estat
}
LLIBRE {
int id_llibre PK
varchar isbn
varchar titol
int anyPublicacio
varchar editorial
}
AUTOR {
int id_autor PK
varchar nom
varchar cognoms
varchar nacionalitat
}
LLIBRE_AUTOR {
int id_llibre FK
int id_autor FK
}
SOCI ||--o{ PRESTEC : "fa"
EXEMPLAR ||--o{ PRESTEC : "es prestat en"
LLIBRE ||--|{ EXEMPLAR : "te"
LLIBRE ||--o{ LLIBRE_AUTOR : "escrit per"
AUTOR ||--o{ LLIBRE_AUTOR : "escriu"
Cardinalitats:
Card(SOCI, FA) = (0,N)— Un soci pot no haver fet cap préstec, o haver-ne fet molts.Card(EXEMPLAR, ES_PRESTAT) = (0,N)— Un exemplar pot haver estat prestat moltes vegades.Card(LLIBRE, TÉ) = (1,N)— Un llibre ha de tenir almenys un exemplar.Card(EXEMPLAR, TÉ) = (1,1)— Un exemplar pertany exactament a un llibre.Card(AUTOR, ESCRIU) = (0,N)iCard(LLIBRE, ESCRIU) = (1,N)— Relació N:M entre autors i llibres.
AC0372/02/02 Miniactivitat Clínica veterinaria
RA2 · CA2.1, CA2.2, CA2.5, CA2.9
Dissenyeu un diagrama ER per a una clínica veterinaria. La clínica té propietaris (clients) que registren els seus animals de companyia. Els veterinaris fan visites als animals. En cada visita es pot administrar un o més tractaments i prescriure medicaments.
- Identifiqueu totes les entitats i els seus atributs.
- Identifiqueu les relacions i la seva cardinalitat amb notació (min, max).
- Identifiqueu si hi ha entitats dèbils.
- Dibuixeu el diagrama ER amb Mermaid.