M2 - Bases de dades / UF1NF2: Annex: Decisions de disseny

El disseny de les BD consisteix a definir una estructuració de les dades tal que satisfaci les necessitats dels futurs usuaris del sistema d’informació que es vol construir.

Per tal de satisfer com cal els requeriments funcionals dels usuaris, el dissenyador de BD haurà de considerar els diferents tipus d’operacions a realitzar sobre les dades.

          El dissenyador haurà de prendre certes decisions en la modelització 
          de les dades, que fins i    tot poden comportar la revisió de l’esquema 
          trobat inicialment, com per exemple en els àmbits següents:

              - Ús d’entitats o d’atributs
              - Ús d’entitats o d’interrelacions         
              - Ús d’una interrelació n-ària o de diferents interrelacions binàries
              - Ubicació dels atributs de les interrelacions
              - Ús de l’entitat DATA

                Pot ser interessant per al dissenyador de BD conèixer 
                algunes notacions alternatives que permetin representar 
                els mateixos conceptes del model ER de manera equivalent,
                com ara l’estàndard UML (unified modeling language), o 
                llenguatge unificat de modelització, el qual permet modelar
                simultàniament dades i funcionalitats, i que està especialment
                orientat al disseny global de dades i d’aplicacions que 
                s’hagin d’implementar preferentment mitjançant llenguatges 
                de programació orientats a objectes. 

          El dissenyador també haurà de detectar i evitar els paranys de disseny que es 
          puguin produir en fer conceptualitzacions errònies del món real, com ara:

               - Encadenament erroni d’interrelacions binàries 1-N
               - Ús incorrecte d’interrelacions binàries M-N
               - Falses interrelacions ternàries

A continuació, cal plasmar totes aquestes decisions en una documentació que permeti continuar treballant en les fases de disseny posteriors.

Alternatives de disseny

Una de les característiques fonamentals del model ER és que és molt flexible. Tant és així, que una mateixa realitat pot ser modelitzada de diferents maneres pel dissenyador, el qual de vegades disposa d’alternatives a l’hora de definir les entitats i les seves interrelacions.

Ús alternatiu d'entitats o d'atributs

          De vegades, un mateix objecte del món real es pot representar mitjançat un atribut 
          o una entitat. 

Considerem la ja coneguda entitat DOCUMENT, del model ER que hem elaborat per la XBIC, i que compta amb els atributs Signatura, Titol, AnyPublicacio, Import i ExclosPrestec. Es podria argumentar que el títol del document podria constituir una entitat per ell mateix. Els motius són els següents:

• Una biblioteca pot disposar de més d’un exemplar d’alguns títols (per exemple, una biblioteca podrà tenir dos o tres exemplars d’una mateixa novel·la si la demanda ho aconsella).

• Una biblioteca també pot disposar d’un mateix títol en diferents formats, cadascun constituirà un document diferent (pensem en el cas, per exemple, d’un mateix títol per a una obra que està disponible en format llibre, còmic i DVD).

• Finalment, un mateix títol pot estar disponible a més d’una biblioteca, i la futura BD ha de possibilitar el préstec interbibliotecari de documents i, per tant, la seva consulta.

Si s’accepta aquest punt de vista, l’entitat DOCUMENT originària s’hauria de tornar a definir de la manera següent:

• L’entitat DOCUMENT es quedaria amb els atributs Signatura, AnyPublicacio, Import i ExclosPrestec, i perdria l’atribut Titol.

• Hi hauria una nova entitat, anomenada TITOL. En previsió de la possible coincidència d’un mateix títol per a diferents obres, establim un atribut anomenat Codi, com a clau primària de l’entitat, i un altre atribut anomenat Descripcio, que emmagatzemarà els diferents títols de què disposin els fons bibliogràfic i documental de la XBIC.

• Seria necessari establir una interrelació entre les entitats TITOL i DOCUMENT, amb cardinalitat 1-N, i anomenar-la, per exemple, TitolDocument, per tal de reflectir l’associació entre cada títol i els documents respectius.

