El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència
HOME Els meus cursos Finalitzats
◄ Anterior
◄

Diagrames Entitat-Relació (ER)

Següent ►
►

A la lliçó anterior vam tancar el document de requisits v1.0 de l'ampliació de BiblioRed: catorze requisits funcionals, deu regles de negoci, dotze consultes i un abast delimitat. És un text excel·lent per discutir amb el client i absolutament inservible per programar. Entre aquestes dues coses hi falta un pas: convertir la prosa en un dibuix.

El model entitat-relació és aquest dibuix. El va proposar Peter Chen el 1976 —el vam situar a la lliçó 01-03— i continua sent, cinquanta anys després, la manera estàndard de pensar un domini abans de tocar el teclat. No és un diagrama decoratiu que es fa al final per documentar: és una eina de raonament. Dibuixar obliga a decidir coses que la prosa permet deixar vagues, i per això la meitat de les preguntes útils d'un projecte apareixen mentre es traça una línia entre dues caixes.

Aquesta lliçó ensenya el llenguatge complet —entitats, atributs, relacions, cardinalitat, participació, jerarquies— i l'aplica, decisió a decisió, a l'encàrrec de BiblioRed. L'entregable és el diagrama ER complet de BiblioRed ampliat, integrant les set taules que ja existien amb tot el que és nou. Continua sense haver-hi ni una sola sentència CREATE TABLE: això és la lliçó següent, i hi ha una raó per a l'ordre.

Contingut

  1. Què és un model conceptual i per què es dibuixa abans que existeixi cap taula
  2. Entitats: fortes i febles
  3. Atributs: simples, compostos, multivaluats, derivats i identificadors
  4. Relacions: binàries, reflexives, ternàries i amb atributs propis
  5. Cardinalitat: 1:1, 1:N i N:M
  6. Participació total o parcial: l'altra meitat que tothom confon
  7. Les notacions: Chen enfront de pota de gall
  8. El model ER estès: generalització i especialització
  9. Dibuixar BiblioRed, decisió a decisió
  10. Entregable: el diagrama ER complet de BiblioRed ampliat
  11. Eines per dibuixar diagrames
  12. Errors Habituals i Consells
  13. Exercicis
  14. Conclusió

  1. Què és un model conceptual i per què es dibuixa abans que existeixi cap taula

Un model conceptual és una representació del que existeix en un domini i de com es relaciona, sense comprometre's amb cap tecnologia. No diu taules ni documents ni columnes ni tipus. Diu: aquí hi ha socis, aquí hi ha esdeveniments, i un soci s'inscriu a molts esdeveniments.

Que sigui independent de la tecnologia no és purisme acadèmic: és el que li dóna la seva utilitat. Tres conseqüències pràctiques:

Es pot discutir amb qui no és informàtic. La coordinadora d'activitats de BiblioRed no revisarà un CREATE TABLE, però sí que pot mirar una línia entre "esdeveniment" i "sala" i dir "això està malament, el contacontes d'estiu el fem al pati". Aquest comentari, fet a la fase del dibuix, costa esborrar una línia. Fet tres mesos després, costa una migració.

Serveix igual per a relacional que per a documental. El mateix diagrama de BiblioRed pot derivar en un esquema PostgreSQL (04-03) o en col·leccions de MongoDB amb les tècniques de 03-03. La decisió d'incrustar o referenciar es pren després, sobre el model conceptual ja tancat. Un diagrama ER és, en aquest sentit, més durador que qualsevol dels dos esquemes.

Fa visibles els forats. La prosa tolera l'ambigüitat; un dibuix, no. Tan bon punt es traça la línia entre ESDEVENIMENT i SALA cal decidir tres coses obligatòriament: quantes sales per esdeveniment, quants esdeveniments per sala, i si pot haver-hi un esdeveniment sense sala. La prosa de R4 no responia la tercera.

El criteri de qualitat d'un model conceptual no és que sigui bonic, sinó que cada línia sigui una afirmació verificable sobre el negoci que algú pugui confirmar o desmentir.

  1. Entitats: fortes i febles

Una entitat és una cosa del domini amb existència pròpia i sobre la qual volem desar informació. Un conjunt d'entitats (el que col·loquialment anomenem "l'entitat") és el tipus: SOCI, ESDEVENIMENT, SALA. Una instància és un individu concret: la sòcia Marta Alsina, el club de lectura del 14 de maig.

Entitat forta

Una entitat forta té un identificador propi i existeix per si sola. SOCI és forta: Marta Alsina existeix encara que mai no demani un préstec. SALA és forta, ESDEVENIMENT és forta, PONENT és forta.

Entitat feble

Una entitat feble no es pot identificar per si mateixa: necessita la identitat d'una altra entitat, anomenada entitat propietària o identificadora. Dos senyals inequívocs:

  1. Les seves instàncies no tenen sentit sense la seva propietària.
  2. El seu identificador és parcial: distingeix instàncies només dins d'una propietària.

L'exemple canònic a BiblioRed és l'exemplar. Segons R2, els exemplars es numeren dins del seu material: "l'exemplar 3 d'El mapa del temps". El número 3 no identifica res tot sol —hi ha un exemplar 3 de cada material del catàleg—; el que identifica és la parella (material, número). Aquest "3" és l'identificador parcial o discriminant.

