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

Revisió del 08:37, 8 oct 2014 (mostra codi font) Rsort (Discussió | contribucions) (→‎Identificació d'entitats) ← Vés a l'edició anterior		Revisió de 13:01, 20 des 2021 (mostra codi font) Rsort (Discussió | contribucions)
(Hi ha 34 revisions intermèdies del mateix usuari que no es mostren)
Línia 1:		Línia 1:
−	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.	+	===BD de la Xarxa de Biblioteques d'INS de Catalunya (XBIC)====
−	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.	+	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.
−	===Disseny de bases de dades===	+	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.
−	El disseny de BD s’estructura, fonamentalment, en tres grans etapes:	+	::'''Informe d'anàlisi i disseny de BD'''
−	:*Disseny conceptual	+	::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.
−	:*Disseny lògic	+	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:
−	:*Disseny físic	+	'''1. Servei de préstec'''
−	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.	+	:*Mitjançant aquest servei, s’ofereix la possibilitat de treure els diversos documents (llibres, revistes, vídeos, CD…) de la biblioteca.
−	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:	+	:*Per utilitzar el servei de préstec, els usuaris han de tenir el carnet de biblioteca.
−	:*Quines entitats ha d’incloure una BD determinada.	+	:*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.
−	:*Quines interrelacions s’han de considerar.	+	:*El mateix carnet serveix per a tota la Xarxa de Biblioteques i permet gaudir d’avantatges interessants en el món de la cultura.
−	:*Quins atributs han d’existir i en quines entitats o interrelacions s’han d’incorporar.	+	:*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.).
−	:*Quines claus primàries ja es poden establir en la fase de disseny conceptual.	+	:*A més, els usuaris poden fer altres gestions en línia relacionades amb el préstec: reserves i renovacions de documents.
−	====Fases del disseny de BD====	+	'''2. Normativa d'ús del servei de préstec de la Xarxa de Biblioteques'''
−	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.	+	:*Tenir el carnet implica acceptar les normes de funcionament de la biblioteca.
−	:::'''Món real'''	+	:*El carnet és personal i intransferible.
−	:::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.	+	:*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.
−	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.	+	:*Cal comunicar, a la biblioteca, qualsevol canvi de domicili o la pèrdua del carnet.
−	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.	+	:*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.
−	És habitual estructurar el disseny de BD en les tres etapes o fases següents:	+	:*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.
−	:1. Disseny conceptual.	+	:*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.
−	:2. Disseny lògic.
−	:3. Disseny físic.
−	'''Fase de disseny conceptual'''	+	:*Queden exclosos de préstec els documents següents:
−	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.	+	::*Algunes obres de referència: enciclopèdies, diccionaris, atles, etc.
−	Aquesta recopilació d’informació es realitzarà per diferents vies, com ara aquestes:	+	::*Fons de reserva.
−	:*Entrevistes amb els futurs usuaris de la BD que s’està dissenyant.	+	::*Documents pertanyents a la col·lecció local.
−	:*Examen de la documentació proporcionada per aquests mateixos usuaris.	+	::*Números corrents de revistes i de diaris.
−	:*Observació directa dels processos a informatitzar.	+	:*Els documents que la biblioteca cregui convenient que no surtin de la biblioteca.
−	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.	+	:*A més del servei de préstec a l’usuari individual, les biblioteques ofereixen altres tipus de préstec:
−	L’'''objectiu del disseny conceptual''' consisteix en l’obtenció d’una especificació sistemàtica.	+	::*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 €.
−	L’esmentada especificació sistemàtica resultat del disseny conceptual ha de complir dos tipus de requisits:	+	::*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 €.
−	:*'''De dades'''. El model resultant ha de tenir en compte l’estructura completa de les dades i la seva integritat.	+	'''3. Consulta del catàleg'''
−	:*'''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.	+	:*S’ha de poder consultar la disponibilitat dels fons bibliotecaris pels conceptes següents:
−	El model Entitat-Interrelació (o model Entitat-Relació) també es coneix de manera abreujada com a model ER (sigles corresponents a entity-relationship).	+	::*Signatura (identificador de l’exemplar físic objecte de préstec)
−	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ó'''.	+	::*Títol
−	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.	+	::*Paraula clau continguda en el títol
−	::'''El model ER'''	+	::*Autor (concretament, pel cognom)
−	::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.	+	::*Nom o cognoms incomplets de l’autor
−	::Una '''interrelació''', en el model ER, és l’associació entre instàncies de diferents entitats tipus. Aquesta associació es pot donar amb diverses cardinalitats.	+	::*Matèria
−	Un atribut, en el model ER, és una característica d’una entitat que ens interessa tenir registrada.	+	:*A més, les cerques s’han de poder limitar als àmbits següents:
−	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.	+	::*Una biblioteca concreta
−	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.	+	::*Totes les biblioteques d’una sola població
−	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à.	+	::*Totes les biblioteques d’una sola comarca
−	'''Fase de disseny lògic'''	+	:*Finalment, s’han de poder limitar els resultats obtinguts en funció dels conceptes següents:
−	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.	+	::*Idioma
−	Les claus primàries serveixen per distingir entre si les diferents tuples d’atributs dins d’una mateixa relació.	+	::*Tipus de format
−	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:	+	::*Any de publicació
−	:*Jeràrquic	+	====Identificació d'entitats====
−	:*Relacional	+	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.
−	:*Distribuït	+	<pre>
		+	La identificació de les entitats i dels seus atributs es pot documentar amb un llistat
		+	que segueixi el format següent:
