M2 - Bases de dades / UF1NF2: Diagrames entitat-relació

Els diagrames Entitat-Relació són un estàndard actual en el disseny de bases de dades. De fet, es tracta d’una eina sense la qual, possiblement, les bases de dades tal com les entenem actualment no existirien.

Els diagrames Entitat-Relació són eines gràfiques clau en el disseny de bases de dades. La seva confecció ha de ser sistemàtica i rigorosa si es vol obtenir un sistema vàlid i eficient, ja que serà a partir d’aquests diagrames que es desenvoluparà tota la implementació de bases de dades en els sistemes gestors de bases de dades concrets que correspongui a cada empresa o organisme.

Disseny de bases de dades

El disseny de BD s’estructura, fonamentalment, en tres grans etapes:

• Disseny conceptual

• Disseny lògic

• Disseny físic

Encara que ens centrem en l’estudi i en la pràctica del disseny conceptual, no s’han de perdre de vista les altres fases del disseny, que també són importants, per tal d’obtenir una visió de conjunt de tots aquests processos.

Conèixer com s’estructura el model Entitat-Relació és important. I també ho són qüestions que ens han de permetre aprofitar la tecnologia proporcionada per les BD i els corresponents sistemes gestors, com ara els següents:

• Quines entitats ha d’incloure una BD determinada.

• Quines interrelacions s’han de considerar.

• Quins atributs han d’existir i en quines entitats o interrelacions s’han d’incorporar.

• Quines claus primàries ja es poden establir en la fase de disseny conceptual.

Fases del disseny de BD

Dissenyar BD no és una tasca senzilla. Encara que la porció del món real que es vulgui modelitzar en un cas concret sigui relativament petita, les estructures de dades resultants poden arribar a tenir un cert grau de complexitat. Tanmateix, a mesura que augmenta la informació a considerar, i la seva complexitat, el model de dades necessari per representar-la es pot convertir, certament, en una construcció complicada.

Món real

Quan parlem de món real, ens referim a l’escenari o situació concreta que es vol modelitzar per tal de ser explotada mitjançant una BD.

Voler resoldre de cop tota la problemàtica que pot comportar la modelització d’una BD no és, doncs, una opció gaire realista. En afrontar una tasca d’aquesta envergadura, és preferible dividir-la en subtasques per tal de simplificar-la.

Així, doncs, resulta convenient descompondre el disseny de BD en diferents etapes, de manera que en cadascuna només s’examinin certs aspectes, o tipus de problemes, per tal de minimitzar la possibilitat d’error. Aleshores, a partir del resultat obtingut en cada fase, es pot continuar treballant en la fase següent, fins a arribar al resultat esperat, al final de l’última fase.

És habitual estructurar el disseny de BD en les tres etapes o fases següents:

1. Disseny conceptual.

2. Disseny lògic.

3. Disseny físic.

Fase de disseny conceptual

El primer que cal fer, durant la fase de disseny conceptual, és recopilar tota la informació necessària de la part del món real que ens proposem modelitzar amb una BD.

Aquesta recopilació d’informació es realitzarà per diferents vies, com ara aquestes:

• Entrevistes amb els futurs usuaris de la BD que s’està dissenyant.

• Examen de la documentació proporcionada per aquests mateixos usuaris.

• Observació directa dels processos a informatitzar.

A continuació, s’han d’estructurar convenientment les dades necessàries per tal de donar resposta a totes les necessitats derivades del conjunt d’informacions compendiades.

L’objectiu del disseny conceptual consisteix en l’obtenció d’una especificació sistemàtica.

L’esmentada especificació sistemàtica resultat del disseny conceptual ha de complir dos tipus de requisits:

• De dades. El model resultant ha de tenir en compte l’estructura completa de les dades i la seva integritat.

• Funcionals. Un bon esquema conceptual també haurà de preveure les necessitats bàsiques en matèria de manipulació de dades (és a dir, les operacions d’inserció, esborrament, consulta i modificació, d’aquestes). Durant les fases posteriors, pot ser convenient depurar el disseny per tal d’optimitzar les operacions a realitzar sobre les dades.

El model Entitat-Interrelació (o model Entitat-Relació) també es coneix de manera abreujada com a model ER (sigles corresponents a entity-relationship).

Finalment, cal triar un model de dades d’alt nivell i traduir els requisits anteriors a un esquema conceptual de la futura BD expressat amb els conceptes i la notació corresponents. Un dels models de dades d’alt nivell més utilitzats és el model entitat-interrelació.

Expressat en la terminologia del model ER, l’esquema de dades desenvolupat durant la fase de disseny conceptual ha d’especificar totes les entitats necessàries, i les interrelacions entre elles, amb les cardinalitats adequades, i també els atributs que corresponguin en cada cas.

El model ER

Una entitat, en el model ER, és una abstracció que ens interessa modelitzar, i mitjançant la qual s’agrupen les instàncies del món real que tenen unes característiques comunes.

Una interrelació, en el model ER, és l’associació entre instàncies de diferents entitats tipus. Aquesta associació es pot donar amb diverses cardinalitats.

Un atribut, en el model ER, és una característica d’una entitat que ens interessa tenir registrada.

El model resultant s’ha de revisar per tal de garantir la satisfacció de totes les necessitats detectades, d’una banda, i per evitar redundàncies de les dades (és a dir, repeticions indesitjades d’aquestes), d’una altra.

El resultat de la fase de disseny conceptual pertany a l’anomenat món de les concepcions, però encara no al món de les representacions, ja que no s’hi especifica cap representació informàtica concreta.

Com es pot veure, durant la fase de disseny conceptual no cal tenir en compte, encara, ni el tipus de BD que s’utilitzarà posteriorment ni, encara menys, el SGBD o el llenguatge concret amb el qual s’implementarà.

Fase de disseny lògic

En la fase de disseny lògic, es treballa amb el model abstracte de dades obtingut al final de l’etapa de disseny conceptual, per tal de traduir-lo al model de dades utilitzat pel sistema gestor de bases de dades (SGBD) amb el qual es vol implementar i mantenir la BD.

Les claus primàries serveixen per distingir entre si les diferents tuples d’atributs dins d’una mateixa relació.

Per tant, a partir d’aquesta fase de disseny, sí que cal tenir en compte la tecnologia concreta que s’ha d’emprar en la creació de la BD, ja que la BD resultant es pot adequar a diferents models lògics, com ara els següents:

• Jeràrquic

• Relacional

• Distribuït

• Orientat a objectes

Malgrat la diversitat de possibilitats, el cert és que el més freqüent, a l’hora de dissenyar una BD, encara consisteix a expressar l’esquema conceptual en un model ER i, a continuació, traduir-lo a un model relacional.

Les claus foranes són uns instruments destinats a permetre la interrelació de la respectiva relació amb d’altres.

Quan el producte d’una fase de disseny lògic és una BD relacional, aquesta consisteix en un conjunt de relacions (altrament, anomenades representacions tabulars) compostes per atributs, alguns dels quals formen part de claus primàries o de claus foranes.

Resulta evident, doncs, que el resultat de la fase de disseny lògic ja se situa dins de l’anomenat món de les representacions informàtiques.

Fase de disseny físic

El disseny físic consisteix a fer certs tipus de modificacions sobre l’esquema lògic obtingut en la fase anterior de disseny lògic, per tal d’incrementar l’eficiència.

L’eficiència d’un esquema pot comportar la modificació d’algunes operacions que s’hagin de fer amb les dades, encara que comportin un cert grau de redundància d’aquestes, com per exemple:

• Afegir algun atribut calculable en alguna relació.

• Dividir una relació en altres dues o en més.

• Incloure en la BD una relació que sigui el producte de combinar dues o més relacions.

Però la fase de disseny físic també es caracteritza per la possibilitat d’adoptar altres decisions, relacionades amb aspectes d’implementació física a més baix nivell, i estretament vinculades amb el SGBD amb el qual es treballa en cada cas, com ara els següents:

• Definició d’índexs.

• Assignació de l’espai inicial per a les taules, i previsió del seu creixement ulterior.

• Selecció de la mida de les memòries intermèdies.

• Parametrització del SGBD segons les opcions que aquest ofereixi.

La volatilitat de les dades té a veure amb el volum d’insercions i esborraments de les mateixes.

Per tal de prendre encertadament aquests tipus de decisions, cal tenir en compte les característiques dels processos que operen amb les dades, la freqüència d’execució dels diferents tipus de consulta, el grau de volatilitat de les dades, els volums d’informació a emmagatzemar, etc.

Disseny conceptual d'una BD

Podem considerar qualsevol empresa, organització, institució, etc. com un sistema amb regles pròpies de funcionament. Aquest sistema, susceptible de ser informatitzat, està compost per tres subsistemes:

• Subsistema de producció. S’encarrega de realitzar les activitats pròpies de l’organització de què es tracti en cada cas (per exemple, fabricar cotxes, o reparar-los, o vendre’ls, etc.).