En la figura següent, es poden veure dos diagrames alternatius segons si es tracta el títol dels documents com un atribut o bé com una entitat.

Quines són, aleshores, les diferències fonamentals entre les dues opcions considerades? Tractar un concepte del món real com una entitat en lloc de com un atribut comporta certs avantatges:

• Evita redundàncies de dades, ja que un mateix valor (com per exemple el títol d’un document) només s’introduirà un cop (i no un cop per l’atribut de cada exemplar), la qual cosa permet el següent:

• Estalviar espai en la BD.

• Minimitzar la possibilitat d’error dels usuaris (i al mateix temps facilitar-los la correcció).

• Optimitzar les consultes sobre la BD i potenciar-ne la coherència dels resultats.

• Assigna una cardinalitat (1 o N), i uns límits sobre aquesta, sense recórrer a l’ús d’atributs multivaluats (els quals no són directament implementables en el model relacional, que continua essent el model lògic més utilitzat), de tal manera que podem assignar 0, 1 o més valors en cada cas, segons la realitat que correspongui modelitzar.

• Inclou informació addicional afegint nous atributs a l’entitat creada o, si no, relacionant aquesta amb altres entitats.

Així, doncs, estem en condicions d’afegir, per exemple, un nou atribut a l’entitat POBLACIO que ens indiqui el nombre d’habitants, o bé d’establir una nova interrelació amb COMARCA que ens indiqui quina és la capital de cadascun d’aquests ens territorials, tal com es pot veure en la figura següent.

Evidentment, aquestes opcions no haurien estat possibles si haguéssim conceptualitzat les poblacions com a simples atributs d’algunes entitats del model (concretament de COMARCA, IES i USUARI).

Això no significa que sempre és recomanable l’ús d’entitats abans que no pas d’atributs. El primer que hauríem de fer abans d’adoptar una decisió en aquest sentit seria examinar si l’atribut en qüestió emmagatzemarà valors repetits, ja que en cas contrari, normalment, serà preferible obtenir només un objecte (una entitat) en lloc de tres (dues entitats i una interrelació), la qual cosa comporta un resultat molt més compacte.

          En definitiva, el fet de tractar un concepte com a entitat és una opció més 
          general que no pas tractar-lo com a atribut, la qual permet emmagatzemar 
          informació addicional, afegint nous atributs o bé establint noves interrelacions. 

Ara bé, decidir-se per aquesta opció només té sentit quan resulta d’alguna utilitat. Per exemple, difícilment es podria defensar el tractament del nom propi dels usuaris com a entitat per si mateix. Encara que, de ben segur, es produiran repeticions de valors en aquest atribut, utilitzar una entitat per representar-lo només complicaria l’esquema resultant, però no reflectiria millor la realitat que es vol modelitzar ni, en principi, aportaria cap avantatge respecte a l’opció inicial.

Ús alternatiu d'entitats o d'interrelacions

          De vegades, és millor representar un objecte del món real mitjançant una entitat i, d’altres 
          vegades, com una   interrelació.

Com a regla general, podem fer les afirmacions següents:

• Les entitats consisteixen en objectes del món real, independentment del fet que existeixin físicament com, per exemple un cotxe, o que tinguin un caràcter més aviat abstracte, com ara una pòlissa d’assegurança. Habitualment, ens hi referim amb substantius.

• En canvi, les interrelacions, haurien de servir per representar accions o processos que tenen lloc entre entitats. És freqüent referir-s’hi utilitzant verbs (encara que sigui amb participis).

Considerar el préstec de documents als usuaris com a una interrelació amb tres atributs propis (Data, Tipus i Preu) provoca certs problemes, ja que els atributs descriptius Tipus i Preu tenen molts pocs valors possibles:

• préstec normal, gratuït

• préstec interbibliotecari, 1,20 €

• préstec a domicili, 1,50 €

