Diferència entre revisions de la pàgina «M2 - Bases de dades / UF1NF2: Diagrames entitat-relació»

Revisió del 18:15, 8 oct 2014 (mostra codi font) Rsort (Discussió | contribucions) (→‎Especialització i generalització) ← Vés a l'edició anterior		Revisió del 18:26, 8 oct 2014 (mostra codi font) Rsort (Discussió | contribucions) (→‎Especialització i generalització) Vés a l'edició següent →
Línia 717:		Línia 717:
	:::Exemple d’herència múltiple		:::Exemple d’herència múltiple
		+	[[Imatge:uf1nf2_exemple_herencia_multiple.png |450px|center| 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)
	<pre>		<pre>
		+	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.).
	</pre>		</pre>
		+	:::Exemple de subclasses D,T
		+
		+	[[Imatge:uf1nf2_exemple_subclases_D_T.png |450px|center| Exemple de subclasses D, T]]
		+
	<pre>		<pre>
	</pre>		</pre>

---

Revisió del 18:26, 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.

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

Agregacions d'entitats

Exemple: BD d'un institut de formació professional