• Subsistema de decisió. S’encarrega de dirigir, coordinar i planificar les activitats realitzades dins de l’àmbit del subsistema de producció.

• Subsistema d’informació. S’encarrega de recollir, emmagatzemar, processar i distribuir, totes les informacions necessàries per al bon funcionament dels altres dos subsistemes.

Les BD serveixen per emmagatzemar les representacions de les informacions utilitzades dins de l’àmbit dels sistemes d’informació.

Els elements que conformen un sistema d’informació són de dos tipus:

• Dades: representacions de les informacions.

• Processos: accions exercides sobre les dades (consultes, modificacions, càlculs, etc.).

En funció de les observacions anteriors, podem afirmar que hi ha dues premisses que tot dissenyador de BD hauria de tenir ben assumides abans de començar a treballar en qualsevol projecte:

• No és competència del dissenyador de BD, com a tal, prendre decisions sobre la porció del món real que vol modelitzar.

• En principi, el dissenyador de BD tampoc no s’ha d’inventar característiques de la realitat a modelitzar: simplement les ha de reflectir de la manera més fidel possible en el model resultant.

Podem subdividir aquesta etapa de disseny conceptual en dues fases successives, les quals comporten tasques de diferents tipus: la recollida i abstracció de les necessitats de l’organització, d’una banda, i l’elaboració d’un esquema conceptual mitjançant un model de dades concret, de l’altra.

La recollida i abstracció de les necessitats de l’organització es duu a terme mitjançant diferents procediments (entrevistes, examen de documentació, etc.), i en aquesta fase cal recollir tota la informació necessària per tal de cobrir tots els requeriments de dades. Però, amb aquesta informació, s’ha de seguir un procés d’abstracció que ens permeti estructurar-la i diferenciar entre les qüestions essencials i les accessòries.

L’elaboració d’un esquema conceptual mitjançant un model de dades concret comporta que tota la informació recollida i degudament estructurada s’ha d’expressar en una notació estandarditzada (com ara els diagrames ER).

Captura i abstracció dels requeriments de dades

Per realitzar la captura i abstracció dels requeriments, en primer lloc, cal esbrinar quines necessitats tenen els usuaris de la futura BD. Sovint, aquests usuaris potencials només tenen una percepció molt general d’allò que necessiten.

Usuaris de les BD

Ho són tant els operadors que interactuen habitualment amb el sistema, com els destinataris finals de la informació que se n’ha d’extreure o que s’ha d’incloure en la BD.

El dissenyador ha de saber seleccionar les qüestions essencials, diferenciar-les dels aspectes accessoris, i descobrir quins són els vertaders interessos dels que han encarregat el disseny de la BD.

El dissenyador de BD és el professional informàtic que s’encarrega de realitzar les tasques que implica el disseny de les BD.

Ara bé, el dissenyador de BD, com a tal, no ha de decidir res. La seva tasca consisteix més aviat a ajudar els usuaris potencials a descobrir què necessiten exactament. És una feina feixuga i complicada, que serveix per descobrir el veritable flux de dades que s’ha de reflectir en el model conceptual resultant. Normalment, aquesta funció comporta el següent:

• Moltes entrevistes amb els futurs usuaris de tots els nivells i seccions de l’organització a informatitzar. Cal anotar tots els detalls sorgits durant les entrevistes, susceptibles d’implementació informàtica.

• Examen exhaustiu de la documentació proporcionada pel client, per tal de conèixer el funcionament intern de l’organització.

• Observacions directes dels diferents processos de l’organització.

Un bon dissenyador de BD ha d’arribar, com a mínim, a una solució plausible per a cada problema que se li hagi plantejat. De vegades, també podrà prendre en consideració solucions parcials alternatives. I, en tot cas, finalment, ha de presentar una anàlisi completa dels requeriments en la qual concreti les especificacions de l’organització que li ha encarregat el projecte de disseny.

Un exemple concret: BD de la Xarxa de Biblioteques d'INS de Catalunya (XBIC)

Examinar els requisits de disseny que ens permetin establir un model conceptual per a una futura BD que doni servei conjuntament a les biblioteques de tots els instituts de Catalunya (mitjançant una aplicació web ulterior, per exemple), per tal de posar a l’abast de qualsevol membre de la comunitat educativa de secundària la totalitat dels fons bibliogràfics i d’altres recursos audiovisuals, encara que no es trobin físicament en el centre docent on treballi o estudiï l’usuari que sol·liciti el préstec, ens proveirà d’un bon escenari per desenvolupar un exemple de disseny de BD concret.

No es tracta ara tant d’aprofundir en qüestions de detall, com del fet de copsar globalment com es treballa durant la fase de disseny conceptual, i aplicar els coneixements adquirits prèviament -els quals són necessaris per elaborar els esquemes conceptuals-, en el nostre cas fonamentalment amb ajuda del model de dades ER.

Informe d'anàlisi i disseny de BD

La informació recollida pels dissenyadors de BD després de la captura i l’abstracció dels requeriments de les dades es recull en un informe.

Després d’entrevistar-nos amb l’alt càrrec del Departament d’Educació de la Generalitat de Catalunya -que promou la coordinació i col·laboració de les biblioteques de tots els instituts (INS) de Catalunya-, amb uns quants directors i directores de diferents biblioteques interessades a adherir-se a la futura Xarxa de Biblioteques d’INS de Catalunya (XBIC), i també amb uns quants bibliotecaris d’aquestes, i de recopilar i examinar diferent documentació que ens ha estat proporcionada, els dissenyadors de BD encarregats del projecte hem sintetitzat les informacions rebudes de la manera següent:

1. Servei de préstec

• Mitjançant aquest servei, s’ofereix la possibilitat de treure els diversos documents (llibres, revistes, vídeos, CD…) de la biblioteca.

• Per utilitzar el servei de préstec, els usuaris han de tenir el carnet de biblioteca.

• Aquest carnet serveix per utilitzar altres serveis de la biblioteca, com ara el servei d’accés a Internet, el servei Wi-Fi, consulta a BD o participació en algunes activitats que organitzin les biblioteques.

• El mateix carnet serveix per a tota la Xarxa de Biblioteques i permet gaudir d’avantatges interessants en el món de la cultura.

• La sol·licitud del carnet de biblioteca s’ha de fer des de la mateixa biblioteca o bé en línia. En el formulari de sol·licitud, es demanen a l’usuari les dades personals necessàries (nom i cognoms, adreça, data de naixement, etc.).

• A més, els usuaris poden fer altres gestions en línia relacionades amb el préstec: reserves i renovacions de documents.

2. Normativa d'ús del servei de préstec de la Xarxa de Biblioteques

• Tenir el carnet implica acceptar les normes de funcionament de la biblioteca.

• El carnet és personal i intransferible.

• Els usuaris menors de setze anys necessiten l’autorització dels pares per fer-se el carnet, i també els majors de setze anys que no tinguin DNI.

• Cal comunicar, a la biblioteca, qualsevol canvi de domicili o la pèrdua del carnet.

• Cada lector es pot emportar en préstec fins a deu documents entre llibres, revistes i audiovisuals, per un termini de tres setmanes, els llibres, i una setmana, les revistes i audiovisuals.

• Passat el termini, qualsevol document en préstec pot ser renovat, sempre que cap altre usuari no l’hagi reservat. La renovació es pot fer a la biblioteca, per telèfon, per correu electrònic o per Internet.

• Cal tenir cura dels documents deixats en préstec. Si un usuari no torna els documents en el termini fixat, pot ser exclòs del servei de préstec de les biblioteques de la Xarxa durant un temps equivalent al que s’ha retardat en la devolució. Si un usuari perd o fa malbé un document, ho ha de notificar a la biblioteca i ha de comprar el mateix document o abonar-ne l’import.

• Queden exclosos de préstec els documents següents:

• Algunes obres de referència: enciclopèdies, diccionaris, atles, etc.

• Fons de reserva.

• Documents pertanyents a la col·lecció local.

• Números corrents de revistes i de diaris.

• Els documents que la biblioteca cregui convenient que no surtin de la biblioteca.

• A més del servei de préstec a l’usuari individual, les biblioteques ofereixen altres tipus de préstec:

• Servei de préstec interbibliotecari. Mitjançant el servei de préstec interbibliotecari, les biblioteques de la Xarxa s’encarreguen de localitzar i proporcionar els documents que no té el fons propi i que estan disponibles en altres biblioteques de la Xarxa. El préstec entre les biblioteques de la Xarxa té un preu públic establert d’1,20 €.

• Servei de préstec a domicili. Aquest servei s’adreça a persones amb problemes de mobilitat temporal o permanent, com ara malalts crònics, persones en període de convalescència, amb discapacitats físiques o gent gran. No totes les biblioteques de la Xarxa ofereixen aquest servei. El servei de préstec a domicili té un preu públic establert d’1,50 €.

3. Consulta del catàleg

• S’ha de poder consultar la disponibilitat dels fons bibliotecaris pels conceptes següents:

• Signatura (identificador de l’exemplar físic objecte de préstec)