Aquestes tres parelles de valors es repetiran per a cada préstec, ocuparan inútilment molt espai d’emmagatzemament i, encara pitjor, deixaran en les mans dels usuaris de la BD (o, com a màxim, dels informàtics que programin aplicacions contra la BD), a cada nova inserció, la responsabilitat de la consistència de les dades, ja que aquests atributs mai no haurien de tenir valors diferents dels esmentats.

Una possibilitat per evitar aquesta problemàtica consistiria a considerar l’existència d’una entitat, anomenada TIPUS_PRESTEC, amb dos atributs, que serien Tipus, com a clau primària, i Preu. Aleshores es podria establir una interrelació ternària de cardinalitat M-N-P entre USUARI, DOCUMENT i PRESTEC, que només incorporés l’atribut Data. Podem veure l’esquema plantejat inicialment i l’alternativa que acabem de descriure en la figura anterior.

Ús alternatiu d'interrelacions binàries o ternàries

              Les interrelacions més freqüents que es troben en les BD són binàries.          

          De vegades, certes interrelacions que en principi no semblen binàries es podrien plantejar 
          més encertadament amb un conjunt d’interrelacions de grau 2.

          Exemple d'una interrelació originàriament ternària
          
          La interrelació d’un fill amb el seu pare i la seva mare (amb cardinalitat N-1-1).
 
          Seria, doncs, més encertat plantejar dues interrelacions binàries que interrelacionessin per 
          separat el fill i el pare, d’una banda, i el fill i la mare, d’una altra (amb cardinalitats N-1).
 
          D’aquesta manera, encara que no constés la paternitat, es podria registrar correctament la 
          maternitat. En canvi, fent servir una interrelació ternària no tindríem aquesta possibilitat.

D’altra banda, sempre és possible (la qual cosa no vol dir recomanable) representar les interrelacions ternàries amb cardinalitat M-N-P (i, per extensió, les n-àries de qualsevol ordre n, amb cardinalitat similar) amb un conjunt de tres interrelacions binàries (o de n, tractant-se d’una n-ària d’ordre superior).

Per aconseguir-ho, cal seguir els passos següents:

• Convertir la interrelació inicial en una entitat.

• S’ha d’establir un atribut identificador que actuï com a clau primària.

• Si la interrelació originària té atributs, aquests s’han d’incorporar a la nova entitat.

• Establir n interrelacions binàries entre la nova entitat i cadascuna de les n entitats preexistents.

Cal dir que aquest procés és reversible, és a dir, que es pot seguir de manera inversa.

En la següent figura, es mostra la conversió de la interrelació ternària Préstec (vegeu figura.6) en una nova entitat i tres noves interrelacions binàries.

Per tant, si no féssim cap altraries. Però això no seria desitjable gairebé mai pels motius següents:

• L’atribut identificador de l’entitat en què convertíssim l’entitat n-ària originària, juntament amb el conjunt d’interrelacions binàries necessàries, normalment comportarien un increment de la complexitat del disseny obtingut i, per tant, també comportarien un augment dels requeriments ulteriors d’emmagatzemament de la BD.

• Una interrelació n-ària mostra més clarament les entitats directament associades que no pas un conjunt d’interrelacions binàries.

Finalment, cal dir que quan alguna cardinalitat de la interrelació n-ària originalment plantejada no és N, sinó 1, no es pot utilitzar el mecanisme de traducció referit més amunt sense pèrdua de significat en el model resultant. Per tant, en aquests casos, mai no s’ha d’utilitzar aquesta alternativa.

Pensem, per exemple, en una interrelació ternària que modelitzés les destinacions del professorat als diferents centres d’ensenyament a l’inici de cada curs acadèmic. Seria una interrelació ternària entre PROFESSOR, CURS i CENTRE amb cardinalitat M-N-1. Doncs bé, si apliquéssim la metodologia que hem explicat, el model resultant (amb una nova entitat i tres noves interrelacions binàries) no podria reflectir la circumstància en què un professor, durant un curs concret, només pot ser destinat a un sol centre docent. En canvi, les cardinalitats de la interrelació ternària reflectirien aquest fet sense cap mena d’ambigüitat.

