Salta el contingut

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 compra
  • PRODUCTE — un article del catàleg
  • COMANDA — una compra realitzada
  • PROFESSOR — un docent del centre
  • ASSIGNATURA — 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: PERSONAPASSAPORT — 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.

ALUMNE(id_alumne, nom) + ASSIGNATURA(id_assignatura, nom)
→ MATRICULA(id_alumne FK, id_assignatura FK, data_matricula)

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 o COTXE o MOTOCICLETA.
  • Parcial (|): Hi pot haver ocurrències de la superclasse que no pertanyin a cap subclasse. Exemple: un EMPLEAT pot ser GERENT o 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 PERSONA pot ser alhora ESTUDIANT i EMPLEAT.

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:

  1. Documentar-lo com a nota de disseny al costat del diagrama.
  2. Indicar-ho explícitament en la documentació del projecte.
  3. 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:

  1. Llegir i comprendre el problema amb atenció.
  2. Identificar les entitats (els substantius del problema) i envolta'ls amb rectangles.
  3. Identificar les relacions (els verbs del problema) i representa-les amb rombes.
  4. Extreure els atributs de cada entitat, sense duplicar informació entre entitats.
  5. Verificar que cada entitat té un identificador (atribut clau).
  6. Moure atributs a relacions quan el valor depèn de la combinació d'entitats, no d'una sola.
  7. Definir les cardinalitats: primer les màximes (1 o N), després les mínimes (0 o 1).
  8. 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:

  1. Identifiqueu les entitats i els seus atributs (incloent-hi la clau de cada una).
  2. Identifiqueu la relació i els seus atributs relacionals.
  3. Definiu les cardinalitats amb la notació (min, max).
  4. 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) i Card(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.

  1. Identifiqueu totes les entitats i els seus atributs.
  2. Identifiqueu les relacions i la seva cardinalitat amb notació (min, max).
  3. Identifiqueu si hi ha entitats dèbils.
  4. Dibuixeu el diagrama ER amb Mermaid.