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.