• Títol

• Paraula clau continguda en el títol

• Autor (concretament, pel cognom)

• Nom o cognoms incomplets de l’autor

• Matèria

• A més, les cerques s’han de poder limitar als àmbits següents:

• Una biblioteca concreta

• Totes les biblioteques d’una sola població

• Totes les biblioteques d’una sola comarca

• Finalment, s’han de poder limitar els resultats obtinguts en funció dels conceptes següents:

• Idioma

• Tipus de format

• Any de publicació

Identificació d'entitats

L’especificació dels requeriments de dades serveix com a punt de partida per a l’elaboració de l’esquema conceptual de la futura BD. A continuació, el primer que s’ha de fer és identificar les entitats i els seus atributs.

          La identificació de les entitats i dels seus atributs es pot documentar amb un llistat
          que segueixi el format següent:

          ENTITAT1 (Atribut1, Atribut2, …)
          ENTITAT2 (Atribut1, Atribut2, …)
          …
          ENTITATn (Atribut1, Atribut2, …)

En el llistat, els noms de les entitats aniran amb majúscules, i els noms dels atributs començaran amb majúscules.

L’exemple parteix de la informació referida en l’apartat “Captura i abstracció dels requeriments de dades”.

Seguint amb l’exemple BD de la XBIC, en una primera aproximació, tot repassant les especificacions que tenim, podríem obtenir una solució que comptés com a mínim amb les tres entitats següents, que incorporen els respectius atributs expressats entre parèntesis:

• INS(Poblacio, Comarca). Possibles atributs addicionals: Nom, Adreça i Telefon.

• DOCUMENT(Format, Import, ExclosPrestec, Signatura, Titol, Autor, Materia, Idioma, AnyPublicacio).

• USUARI(DNI, Nom, Cognoms, Adreça, DataNaixement, Carnet, DataFinalExclusioPrestec).

Però estem en condicions de depurar aquest resultat rudimentari. Fixem-nos en què hi haurà moltes poblacions i comarques que es repetiran per a diferents INS. Fóra millor, doncs, que aquests dos atributs constituïssin dues entitats independents, convenientment interrelacionades amb l’entitat INS: POBLACIO i COMARCA.

Un altre avantatge d’utilitzar aquestes dues entitats en comptes de considerar-les atributs d’una entitat concreta, és que les podrem reaprofitar interrelacionant-les amb altres entitats, en cas necessari.

Passa el mateix amb altres atributs de DOCUMENT: el format, l’autor la matèria i l’idioma.

Seria millor tenir una entitat per enregistrar els tipus de format, que sempre seran els mateixos (llibre, revista, CD, etc.), anomenada per exemple FORMAT, i interrelacionar-la amb DOCUMENT.

Estarem davant del mateix fenomen amb els idiomes (català, castellà, anglès, etc.) i les matèries (història, música, física, etc.). Per tant, serà convenient comptar amb dues entitats més: IDIOMA i MATERIA.

D’altra banda, els autors podran ser autors d’una pluralitat de documents i, a fi de simplificar les cerques ulteriors per autor, és preferible destinar una entitat pròpia per representar-los (podem anomenar-la, senzillament, AUTOR). Després de fer aquestes consideracions, ens trobaríem amb unes quantes entitats més que no pas inicialment:

• INS(Nom, Adreça, Telefon)

• DOCUMENT(Signatura, Titol, AnyP ublicacio, Import, ExclosPrestec)

• USUARI(Carnet, DNI, Nom, Cognoms, Adreça, DataNaixement, DataFinalExclusioPrestec)

• POBLACIO(Nom)

• COMARCA(Nom)

• FORMAT(Descripcio)

• AUTOR(Nom, Cognoms)

• MATERIA(Descripcio)

• IDIOMA(Descripcio)

Hem de ser conscients que qualsevol especificació que no es desprengui directament dels documents de treball inicial en què hem sintetitzat els diferents requeriments de dades detectats com, per exemple, afegir els nous atributs a INS s’ha de validar mitjançant noves entrevistes, o l’examen de nova documentació o bé revisió de l’antiga, o, si no, observant in situ el procés en execució que pugui comportar una innovació en l’especificació.

En canvi, altres aspectes que poden semblar més agosarats (com ara representar el que era inicialment l’atribut d’una entitat com una altra entitat independent) no han d’implicar necessàriament uns processos de validació com els que acabem de descriure, si es tracten purament de decisions tècniques de disseny.

              Cal fer notar que, per poc complicada que sigui la porció del món real a modelitzar, normalment 
              és possible obtenir uns quants models conceptuals, en alguns casos alternatius i equivalents, i 
              en d’altres orientats a satisfer en més o menys mesura diferents finalitats, però amb resultats 
              igualment correctes.

Designació d'interrelacions

Després de la captura i abstracció dels requeriments de dades i de la identificació d’entitats, el pas següent consisteix a establir les interrelacions necessàries entre les entitats detectades.

          Les interrelacions es poden documentar amb el format següent:

          Interrelacio (Atribut1, Atribut2, …), entre ENTITATi i ENTITATj

          En què el nom de la interrelació començarà amb majúscules i, en cas de disposar d’atributs, aquests 
          aniran entre parèntesis i amb la inicial del nom també amb majúscules. Caldrà especificar el nom de 
          les entitats que interrelaciona.

               L’exemple esmentat es refereix a les informacions que conté l’apartat “Captura i 
               abstracció dels requeriments de dades”, i es desenvolupa al llarg de les diferents
               fases de disseny conceptual de BD.

En algun cas, les interrelacions poden incorporar algun atribut (com passa amb la interrelació Prestec), de la mateixa manera que les entitats. Inicialment podem trobar, com a mínim, quatre interrelacions que només afecten les tres entitats originàries:

• Prestec(Data, Tipus, Preu), entre USUARI i DOCUMENT

• RenovacioPrestec(Data), entre USUARI i DOCUMENT

• Reserva(Data), entre USUARI i DOCUMENT

• Ubicació, entre INS i DOCUMENT

Però, després de considerar l’establiment de la resta d’entitats, haurem d’afegir les interrelacions corresponents:

• Esta, entre INS i POBLACIO

• Pertany, entre POBLACIO i COMARCA

• Te1, entre FORMAT i DOCUMENT

• Te2, entre AUTOR i DOCUMENT

• Versa, entre MATERIA i DOCUMENT

• Expressat, entre IDIOMA i DOCUMENT

Notem que quan es repeteix un mateix nom en més d’una interrelació (com aquí passa amb Te), cal numerar-les correlativament, per tal d’evitar confusions en fer referència a cadascuna.

I, a més, podríem considerar l’establiment d’una interrelació entre USUARI i POBLACIO per tal de completar-ne l’adreça degudament (com hem fet amb els INS). Quedaria així:

• Viu, entre USUARI i POBLACIO

Establiment de claus

Recordem que la clau primària d’una entitat està constituïda per un atribut, o per un conjunt d’atributs, els valors dels quals són capaços d’identificar unívocament les instàncies d’aquella.

De vegades, una entitat disposa de més d’un atribut, o conjunt d’atributs, que estan en condicions de constituir la clau primària. En aquest cas, parlem de claus candidates.

          I una vegada que el dissenyador tria un atribut o conjunt d’atributs concrets per identificar 
          unívocament les instàncies, entre els que compleixen les condicions (claus candidates), aquest
          o aquests atributs passen a ser la clau primària, i els no seleccionats romanen com a claus 
          alternatives.

Un criteri important a l’hora de decidir-se perquè un o més atributs formin la clau primària d’una entitat, és que el seu valor no canviï mai o, si més no, molt rarament.

          L’atribut o conjunt d’atributs que formen la clau primària han d’aparèixer subratllats en la 
          documentació.

Per exemple, no seria gaire prudent decidir-se pel número de telèfon mòbil com a clau primària d’una entitat que emmagatzema persones, perquè, tot i ser un número habitualment d’ús personal, pot canviar al llarg del temps (per exemple, una persona pot regalar el seu mòbil a una altra). En canvi, el número de DNI pot ser, en general, una bona opció, ja que, en principi, aquest número és personal i intransferible.

         L’exemple esmentat es refereix a les informacions contingudes en l’apartat “Captura i 
         abstracció dels requeriments de dades”, i es desenvolupa al llarg de les diferents fases
         de disseny conceptual de BD.

Continuant amb el nostre exemple, estem en condicions de trobar les claus següents, formades per només un atribut, les quals es mostren subratllades:

• DOCUMENT(Signatura , Titol, AnyPublicacio, Import, ExclosPrestec)

• COMARCA(Nom)

• POBLACIO(Nom)

• FORMAT(Descripcio)

• MATERIA(Descripcio)

• IDIOMA(Descripcio)