−	:*Orientat a objectes	+	ENTITAT1 (Atribut1, Atribut2, …)
		+	ENTITAT2 (Atribut1, Atribut2, …)
		+	…
		+	ENTITATn (Atribut1, Atribut2, …)
		+	</pre>
−	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.	+	En el llistat, els noms de les entitats aniran amb majúscules, i els noms dels atributs començaran amb majúscules.
−	Les claus foranes són uns instruments destinats a permetre la interrelació de la respectiva relació amb d’altres.	+	::L’exemple parteix de la informació referida en l’apartat “Captura i abstracció dels requeriments de dades”.
−	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.	+	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:
−	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'''.	+	:*INS(Poblacio, Comarca). Possibles atributs addicionals: Nom, Adreça i Telefon.
−	'''Fase de disseny físic'''	+	:*DOCUMENT(Format, Import, ExclosPrestec, Signatura, Titol, Autor, Materia, Idioma, AnyPublicacio).
−	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.	+	:*USUARI(DNI, Nom, Cognoms, Adreça, DataNaixement, Carnet, DataFinalExclusioPrestec).
−	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:	+	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.
−	:*Afegir algun atribut calculable en alguna relació.	+	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.
−	:*Dividir una relació en altres dues o en més.	+	Passa el mateix amb altres atributs de DOCUMENT: el format, l’autor la matèria i l’idioma.
−	:*Incloure en la BD una relació que sigui el producte de combinar dues o més relacions.	+	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.
−	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:	+	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.
−	:*Definició d’índexs.	+	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:
−	:*Assignació de l’espai inicial per a les taules, i previsió del seu creixement ulterior.	+	:*INS(Nom, Adreça, Telefon)
−	:*Selecció de la mida de les memòries intermèdies.	+	:*DOCUMENT(Signatura, Titol, AnyP ublicacio, Import, ExclosPrestec)
−	:*Parametrització del SGBD segons les opcions que aquest ofereixi.	+	:*USUARI(Carnet, DNI, Nom, Cognoms, Adreça, DataNaixement, DataFinalExclusioPrestec)
−	La volatilitat de les dades té a veure amb el volum d’insercions i esborraments de les mateixes.	+	:*POBLACIO(Nom)
−	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.	+	:*COMARCA(Nom)
−	====Disseny conceptual d'una BD====	+	:*FORMAT(Descripcio)
−	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:	+	:*AUTOR(Nom, Cognoms)
−	:*'''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.).	+	:*MATERIA(Descripcio)
−	:*'''Subsistema de decisió'''. S’encarrega de dirigir, coordinar i planificar les activitats realitzades dins de l’àmbit del subsistema de producció.	+	:*IDIOMA(Descripcio)
−	:*'''Subsistema d’informació'''. S’encarrega de recollir, emmagatzemar, processar i distribuir, totes les informacions necessàries per al bon funcionament dels altres dos subsistemes.	+	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ó.
−	Les BD serveixen per emmagatzemar les representacions de les informacions utilitzades dins de l’àmbit dels sistemes d’informació.	+	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.
		+	<pre>
		+	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.
		+	</pre>