Entitat Tipus Identificador Per què
MATERIAL Forta Identificador propi Un material existeix al catàleg encara que no s'hagi comprat encara cap exemplar
EXEMPLAR Feble de MATERIAL (material, núm. d'exemplar) "Exemplar 3" no significa res sense dir de què
INSCRIPCIO Feble d'ESDEVENIMENT i SOCI (esdeveniment, soci) Una inscripció no existeix sense tots dos
TELEFON Feble de SOCI (soci, número) Un telèfon solt no és una entitat del domini
PAGAMENT Feble de MULTA (multa, núm. de pagament) Un pagament només té sentit contra una multa concreta

Una precisió que evita molta confusió: al model conceptual, una entitat és feble per una raó semàntica (no existeix sense l'altra), no perquè li posarem una clau composta. El segon és una conseqüència habitual, però és una decisió de la fase lògica, i a 04-03 veurem que de vegades es resol amb clau subrogada per comoditat sense deixar de ser conceptualment feble.

La pregunta que decideix: si desaparegués l'entitat propietària, tindria sentit conservar aquesta? Si desapareix "El mapa del temps" del catàleg, té sentit conservar-ne l'exemplar 3? No. És feble.

  1. Atributs: simples, compostos, multivaluats, derivats i identificadors

Un atribut és una propietat d'una entitat o d'una relació. N'hi ha cinc tipus i distingir-los importa, perquè cadascun es transforma d'una manera diferent a 04-03.

Simple (o atòmic)

Un valor indivisible per al negoci: aforament, titol, data_inscripcio. És el cas normal.

Compost

Un atribut que es descompon en parts amb significat propi. El cas de BiblioRed és R13: l'adreça d'una sucursal, avui un text únic, que el web necessita descompondre en carrer, número, codi postal i ciutat.

                    ┌── carrer
                    ├── numero
     adreca ────────┤
                    ├── codi_postal
                    └── ciutat

La pregunta per decidir si es descompon és sempre la mateixa: algú buscarà, filtrarà o ordenarà per una de les parts? R13 diu explícitament que sí (cercar per codi postal), així que es descompon. Si ningú no ho hagués de fer, un text únic seria l'opció correcta i més simple.

Multivaluat

Un atribut que pot tenir diversos valors alhora per a la mateixa instància. A BiblioRed n'hi ha dos, i tots dos es detecten per un plural a l'enunciat:

  • Els idiomes de subtítols d'un DVD (R1).
  • Els telèfons d'un soci, fins a tres (R12).

És important no confondre'l amb un atribut que canvia amb el temps: l'estat d'un exemplar canvia, però en cada moment en té un de sol. Multivaluat significa simultani.

Derivat

Un atribut el valor del qual es calcula a partir d'altres i per tant no cal emmagatzemar-lo. BiblioRed en té diversos:

Atribut derivat Es calcula a partir de Requisit
Places lliures d'un esdeveniment places_ofertes − inscripcions confirmades (amb acompanyants) C2, RN2
Import pendent d'una multa import − suma dels seus pagaments R11
Dies de retard d'un préstec data_devolucio − data_devolucio_prevista R10
Sucursal d'un esdeveniment La sucursal de la seva sala R4
Núm. d'exemplars d'un material Recompte dels seus exemplars RN10

En un diagrama es marquen (clàssicament, amb un oval de línia discontínua) precisament per deixar constància que no es desen. Que de vegades se n'acabi desant un per rendiment és una decisió posterior i conscient, que té nom —desnormalització— i s'estudia a 05-04.

Identificador (o clau)

L'atribut, o conjunt d'atributs, que distingeix una instància d'una altra dins del conjunt. Al model conceptual s'anomena clau candidata; quan se n'escull una, és la clau primària. Reprenem aquí exactament el de 02-01 i la decisió de disseny de l'apartat 10 de 04-01.

A BiblioRed la sala il·lustra un matís fi: segons R3, el nom de sala només és únic dins de la seva sucursal. És a dir, nom no és identificador de SALA, però la parella (sucursal, nom) sí que ho és. Un identificador que necessita l'entitat relacionada és la marca clàssica d'una entitat feble… i en efecte, una sala és conceptualment feble respecte de la seva sucursal. Ho assumirem així i a 04-03 veurem què en fem.

Taula resum

Tipus d'atribut Senyal per detectar-lo Exemple a BiblioRed Com es transforma (04-03)
Simple Un valor, indivisible aforament, titol Una columna
Compost Es pot trossejar amb sentit adreca de sucursal Diverses columnes, o una si ningú no busca per les parts
Multivaluat Apareix en plural subtítols d'un DVD, telèfons Taula a part
Derivat "Es calcula", "és el total de" places lliures, deute pendent No es desa (o vista / columna generada)
Identificador "Cada X té el seu número" ISBN, codi d'exemplar Clau primària o UNIQUE

  1. Relacions: binàries, reflexives, ternàries i amb atributs propis

Una relació (o interrelació) és una associació entre instàncies d'entitats. A l'enunciat gairebé sempre correspon a un verb: un soci s'inscriu a un esdeveniment, un esdeveniment se celebra en una sala, un préstec genera una multa.

Grau de la relació

El grau és quantes entitats hi participen:

Grau Nom Exemple a BiblioRed
2 Binària SOCI — s_inscriu — ESDEVENIMENT
1 Reflexiva (o recursiva) Un material *és la continuació d'*un altre material
3 Ternària ESDEVENIMENT — PONENT — ROL: qui hi participa, en quin esdeveniment, amb quin paper (R7)

La immensa majoria de les relacions útils són binàries. Les de grau superior són rares, difícils de llegir i gairebé sempre són tres binàries disfressades; hi tornarem a l'apartat 9 i amb més contundència a 04-03.

Relació reflexiva

És una relació d'una entitat amb ella mateixa. Es llegeix sempre amb dos rols diferents, i sense anomenar-los el diagrama és incomprensible.

        ┌──────────────┐
        │   MATERIAL   │
        └──┬────────┬──┘
   (obra)  │        │  (continuacio)
           └───◇────┘
           es_continuacio_de

A BiblioRed no és als requisits v1.0, però és útil veure-la perquè apareix en gairebé tots els dominis: empleat/cap, categoria/subcategoria, material/seqüela.

Relació amb atributs propis

Aquest és el concepte més important de l'apartat. Hi ha dades que no pertanyen a cap de les dues entitats, sinó al seu creuament.

Pensa en la inscripció de R6. La data d'inscripció, és un atribut del soci? No: un soci no té "una data d'inscripció", en té moltes, una per esdeveniment. És un atribut de l'esdeveniment? Tampoc, pel mateix motiu. És un atribut de la relació: existeix només quan aquell soci concret es creua amb aquell esdeveniment concret.

Relació Atributs propis Requisit
SOCI — s_inscriu — ESDEVENIMENT data d'inscripció, estat, acompanyants R6
PONENT — participa — ESDEVENIMENT rol, honoraris R7
ESDEVENIMENT — tracta — MATERIAL paper (principal / recomanat) R8

La regla infal·lible per detectar-los: si un atribut necessita saber totes dues claus per tenir un valor, pertany a la relació. "Quins són els honoraris d'Elena Roig?" no té resposta; "quins són els honoraris d'Elena Roig al taller del 12 de juny?" sí.

Les relacions N:M sempre admeten atributs propis; les 1:N també en poden tenir, encara que a la pràctica s'acaben absorbint al costat N.

  1. Cardinalitat: 1:1, 1:N i N:M

La cardinalitat (o raó de cardinalitat) respon a: amb quantes instàncies de l'altre costat es pot associar una instància d'aquest?

Tipus Significat Exemple a BiblioRed Requisit
1:1 Cada A amb com a molt un B, i cada B amb com a molt un A ESDEVENIMENT — té — INFORME R9
1:N Cada A amb molts B; cada B amb un sol A SALA — acull — ESDEVENIMENT R4
N:M Cada A amb molts B i cada B amb molts A SOCI — s_inscriu — ESDEVENIMENT R6

Com es determina, a la pràctica

Es fan dues preguntes, una per sentit, i s'anota cada resposta:

Pregunta 1: Un esdeveniment, en quantes sales se celebra? → En una (R4). Pregunta 2: Una sala, quants esdeveniments acull? → Molts.

Conclusió: SALA 1 — N ESDEVENIMENT.

Repetit per a les relacions noves de BiblioRed:

Relació Quants del costat dret? Quants del costat esquerre? Cardinalitat
SUCURSAL – té – SALA Una sucursal té 1..6 sales Una sala és a 1 sucursal 1:N
TIPUS_ESDEVENIMENT – classifica – ESDEVENIMENT Un tipus classifica molts esdeveniments Un esdeveniment té 1 tipus 1:N
SALA – acull – ESDEVENIMENT Una sala acull molts esdeveniments Un esdeveniment fa servir 1 sala 1:N
SOCI – s_inscriu – ESDEVENIMENT Un soci s'inscriu a molts Un esdeveniment admet molts socis N:M
PONENT – participa – ESDEVENIMENT Un ponent participa en molts Un esdeveniment té diversos ponents N:M
ESDEVENIMENT – tracta – MATERIAL Un esdeveniment tracta diversos materials Un material es tracta en diversos esdeveniments N:M
ESDEVENIMENT – té – INFORME Un esdeveniment té 0 o 1 informe Un informe és d'1 esdeveniment 1:1
PRESTEC – genera – MULTA Un préstec genera 0..3 multes (una per motiu) Una multa ve d'1 préstec 1:N
MULTA – es_liquida – PAGAMENT Una multa rep diversos pagaments Un pagament és d'1 multa 1:N
MATERIAL – té – EXEMPLAR Un material té 0..N exemplars Un exemplar és d'1 material 1:N

Cardinalitat mínima i màxima

L'anterior és la cardinalitat màxima (1 o "molts"). També existeix la mínima (0 o 1), i és la que expressa l'obligatorietat. La notació completa, molt usada a Europa, escriu totes dues: (0,1), (1,1), (0,N), (1,N).

   ESDEVENIMENT ──(1,1)──◇ se_celebra_a ◇──(0,N)── SALA

Es llegeix: un esdeveniment se celebra en una sala com a mínim i com a màxim (obligatori, exactament una); una sala acull entre zero i molts esdeveniments. Aquest (0,N) diu que pot existir una sala sense cap esdeveniment, cosa que la cardinalitat 1:N sola no deia.

Un detall que confon molta gent: a la notació (mín,màx), els números s'anoten al costat de l'entitat que descriuen, mentre que a la notació de pota de gall els símbols es dibuixen al costat de l'entitat de l'altre extrem. És la causa més freqüent de diagrames llegits a l'inrevés.

  1. Participació total o parcial: l'altra meitat que tothom confon

La participació respon a una pregunta diferent de la cardinalitat: ha de participar tota instància d'aquesta entitat en la relació, o pot haver-n'hi alguna que no hi participi?

  • Participació total (obligatòria): tota instància hi participa. Es dibuixa amb línia doble a Chen, o amb un traç perpendicular | a pota de gall.
  • Participació parcial (opcional): pot haver-hi instàncies que no hi participin. Cercle o a pota de gall.

Que siguin dues coses diferents es veu millor amb un exemple on no coincideixen:

Relació Cardinalitat Participació d'A Participació de B
ESDEVENIMENT (A) — té — INFORME (B) 1:1 Parcial: hi ha esdeveniments sense informe (R9) Total: no hi ha informe sense esdeveniment
MATERIAL (A) — té — EXEMPLAR (B) 1:N Parcial: un material acabat de catalogar pot no tenir exemplars encara (R2) Total: tot exemplar és d'algun material
SUCURSAL (A) — té — SALA (B) 1:N Total: tota sucursal té almenys una sala (R3, "entre 1 i 6") Total: tota sala és en una sucursal
SOCI (A) — s_inscriu — ESDEVENIMENT (B) N:M Parcial: la majoria de socis no s'inscriu a res Parcial: un esdeveniment acabat de crear no té inscrits

L'error clàssic és dir "és 1:N" i creure que amb això ja està tot dit. La cardinalitat diu quants; la participació diu si en cal almenys un. Són eixos independents i es combinen lliurement:

Participació parcial Participació total
Màx. 1 0 o 1 (opcional) Exactament 1 (obligatori)
Màx. N 0 o molts 1 o molts

Les conseqüències a la fase lògica són directíssimes i per això convé fixar-ho bé ara:

Decisió conceptual Conseqüència a 04-03 / 04-04
Participació total del costat N en una 1:N La clau forana és NOT NULL
Participació parcial del costat N La clau forana admet NULL
Participació total del costat 1 ("tota sucursal té ≥1 sala") No es pot expressar amb una restricció simple: necessita un disparador o validació a l'aplicació

Aquesta última fila és una limitació real del model relacional que convé conèixer des d'ara: "tota sucursal té almenys una sala" no ho garanteix cap clau forana. Es documenta com a regla de negoci i es decideix on viu; el criteri general el tanquem a 04-04.

  1. Les notacions: Chen enfront de pota de gall

El model ER té el mateix contingut en qualsevol notació; canvia el dibuix. Cal conèixer-ne dues.

Notació de Chen (1976)

L'original. Rectangles per a entitats, rombes per a relacions, ovals per a atributs, penjant de la seva entitat.

                 ┌──────────┐              ┌────────────────┐
        (nom)────│          │              │                │────(titol)
                 │  SALA    │              │  ESDEVENIMENT  │
   (aforament)───│          │◇────────────◇│                │────(inici)
                 └──────────┘   acull      └────────────────┘
                       1            N

És molt expressiva —els atributs es veuen, els atributs derivats porten oval discontinu, els multivaluats oval doble— i per això es fa servir a l'ensenyament. I és impracticable en un domini real: un diagrama de vint entitats amb tots els seus atributs en ovals no cap en cap pantalla ni en cap paret.

Notació de pota de gall (crow's foot, Bachman/Barker)

La que s'usa avui a la indústria i la que implementen totes les eines. Les entitats són caixes amb la llista d'atributs a dins, les relacions són línies, i els símbols dels extrems codifiquen cardinalitat i participació alhora.

Els símbols es llegeixen a l'extrem que toca l'entitat, i descriuen quantes instàncies d'aquesta entitat corresponen a una de l'altre costat:

Símbol ASCII Mínim Màxim Es llegeix
Traç + traç || 1 1 Exactament un
Cercle + traç o| 0 1 Zero o un
Traç + pota |{ 1 N Un o molts
Cercle + pota o{ 0 N Zero o molts

Taula d'equivalència entre notacions

Concepte Chen Pota de gall Mermaid erDiagram
Entitat forta Rectangle simple Caixa ENTITAT { ... }
Entitat feble Rectangle doble Caixa, línia identificadora -- (línia sòlida)
Relació Rombe Línia amb etiqueta A ||--o{ B : "verb"
Relació identificadora Rombe doble Línia contínua --
Relació no identificadora — Línia discontínua ..
Atribut Oval Fila dins de la caixa Fila amb tipus i nom
Atribut clau Oval subratllat Marca PK PK
Atribut multivaluat Oval doble No existeix: es treu a una altra entitat Entitat a part
Atribut derivat Oval discontinu No existeix: s'anota o s'omet Comentari
Atribut compost Oval amb ovals fills No existeix: columnes separades Files separades
Cardinalitat màx. 1 1 al costat del rombe || o o| || / o|
Cardinalitat màx. N N al costat del rombe |{ o o{ |{ / o{
Participació total Línia doble Traç | |
Participació parcial Línia simple Cercle o o
Relació ternària Rombe amb tres línies No existeix: es converteix en entitat Entitat intermèdia

Fixa't en les quatre files on posa "no existeix". Pota de gall perd expressivitat respecte de Chen en atributs multivaluats, derivats, compostos i relacions ternàries. No és un defecte casual: pota de gall és a mig camí entre el model conceptual i el lògic, i aquests quatre conceptes desapareixen en la transformació a taules (els veurem morir un a un a 04-03). Per això la pràctica habitual és: pensar en Chen, dibuixar en pota de gall i anotar en text el que la notació no recull. És exactament el que farem amb BiblioRed.

Un advertiment sobre mermaid

Mermaid implementa pota de gall. És una eina excel·lent perquè el diagrama viu com a text al repositori, al costat del codi, i es versiona amb ell. Però hereta les quatre limitacions anteriors i n'afegeix una de pròpia: no dibuixa jerarquies de generalització. Quan apareguin, a l'apartat 8, les explicarem amb taules i ASCII.

  1. El model ER estès: generalització i especialització

El model ER bàsic no sabia expressar que "un llibre és un tipus de material". El model ER estès (EER) hi afegeix les jerarquies de tipus, i és exactament el que R1 necessita.

El problema de BiblioRed

R1 diu que el catàleg ha d'admetre llibres, DVD, revistes i audiollibres. Tots comparteixen títol, idioma, editorial, any i data d'alta. Cadascun té el que és seu: ISBN i pàgines el llibre; durada, format i regió el DVD; ISSN, número i periodicitat la revista; durada, narrador i format l'audiollibre.

Modelar-ho com a quatre entitats independents trenca tota la resta: un exemplar hauria d'apuntar a una de les quatre i no se sabria a quina; un préstec tampoc; i la consulta C10 ("els deu materials més prestats, desglossats per tipus") necessitaria unir quatre consultes. Modelar-ho com una sola entitat amb tots els atributs deixa narrador a NULL al 90 % de les files i fa impossible exigir que un llibre tingui ISBN.

La solució és la generalització: una superentitat MATERIAL amb el que és comú i quatre subentitats amb el que és específic.

                        ┌───────────────────────┐
                        │       MATERIAL        │
                        │  material_id (PK)     │
                        │  titol, idioma,       │
                        │  editorial, any,      │
                        │  data_alta, autor     │
                        └───────────┬───────────┘
                                    │
                                   ╱d╲          d = disjunta
                                  ╱   ╲         linia doble = total
                        ══════════╧════╧══════════
                    │           │           │           │
            ┌───────┴──┐ ┌──────┴───┐ ┌─────┴────┐ ┌────┴───────┐
            │  LLIBRE  │ │   DVD    │ │ REVISTA  │ │AUDIOLLIBRE │
            │ isbn     │ │ durada   │ │ issn     │ │ durada     │
            │ pagines  │ │ format   │ │ numero   │ │ narrador   │
            │ enquad.  │ │ regio    │ │ periodic.│ │ format     │
            └──────────┘ │{subtitol}│ └──────────┘ └────────────┘
                         └──────────┘

Els dos eixos que cal decidir

Tota jerarquia es caracteritza per dues propietats independents, i cal fixar-les explícitament perquè canvien el disseny:

Eix 1 — Disjunció enfront de solapament

Significat Exemple
Disjunta (disjoint, d) Una instància pertany com a molt a una subentitat Un material és llibre o DVD o revista o audiollibre
Solapada (overlapping, o) Una instància pot pertànyer a diverses Una persona pot ser alhora soci i ponent

Eix 2 — Totalitat enfront de parcialitat

Significat Exemple
Total (línia doble) Tota instància de la superentitat pertany a alguna subentitat Tot material és d'un dels quatre tipus
Parcial (línia simple) Pot haver-hi instàncies que no siguin de cap subtipus Un empleat que no és ni comercial ni tècnic

Combinant-los surten quatre casos, i cadascun s'implementa diferent a 04-03:

Combinació Què significa Conseqüència a l'esquema
Total i disjunta Cada instància és exactament en una subentitat Es pot fer servir qualsevol de les tres estratègies; la "taula per classe concreta" només és viable aquí
Total i solapada Cada instància és en una o més Força taula única o taula per subclasse
Parcial i disjunta Zero o una subentitat Taula única o taula per subclasse; la superentitat ha de poder existir sola
Parcial i solapada El cas més flexible i més costós Taula per subclasse

La decisió de BiblioRed

La jerarquia de materials és total i disjunta. Es va discutir amb el client i va quedar escrit:

  • Total: tot el que es cataloga és d'un dels quatre tipus. Si demà arriben mapes o partitures, s'afegeix un subtipus. No existeixen materials "genèrics".
  • Disjunta: un material concret és llibre o audiollibre, mai tots dos. La versió narrada d'"El mapa del temps" és un altre material diferent, amb el seu propi identificador, no el mateix material amb dues natures. Aquesta pregunta es va fer explícitament i la resposta orienta tot el disseny.

Un contraexemple útil per veure que no sempre és així: si BiblioRed decidís modelar PERSONA com a superentitat de SOCI i PONENT, aquesta jerarquia seria solapada (un soci pot fer un taller) i parcial (hi ha persones al sistema que no són ni una cosa ni l'altra). A la v1.0 no es fa: R7 diu que els ponents són entitat pròpia, i duplicar el nom de les quatre persones que són totes dues coses és un preu menor comparat amb la complicació d'una jerarquia solapada. És una decisió conscient i va al registre de decisions.

Les tres estratègies per portar aquesta jerarquia a taules —taula única, taula per subclasse, taula per classe concreta— amb la seva taula comparativa d'avantatges i inconvenients són l'apartat 10 de la lliçó següent.

  1. Dibuixar BiblioRed, decisió a decisió

Ara recorrem el document de requisits de 04-01 i construïm el diagrama. El valor d'aquest apartat és a les preguntes de cada pas, no en el resultat.

Pas 1 — Punt de partida: el que ja existeix

Set entitats de l'esquema actual: SUCURSAL, AUTOR, SOCI, LLIBRE, EXEMPLAR, PRESTEC, RESERVA. No es toquen per caprici, però R1 obliga a un canvi estructural: LLIBRE es converteix en subentitat de MATERIAL, i les relacions que apuntaven a LLIBRE (EXEMPLAR i RESERVA) passen a apuntar a MATERIAL. És el canvi més profund de tota l'ampliació i convé identificar-lo aviat.

Pas 2 — Sales (R3)

  • Entitat? Sí: té atributs propis (aforament, planta, accessible) i cicle de vida.
  • Relació amb sucursal? SUCURSAL 1 — N SALA.
  • Participació? Total als dos costats: tota sala és en una sucursal i tota sucursal té entre 1 i 6 sales.
  • Decisió fina: el nom només és únic dins de la sucursal (R3). Conceptualment, SALA és una entitat feble de SUCURSAL amb discriminant nom.

Pas 3 — Tipus d'esdeveniment (R5)

Apliquem els criteris de l'apartat 8 de 04-01: té atributs propis (descripció, durada estàndard), l'usuari gestiona el conjunt de valors. Entitat, amb relació TIPUS_ESDEVENIMENT 1 — N ESDEVENIMENT. Participació total del costat de l'esdeveniment (tot esdeveniment té tipus), parcial del costat del tipus (pot haver-hi un tipus acabat de crear sense esdeveniments).

Pas 4 — Esdeveniments (R4)

Entitat forta, amb titol, descripcio, inici, fi, places_ofertes, estat, publicat.

  • Relació amb SALA: 1:N (una sala, molts esdeveniments).
  • Pregunta obligada de la participació: pot haver-hi un esdeveniment sense sala? Aquí és on la coordinadora va esmentar el contacontes d'estiu al pati. Decisió: participació parcial —la sala és opcional—, però RN8 exigeix que si l'esdeveniment està publicat, tingui sala. S'anota com a regla de negoci per a 04-04.
  • Atribut derivat: la sucursal de l'esdeveniment és la de la seva sala (R4). No es dibuixa com a relació amb SUCURSAL: seria redundància. S'anota com a derivat.
  • Atribut derivat: les places lliures (C2). Tampoc no es desa.

Pas 5 — Inscripcions (R6)

Aquí hi ha el cor de l'ampliació.

  • Cardinalitat? Un soci a molts esdeveniments, un esdeveniment amb molts socis: N:M.
  • Té atributs propis? Sí: data, estat, acompanyants. Relació N:M amb atributs.
  • Identificador? La parella (esdeveniment, soci), que és literalment la regla de R6 ("un soci no es pot inscriure dues vegades al mateix esdeveniment"). És a dir: entitat feble dependent de dues propietàries.
  • Participació? Parcial a tots dos costats.

Aquest és el punt on el model conceptual paga el seu preu: a Chen seria un rombe amb tres ovals penjant; a pota de gall cal dibuixar-ho ja com una caixa intermèdia. No és un error de la notació, és l'avançament de la transformació de 04-03.

Pas 6 — Ponents i participacions (R7)

  • PONENT: entitat forta (nom, cognoms, email, biografia, si és extern).
  • Relació amb ESDEVENIMENT: N:M amb atributs (rol, honoraris).
  • La trampa: R7 diu que en un mateix esdeveniment una persona pot exercir més d'un paper. Això significa que la parella (esdeveniment, ponent) no identifica la participació: cal el rol. Conceptualment és una relació ternària entre ESDEVENIMENT, PONENT i ROL.

És ROL una entitat de debò? Aplicant els criteris de 04-01: conjunt petit (moderador, tallerista, autor convidat, presentador), estable, sense atributs propis, ningú no el gestiona. És un atribut, no una entitat. Així que en lloc d'una ternària pura tenim una N:M identificada per (esdeveniment, ponent, rol), amb rol com a part de l'identificador. És la forma habitual com les ternàries aparents es resolen a la pràctica, i a 04-03 hi tornarem amb la regla 9.

Pas 7 — Materials tractats en un esdeveniment (R8)

N:M neta entre ESDEVENIMENT i MATERIAL, amb un atribut propi: paper (principal / recomanat). Participació parcial a tots dos costats. És l'exemple més simple de N:M del diagrama i serveix de contrast amb els dos anteriors.

Pas 8 — Informe de l'esdeveniment (R9)

  • Cardinalitat 1:1: un esdeveniment té com a molt un informe, un informe és d'un esdeveniment.
  • Participació: parcial del costat de l'esdeveniment (molts esdeveniments no tenen informe), total del costat de l'informe.
  • Pregunta obligada: per què no ficar els tres camps de l'informe dins d'ESDEVENIMENT? Perquè només tenen valor per a esdeveniments ja celebrats; a ESDEVENIMENT estarien a NULL a la majoria de les files i no es podria distingir "encara no redactat" de "zero assistents". La discussió completa de les tres opcions per a una 1:1 és la regla 6 de 04-03.

Pas 9 — Multes i pagaments (R10, R11)

  • MULTA es relaciona amb PRESTEC: 1:N, perquè un préstec pot generar fins a tres multes, una per motiu.
  • Decisió discutible i per això interessant: es relaciona la multa també amb el soci? El soci es pot obtenir pel préstec, així que seria derivat. Però R10 admet multes per pèrdua que podrien no venir d'un préstec (un soci que perd un material que va consultar a la sala). Es decideix mantenir la relació directa amb SOCI i fer que la relació amb PRESTEC sigui de participació parcial. Queda registrat com a decisió, amb el seu motiu.
  • PAGAMENT és entitat feble de MULTA (1:N): un pagament no existeix sense la seva multa. Participació total del costat del pagament, parcial del costat de la multa (una multa acabada d'emetre no té pagaments).
  • Atribut derivat: l'import pendent (R11). No es desa.

Pas 10 — Atributs multivaluats (R12, R1)

Els dos plurals de l'enunciat es converteixen en entitats febles:

  • TELEFON feble de SOCI, amb discriminant numero i atribut tipus.
  • SUBTITOL feble de DVD, amb discriminant idioma.

Pas 11 — Atribut compost (R13)

L'adreça de la sucursal es descompon en carrer, número, codi postal i ciutat. No genera entitat ni relació: és un canvi dins de la caixa de SUCURSAL.

Resum de les decisions registrades

# Decisió Alternativa descartada Motiu
D1 LLIBRE passa a ser subtipus de MATERIAL Quatre entitats independents Exemplars, préstecs i reserves necessiten una entitat comuna (R1, C10)
D2 Jerarquia total i disjunta Solapada Un audiollibre és un altre material, no el mateix amb dues cares
D3 TIPUS_ESDEVENIMENT és entitat Atribut de text L'usuari ha de poder afegir tipus (R5)
D4 La sala de l'esdeveniment és opcional Obligatòria Esdeveniments a l'aire lliure; RN8 l'exigeix només si està publicat
D5 ROL és atribut, no entitat Ternària pura amb entitat ROL Conjunt estable i sense atributs propis
D6 MULTA es relaciona amb SOCI i amb PRESTEC Només amb PRESTEC Pot haver-hi multes sense préstec (pèrdua a la sala)
D7 L'informe va en entitat a part Columnes dins d'ESDEVENIMENT Nuls massius i ambigüitat entre "sense redactar" i "zero"
D8 PERSONA no es generalitza sobre SOCI i PONENT Jerarquia solapada parcial Complexitat desproporcionada per a quatre casos
D9 Places lliures, deute pendent i sucursal de l'esdeveniment són derivats Columnes emmagatzemades Redundància; es revisarà per rendiment a 05-04

  1. Entregable: el diagrama ER complet de BiblioRed ampliat

Aquest és el resultat. Està en notació de pota de gall amb mermaid, integra el que existeix i el que és nou, i va acompanyat de les anotacions que la notació no pot expressar.

erDiagram
    SUCURSALS ||--|{ SALES : "disposa de"
    SUCURSALS ||--o{ SOCIS : "dona d alta"
    SUCURSALS ||--o{ EXEMPLARS : "custodia"

    SOCIS ||--o{ TELEFONS_SOCI : "te"
    SOCIS ||--o{ PRESTECS : "realitza"
    SOCIS ||--o{ RESERVES : "sollicita"
    SOCIS ||--o{ INSCRIPCIONS : "s inscriu"
    SOCIS ||--o{ MULTES : "acumula"

    AUTORS ||--o{ MATERIALS : "escriu"

    MATERIALS ||--o{ EXEMPLARS : "es materialitza en"
    MATERIALS ||--o{ RESERVES : "es reservat en"
    MATERIALS ||--o{ ESDEVENIMENTS_MATERIALS : "es tracta en"
    MATERIALS ||--o| MATERIALS_LLIBRE : "es un"
    MATERIALS ||--o| MATERIALS_DVD : "es un"
    MATERIALS ||--o| MATERIALS_REVISTA : "es un"
    MATERIALS ||--o| MATERIALS_AUDIOLLIBRE : "es un"
    MATERIALS_DVD ||--o{ SUBTITOLS_DVD : "ofereix"

    EXEMPLARS ||--o{ PRESTECS : "es prestat en"
    PRESTECS ||--o{ MULTES : "genera"
    MULTES ||--o{ PAGAMENTS : "es liquida amb"

    SUCURSALS {
        int sucursal_id PK
        varchar nom UK
        varchar adr_carrer "compost R13"
        varchar adr_numero
        char adr_codi_postal
        varchar adr_ciutat
        varchar telefon
        date data_obertura
    }
    SALES {
        int sala_id PK
        int sucursal_id FK "feble: nom unic per sucursal"
        varchar nom
        int aforament
        smallint planta
        boolean accessible
    }
    SOCIS {
        int soci_id PK
        varchar nom
        varchar cognoms
        varchar email UK
        date data_alta
        int sucursal_id FK
        boolean actiu
    }
    TELEFONS_SOCI {
        int soci_id PK,FK "feble de SOCIS"
        varchar numero PK
        varchar tipus "mobil / fix / feina"
    }
    AUTORS {
        int autor_id PK
        varchar nom
        varchar cognoms
        varchar nacionalitat
        smallint any_naixement
    }
    MATERIALS {
        int material_id PK
        varchar tipus_material "llibre / dvd / revista / audiollibre"
        varchar titol
        int autor_id FK "opcional"
        varchar editorial
        smallint any_publicacio
        varchar idioma
        date data_alta
    }
    MATERIALS_LLIBRE {
        int material_id PK,FK
        varchar isbn UK
        int num_pagines
        varchar enquadernacio
    }
    MATERIALS_DVD {
        int material_id PK,FK
        int durada_min
        varchar format_video
        smallint codi_regio
    }
    MATERIALS_REVISTA {
        int material_id PK,FK
        varchar issn
        varchar numero
        varchar periodicitat
    }
    MATERIALS_AUDIOLLIBRE {
        int material_id PK,FK
        int durada_min
        varchar narrador
        varchar format_audio
    }
    SUBTITOLS_DVD {
        int material_id PK,FK "multivaluat R1"
        varchar idioma PK
    }
    EXEMPLARS {
        int exemplar_id PK
        varchar codi UK
        int material_id FK "feble: num_exemplar unic per material"
        smallint num_exemplar
        int sucursal_id FK
        varchar estat
        date data_adquisicio
    }
    PRESTECS {
        int prestec_id PK
        int soci_id FK
        int exemplar_id FK
        date data_prestec
        date data_devolucio_prevista
        date data_devolucio "nul si no retornat"
        numeric recarrec "OBSOLETA, veure MULTES"
    }
    RESERVES {
        int reserva_id PK
        int soci_id FK
        int material_id FK
        date data_reserva
        date data_expiracio
        varchar estat
    }
    MULTES {
        int multa_id PK
        int soci_id FK
        int prestec_id FK "opcional D6"
        varchar motiu "retard / deteriorament / perdua"
        numeric import
        date data_emissio
        varchar estat
    }
    PAGAMENTS {
        int pagament_id PK
        int multa_id FK "feble de MULTES"
        timestamptz data_pagament
        numeric import
        varchar metode
        varchar referencia
    }

    TIPUS_ESDEVENIMENT ||--o{ ESDEVENIMENTS : "classifica"
    SALES ||--o{ ESDEVENIMENTS : "acull"
    ESDEVENIMENTS ||--o{ INSCRIPCIONS : "rep"
    ESDEVENIMENTS ||--o| INFORMES_ESDEVENIMENT : "es documenta en"
    ESDEVENIMENTS ||--o{ PARTICIPACIONS : "compta amb"
    PONENTS ||--o{ PARTICIPACIONS : "intervé en"
    ESDEVENIMENTS ||--o{ ESDEVENIMENTS_MATERIALS : "tracta"

    TIPUS_ESDEVENIMENT {
        int tipus_esdeveniment_id PK
        varchar codi UK
        varchar nom
        varchar descripcio
        int durada_estandard_min
    }
    ESDEVENIMENTS {
        int esdeveniment_id PK
        varchar titol
        varchar descripcio
        int tipus_esdeveniment_id FK
        int sala_id FK "opcional D4"
        timestamptz inici
        timestamptz fi
        int places_ofertes
        varchar estat
        boolean publicat
    }
    INSCRIPCIONS {
        int esdeveniment_id PK,FK "N:M amb atributs R6"
        int soci_id PK,FK
        timestamptz data_inscripcio
        varchar estat
        smallint acompanyants
    }
    INFORMES_ESDEVENIMENT {
        int esdeveniment_id PK,FK "relacio 1:1 R9"
        int assistents_reals
        numeric valoracio_mitjana
        varchar observacions
        date data_redaccio
    }
    PONENTS {
        int ponent_id PK
        varchar nom
        varchar cognoms
        varchar email UK
        varchar biografia
        boolean extern
    }
    PARTICIPACIONS {
        int esdeveniment_id PK,FK "ternaria resolta D5"
        int ponent_id PK,FK
        varchar rol PK
        numeric honoraris
    }
    ESDEVENIMENTS_MATERIALS {
        int esdeveniment_id PK,FK "N:M R8"
        int material_id PK,FK
        varchar paper "principal / recomanat"
    }

El que el diagrama no pot dir (anotacions obligatòries)

Com vam advertir a l'apartat 7, hi ha quatre conceptes que pota de gall no representa. Van aquí, i formen part de l'entregable tant com el dibuix:

A. La jerarquia de generalització. Les quatre relacions MATERIALS ||--o| MATERIALS_* no són quatre relacions 1:1 independents: són una jerarquia total i disjunta. La restricció real, que cap línia no expressa, és:

Tot material pertany a exactament una de les quatre subentitats, i la subentitat ha de coincidir amb el valor de tipus_material.

B. Els atributs derivats. No apareixen en cap caixa, deliberadament:

Derivat Fórmula
Places lliures d'un esdeveniment places_ofertes − Σ(1 + acompanyants) de les inscripcions confirmades
Import pendent d'una multa import − Σ pagaments.import
Sucursal d'un esdeveniment esdeveniments → sales → sucursal_id
Deute total d'un soci Σ pendents de les seves multes en estat pendent
Dies de retard data_devolucio − data_devolucio_prevista

C. Les entitats febles. Mermaid dibuixa SALES com una entitat normal. L'afirmació real és que el nom de la sala només és únic dins de la seva sucursal, el mateix que num_exemplar dins del seu material. Anotat als comentaris de les caixes i recollit a 04-03.

D. Les regles de negoci RN1–RN10. Cap no és dibuixable. Continuen vives al document de 04-01 i es converteixen en restriccions a 04-04.

Validació del diagrama contra les consultes

Abans de donar per bo un model conceptual, es recorre la llista de consultes del document de requisits i es comprova que cadascuna té un camí al diagrama:

Consulta Camí al diagrama Respon?
C1 Agenda del mes per sucursal ESDEVENIMENTS → SALES → SUCURSALS, filtrant publicat Sí
C2 Places lliures ESDEVENIMENTS → INSCRIPCIONS (derivat) Sí
C3 Inscrits amb telèfon ESDEVENIMENTS → INSCRIPCIONS → SOCIS → TELEFONS_SOCI Sí
C4 Historial d'un soci SOCIS → INSCRIPCIONS → ESDEVENIMENTS Sí
C5 Ocupació per sala i trimestre SALES → ESDEVENIMENTS → INSCRIPCIONS Sí
C6 Recaptació per mes i mètode PAGAMENTS Sí
C7 Socis amb deute > 20 € SOCIS → MULTES → PAGAMENTS (derivat) Sí
C8 Catàleg per tipus i idioma MATERIALS Sí
C9 DVD amb subtítols en català MATERIALS_DVD → SUBTITOLS_DVD Sí
C10 Més prestats per tipus PRESTECS → EXEMPLARS → MATERIALS Sí
C11 Ponents amb > 3 esdeveniments PONENTS → PARTICIPACIONS Sí
C12 Esdeveniments sense informe ESDEVENIMENTS anti-join amb INFORMES_ESDEVENIMENT Sí

Dotze de dotze. Si alguna hagués fallat, el diagrama estaria incomplet, i és infinitament més barat descobrir-ho aquí que després d'escriure el DDL.

  1. Eines per dibuixar diagrames

Un repàs breu; el detall és a la lliçó 09-03.

Eina Tipus Nota
Mermaid Diagrama com a text El que hem fet servir. Viu al repositori, es versiona amb el codi, es renderitza a GitHub i en editors. Limitat en jerarquies i ternàries.
dbdiagram.io / DBML Diagrama com a text, al web Sintaxi específica de bases de dades; exporta a SQL.
PlantUML Diagrama com a text Més expressiu que mermaid; suporta jerarquies.
draw.io / diagrams.net Dibuix lliure Control total de l'aspecte, cap control de la coherència.
pgModeler, MySQL Workbench, DBeaver Modelatge amb enginyeria inversa Llegeixen una base existent i en dibuixen l'esquema; útils per documentar el que ja hi ha.
Paper i pissarra — Continua sent la millor per a les dues primeres hores.

El criteri d'elecció, més important que l'eina: per al model conceptual, prioritza la velocitat de canvi (paper, pissarra, mermaid), perquè el redibuixaràs deu vegades. Per al diagrama final que acompanya l'esquema, prioritza que visqui al costat del codi i es versioni amb ell, perquè un diagrama al disc dur d'algú és obsolet en tres setmanes.

Errors Habituals i Consells

Confondre cardinalitat amb participació. L'error número u. "És 1:N" no diu si el costat N pot estar buit. Les dues preguntes són diferents i cal fer-les totes dues, sempre, per a cada relació.

Posar el símbol de pota de gall al costat equivocat. Els símbols van al costat de l'entitat que descriuen, comptant quantes instàncies d'aquesta entitat hi ha per cada una de l'altre costat. A la notació (mín,màx) és a l'inrevés. Un diagrama llegit a l'inrevés genera claus foranes al costat incorrecte, que és dels errors més cars de corregir.

Modelar una relació N:M sense preguntar-se si té atributs. Gairebé totes en tenen. Si INSCRIPCIONS s'hagués dibuixat com una simple N:M sense caixa, no hi hauria on posar la data, l'estat ni els acompanyants, i R6 hauria quedat sense cobrir.

Crear entitats per al que són atributs. Una taula idiomes amb dues columnes, una taula estats amb quatre files, una taula nacionalitats... Multipliquen els JOIN sense aportar res. Aplica els cinc criteris de 04-01 abans de crear cada caixa.

Dibuixar relacions redundants. Si ESDEVENIMENT → SALA → SUCURSAL, dibuixar a més ESDEVENIMENT → SUCURSAL crea un cicle en què les dues rutes poden donar respostes diferents. Cada vegada que aparegui un cicle al diagrama, cal justificar-lo o eliminar-lo: gairebé sempre una de les arestes és derivada.

Oblidar la dimensió temporal. "Un soci pertany a una sucursal" és 1:N avui. Si cal saber a quina pertanyia el 2024, és una N:M amb dates. Preguntar "necessites l'històric?" a cada relació costa cinc segons.

Ficar atributs de rendiment al model conceptual. num_inscrits a ESDEVENIMENTS és la resposta a un problema que encara no existeix. Al conceptual va com a derivat; si el mesurament demostra que cal, es desa a la fase física amb els ulls oberts (05-04).

Consell: anomena les relacions amb un verb i en un sol sentit. "Acull", "genera", "es liquida amb". Un diagrama amb relacions sense nom o anomenades "té" és un diagrama que no es pot llegir en veu alta, i llegir-lo en veu alta és la millor validació disponible.

Consell: dibuixa primer sense atributs. Deu caixes i les línies entre elles. L'estructura es veu molt millor i els atributs, que són la part fàcil, s'afegeixen després.

Consell: compta les línies que surten de cada entitat. Una entitat amb set relacions acostuma a estar fent dues feines i és candidata a dividir-se. Una entitat sense cap acostuma a sobrar o a estar mal connectada.

Exercicis

Exercici 1 — Cardinalitat i participació

Per a cada afirmació, determina la cardinalitat i la participació de cada costat, i expressa-ho en notació de pota de gall amb mermaid (A ||--o{ B : "verb"). Justifica la participació citant el requisit.

  1. Un exemplar pertany a una sucursal; una sucursal custodia molts exemplars.
  2. Un pagament liquida una multa; una multa es liquida amb diversos pagaments.
  3. Un tipus d'esdeveniment classifica molts esdeveniments; un esdeveniment té un tipus.
  4. Un soci realitza molts préstecs; un préstec és d'un soci.
  5. Un esdeveniment té com a molt un informe; un informe és d'un esdeveniment.

Exercici 2 — Modelar una ampliació nova

BiblioRed afegeix a la v1.1 el requisit següent:

R15 — Préstec d'equips a associacions. Les associacions del barri (amb nom, CIF, persona de contacte i telèfon) es poden endur en préstec equips tècnics (projectors, altaveus, pantalles). Cada equip té un codi d'inventari, una descripció, la sucursal on es guarda i el seu estat. Un val de préstec pot incloure diversos equips alhora, té data de sortida, data prevista de devolució i data real. Si un equip torna espatllat es registra una incidència amb data, descripció i cost estimat de reparació. Un equip pot tenir diverses incidències al llarg de la seva vida.

Dibuixa el fragment de diagrama ER en mermaid. Indica per a cada relació la seva cardinalitat i participació, assenyala si hi ha entitats febles, atributs multivaluats o derivats, i anota almenys dues decisions de disseny amb el seu motiu.

Exercici 3 — Jerarquia de generalització

BiblioRed es planteja unificar SOCIS i PONENTS sota una superentitat PERSONES amb les dades comunes (nom, cognoms, email, telèfon).

  1. Determina si la jerarquia seria disjunta o solapada i total o parcial, justificant-ho amb els requisits.
  2. Enumera dos avantatges i dos inconvenients concrets de fer-ho.
  3. Decideix si ho faries a la v1.0 i escriu l'entrada del registre de decisions (decisió / alternativa descartada / motiu).

Solucions

Solució a l'Exercici 1

erDiagram
    SUCURSALS ||--o{ EXEMPLARS : "custodia"
    MULTES ||--o{ PAGAMENTS : "es liquida amb"
    TIPUS_ESDEVENIMENT ||--o{ ESDEVENIMENTS : "classifica"
    SOCIS ||--o{ PRESTECS : "realitza"
    ESDEVENIMENTS ||--o| INFORMES_ESDEVENIMENT : "es documenta en"
# Cardinalitat Participació esquerra Participació dreta Justificació
1 1:N Parcial (o{): una sucursal nova pot no tenir exemplars encara Total (||): tot exemplar és en alguna sucursal R2
2 1:N Parcial: una multa acabada d'emetre no té pagaments Total: no existeix pagament sense multa (entitat feble) R11
3 1:N Parcial: un tipus acabat de crear pot no tenir esdeveniments Total: tot esdeveniment té tipus R4, R5
4 1:N Parcial: la majoria de socis no té préstecs actius, i hi ha socis sense cap Total: tot préstec és d'un soci Esquema existent
5 1:1 Parcial (o|): la majoria d'esdeveniments no té informe Total: no hi ha informe sense esdeveniment R9

Nota sobre el cas 5: o| a l'extrem dret és el que distingeix una 1:1 opcional d'una 1:1 obligatòria, i és precisament el que justificarà posar l'informe en taula a part a 04-03.

Solució a l'Exercici 2

erDiagram
    ASSOCIACIONS ||--o{ VALS_EQUIP : "sollicita"
    SUCURSALS ||--o{ EQUIPS : "guarda"
    SUCURSALS ||--o{ VALS_EQUIP : "tramita"
    VALS_EQUIP ||--|{ LINIES_VAL : "inclou"
    EQUIPS ||--o{ LINIES_VAL : "es prestat en"
    EQUIPS ||--o{ INCIDENCIES_EQUIP : "pateix"

    ASSOCIACIONS {
        int associacio_id PK
        varchar nom
        varchar cif UK
        varchar contacte_nom
        varchar contacte_telefon
    }
    EQUIPS {
        int equip_id PK
        varchar codi_inventari UK
        varchar descripcio
        int sucursal_id FK
        varchar estat
    }
    VALS_EQUIP {
        int val_id PK
        int associacio_id FK
        int sucursal_id FK
        date data_sortida
        date data_prevista
        date data_devolucio "nul si no retornat"
    }
    LINIES_VAL {
        int val_id PK,FK "feble de VALS_EQUIP"
        int equip_id PK,FK
        varchar estat_devolucio
    }
    INCIDENCIES_EQUIP {
        int incidencia_id PK
        int equip_id FK
        int val_id FK "opcional"
        date data
        varchar descripcio
        numeric cost_estimat
    }
Relació Cardinalitat Participació Nota
ASSOCIACIONS – VALS_EQUIP 1:N Parcial / Total Una associació pot no haver demanat mai res
VALS_EQUIP – LINIES_VAL 1:N Total als dos costats (||--|{) Un val sense cap equip no té sentit
EQUIPS – LINIES_VAL 1:N Parcial / Total Un equip pot no haver-se prestat mai
EQUIPS – INCIDENCIES_EQUIP 1:N Parcial / Total La majoria d'equips no té incidències
  • Entitat feble: LINIES_VAL, identificada per (val_id, equip_id). És la N:M entre val i equip, i apareix perquè "un val inclou diversos equips" (el plural de l'enunciat).
  • Atribut multivaluat: cap d'explícit. Si es demanessin diversos telèfons de contacte per associació, n'apareixeria un altre.
  • Atributs derivats: dies de retard del val (data_devolucio − data_prevista), cost total d'incidències d'un equip.

Decisions registrades:

Decisió Alternativa descartada Motiu
ASSOCIACIONS és entitat pròpia, no un tipus de SOCIS Reutilitzar socis amb un camp es_associacio Els atributs són diferents (CIF, persona de contacte) i les regles de préstec també; barrejar-los produiria nuls massius i CHECK condicionals
INCIDENCIES_EQUIP penja d'EQUIPS, no de LINIES_VAL Penjar-la del val Un equip es pot espatllar fora d'un préstec; la relació amb el val es conserva com a opcional per saber qui el va tornar així
La persona de contacte és atribut, no entitat Entitat CONTACTES A la v1.1 no té atributs propis ni cicle de vida independent; si demà calen diversos contactes per associació, es promociona

Solució a l'Exercici 3

1. Naturalesa de la jerarquia.

  • Solapada: res no impedeix que un soci de BiblioRed imparteixi un taller. R7 diu explícitament que els ponents poden ser "personal propi o professionals externs", i cap de les dues categories no exclou ser soci. Una persona podria ser soci i ponent alhora.
  • Parcial: si la superentitat PERSONES recollís també, per exemple, contactes d'associacions o personal administratiu, hi hauria persones que no són ni socis ni ponents. Fins i tot limitant-la als dos subtipus actuals, és parcial en el sentit que res no garanteix que tota persona registrada sigui d'un dels dos tipus.

Per tant: jerarquia parcial i solapada, la combinació més flexible i també la més costosa d'implementar.

2. Avantatges i inconvenients.

Avantatges Inconvenients
Les dades de contacte d'una persona que és sòcia i ponent són en un sol lloc: es compleix "una cosa, un lloc" i un canvi d'email es fa una vegada Tota consulta sobre socis passa a necessitar un JOIN addicional: C3, C4 i C7 es compliquen sense guanyar res
El correu electrònic seria únic a nivell de persona, no per taula, evitant que la mateixa persona figuri amb dues adreces diferents La jerarquia solapada impedeix l'estratègia de taula per classe concreta i obliga a comprovar la coherència entre subtipus
Facilita futurs subtipus (personal, contacte d'associació) sense duplicar camps Sobreenginyeria per a quatre casos reals de solapament: es paga complexitat permanent per un benefici marginal

3. Decisió per a la v1.0: no fer-ho. Entrada del registre:

Decisió Alternativa descartada Motiu
SOCIS i PONENTS es mantenen com a entitats independents; no es crea la superentitat PERSONES Jerarquia de generalització parcial i solapada sobre PERSONES La coordinació estima quatre casos de solapament sobre 12.000 socis. El cost és un JOIN extra en totes les consultes de socis (C3, C4, C7) i comprovacions de coherència entre subtipus, davant del benefici d'evitar quatre duplicats. Es revisarà si el catàleg de persones creix amb més subtipus (personal, contactes d'associacions).

Aquesta última fila il·lustra el criteri de l'apartat 12.5 de la lliçó 04-01: la generalització és correcta des del punt de vista teòric i sobreenginyeria des del punt de vista pràctic. El disseny no és el model més pur, sinó el més adequat al problema real.

Conclusió

Aquesta lliçó ha convertit catorze requisits en prosa en un model conceptual complet.

  • Un model conceptual descriu què existeix i com es relaciona, sense comprometre's amb cap tecnologia. Això li permet discutir-se amb qui no és informàtic, servir igual per a relacional que per a documental, i —el més valuós— fer visibles els forats que la prosa tolera.
  • Les entitats són fortes o febles. Una entitat feble no s'identifica sola: necessita la de la seva propietària, i el seu identificador és parcial. A BiblioRed ho són els exemplars, les inscripcions, els telèfons, els pagaments i les sales.
  • Els atributs són de cinc tipus i cadascun es transformarà diferent: simple (columna), compost (diverses columnes), multivaluat (taula a part), derivat (no es desa) i identificador.
  • Les relacions es detecten en els verbs. El seu grau és gairebé sempre binari; les reflexives necessiten rols anomenats i les ternàries gairebé sempre amaguen alguna cosa més simple. El decisiu: les relacions poden tenir atributs propis, i la regla infal·lible per detectar-los és que necessitin totes dues claus per tenir valor.
  • La cardinalitat (1:1, 1:N, N:M) es determina amb dues preguntes, una per sentit. La participació (total o parcial) respon a una pregunta diferent —si pot haver-hi instàncies que no hi participin— i és un eix independent. Confondre-les és l'error més freqüent del modelatge.
  • Es coneixen dues notacions: Chen, més expressiva i només viable en dominis petits, i pota de gall, la de la indústria, que perd quatre conceptes (multivaluats, derivats, compostos i ternàries) precisament perquè estan a punt de desaparèixer en la transformació a taules. La pràctica correcta és pensar en Chen, dibuixar en pota de gall i anotar en text el que el dibuix no recull.
  • El model ER estès aporta la generalització/especialització, amb dos eixos que cal fixar sempre: disjunta o solapada i total o parcial. La jerarquia de materials de BiblioRed és total i disjunta, i aquesta decisió condiciona tot el que ve després.
  • El diagrama de BiblioRed es va construir en onze passos, amb nou decisions registrades amb el seu motiu i la seva alternativa descartada.
  • L'entregable és el diagrama ER complet en mermaid, amb vint-i-una entitats, més les quatre anotacions que la notació no pot expressar: la jerarquia, els derivats, les entitats febles i les deu regles de negoci.
  • El diagrama es va validar contra les dotze consultes del document de requisits, i les dotze tenen camí. Aquesta comprovació és el que separa un dibuix bonic d'un model utilitzable.

Tenim el dibuix, tenim les anotacions i tenim la validació. El que encara no tenim és ni una sola taula. A la lliçó següent, 04-03 Transformació de Diagrames ER a Esquemes Relacionals, aprendrem l'algorisme que converteix aquest diagrama en CREATE TABLE: deu regles mecàniques —entitat forta, atribut compost, multivaluat, derivat, 1:N, 1:1, N:M, entitat feble, ternària i jerarquia— cadascuna amb el seu exemple de BiblioRed i el seu SQL. Aquí és on els rombes es converteixen en claus foranes, els atributs multivaluats en taules i aquesta jerarquia total i disjunta de materials es resol, per fi, triant entre tres estratègies amb conseqüències molt diferents.

◄ Anterior
◄
Següent ►
►
El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència
© Copyright 2026. Tots els drets reservats