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

De wikiserver
Dreceres ràpides: navegació, cerca

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 inicial de la XBIC
Diagrama ER de la XBIC a mig fer
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
Diagrama ER de la XBIC totalment acabat

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
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.