L’entitat AUTOR no té cap atribut que identifiqui plenament les seves instàncies. Aquí podríem haver optat per combinar els valors que adoptin els atributs Nom i Cognoms en cada tuple, per tal de no haver d’introduir cap tipus de codificació artificial, però aquesta no deixa de ser una opció arriscada, ja que pot passar que hi hagi dos autors amb el mateix nom i cognoms. Per tant, afegim un nou atribut, anomenat Codi, per tal que no hi hagi problemes amb la clau primària d’aquesta entitat. Per tant, l’entitat ens queda així:

• AUTOR(Codi, Nom, Cognoms)

En certa manera podríem considerar que USUARI té dues claus alternatives: Carnet i DNI. Però en realitat no és així, ja que hi poden haver usuaris menors d’edat que encara no tenen DNI. I ja sabem que cap clau primària pot admetre valors nuls, ja que aleshores no serviria per distingir unívocament les instàncies entre elles. En canvi, tot usuari disposarà d’un número de carnet. Per tant, ens quedarà l’estructura següent:

• USUARI(Carnet, DNI, Nom, Cognoms, Adreça, DataNaixement, DataFinalExclusioPrestec)

Finalment, hem d’examinar l’entitat INS. El nom dels instituts es pot repetir, i de fet es repeteix (per exemple, hi ha un INS anomenat Milà i Fontanals a Barcelona, un altre a Igualada, un altre a Vilafranca del Penedès, etc.). Per tant, l’atribut Nom no és suficient per constituir per si sol la clau primària de l’entitat. Una opció seria establir algun tipus de codificació. Però, en aquest cas, hem preferit considerar INS com una entitat feble que depèn de POBLACIO. Per tant, la clau primària d’INS estarà formada per la clau primària de l’entitat forta (l’atribut Nom de POBLACIO) més l’atribut discriminant de l’entitat feble (l’atribut Nom d’INS), que també mostrem subratllat:

• INS(Nom , Adreça, Telefon)

Establiment de cardinalitats

L’establiment correcte de les cardinalitats adequades per a cada interrelació depèn de les característiques del món real que es volen modelitzar.

Cal afegir, doncs, la informació referent a les cardinalitats de les interrelacions en la documentació de disseny.

               L’exemple es planteja en l’apartat “Captura i abstracció dels requeriments de 
               dades”, i es va construint seguint les diferents fases de disseny conceptual de BD.

En el model que estem construint (seguint l’exemple de la BD de la XBIC) podem establir les cardinalitats següents:

• Un mateix usuari pot agafar en préstec diferents documents, i un mateix document es pot prestar a diferents usuaris, al llarg del temps:

          Prestec(Data, Tipus, Preu), entre USUARI i DOCUMENT: M-N

• Passa el mateix en cas de renovar un préstec o de reservar un document:

  
          RenovacioPrestec(Data), entre USUARI i DOCUMENT: M-N

          Reserva(Data), entre USUARI i DOCUMENT: M-N

• Tot document pertanyerà a la biblioteca d’un INS concret, la qual podrà disposar de molts documents:

Ubicació, entre INS i DOCUMENT: 1-N

• Dins d’una mateixa població podran coexistir diferents INS, però un INS estarà en una població concreta. A més no oblidem que, en tractarse d’una entitat feble, la cardinalitat ha de ser 1-N, amb l’entitat feble al costat de la N:

          Esta, entre INS i POBLACIO: N-1

• Cada població pertany a una sola comarca, però cada comarca tindrà més d’una població a dins del seu territori:

    
          Pertany, entre POBLACIO i COMARCA: N-1

• S’ha considerat que cada document només té un format, però evidentment cada format serà aplicable a molts documents diferents:

          Te1, entre FORMAT i DOCUMENT: 1-N

• Amb una cardinalitat M-N, fem possible registrar més d’un autor per a un mateix document:

    
          Te2, entre AUTOR i DOCUMENT: M-N

• En canvi, considerem que cada document només pot versar sobre una sola matèria:

    
          Versa, entre MATERIA i DOCUMENT: 1-N

• Un document (com ara una pel·lícula en DVD) podrà estar expressat en diferents idiomes:

    
          Expressat, entre IDIOMA i DOCUMENT: M-N

• Cada usuari té el domicili en una població concreta. Però en una mateixa població hi poden viure diferents usuaris:

    
          Viu, entre USUARI i POBLACIO: N-1

Restriccions de participació i límits de cardinalitat

          Es diu que la participació d’una entitat en una interrelació és total si cadascuna
          de les seves instàncies participa un cop, com a mínim, en la interrelació esmentada,
          i parcial en cas contrari. 

• Prestec(Data, Tipus, Preu), entre USUARI (parcial) i DOCUMENT (parcial): M-N

• RenovacioPrestec(Data), entre USUARI (parcial) i DOCUMENT (parcial): M-N

• Reserva(Data), entre USUARI (parcial) i DOCUMENT (parcial): M-N

• Ubicació, entre INS (parcial) i DOCUMENT (total): 1-N

• Esta, entre INS (total) i POBLACIO (parcial): N-1

• Pertany, entre POBLACIO (total) i COMARCA (total): N-1

• Te1, entre FORMAT (parcial) i DOCUMENT (total): 1-N

• Te2, entre AUTOR (total) i DOCUMENT (total): M-N

• Versa, entre MATERIA (parcial) i DOCUMENT (total): 1-N

• Expressat, entre IDIOMA (total) i DOCUMENT (total): M-N

• Viu, entre USUARI (total) i POBLACIO (parcial): N-1

A més, hem d’establir un límit màxim a la cardinalitat de la interrelació Prestec perquè, en principi, un usuari no pot sol·licitar en préstec més de deu documents simultàniament.

         Les interrelacions quedaran documentades, doncs, amb el format següent:

         Interrelacio (Atribut1, Atribut2, …), entre ENTITATi (participacio) i ENTITATj
         (participacio): tipus_de_cardinalitat

         En què el nom de la interrelació començarà amb majúscules i, en cas de disposar
         d’atributs, aquests aniran entre parèntesis, separats per comes, i amb la inicial del
         nom també amb majúscules. Caldrà especificar el nom de les entitats que interrelaciona
         i el tipus de cardinalitat, que pot ser 1-1, 1-N, N-1 o M-N. La participació pot ser 
         total o parcial. 

Elaboració d'un esquema conceptual

         Una vegada tenim els requeriments; i hem identificat les entitats, atributs i interrelacions;
         i gràcies al coneixement assolit de les necessitats que han de satisfer les dades, el
         dissenyador està en condicions d’elaborar un esquema conceptual complet d’aquestes i de les
         seves interrelacions. 

Per tal de confeccionar aquest model conceptual, el dissenyador de BD utilitzarà algun model de dades que s’adapti a les necessitats del projecte, i permeti continuar treballant-hi durant la fase ulterior de disseny lògic.

              Un diagrama ER és un esquema gràfic que serveix per representar un model ER. 

          El model de dades més utilitzat per elaborar l’esquema conceptual és el model ER, i la 
          documentació del disseny conceptual culmina amb el diagrama ER. 

               UML

               Acrònim de unified modeling language (llenguatge unificat de modelització).
               Notació gràfica que permet especificar dades i aplicacions orientades a 
               objectes. S’entén per model de dades UML aquella part de l’UML destinada a 
               descriure les dades. 

Tot i que el model ER continua sent el model de dades més utilitzat, amb diferents variacions en aspectes de notació, cada vegada s’utilitza més el model UML de dades, molt útil en projectes que basin la implementació de la programació en el paradigma de l’orientació a objectes.

Per començar a treballar amb els diagrames ER, pot ser còmode establir l’esquelet del model, sense incloure encara tots els detalls (atributs, cardinalitats, etc.). En la següent figura, hi ha un esquema conceptual inacabat, expressat amb l’ajuda del model de dades ER, que només inclou les entitats i les interrelacions detectades inicialment.

Diagrama ER inicial de la XBIC

Diagrama ER de la XBIC a mig fer

A l’hora de dissenyar el diagrama ER, pot ser una bona pràctica partir d’un primer diagrama inacabat (com el de la primera figura) i incorporar-hi més detalls progressivament. En la segona figura, per exemple, ja han quedat establertes les cardinalitats i les restriccions de participació.

I l’últim pas que farà el dissenyador per completar el diagrama, de manera que reflecteixi tots els requeriments prèviament detectats, es pot veure en l’exemple de la següent figura, en què hi ha especificats tots els atributs i claus.

Diagrama ER de la XBIC totalment acabat

Extensions del model Entitat-Relació

Les estructures bàsiques del model Entitat-Relació (model ER) permeten representar la majoria de situacions del món real que habitualment cal incorporar en les BD. Però, de vegades, certs aspectes de les dades s’han de descriure mitjançant unes construccions més avançades del model ER, les quals comporten una extensió del model ER bàsic. Aquestes ampliacions del model ER consisteixen en l’especialització, la generalització i l’agregació, d’entitats.

Especialització i generalització

Ens podem trobar amb el cas d’alguna entitat tipus en què -a més de les característiques generals, comunes a totes les seves instàncies- ens interessi modelitzar, addicionalment, certes característiques específiques aplicables només a part de les seves instàncies.