−	Els elements que conformen un '''sistema d’informació''' són de dos tipus:	+	====Designació d'interrelacions====
−	:*Dades: representacions de les informacions.	+	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.
		+	<pre>
		+	Les interrelacions es poden documentar amb el format següent:
−	:*Processos: accions exercides sobre les dades (consultes, modificacions, càlculs, etc.).	+	Interrelacio (Atribut1, Atribut2, …), entre ENTITATi i ENTITATj
−	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:	+	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.
		+	</pre>
		+	<pre>
		+	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.
		+	</pre>
		+	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:
−	:*No és competència del dissenyador de BD, com a tal, prendre decisions sobre la porció del món real que vol modelitzar.	+	:*Prestec(Data, Tipus, Preu), entre USUARI i DOCUMENT
−	:*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.	+	:*RenovacioPrestec(Data), entre USUARI i DOCUMENT
−	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.	+	:*Reserva(Data), entre USUARI i DOCUMENT
−	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.	+	:*Ubicació, entre INS i DOCUMENT
−	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).	+	Però, després de considerar l’establiment de la resta d’entitats, haurem d’afegir les interrelacions corresponents:
−	====Captura i abstracció dels requeriments de dades====	+	:*Esta, entre INS i POBLACIO
−	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.	+	:*Pertany, entre POBLACIO i COMARCA
−	::'''Usuaris de les BD'''	+	:*Te1, entre FORMAT i DOCUMENT
−	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.	+	:*Te2, entre AUTOR i DOCUMENT
−	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.	+	:*Versa, entre MATERIA i DOCUMENT
−	El dissenyador de BD és el professional informàtic que s’encarrega de realitzar les tasques que implica el disseny de les BD.	+	:*Expressat, entre IDIOMA i DOCUMENT
−	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:	+	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.
−	:*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.	+	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í:
−	:*Examen exhaustiu de la documentació proporcionada pel client, per tal de conèixer el funcionament intern de l’organització.	+	:*Viu, entre USUARI i POBLACIO
−	:*Observacions directes dels diferents processos de l’organització.	+	====Establiment de claus====
−	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.	+	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.
−	'''Un exemple concret: BD de la Xarxa de Biblioteques d'INS de Catalunya (XBIC)'''	+	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'''.
		+	<pre>
		+	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.
		+	</pre>
		+	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.
		+	<pre>
		+	L’atribut o conjunt d’atributs que formen la clau primària han d’aparèixer subratllats en la
		+	documentació.
		+	</pre>
		+	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.
		+	<pre>
		+	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.
		+	</pre>
		+	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:
−	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.	+	:*DOCUMENT(Signatura , Titol, AnyPublicacio, Import, ExclosPrestec)
−	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.	+	:*COMARCA(Nom)
−	::'''Informe d'anàlisi i disseny de BD'''	+	:*POBLACIO(Nom)
−	::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.	+	:*FORMAT(Descripcio)
−	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:	+	:*MATERIA(Descripcio)
−	'''1. Servei de préstec'''	+	:*IDIOMA(Descripcio)
−	:*Mitjançant aquest servei, s’ofereix la possibilitat de treure els diversos documents (llibres, revistes, vídeos, CD…) de la biblioteca.	+	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í:
−	:*Per utilitzar el servei de préstec, els usuaris han de tenir el carnet de biblioteca.	+	:*AUTOR(Codi, Nom, Cognoms)
−	:*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.	+	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:
−	:*El mateix carnet serveix per a tota la Xarxa de Biblioteques i permet gaudir d’avantatges interessants en el món de la cultura.	+	:*USUARI(Carnet, DNI, Nom, Cognoms, Adreça, DataNaixement, DataFinalExclusioPrestec)
−	:*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.).	+	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:
−	:*A més, els usuaris poden fer altres gestions en línia relacionades amb el préstec: reserves i renovacions de documents.	+	:*INS(Nom , Adreça, Telefon)
−	'''2. Normativa d'ús del servei de préstec de la Xarxa de Biblioteques'''	+	====Establiment de cardinalitats====
−	:*Tenir el carnet implica acceptar les normes de funcionament de la biblioteca.	+	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.
−	:*El carnet és personal i intransferible.	+	Cal afegir, doncs, la informació referent a les cardinalitats de les interrelacions en la documentació de disseny.
		+	<pre>
		+	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.
		+	</pre>
		+	En el model que estem construint (seguint l’exemple de la BD de la XBIC) podem establir les cardinalitats següents:
−	:*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.	+	:*Un mateix usuari pot agafar en préstec diferents documents, i un mateix document es pot prestar a diferents usuaris, al llarg del temps:
		+	<pre>
		+	Prestec(Data, Tipus, Preu), entre USUARI i DOCUMENT: M-N
		+	</pre>
		+	:*Passa el mateix en cas de renovar un préstec o de reservar un document:
		+	<pre>
		+	RenovacioPrestec(Data), entre USUARI i DOCUMENT: M-N
		+	</pre>
		+	<pre>
		+	Reserva(Data), entre USUARI i DOCUMENT: M-N
		+	</pre>
		+	:*Tot document pertanyerà a la biblioteca d’un INS concret, la qual podrà disposar de molts documents:
−	:*Cal comunicar, a la biblioteca, qualsevol canvi de domicili o la pèrdua del carnet.	+	Ubicació, entre INS i DOCUMENT: 1-N
−	:*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.	+	:*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:
		+	<pre>
		+	Esta, entre INS i POBLACIO: N-1
		+	</pre>
		+	:*Cada població pertany a una sola comarca, però cada comarca tindrà més d’una població a dins del seu territori:
		+	<pre>
		+	Pertany, entre POBLACIO i COMARCA: N-1
		+	</pre>
		+	:*S’ha considerat que cada document només té un format, però evidentment cada format serà aplicable a molts documents diferents:
		+	<pre>
		+	Te1, entre FORMAT i DOCUMENT: 1-N
		+	</pre>
		+	:*Amb una cardinalitat M-N, fem possible registrar més d’un autor per a un mateix document:
		+	<pre>
		+	Te2, entre AUTOR i DOCUMENT: M-N
		+	</pre>
		+	:*En canvi, considerem que cada document només pot versar sobre una sola matèria:
		+	<pre>
		+	Versa, entre MATERIA i DOCUMENT: 1-N
		+	</pre>
		+	:*Un document (com ara una pel·lícula en DVD) podrà estar expressat en diferents idiomes:
		+	<pre>
		+	Expressat, entre IDIOMA i DOCUMENT: M-N
		+	</pre>
		+	:*Cada usuari té el domicili en una població concreta. Però en una mateixa població hi poden viure diferents usuaris:
		+	<pre>
		+	Viu, entre USUARI i POBLACIO: N-1
		+	</pre>
−	:*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.	+	====Restriccions de participació i límits de cardinalitat====
		+	<pre>
		+	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.
		+	</pre>
		+	:*Prestec(Data, Tipus, Preu), entre USUARI (parcial) i DOCUMENT (parcial): M-N
−	:*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.	+	:*RenovacioPrestec(Data), entre USUARI (parcial) i DOCUMENT (parcial): M-N
−	:*Queden exclosos de préstec els documents següents:	+	:*Reserva(Data), entre USUARI (parcial) i DOCUMENT (parcial): M-N
−	::*Algunes obres de referència: enciclopèdies, diccionaris, atles, etc.	+	:*Ubicació, entre INS (parcial) i DOCUMENT (total): 1-N
−	::*Fons de reserva.	+	:*Esta, entre INS (total) i POBLACIO (parcial): N-1
−	::*Documents pertanyents a la col·lecció local.	+	:*Pertany, entre POBLACIO (total) i COMARCA (total): N-1
−	::*Números corrents de revistes i de diaris.	+	:*Te1, entre FORMAT (parcial) i DOCUMENT (total): 1-N
−	:*Els documents que la biblioteca cregui convenient que no surtin de la biblioteca.	+	:*Te2, entre AUTOR (total) i DOCUMENT (total): M-N
−	:*A més del servei de préstec a l’usuari individual, les biblioteques ofereixen altres tipus de préstec:	+	:*Versa, entre MATERIA (parcial) i DOCUMENT (total): 1-N
−	::*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 €.	+	:*Expressat, entre IDIOMA (total) i DOCUMENT (total): M-N
−	::*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 €.	+	:*Viu, entre USUARI (total) i POBLACIO (parcial): N-1
−	'''3. Consulta del catàleg'''	+	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.
		+	<pre>
		+	Les interrelacions quedaran documentades, doncs, amb el format següent:
−	:*S’ha de poder consultar la disponibilitat dels fons bibliotecaris pels conceptes següents:	+	Interrelacio (Atribut1, Atribut2, …), entre ENTITATi (participacio) i ENTITATj
		+	(participacio): tipus_de_cardinalitat
−	::*Signatura (identificador de l’exemplar físic objecte de préstec)	+	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.
		+	</pre>
−	::*Títol	+	====Elaboració d'un esquema conceptual====
		+	<pre>
		+	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.
		+	</pre>
		+	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.
		+	<pre>
		+	Un diagrama ER és un esquema gràfic que serveix per representar un model ER.
		+	</pre>
		+	<pre>
		+	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.
		+	</pre>
		+	<pre>
		+	UML
−	::*Paraula clau continguda en el títol	+	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.
		+	</pre>
		+	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.
−	::*Autor (concretament, pel cognom)	+	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.
−	::*Nom o cognoms incomplets de l’autor	+	::Diagrama ER inicial de la XBIC
−	::*Matèria	+	[[Imatge:uf1nf2_diagrama_ER_inicial_XBIC.png |600px|center| Diagrama ER inicial de la XBIC]]
−	:*A més, les cerques s’han de poder limitar als àmbits següents:	+	::Diagrama ER de la XBIC a mig fer
−	::*Una biblioteca concreta	+	[[Imatge:uf1nf2_diagrama_ER_XBIC_mig_fer.png |600px|center| Diagrama ER de la XBIC a mig fer]]
−	::*Totes les biblioteques d’una sola població	+	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ó.
−	::*Totes les biblioteques d’una sola comarca	+	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.
−	:*Finalment, s’han de poder limitar els resultats obtinguts en funció dels conceptes següents:	+	::Diagrama ER de la XBIC totalment acabat
−	::*Idioma	+	[[Imatge:uf1nf2_diagrama_ER_XBIC_acabat.png |600px|center| Diagrama ER de la XBIC totalment acabat]]
−	::*Tipus de format	+	===BD d'un institut de formació professional===
−	::*Any de publicació	+	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.
−	====Identificació d'entitats====	+	Les descripcions següents resumeixen els requisits dels usuaris de la futura BD:
−
−	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.
	<pre>		<pre>
−	La identificació de les entitats i dels seus atributs es pot documentar amb un llistat	+	Els requisits per dissenyar una BD...
−	que segueixi el format següent:
−	ENTITAT1 (Atribut1, Atribut2, …)	+	… d’un institut real segurament serien molt més nombrosos que els
−	ENTITAT2 (Atribut1, Atribut2, …)	+	que hem exposat aquí, els quals estan seleccionats amb finalitats
−	…	+	educatives, i no necessàriament en funció de la seva importància o
−	ENTITATn (Atribut1, Atribut2, …)	+	freqüència en el món real.
	</pre>		</pre>
		+	:*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.