Ubicació dels atributs de les interrelacions

          Les cardinalitats de les interrelacions poden afectar la situació dels seus atributs.

Tenim les possibilitats següents en les interrelacions binàries:

• Interrelacions binàries amb cardinalitat 1-1 i 1-N

• Interrelacions binàries amb cardinalitat M-N i interrelacions n-àries

Interrelacions binàries amb cardinalitat 1-1 i 1-N

Hi poden haver atributs adscrits directament a una interrelació binària amb cardinalitat 1-1, en lloc d’estar associats a alguna de les dues entitats participants.

                    Interrelacions binàries amb cardinalitat 1-1 i 1-N
              
                    Per exemple, podem afegir un atribut a la interrelació 
                    Capital, entre les entitats COMARCA i POBLACIO, i anomenar-lo 
                    AdreçaGestora, perquè emmagatzemi l’adreça corresponent de la 
                    delegació (o gestora) territorial del Departament d’Educació.

L’altra opció consisteix a afegir l’atribut a una de les dues entitats interrelacionades:

• Quan no se sap de qui depèn l’existència de les entitats, resulta indiferent associar els atributs de la interrelació a qualsevol de les dues entitats implicades.

• Però quan una de les dues entitats és opcional en la interrelació, com en aquest cas l’entitat COMARCA, només podem optar entre associar l’atribut a la interrelació o bé a l’entitat opcional. En cap cas no hem d’associar-lo amb l’entitat obligatòria, ja que es generarien atributs amb valors nuls (en aquest exemple, seria el cas, d’altra banda majoritari, de les poblacions que no són capital de comarca).

La figura següent mostra un exemple de cadascuna de les dues possibilitats esmentades.

En el cas de les interrelacions binàries amb cardinalitat 1-N, també hi poden haver atributs directament associats amb la interrelació, en lloc d’estar-ho amb alguna de les dues entitats participants:

Per exemple, podem afegir un atribut, anomenat Localitzacio, a la interrelació Ubicació, existent entre les entitats DOCUMENT i IES, per tal de facilitar la localització física dels documents dins de cada institut (típicament estaran a la biblioteca, però alguns podran estar als departaments didàctics, als laboratoris, a la sala de professors, etc., en raó del seu ús habitual, encara que al mateix temps es puguin prestar).

L’altra opció vàlida consisteix a afegir l’atribut a l’entitat interrelacionada al costat de la N. En cap cas no l’hem d’associar amb l’entitat del costat de l’1, ja que aleshores només es podria indicar un mateix valor per a totes les interrelacions entre entitats:

En aquest exemple, si afegíssim el nou atribut considerat a l’entitat IES, que és al costat 1 de la interrelació, constaria que tots els documents de cada institut estarien a la mateixa ubicació, i això no reflectiria la realitat que es vol modelitzar. En canvi, si afegim el nou atribut a l’entitat DOCUMENT, que és al costat N, podrem indicar sense problemes la localització concreta de cada document dins de l’institut respectiu (vegeu figura següent).

En aquests casos, fer dependre els atributs descriptius de la interrelació o d’una de les entitats (sempre que l’equivalència sigui possible) és una decisió de disseny que pot contribuir a reflectir millor o pitjor les característiques pròpies de la porció del món real que es vol modelitzar, encara el model lògic resultant serà el mateix en tots dos casos.

          En interrelacions binàries amb cardinalitats M-N, i en interrelacions ternàries o n-àries 
          d’ordre superior, independentment de les cardinalitats, la ubicació dels atributs descriptius 
          és molt més clara, i no hi ha equivalències:

             - Sempre que un atribut descrigui una característica d’una entitat, ha de dependre directament
               d’aquesta.
             - En canvi, quan el valor d’un atribut es determina en funció d’una combinació d’instàncies de 
               les entitats que participen en la interrelació, només pot estar associat amb la interrelació.