Aleshores, podrem considerar que aquesta entitat tipus conté altres entitats tipus, de nivell inferior, amb característiques pròpies.

          L’especialització permet reflectir l’existència d’una entitat general, anomenada 
          entitat superclasse, que es pot especialitzar en diferents entitats subclasse. 

L’entitat superclasse permet representar les característiques comunes de l’entitat des d’un punt de vista general. Les entitats subclasse, en canvi, permeten representar les característiques pròpies de les especialitzacions de l’entitat superclasse.

Les instàncies de les subclasses han de ser, al mateix temps, instàncies de la superclasse respectiva.

El procés de designació de subclasses a partir d’una superclasse s’anomena especialització.

        Exemple d'especialització

        Fins ara comptàvem amb una única entitat PROFESSOR, que ens servia per treballar
        amb tots els docents del centre, ja que encara no havíem detectat cap subconjunt
        d’aquest col·lectiu que ens hagués fet pensar en implementar-ne una especialització.

        Però resulta que la direcció del centre vol implicar, en la gestió d’aquest i en el 
        seu manteniment informàtic, el professorat de dues famílies professionals: l’administrativa
        i la informàtica, respectivament.

        Per tant, ens interessa tenir constància, d’una banda, de la titulació dels professors 
        de la família administrativa i de la seva especialitat, ja que en funció d’aquestes
        característiques podran assumir, o no, les responsabilitats que se’ls volen encomanar.

        També pot resultar útil saber quina és l’especialitat principal, tant en maquinari com 
        en programari, del professorat de la família d’informàtica, per assignar les tasques de 
        manteniment amb una certa garantia d’èxit.

        Com a conseqüència de tot això, implementarem una especialització de l’entitat PROFESSOR 
        en dues subclasses: ADMINISTRATIU, que incorporarà dos nous atributs (Titulacio i 
        Especialitat), i INFORMATIC, que n’incorporarà uns altres dos (EspecialitatMaquinari i 
        EspecialitatProgramari). 

Exemple d’especialització

             L’especialització en els diagrames ER es representa amb un triangle. 

En funció de les similituds detectades entre diferents entitats, aquestes es poden arribar a sintetitzar en una sola entitat, de nivell superior, mitjançant un procés de generalització.

La generalització serveix per ressaltar les similituds entre entitats, per sobre de les diferències, i també per simplificar les representacions de les dades, en evitar la repetició d’atributs compartits per diferents subclasses.

          Exemple de generalització

          Fins ara, hem utilitzat dues entitats diferents que ens han servit per modelitzar 
          dues categories, també diferents, existents al món real: ALUMNE i PROFESSOR.

          Però, és evident que tant els alumnes com els professors són persones, tot i que amb 
          rols diferents. Per tant, tindran una sèrie de característiques comunes, que es podran
          modelitzar de la mateixa manera.

          Així, tant els uns com els altres tindran nom, cognoms, telèfons de contacte, etc., que
          es podran modelitzar mitjançant els mateixos atributs.

          També és possible que totes dues tipologies puguin participar en les mateixes  
          interrelacions. Per exemple, per tal d’indicar la localitat de residència, el més 
          habitual és relacionar l’entitat que representa les persones amb una altra entitat que 
          emmagatzema les diferents localitats.

          En definitiva, partint de les entitats ALUMNE i PROFESSOR, podríem crear una altra 
          entitat, superclasse de les anteriors, i anomenar-la, per exemple, PERSONA.

          D’aquesta manera implementarem l’entitat PERSONA, com a generalització d’ALUMNE i 
          PROFESSOR, la qual contindrà els atributs comuns a les seves subclasses, i a més 
          participarà directament en les interrelacions que també siguin comunes a les subclasses 
          esmentades. 

               La generalització en els diagrames ER es representa amb un triangle, com en
               l’especialització. 

Exemple de generalització

El producte resultant de l’especialització i de la generalització és, doncs, idèntic. La diferència entre ambdós recau en el tipus de procés que condueix a cadascuna:

• L’especialització deriva d’un procés de disseny descendent, durant el qual, a partir d’una entitat preexistent, considerada com a superclasse es detecta la utilitat d’establir certes subclasses, a causa de l’existència de certes característiques (atributs i participacions en interrelacions) no aplicables a totes les instàncies de la superclasse.

• La generalització respon a un procés considerat de disseny ascendent. Durant aquest tipus de disseny es valora la utilitat de contemplar unes quantes entitats preexistents, anomenades subclasses, dependents d’una mateixa superclasse comuna a totes elles. La superclasse presenta unes característiques comunes (atributs i participacions en interrelacions) a totes les subclasses que en depenen.

Herència de propietats

Tant en el cas de generalització com en el d’especialització, les característiques de l’entitat superclasse s’estenen cap a les entitats subclasse. Com ja sabem, aquestes característiques poden consistir o bé en atributs de l’entitat superclasse, o bé en la seva participació en diferents interrelacions.

          Anomenem herència de propietats la transmissió de característiques (atributs
          i interrelacions) des de l’entitat superclasse cap a les entitats subclasse. 

Pot passar que una mateixa entitat adopti el rol de subclasse en un procés de generalització o especialització i que, al mateix temps, assumeixi el paper de superclasse en un altre d’aquests processos en què participi.

               Jerarquia d'entitats

               Quan s’encadenen diferents generalitzacions o especialitzacions de
               tal manera que una mateixa entitat és subclasse d’una estructura, i 
               superclasse d’una altra, té lloc el que s’anomena jerarquia d’entitats.

Quan es produeix una jerarquia d’entitats, les entitats dels nivells inferiors poden heretar característiques no solament de la superclasse respectiva, sinó també d’altres classes de nivells superiors.

          Anomenem herència múltiple la recepció, per part d’una entitat subclasse, tant de 
          les característiques (atributs i interrelacions) de la seva superclasse, com de les 
          d’altres entitats de nivells superiors, dins d’una estructura jeràrquica d’entitats 
          amb generalitzacions o especialitzacions encadenades. 

          Exemple de jerarquia d'entitats i d'herència múltiple

          Com a resultat d’un procés de generalització hem conferit, a l’entitat PERSONA, la 
          qualitat de superclasse de les entitats PROFESSOR i ALUMNE, considerades subclasses
          d’aquella.

          Al mateix temps, però com a resultat d’un procés d’especialització, hem conferit a 
          l’entitat PROFESSOR la categoria de superclasse de dues noves entitats, subclasses 
          de la mateixa: INFORMATIC i ADMINISTRATIU.

          A conseqüència de tot això, les entitats del nivell inferior (INFORMATIC i ADMINISTRATIU)
          no solament heretaran les característiques de la seva superclasse (PROFESSOR), sinó també 
          les de les altres entitats de nivells superiors de les quals siguin descendents i, per tant,
          hereves.

          En aquest cas, doncs, INFORMATIC i ADMINISTRATIU heretaran les característiques de la seva
          superclasse (PROFESSOR) i també les propietats de la superclasse d’aquella (PERSONA). Però 
          no heretaran cap propietat d’ALUMNE, perquè no són descendents d’aquesta entitat. 

Exemple d’herència múltiple

Restriccions

Per tal de modelitzar més exactament la parcel·la del món real que ens interessi, es poden establir certes restriccions sobre les especialitzacions o generalitzacions detectades.

Un primer tipus de restriccions defineix si les instàncies poden pertànyer simultàniament o no a més d’una subclasse d’una estructura simple (és a dir, que compti amb una sola superclasse i un sol nivell de subclasses) de generalització o especialització. En aquests casos, les entitats de tipus subclasse poden ser de dos tipus:

• Disjuntes. Una mateixa entitat instància no pot aparèixer en dues entitats subclasse diferents. Es representa en el diagrama afegint una etiqueta amb la lletra D.

• Encavalcades. Una mateixa entitat instància pot aparèixer en dues (o, fins i tot, en més de dues) entitats subclasse diferents. Es representa en el diagrama afegint una etiqueta amb la lletra E.

Un segon tipus de restriccions especifica si tota instància de la superclasse ha de pertànyer simultàniament a una o més de les subclasses o no. Aquí les entitats de tipus subclasse també poden ser de dos tipus:

• Totals. Tota instància de l’entitat superclasse ha de pertànyer simultàniament, com a mínim, a una de les seves entitats subclasse. Es denota amb l’etiqueta T.

• Parcials. Algunes instàncies de l’entitat superclasse poden no pertànyer simultàniament a cap de les seves entitats subclasse. Es denota amb l’etiqueta P.

Combinant aquestes restriccions obtenim, doncs, quatre possibilitats aplicables a les subclasses d’una generalització o especificació. Cal separar les lletres que s’inclouen en l’etiqueta amb una coma:

• D, T (disjuntes i totals)
• D, P (disjuntes i parcials)
• E, T (encavalcades i totals)
• E, P (encavalcades i parcials)

          Exemple de subclasses D, T

          Haurem de considerar disjuntes les subclasses de PERSONA si els reglaments de 
          funcionament del centre no permeten que cap professor s’hi matriculi com a alumne, 
          simultàniament amb l’exercici de la seva tasca docent.

          Al mateix temps, les considerarem totals si la nostra BD registra exclusivament les 
          dades de professors i d’alumnes, sense ocupar-se d’altres categories de persones (com 
          podria ser el personal administratiu, de manteniment, de neteja, etc.). 

Exemple de subclasses D,T

          Exemple de subclasses E, P

          Haurem de considerar encavalcades les subclasses de PROFESSOR si volem reflectir
          el fet que alguns professors, tot i exercir com a tals amb una especialitat concreta
          en un curs acadèmic, poden tenir altres especialitats. Per tant, un professor podrà 
          ser simultàniament INFORMATIC i ADMINISTRATIU.

          D’altra banda, les considerarem parcials perquè al nostre institut hi podrà haver, amb 
          tota seguretat, professors d’altres especialitats (com ara electròniques, comercials, 
          etc.), que no seran ni informàtics ni administratius. 

Exemple de subclasses E,P

Per reflectir una combinació de característiques encara més complicada, s’ha de recórrer a una especificació textual que acompanyi el diagrama.

         Exemple de subclasses amb diferents restriccions

         Imaginem que volem afegir una nova subclasse de PERSONA, per tal d’incloure-hi el
         personal d’administració i serveis del centre. Anomenarem aquesta nova entitat 
         ADMO_SERVEI.

         Ja hem exposat més amunt que els reglaments interns del nostre institut no permeten 
         que cap professor sigui, simultàniament, alumne del centre. Però ara ens trobem que, 
         al personal d’administració i serveis, sí que se li permet matricular-se com a alumne 
         en algun dels estudis impartits al centre al mateix temps que exerceixen la seva tasca 
         professional.

         Totes tres subclasses seran totals, com abans, perquè tothom haurà de pertànyer a alguna
         de les tres categories reflectides.

         PROFESSOR i ALUMNE seran disjuntes entre elles, igual que PROFESSOR i ADMO_SERVEI, ja que 
         no es poden compatibilitzar les condicions esmentades. Però, al mateix temps, ALUMNE i 
         ADMO_SERVEI seran encavalcades, perquè una persona podrà estar inclosa en aquestes dues 
         categories simultàniament, segons hem vist.

         Per reflectir una realitat com aquesta, no hi ha altre remei que fer servir una 
         especificació textual que, tot acompanyant el diagrama, aclareixi degudament les 
         característiques específiques de cada subclasse o agrupació d’aquestes. 

Exemple de subclasses amb diferents restriccions

Notació

Tant l’especialització com la generalització es representen mitjançant un triangle que inclou, al seu interior, l’etiqueta ES. Aquesta etiqueta indica que tota instància de qualssevol de les subclasses és, al mateix temps, una instància de la superclasse corresponent (per exemple, tant un informàtic com un administratiu seran, al mateix temps, un professor).

Per distingir clarament la superclasse en els casos en què hi ha un gran nombre d’entitats subclasse implicades en l’estructura, o bé quan resulta difícil, per les característiques del diagrama, alinear clarament totes les subclasses, és convenient indicar els límits de cardinalitat de la generalització o especialització. Per a això, només cal afegir una etiqueta del tipus mín..màx, per tal d’expressar els límits respectius, al costat de la línia que uneix cada entitat amb el triangle que representa la generalització o especialització, en què mín i màx podran tenir els valors següents:

• 1..1 en la línia que enllaça la superclasse, perquè tota instància de qualsevol subclasse sempre constituirà, simultàniament, una i només una instància de la superclasse.

• 0..1 en la línia que enllaça cada subclasse, perquè no necessàriament tota instància de la superclasse haurà de ser, simultàniament, instància de la subclasse en qüestió (ho podrà ser d’una altra subclasse, o podrà no ser-ho de cap, si estem en presència d’una restricció de parcialitat).

Les entitats que formen part d’una estructura de generalització o especialització es representen com la resta d’entitats: cadascuna amb un rectangle que incorpora el nom respectiu, i els atributs respectius encerclats dins d’el·lipses lligades a la seva entitat amb una línia. Si els atributs formen una clau primària, el seu nom haurà d’anar subratllat.

En termes de notació diagramàtica, no s’estableix cap diferència entre una generalització i una especialització. Les diferències entre ambdós fenòmens es redueixen al procés que s’ha seguit per derivar en cadascun d’ells, però no en el resultat, que sempre és el mateix: l’establiment d’una superclasse i d’unes subclasses amb unes restriccions concretes, que es representen afegint, a l’etiqueta ES, les inicials de les dues restriccions aplicables separades per una coma:

• D, T (disjuntes i totals)

• D, P (disjuntes i parcials)

• E, T (encavalcades i totals)

• E, P (encavalcades i parcials)

Agregacions d'entitats

Amb les regles bàsiques del model ER, només es poden modelitzar interrelacions en què participen exclusivament entitats, però no es pot expressar la possibilitat que una interrelació participi directament en una altra interrelació. Però hi ha un mecanisme, anomenat agregació, que permet superar la limitació descrita anteriorment, tot considerant una interrelació entre entitats com si fos una entitat, i utilitzant-la com a tal.

               Les agregacions també són conegudes com a entitats associatives. 

         L’agregació d’entitats és una abstracció, mitjançant la qual, una interrelació es 
         tracta com una entitat de nivell més alt, que agrupa les entitats interrelacionades 
         gràcies a ella. L’agregació ha de tenir el mateix nom que la interrelació sobre la 
         qual es defineix. 

La utilitat d’una agregació d’entitats, doncs, consisteix en el fet que la interrelació en què es basa es pot interrelacionar amb altres entitats. Una agregació d’entitats es denota requadrant totes les entitats que participen en una interrelació determinada, per tal de construir una nova entitat que pot establir les pròpies interrelacions.

         Exemple d'agregació d'entitats

         Considerem la interrelació Practica, binària i de cardinalitat N-M, que té lloc entre
         les entitats ALUMNE i ESPORT, que ja coneixem.

         Imaginem ara que es vol tenir constància del professor que, si és el cas, es dedica a 
         entrenar un alumne que practica un esport determinat. I recordem que ja existeix en el 
         nostre model una entitat anomenada PROFESSOR.

         Una alternativa per representar aquesta realitat consistiria a crear una interrelació 
         ternària, anomenada, per exemple, Entrena, entre les entitats ALUMNE, ESPORT i PROFESSOR. 

Exemple d’interrelacions redundants

---

D’aquesta manera, pot semblar que les interrelacions Practica i Entrena es poden combinar en una única interrelació. Però això no és del tot cert, ja que hi haurà interrelacions entre ALUMNE i ESPORT que no disposaran necessàriament d’un professor que actuï com a entrenador.

Ara bé, hi ha informació redundant en l’esquema proposat fins ara, ja que tota combinació entre instàncies de les entitats ALUMNE i ESPORT que hi ha a Entrena també és a Practica.

Si l’entrenador només fos un valor, ens podríem plantejar simplement afegir un atribut a la interrelació Practica, que es digués, per exemple, Entrenador. Però en existir una entitat (PROFESSOR) que conté la instància aplicable a cada cas, quan és necessari, hem de descartar aquesta possibilitat.

Així, doncs, la millor manera de reflectir totes aquestes circumstàncies és fer ús d’una agregació d’entitats. En aquest cas, cal considerar la interrelació Practica, entre ALUMNE i ESPORT, com una altra entitat de nivell més alt, anomenada PRACTICA. I, seguidament, es pot establir una interrelació binària amb cardinalitat 1-N entre PROFESSOR i l’agregació PRACTICA, i anomenar-la Entrena, i que inclogui les combinacions necessàries entre ambdues, per tal de modelitzar qui entrena la pràctica dels esports per part dels alumnes, quan es produeix aquesta circumstància (figura següent).

---

               Les agregacions d’entitats en els diagrames ER es representen com 
               una agrupació rectangular de les entitats i relacions que integren. 

Exemple d’agregació d'entitats sense redundància

La tècnica de les agregacions engloba la de les entitats febles, però encara resulta més potent: sempre que fem servir una entitat dèbil, la podrem substituir per una agregació, però no a l’inrevés. Ara bé, cal mantenir les entitats febles en el model ER perquè, tot i que resulten menys complexes que les agregacions, normalment són suficients per modelitzar la majoria de les situacions que es produeixen al món real.

Exemple de substitució d'una entitat feble per una agregació

Recuperem l’entitat feble ASSIGNATURA. Ara imaginem que, per establir un cert control en matèria de coordinació pedagògica, es necessita saber qui és el professor responsable de realitzar la programació didàctica de cada assignatura.

Entre PROFESSOR i ASSIGNATURA es pot establir una interrelació binària de cardinalitat 1-N per representar aquest fet, que s’anomena, per exemple, Programa. 

Però, alternativament, podríem modelitzar aquesta dada convertint ASSIGNATURA en una agregació.

