Diferència entre revisions de la pàgina «M2 - Bases de dades / UF1NF2: Diagrames entitat-relació»
(→Elaboració d'un esquema conceptual) |
(→Elaboració d'un esquema conceptual) |
||
| Línia 571: | Línia 571: | ||
[[Imatge:uf1nf2_diagrama_ER_XBIC_mig_fer.png |300px|center| Diagrama ER de la XBIC a mig fer]] | [[Imatge:uf1nf2_diagrama_ER_XBIC_mig_fer.png |300px|center| 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 | ||
| + | |||
| + | [[Imatge:uf1nf2_diagrama_ER_XBIC_acabat.png |300px|center| Diagrama ER de la XBIC totalment acabat]] | ||
<pre> | <pre> | ||
</pre> | </pre> | ||
Revisió del 16:45, 8 oct 2014
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.
Contingut
- 1 Disseny de bases de dades
- 1.1 Fases del disseny de BD
- 1.2 Disseny conceptual d'una BD
- 1.3 Captura i abstracció dels requeriments de dades
- 1.4 Identificació d'entitats
- 1.5 Designació d'interrelacions
- 1.6 Establiment de claus
- 1.7 Establiment de cardinalitats
- 1.8 Restriccions de participació i límits de cardinalitat
- 1.9 Elaboració d'un esquema conceptual
- 2 Extensions del model Entitat-Relació
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