Examinem, per exemple, la interrelació ternària Prestec de la figura següent. L’atribut Data no és una dada que respongui exclusivament dels usuaris de la xarxa de biblioteques, ni dels documents existents, ni tampoc dels tipus de préstec que es poden realitzar. Cada valor de l’atribut Data només tindrà sentit aplicat a una combinació d’instàncies de les tres entitats que participen en la interrelació (USUARI, DOCUMENT i TIPUS_PRESTEC), la qual constitueix una modalitat de préstec d’un document a un usuari en una data determinada. Per tant, en aquest cas, Data haurà d’acompanyar necessàriament la interrelació Prestec. En canvi, si l’afegíssim a una de les tres entitats abans esmentades, no ens serviria per modelitzar l’aspecte cronològic dels préstecs.

L'entitat DATA

Considerem una interrelació anomenada Prestec (amb un atribut per enregistrar la data) entre les entitats USUARI, DOCUMENT i TIPUS_PRESTEC, amb cardinalitat M-N-P.

Concebuda la interrelació Prestec d’aquesta manera, permet representar la circumstància en què un document concret es presta, d’una manera determinada (segons el tipus de préstec de què es tracti), a un usuari de la xarxa de biblioteques, però només en una única data.

Això vol dir que si un usuari demana un document que ja se li ha prestat, no podrà formalitzar el préstec, encara que el document estigui disponible, perquè el sistema no ho permetrà.

Però la xarxa de biblioteques permet, evidentment, que un usuari pugui tornar a demanar en préstec un document, encara que se li hagi prestat en algun altre moment anterior. Per tant, l’estructura actual constitueix una errada de disseny, perquè la realitat no està ben modelitzada.

Una possible solució consistiria a afegir al diagrama una entitat abstracta, anomenada DATA, que participés de la interrelació Préstec amb cardinalitat N. D’aquesta manera, el sistema permetria registrar préstecs d’un mateix tipus, d’un mateix document, i a un mateix usuari, tantes vegades com fos necessari, això sí, en dates diferents. Podem observar el model resultant en la figura.8, on la interrelació ternària originària passa a convertir-se en quaternària.

          DATA és una entitat abstracta que es fa servir molt sovint en els diagrames ER, 
          afegint-la a una interrelació, per tal de modelitzar la possibilitat que una mateixa 
          combinació d’instàncies de la resta d’entitats associades es pugui tornar a produir 
          en més d’un instant.

Fixem-nos que hem fet servir una entitat molt útil, anomenada DATA, però que té una elaboració molt abstracta. A diferència de les altres entitats, no existeix com a tal en el món real. I també al contrari que la resta d’entitats, no acabarà donant lloc a una representació tabular, per si mateixa, en la futura BD.

Només cal fer servir l’entitat DATA quan la cardinalitat aplicable en connectar-la a la interrelació de què es tracti sigui N. En canvi, si ha de ser 1, es pot continuar utilitzant un atribut associat a la interrelació (i de fet, és millor així, perquè el diagrama resultant serà més compacte).

Si allò que ens interessa modelitzar no són les dates, sinó les hores, podem, simplement, anomenar aquesta entitat abstracta HORA. I, finalment, si el que en realitat volem modelitzar són dates i hores, també li podem dir DATA_HORA.

Paranys del disseny

         Anomenem paranys de disseny les conceptualitzacions errònies del món real, 
         produïdes durant la fase de disseny conceptual, que tenen repercussions 
         negatives tant en la modelització inicial com en la implementació ulterior 
         de la BD.

Aquests paranys poden comportar la impossibilitat de representar les dades tal com són, o bé la impossibilitat de realitzar determinades consultes sobre aquestes.