Per aconseguir-ho, en primer lloc hauríem de considerar una nova entitat, i anomenar-la per exemple CODI, que emmagatzemés simplement codis d’assignatura (com ara C1, C2, C3, etc.).

A continuació, hauríem d’establir, d’una banda, una interrelació binària de cardinalitat N-M entre CICLE i CODI, i anomenar-la Assignatura. I, d’altra banda, també hauríem d’obtenir una agregació de la interrelació entre CICLE i CODI (és a dir, Assignatura).

Finalment, hauríem d’interrelacionar l’agregació resultant amb l’entitat PROFESSOR, amb una senzilla interrelació binària amb cardinalitat 1-N, anomenada Programa (figura següent). 

Exemple d’agregació d'entitats sense redundància

Notació

Les agregacions d’entitats es representen incloent dins d’un requadre totes les entitats que participen en una interrelació determinada.

               Les agregacions també es representen freqüentment incloent, dins d’un requadre, 
               només el rombe de la interrelació de la qual provenen les entitats implicades. 

Des d’una interrelació, es pot fer arribar una una fletxa (de punta senzilla o doble, per tal d’expressar la cardinalitat 1 o N, respectivament) fins al rombe inclòs dins del requadre que indica l’existència d’una agregació (o bé fins al mateix requadre, exactament igual que si es tractés d’una simple entitat).

Tota agregació ha de tenir el mateix nom que la interrelació sobre la qual es defineix.

Exemple: BD d'un institut de formació professional

Ara desenvolupem un exemple de disseny conceptual de BD, corresponent a un institut de formació professional, per il·lustrar per separat els diferents conceptes i la seva respectiva modelització. Es tracta de dissenyar una BD per gestionar el personal de l’institut (compost pels professors, i pels treballadors d’administració i serveis) i el seu alumnat, a més dels estudis impartits.

Les descripcions següents resumeixen els requisits dels usuaris de la futura BD:

               Els requisits per dissenyar una BD...

               … d’un institut real segurament serien molt més nombrosos que els
               que hem exposat aquí, els quals estan seleccionats amb finalitats 
               educatives, i no necessàriament en funció de la seva importància o 
               freqüència en el món real. 

• Les persones que formen part de la nostra comunitat educativa s’identifiquen mitjançant el DNI (o document equivalent, com ara la targeta de residència).

• També volem conèixer, d’aquestes persones, el nom i cognoms, l’adreça, un (i només un, de moment) telèfon de contacte, i la data de naixement.

• A més, hem de tenir registrada la localitat de residència, tot tenint en compte que la BD ha de poder emmagatzemar, per a altres usos, localitats on no visqui ningú.

• Tota persona de la comunitat educativa pertany, com a mínim, a un dels tres subtipus següents:

• Professors

• Alumnes

• Personal d’administració i serveis

• Les persones només poden mantenir un tipus de relació laboral amb el centre educatiu. Per tant, els professors no poden pertànyer simultàniament al col·lectiu del personal d’administració i serveis.

• Tampoc no està permès que els professors es matriculin en el centre de treball en cap dels estudis impartits. Per tant, els professors no es poden considerar simultàniament alumnes.

• En canvi, sí està permès als integrants del col·lectiu d’administració i serveis que es matriculin, fora del seu horari laboral, en algun dels estudis impartits. Per tant, el personal d’administració i serveis pot pertànyer simultàniament a la categoria d’alumne.

• Hem de tenir constància del sou dels professors i del personal d’administració i serveis.

• Organitzativament, tot professor està assignat a un sol departament. I cada departament té assignat un dels seus professors com a coordinador.

• Tot professor té reconeguda una especialitat determinada (o més d’una). Però internament, la BD de l’institut només necessita registrar quins dels professors que té assignats el centre pertanyen a les especialitats d’informàtica o d’administració, per tal d’assignar-los tasques específiques addicionals a les docents que els són pròpies.

• De cada informàtic, voldrem saber les especialitats professionals, quan n’hi hagin, tant en l’àmbit del maquinari com també en el del programari.

• De cada administratiu, voldrem conèixer la titulació acadèmica i l’especialitat professional, si en té.

• Els alumnes poden practicar alguns esports a les instal·lacions del centre. I, fins i tot, poden disposar d’alguns professors com a entrenadors personals, que s’han ofert voluntàriament per realitzar aquesta tasca.

• Com és lògic, en tractar-se d’un centre de formació professional, l’institut del nostre exemple ofereix diferents estudis estructurats en cicles formatius, i cada cicle formatiu té les seves pròpies assignatures. Ens interessa, doncs, codificar les assignatures de la mateixa manera que es fa en el currículum oficial del cicle formatiu al qual pertanyen. El problema és que aquests codis es repeteixen per a tots els cicles formatius, ja que la codificació sempre consisteix en una C (per ser la inicial de la paraula crèdit) seguida d’un número enter (C1, C2, C3, i així successivament).

• Dins d’un mateix cicle formatiu, es pot exigir als alumnes que, per matricular-se en algunes assignatures, hagin superat alguna assignatura (o més d’una).

• D’altra banda, sempre hi ha un professor encarregat de realitzar la programació didàctica de cada assignatura. Un mateix professor, però, es pot encarregar de la programació didàctica de més d’una assignatura.

• Tots els alumnes del centre tenen un company que actua com a delegat en l’àmbit d’una assignatura i s’encarrega, per exemple, de distribuir els materials o les bateries d’exercicis. Un mateix alumne pot actuar com a delegat en l’àmbit de més d’una assignatura. Però cada alumne només tindrà un delegat en cada assignatura en què estigui matriculat.

• Finalment, la BD ha de recollir a quines assignatures està matriculat cada alumne en cada curs acadèmic, i la nota final obtinguda.

La figura següent mostra un diagrama ER que compleix els requisits esmentats anteriorment.

Exemple: BD d’un institut de formació professional

A continuació, es mostra una llista de totes les entitats que apareixen en el diagrama, acompanyades dels respectius atributs (subratllats si formen part d’una clau primària).

• DEPARTAMENT

• CodiDepartament, NomDepartament

• LOCALITAT

• CodiLocalitat, NomLocalitat

• PERSONA

• DNI, Nom, Cognoms, Adreça, Telefon, DataNaixement

• PROFESSOR (subclasse de PERSONA)

• DNI, Sou

• ADMO_SERVEI (subclasse de PERSONA)

• DNI, Sou

• ALUMNE (subclasse de PERSONA)

• DNI

• INFORMATIC (subclasse de PROFESSOR)

• DNI, EspecialitatMaquinari, EspecialitatProgramari

• ADMINISTRATIU (subclasse de PROFESSOR)

• DNI, Titulacio, Especialitat

• ESPORT

• CodiEsport, NomEsport

• CURS

• CodiCurs

• CICLE

• CodiCicle, NomCicle

• ASSIGNATURA (entitat feble: CodiAssignatura la identifica parcialment, i necessita el codi del cicle corresponent per tal d’identificar-se completament)

• CodiAssignatura, NomAssignatura

Finalment, cal comentar alguns dels aspectes més complexos d’aquest model, proporcionat a tall d’exemple:

• Les subclasses en què s’especialitza PROFESSOR (INFORMATIC i ADMINISTRATIU) són encavalcades (E) entre elles, i a més a més parcials (P):

• Són encavalcades perquè les instàncies de la superclasse poden pertànyer simultàniament a ambdues categories.

• Són parcials, perquè no totes les instàncies de la superclasse han de pertànyer necessàriament a alguna de les dues categories.

• Les subclasses que donen lloc a la generalització de PERSONA (PROFESSOR, ADMO_SERVEI i ALUMNE) són totals, perquè tota instància de la superclasse ha de pertànyer simultàniament a alguna de les tres subclasses esmentades. Ara bé, respecte al fet de si poden pertànyer simultàniament a diferents subclasses o no, tenen restriccions específiques, i les combinen de dues en dues. Aquesta particularitat està especificada textualment dins del diagrama:

• PROFESSOR i ADMO_SERVEI: les entitats són disjuntes entre elles, perquè les instàncies respectives no poden pertànyer al mateix temps a totes dues.

• PROFESSOR i ALUMNE: es dóna la mateixa circumstància que en el cas anterior.

• ALUMNE i ADMO_SERVEI: les entitats són encavalcades entre elles, perquè les instàncies respectives sí poden pertànyer al mateix temps a totes dues.

• Entre DEPARTAMENT i PROFESSOR hi ha dues interrelacions perquè serveixen per modelitzar dues realitats diferents: la coordinació del departament per part d’un professor (amb cardinalitat 1:1), i el fet que una pluralitat de professors estiguin adscrits al mateix (amb cardinalitat 1:N).

• La localitat de residència de les persones s’ha implementat mitjançant una entitat independent, i no com un simple atribut de l’entitat PERSONA. D’aquesta manera, s’evitaran redundàncies, perquè cada localitat només es registrarà un cop dins de la BD, tot i que després s’interrelacionarà amb totes les instàncies de PERSONA que calgui.