−	En el llistat, els noms de les entitats aniran amb majúscules, i els noms dels atributs començaran amb majúscules.	+	:*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
		+
		+	[[Imatge:uf1nf2_exemple_BD_institut_FP.png |600px|center| Exemple: BD d'un institut de formació professional]]
−	::L’exemple parteix de la informació referida en l’apartat “Captura i abstracció dels requeriments de dades”.	+	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).
−	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:	+	:*DEPARTAMENT
−	:*INS(Poblacio, Comarca). Possibles atributs addicionals: Nom, Adreça i Telefon.	+	::*CodiDepartament, NomDepartament
−	:*DOCUMENT(Format, Import, ExclosPrestec, Signatura, Titol, Autor, Materia, Idioma, AnyPublicacio).	+	:*LOCALITAT
		+
		+	::*CodiLocalitat, NomLocalitat
		+
		+	:*PERSONA
		+
		+	::*DNI, Nom, Cognoms, Adreça, Telefon, DataNaixement
		+
		+	:*PROFESSOR (subclasse de PERSONA)
−	:*USUARI(DNI, Nom, Cognoms, Adreça, DataNaixement, Carnet, DataFinalExclusioPrestec).	+	::*DNI, Sou
		+
		+	:*ADMO_SERVEI (subclasse de PERSONA)
		+
		+	::*DNI, Sou
		+
		+	:*ALUMNE (subclasse de PERSONA)
−	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.	+	::*DNI
−	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.	+	:*INFORMATIC (subclasse de PROFESSOR)
−	Passa el mateix amb altres atributs de DOCUMENT: el format, l’autor la matèria i l’idioma.	+	::*DNI, EspecialitatMaquinari, EspecialitatProgramari
−	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.	+	:*ADMINISTRATIU (subclasse de PROFESSOR)
−	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.	+	::*DNI, Titulacio, Especialitat
−	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).	+	:*ESPORT
−	Després de fer aquestes consideracions, ens trobaríem amb unes quantes entitats més que no pas inicialment:
−	:*INS(Nom, Adreça, Telefon)	+	::*CodiEsport, NomEsport
−	:*DOCUMENT(Signatura, Titol, AnyP ublicacio, Import, ExclosPrestec)	+	:*CURS
−	:*USUARI(Carnet, DNI, Nom, Cognoms, Adreça, DataNaixement, DataFinalExclusioPrestec)	+	::*CodiCurs
−	:*POBLACIO(Nom)	+	:*CICLE
−	:*COMARCA(Nom)	+	::*CodiCicle, NomCicle
−	:*FORMAT(Descripcio)	+	:*ASSIGNATURA (entitat feble: CodiAssignatura la identifica parcialment, i necessita el codi del cicle corresponent per tal d’identificar-se completament)
−	:*AUTOR(Nom, Cognoms)	+	::*CodiAssignatura, NomAssignatura
−	:*MATERIA(Descripcio)	+	Finalment, cal comentar alguns dels aspectes més complexos d’aquest model, proporcionat a tall d’exemple:
−	:*IDIOMA(Descripcio)	+	:*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):
−	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ó.	+	::*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.
−	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.	+	:*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:
−	<pre>
−	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.
−	</pre>
−	====Designació d'interrelacions====	+	::*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.
−	====Establiment de claus====	+	::*PROFESSOR i ALUMNE: es dóna la mateixa circumstància que en el cas anterior.
−	====Establiment de cardinalitats====	+	::*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).
−	====Restriccions de participació i límits de cardinalitat====	+	:*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.
−	====Elaboració d'un esquema conceptual====	+	:*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.
−	===Extensions del model Entitat-Relació===	+	:*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.
−	====Especialització i generalització====
−	====Agregacions d'entitats====
−	====Exemple: BD d'un institut de formació professional====	+	:*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.

---

Revisió de 13:01, 20 des 2021

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

BD d'un institut de formació professional

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

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

               Els requisits per dissenyar una BD...

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

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

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

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

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

• Professors

• Alumnes

• Personal d’administració i serveis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Exemple: BD d’un institut de formació professional

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

• DEPARTAMENT

• CodiDepartament, NomDepartament

• LOCALITAT

• CodiLocalitat, NomLocalitat

• PERSONA

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

• PROFESSOR (subclasse de PERSONA)

• DNI, Sou

• ADMO_SERVEI (subclasse de PERSONA)

• DNI, Sou

• ALUMNE (subclasse de PERSONA)

• DNI

• INFORMATIC (subclasse de PROFESSOR)

• DNI, EspecialitatMaquinari, EspecialitatProgramari

• ADMINISTRATIU (subclasse de PROFESSOR)

• DNI, Titulacio, Especialitat

• ESPORT

• CodiEsport, NomEsport

• CURS

• CodiCurs

• CICLE

• CodiCicle, NomCicle

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

• CodiAssignatura, NomAssignatura

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

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

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

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

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

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

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

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

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

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

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

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

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

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