Encadenament erroni d'interrelacions binàries 1-N

          L’encadenament erroni d’interrelacions es pot produir sempre que ens trobem
          amb dues (o més) interrelacions de cardinalitat 1-N mal encadenades. Considerem 
          una entitat (A) que està associada amb una altra (B), que al mateix temps ho 
          està amb una tercera entitat C. Aleshores, si en l’aplicació errònia de la 
          transitivitat s’associa directament l’entitat A amb la C, es pot produir un 
          error conceptual que provoqui pèrdua d’informació.

Amb el diagrama erroni de la figura següent, per exemple, no es reflecteix a quina població viu cada usuari, ja que a cada comarca pertany una pluralitat de poblacions. En canvi, amb l’esquema originari sí que es pot determinar, en primer lloc, a quina població viu cada usuari i, a continuació, si ens interessa, a quina comarca pertany cadascuna de les poblacions obtingudes.

Aquest parany pot comportar la impossibilitat de resoldre correctament totes les consultes que s’haurien de poder fer sobre les dades. És molt important, doncs, triar correctament les associacions realment necessàries per tal de modelitzar correctament la realitat.

Altres vegades, l’encadenament erroni d’interrelacions no produeix una pèrdua d’informació, estrictament, ja que es poden realitzar totes les consultes necessàries sobre les dades, encara que sigui de manera ineficient. El problema principal rau en el fet que, en esborrar-se instàncies de l’entitat central, poden quedar desconnectades algunes de les instàncies de les entitats exteriors.

En la figura següent, podem veure una modelització errònia que ens permet registrar i consultar, tot i que de manera ineficient, l’associació entre instàncies de POBLACIO i COMARCA.

El problema principal deriva del fet que aquesta associació s’ha de fer mitjançant l’entitat USUARI. Si no hi ha cap usuari que visqui ni en una població ni en una comarca concretes, el sistema no permetrà associar aquestes dues instàncies (és a dir, no es podrà registrar a quina comarca està ubicada la població en qüestió). El mateix impediment es produirà en cas que esborrem tots els usuaris que permeten associar una població amb una comarca concreta: l’associació entre ambdues deixarà d’existir.

Ús incorrecte d'interrelacions binàries M-N

          L’ús de dues interrelacions binàries, encadenades i de cardinalitat M-N serà 
          erroni sempre que en el món real existeixi algun tipus d’associació entre les 
          instàncies de les entitats de tots dos extrems, ja que aquesta no quedarà 
          reflectida en el model. La solució consistirà a substituir les dues interrelacions
          binàries per una de ternària, amb cardinalitat M-N-P.

El model proposat en la figura següent només permetria enregistrar els préstecs de documents als usuaris, i els tipus de préstec que admet cada document. Però no permetria emmagatzemar el tipus de préstec que té lloc en cada cas. La manera de solucionar aquesta mancança consisteix a associar les tres entitats (USUARI, DOCUMENT i TIPUS_PRESTEC) en una interrelació ternària amb cardinalitat M-N-P.

Falses interrelacions ternàries

         Quan alguna interrelació ternària (o n-ària d’ordre superior) té associada alguna
         entitat amb cardinalitat 1, s’ha d’estudiar detingudament, ja que és possible que 
         aquesta entitat estigui directament relacionada només amb una sola de les altres 
         entitats i que, per tant, no hagi de participar en la interrelació examinada, sinó 
         en una de binària amb l’entitat amb la qual manté realment una associació.

En la figura següent, es pot veure com s’utilitza innecessàriament una interrelació ternària per indicar la població i la comarca de residència dels usuaris. De fet, només caldria fer un encadenament (això sí, correcte) de dues interrelacions binàries (una entre USUARI i POBLACIÓ i una altra entre POBLACIÓ i COMARCA) amb les cardinalitats adients, tal com apareix al diagrama superior de la figura del encadenament erroni amb pèrdua d'informació, per tal d’obtenir un model molt més compacte.

D’altra banda, si l’entitat connectada amb un 1 només té un atribut, normalment és preferible tractar-la com un atribut de la interrelació, ja que aquesta opció també contribueix a simplificar l’esquema resultant.