• S’ha optat per establir una agregació a partir de la interrelació Practica, per tal de permetre establir una altra interrelació (Entrena) entre aquesta i PROFESSOR, que evita la redundància de dades que hi hauria si s’hagués utilitzat una interrelació ternària entre ALUMNE, ESPORT i PROFESSOR, ja que contindria totes les combinacions de la interrelació entre ALUMNE i ESPORT. I no es podria implementar simplement una ternària entre ALUMNE, ESPORT i PROFESSOR, i suprimir la binària esmentada, perquè els alumnes també poden practicar els esports per lliure, sense cap professor que els entreni.

• Per representar la figura de l’alumne delegat d’assignatura, ha calgut recórrer a una interrelació recursiva ternària, ja que és necessari interrelacionar cada alumne que actua com a delegat amb els seus alumnes representats i, a més, amb l’assignatura de què es tracti en cada cas.

• Per representar els prerequisits de matriculació, hem afegit una altra interrelació recursiva, en aquest cas binària, que serveix per associar les assignatures entre elles quan és necessari.

• Fixem-nos que la interrelació ternària Matricula, entre CURS, ALUMNE i ASSIGNATURA, amb cardinalitat M:N:P, té un atribut propi per tal d’emmagatzemar la nota final de cada alumne.

Activitats

Pizzeria

• Ingredients d'una pizza

Dissenyeu un petit diagrama ER pel següent fragment del sistema: La cadena de pizzeries té una carta de pizzes on cada pizza conté diversos ingredients.

• Ingredients substituibles

Dissenyeu un petit diagrama ER pel següent fragment del sistema: La cadena de pizzeries té una carta de pizzes on cada pizza conté diversos ingredients.

• Locals de la cadena de pizzeries

Dissenyeu un petit diagrama ER pel següent fragment del sistema: La cadena de pizzeries té locals que poden ser de tipus restaurant, on els clients poden degustar-hi les pizzes in situ, o de tipus “per emportar”. Un mateix local pot ser, a la vegada, restaurant i admetre comandes per emportar.

• Comandes de pizzes

Dissenyeu un petit diagrama ER pel següent fragment del sistema: Per cada comanda, en una pizzeria, cal enregistrar les línies que la composen, seguin com a mostra el següent exemple:

COMANDA 278 2 Pizza margarita 10 €/unitat 1 Pizza americana 12 €/unitat 3 Refrescos 3 €/unitat TOTAL: 41 €

• Empleats d'una pizzeria

Dissenyeu un petit diagrama ER pel següent fragment del sistema: Cada local de la pizzeria té assignats diversos empleats, que poden ser: cuiners, cambrers, telefonistes o motoristes. Tenint en compte, però, que els un empleat pot canviar de rol, en un moment donat. Per exemple, un cambrer pot ser telefonista en un moment donat.

• L'empleat del mes

Dissenyeu un petit diagrama ER pel següent fragment del sistema: Cal enregistrar en el sistema de bases de dades, quin empleat serveix cada comanda, en una pizzeria, per tal de poder obtenir a posteriori l’empleat del mes (aquell que ha facturat més).

• Motoristes

Dissenyeu un petit diagrama ER pel següent fragment del sistema: En una pizzeria, cada empleat motorista té associada una moto, però una moto és compartida per diversos motoristes de diversos torns.

• Stock d'ingredients

Dissenyeu un petit diagrama ER pel següent fragment del sistema: En cada local d’una cadena de pizzeries cal controlar l’stock de cada ingredient que hi ha en un moment donat, així com l’stock mínim admissible, per tal que el sistema doni l’avís de compra, si es passa aquest mínim.

• Taules d'una pizzeria

Dissenyeu un petit diagrama ER pel següent fragment del sistema: En els locals que són de tipus restaurant, hi ha diverses taules. De cada taula cal enregistrar en la nostra base de dades el nombre de seients.

• Fer una reserva en una pizzeria

Dissenyeu un petit diagrama ER pel següent fragment del sistema: En els locals de tipus restaurant s’admeten reserves. Llavors caldrà enregistrar el nom, el telèfon, el nombre de persones i la data i hora de la reserva, a més de la taula que se’ls assignarà, en el moment de fer la reserva.

Fórmula 1

• Neumàtics d'una escuderia de F1

Dissenyeu un petit diagrama ER pel següent fragment del sistema: Cada Escuderia de F1 fa servir neumàtics d’una sola marca, però evidentment, cadascuna de les marques pot subministrar neumàtics a més d’una escuderia.

• Circuïts d'un gran premi de F1

Dissenyeu un petit diagrama ER pel següent fragment del sistema: Cada Gran Premi de F1 té lloc en un Circuit concret. Cal saber el nombre de voltes a completar per tal d’acabar cada Gran Premi, així com la data en què aquest tindrà lloc.

• Països dels circuïts de F1

Dissenyeu un petit diagrama ER pel següent fragment del sistema: Cada circuit de F1 està en un país concret, però un mateix país pot tenir més d’un circuit (per exemple a Espanya tenim Montmeló i València).

• Entrenaments de F1

Dissenyeu un petit diagrama ER pel següent fragment del sistema: Cal conservar el millor temps aconseguit per cada pilot als entrenaments oficials de cada Gran Premi de F1.

• Posició i temps en la F1

Dissenyeu un petit diagrama ER pel següent fragment del sistema: Cal guardar la posició en què queden els pilots a cada Gran Premi de F1, així com el temps total transcorregut des de la sortida fins a l’arribada a la meta.

• Monoplaces d'una escuderia de F1

Dissenyeu un petit diagrama ER pel següent fragment del sistema: Cada escuderia té 2 monoplaces (identificats per un número) per a participar en el Campionat. Els monoplaces d’una mateixa Escuderia poden anar equipats amb diferent motor.

• Empleats de les escuderies de F1

Dissenyeu un petit diagrama ER pel següent fragment del sistema: La majoria dels empleats de les escuderies pertany a alguna d’aquestes 3 categories: enginyers, mecànics i pilots. Els empleats, però, no poden pertànyer simultàniament a més d’una d’elles.

• Tipus de pilots de F1

Dissenyeu un petit diagrama ER pel següent fragment del sistema: Els pilots, a la F1, poden ser provadors o “amb seient”, i en aquest últim cas cal saber quin monoplaça tenen assignat.

• Pilots de F1 incompatibles

Dissenyeu un petit diagrama ER pel següent fragment del sistema: El sistema ha de registrar, quins pilots (provadors i “amb seient”) són incompatibles entre si, per tal de no fer-los coincidir en una mateixa Escuderia. Cal qualificar aquest grau d’incompatibilitat com a “greu”, “mitjà” o “lleu”.

La Vuelta

• Etapes de La Vuelta

Dissenyeu un petit diagrama ER pel següent fragment del sistema: Les etapes de La Vuelta s’identifiquen per un número correlatiu, a comptar a partir de l’1, que com és lògic s’associa a la primera etapa, a continuació el 2 s’associa a la segona, i així successivament fins a l’última. Cada etapa comença en una localitat i acaba en un altra.

• Ports de muntanya en les etapes de La Vuelta

Dissenyeu un petit diagrama ER pel següent fragment del sistema: Cada etapa de La Vuelta pot incloure un o més ports de muntanya (o cap), però cada port només pot estar inclòs dins d’una etapa.

• Províncies en les etapes de La Vuelta

Dissenyeu un petit diagrama ER pel següent fragment del sistema: Cada etapa de La Vuelta passa pel territori d’una o més províncies, però per una mateixa província pot passar més d’una etapa (o cap). Cal registrar el total de km de cada etapa que travessen cada província. Per exemple, una etapa podria travessar 35 km. de la província de Barcelona i 47 de la de Tarragona.

• Maillot dels ciclistes en les etapes de La Vuelta

Dissenyeu un petit diagrama ER pel següent fragment del sistema: La nostra BD ha de registrar quin ciclista porta cada maillot (general, muntanya, etc.) a cada etapa de La Vuelta. Cada maillot s’identifica mitjançant un codi, i és d’un color determinat. Els ciclistes s’identifiquen per un dorsal, hi a la BD ha de constar el seu nom i la seva data de naixement.

• Puntuació en els ports de muntanya de La Vuelta

Dissenyeu un petit diagrama ER pel següent fragment del sistema: Els ports de muntanya s’identifiquen pel seu topònim, i arriben a una alçada màxima determinada per sobre del nivell del mar. Els ports es classifiquen en quatre categories (especial, 1a, 2a i 3a). Cal dissenyar un sistema per tal d’emmagatzemar els punts que poden assolir els ciclistes segons la posició en què arribin a cada port segons es detalla a continuació (només amb la finalitat de millorar la comprensió de la funcionalitat requerida).

Ports de categoria especial:

     ____________________________
     Posició        Punts
     ____________________________
     1º 	    12
     2º 	     8
     3º 	     6
     4º 	     5
     5º 	     4
     6º 	     3
     7º 	     2
     8º 	     1      

*

*

*

*

*

*

*

*

*