Transformació model entitat-relació al model relacional

Desenvolupament aplicacions multiplataforma (DAM)

Mòdul 2 – Bases de dades

Durada mòdul: 231 hores

UF1 - Introducció a les bases de dades

Tema 3 – Model relacional

Durada UF: 48 Hores

Durada: hores

Total hores:

Coneixements previs• Model enitat-relació (ER).

• Entitat i conjunt d'entitats.

◦ Entitats fortes i dèbils

• Atributs

◦ Domini

◦ Null

◦ Identificador

◦ Multivalor

◦ Compost o jeràrquic

◦ Calculat o derivat

• Relacions

◦ Tipus de relació i cardinalitat màxima i mínima

◦ Participació total / parcial

◦ Ternàries (n-àries)

◦ Reflexives

• Especialització i generalització

◦ Total o parcial

◦ Disjunta o solapada

• Elements model relacional

◦ Taula

◦ Camp

◦ Clau primària

◦ Clau candidata o secundària

• Normalització

◦ Dependència funcional

◦ Formes normals (1FN, 2FN, 3FN, 3FNBC)

Miquel Boada Artigas Pàgina: 1 Ver: 1.0






Durada UF: 48 Hores

Durada: hores

Total hores:

MODEL RELACIONALDel Model ER

al model relacional

Miquel Boada Artigas







Durada UF: 48 Hores

Durada: hores

Total hores:

Model RelacionalConeixements previs.........................................................................................................1MODEL RELACIONAL..........................................................................................................2Introducció.........................................................................................................................5Del model ER al model relacional......................................................................................5

Conjunt d'entitats..........................................................................................................6Atributs identificadors....................................................................................................6Atributs calculats/derivats.............................................................................................6Atributs multivalor.........................................................................................................7Atributs compostos........................................................................................................7Relacions........................................................................................................................8

Relacions 1:N i N:1.....................................................................................................8Relacions N:M.............................................................................................................9

Relació «Accedir»...................................................................................................9Relació «Prohibir».................................................................................................10

Relacions ternàries...................................................................................................10Relacions 1:1............................................................................................................11

Relació «Ubicar»...................................................................................................11Generar 1 taula................................................................................................11Generar 2 taules...............................................................................................12

Relacions 1:1 amb participació total....................................................................12Generació 1 única taula....................................................................................13

Relacions 1:1 amb participació parcial i total.......................................................15Generació 2 taules............................................................................................15Generació 1 taula.............................................................................................16

Relacions 1:1 amb participació parcial.................................................................18Generació 3 taules............................................................................................18Generació 1 única taula....................................................................................20Generació 2 taules............................................................................................20Tria d'una opció................................................................................................21

Relacions reflexives..................................................................................................22Reflexiva 1:N........................................................................................................22Reflexiva N:M........................................................................................................23

Transformació jerarquies..............................................................................................24Jerarquia disjunta.....................................................................................................24

Participació total...................................................................................................24Creació de 2 taules...........................................................................................24Creació de 3 taules...........................................................................................25Quin sistema utilitzar........................................................................................25Participació parcial............................................................................................25







Durada UF: 48 Hores

Durada: hores

Total hores:

Jerarquia solapada...................................................................................................27Webgrafia........................................................................................................................29







Durada UF: 48 Hores

Durada: hores

Total hores:

IntroduccióL'aplicació de les formes normals ens permeten obtenir un disseny de base de dadesòptim a partir d'una taula i la seva descomposició de taules menors. Si bé el mètode espot aplicar de forma sistemàtica, és un sistema molt lent quan una taula conté molts decamps. Tot i això, l'aplicació de la 3 forma normal Boyce-Codd (3FNBC) és unametodologia per a validar que el disseny d'una taula és correcte i en cas que no ho siguiobtenir un nou disseny vàlid.La transformació del model entitat-relació (ER) al model relacional es pot realitzar deforma directe sense aplicar les formes normals seguint una metodologia tenint encompte les relacions entre els diferents tipus de conjunts d'entitats i el tipus de relació.Si bé aquest sistema és més ràpid cal anar en compte ja que el model resultant nosempre és correcte i, per tant, aplicar les 3 formes normals a les taules resultants finalssempre és una mesura interessant.

Del model ER al model relacionalPer a passar del model ER al model relacional cal realitzar una sèrie de transformacionssegons els atributs, els conjunts d'entitats, les relacions i el tipus de relacions. Per aexplicar aquest procés s'utilitzarà el disseny per a controlar els accesos a un localsegons el següent diagrama ER.







Durada UF: 48 Hores

Durada: hores

Total hores:

Conjunt d'entitatsTot conjunt d'entitats genera una nova taula. Cal tenir en compte que de forma ques'avanci en el procés de conversió es podran generar noves taules i també hi hauràunificacions de diferents taules. Per tant, el nombre de taules finals del model relacionalno ha de perquè coincidir amb el nombre de conjunt d'entitats del model ER.En el model ER d'exemple hi ha 3 conjunts d'entitats: Persona, Local i Ciutat.Començarem a crear el nostre model relacional amb aquestes tres taules. Els camps decada una de les taules es correspondran amb els atributs de cada una de les entitats,sempre hi quan no sigui un atribut calculat/derivat o bé no sigui un atribut multivalor.Taules: Persona, Local i Ciutat

Persona: {dni,nom,dataNaix}

Local: {nom, capacitat,x,y}

Ciutat: {cp,nom}

Indicarem els camps de cada una de les taules incloent-los entre claus.

Atributs identificadorsCada taula tindrà com a clau primària els atributs identificadors del conjunt d'entitatsque estan associats. Per a representar la clau primària subratllem el nom del camp.Adicionalment es pot incloure el text (PK1) després del nom del camp.

Persona: {dni (PK),nom,dataNaix}

Local: {nom (PK), capacitat,x,y}

Ciutat: {cp (PK),nom}

Atributs calculats/derivatsTots els atributs calculats s'eliminen del model relacional. En el nostre exemple hi ha unatribut «edat» que és calculat a partir de l'atribut «dataNaix». La taula «Persona» noprecisa d'aquest atribut.

Persona: {dni,nom,dataNaix,edat}


Ciutat: {cp,nom}

1 PK per l'anglès «Primary Key»







Durada UF: 48 Hores

Durada: hores

Total hores:

Atributs multivalorEs generarà una nova taula per a cada atribut multivalor. Aquesta taula contindràl'atribut o atributs identificadors (si n'hi ha més d'un) i l'atribut propi multivalor.


email: {local, email}


Ciutat: {cp,nom}

En el nostre exemple hem considerat que dues persones podien compartir telèfon, perexemple, el telèfon fix. La clau primària estarà composada per dos atributs.

Atributs compostosDels atributs compostos només es consideren en el model relacional aquells atributsque realment contenen la informació: tots els nodes finals de la composició. En el nostreexemple hi ha un atribut compost «coord», que està format per un atribut «x» i unatribut «y» que seran els que formaran part de la taula «local».


Telèfon: {dni, telèfon}


Ciutat: {cp,nom}







Durada UF: 48 Hores

Durada: hores

Total hores:

RelacionsPer a transformar les relacions del model ER al model relacional cal tenir en compte eltipus de relació que és. La transformació depèn realment del tipus de relació que hi haentre els dos conjunts d'entitats.

Relacions 1:N i N:1Quan entre dos conjunts d'entitats s'estableix una relació 1:N o N:1, l'atributidentificador de la taula que té cardinalitat 1 s'afegeix a la taula amb cardinalitat N. En el nostre exemple, entre els conjunts d'entitats «Persona» i «Ciutat», s'ha establertuna relació N:1. El conjunt d'entitats «Ciutat» té una cardinalitat 1 en la relació viu i elconjunt d'entitats «Persona». Per contra, el conjunt d'entitats «Persona» presenta unacardinalitat N.

Persona: {dni,nom,dataNaix,població}

Nota: Població referència a CP del conjunt d'entitats Ciutat.

Telèfon: {dni, telèfon}


Ciutat: {cp,nom}

En la taula «Persona» s'ha creat un nou atribut «població» que està relacionat ambl'atribut «CP» de la taula «Ciutat». Sempre hi quan es compleixi la 1era FN, es potdeixar el mateix nom a l'atribut (es podria haver anomenat «CP» al nou atribut de lataula «Persona») o canviar-lo per un nom més adient.







Durada UF: 48 Hores

Durada: hores

Total hores:

Relacions N:MPer les relacions N:M sempre cal generar una nova taula. Aquesta taula com a mínimcontindrà els atributs identificadors dels conjunts d'entitats relacionades. Si en la relacióhi ha algun atribut adicional , aquest atribut també formarà part de la nova taula.La clau primària de la nova taula generada, com a mínim, contindrà els atributsidentificadors dels conjunts d'entitats relacionats. Si hi ha associat un atribut data a larelació, normalment aquesta també forma part de la clau primària, tot i que calexaminar cada cas de forma individual.En l'exemple hi ha dues relacions de tipus (N:M) : «Prohibir» i «Accedir».

Relació «Accedir» La relació «Accedir» relaciona les taules «Persona» i «Local». A més té un atribut propi,«Data» que representa la data en que la persona va accedir a un determinat local. Lanova taula, que assignarem el nom d'«Accés» tindrà com a atributs: «dni» clau primàriade la taula «persona», i «nom» que és l'atribut identificador del conjunt d'entitats«local». A més tindrà l'atribut «Data» que és un atribut propi de la relació.En aquest cas, canviarem els noms dels camps associats als atributs «dni» i «nom» per«persona» i «local» que es consideren noms més adients, sobretot el de «local»; «nom»és un mot que no aporta significat a la nova taula. Donat que una persona pot accedir aun local vàries vegades i que en un local hi podran accedir moltes persones, cal incloureel camp «data» en la clau principal de la taula.

Accedir

Persona Local Data

77325521 GPlus 15/10/2015

77325521 GPlus 15/09/2016

Persona: {dni, nom, dataNaix, població}

Telèfon: {dni, telèfon }

Local: { nom, capacitat, x, y }

Ciutat: { cp,nom }

Accedir: { persona, local, data }







Durada UF: 48 Hores

Durada: hores

Total hores:

Relació «Prohibir»La relació «Prohibir» té una estructura molt semblant a la d'«accedir» que ja hem vistanteriorment. En aquest cas, hi ha 2 atributs associats a la relació: «data» i «temps»que fan referència a la data en què s'inicia la prohibició i a la seva durada. La nova taula«prohibit» tindrà com a camps els atributs identificadors dels conjunts d'entitats«Persona» i «local» que són les que intervenen en la relació «prohibir», i els atributspropis «data» i «temps».

Prohibir

Persona Local Data Durada(dies)

77325521 GPlus 15/10/2015 30

77325521 GPlus 15/09/2016 30




Ciutat: { cp,nom }


Prohibir: { persona, local, data, durada} La durada està expressada en dies

Relacions ternàriesQuan s'ha de transformar una relació ternària o n-ària, la tècnica és la mateixa quel'aplicada en les relacions binàries: la creació d'una nova taula2. La clau primària de lanova taula estarà formada com a mínim per a tots els atributs dels conjunts d'entitatsrelacionades i podrà contenir algun camp adicional si els atributs identificadorsimplicats són insuficients per a identificar a cada una de les entitats del conjuntd'entitats.

2 Es podria donar alguna excepció si la relació ternària és de tipus 1:1:1







Durada UF: 48 Hores

Durada: hores

Total hores:

Relacions 1:1Quan entre dos conjunts d'entitats hi ha una relació 1:1, no hi ha una única possibilitaten la transformació a taules. En aquest sentit, el resultat pot ser utilitzar una única taulao bé dues taules. En qualsevol dels casos cal tenir en compte que la 3 forma normalBoyce Codd s'ha de complir en totes les taules del nostre disseny de base de dades.

Relació «Ubicar»La relació «Ubicar» ens indica la ciutat de cada un dels locals. Una de les restriccionsdel negoci és que en una ciutat no hi pot haver més d'un local. Tot i ser una relació 1:1entre «local» i «ciutat» , hi ha una segona relació que afecta també a «ciutat» i«Persona». Per a poder representar aquesta 2a relació, la taula «Ciutat» ha d'existir.

Per a veure com funcionen les relacions 1:1, s'ha modificat el disseny eliminant larelació entre «Persona» i «Ciutat». El nou disseny es mostra en la imatge següent:

Generar 1 taulaUna de les possibilitats és unificar els atributs del conjunt d'entitats «Ciutat» amb«Local».

Local: { nom, capacitat, x, y, població, codiPostal}

El problema d'aquest disseny és que hi ha una dependència funcional entre «població» i«codiPostal». Per tant, la taula no està en 3a forma normal i el disseny no és correcte.







Durada UF: 48 Hores

Durada: hores

Total hores:

Generar 2 taulesEn el nostre cas particular, la solució per a resoldre la relació entre «local» i «Ciutat» ésla de tenir una taula per «local» i una altra per «Ciutat». Aquest fet ve determinat per ladependència funcional entre els atributs «nom» i «CP» de l'entitat «Ciutat».




Ciutat: { cp,nom }


Prohibir: { persona, local, data, durada} La durada està expressada en dies

Relacions 1:1 amb participació totalQuan no hi ha una dependència funcional que ens obligui a dividir les taules, cal teniren compte si la participació és total o parcial. Suposem un nou disseny de persones icontractes. De cada persona només es vol saber quin és el seu contracte actual: elscontractes anteriors no són rellevants. A més, una persona només pot tenir un contracteassignat. En aquestes condicions es pot establir una relació 1:1 entre els conjuntsd'entitats «Contracte» i «Persona» tal i com es mostra en la imatge

En les relacions de tipus 1:1 amb participació total pels dos conjunts d'entitatsimplicades, la solució normalment passa per a crear una única taula amb els atributsdels dos conjunts d'entitats. La clau primària d'aquesta taula serà la clau més simpledels atributs identificadors del conjunt d'entitats afectats. En el cas que el nombred'atributs per a identificar una entitat sigui el mateix en els dos conjunts d'entitats,s'escollirà qualsevol dels dos.







Durada UF: 48 Hores

Durada: hores

Total hores:

Generació 1 única taula

La fusió dels conjunts d'entitats «Persona» i «Contracte» ens genera una taula amb elssegüents camps:

Persona: {dni,nom,dataNaix,gènere,codiContr,tipus,data,responsable, condicions }

CodiContr és clau candidata

En el nostre exemple els dos conjunts d'entitats estan formats per un únic atributidentificador: «DNI» per a identificar la persona i «codi» per a identificar el contracte.S'ha decidit escollir com a clau primària l'atribut «DNI» ja que a la fusió de la taula s'hadonat el nom de «persona». Amb aquest nom sembla més lògic utilitzar el dni, que no elcodi del contracte. Tot i això, l'utilització de l'atribut «codiContr» seria també correcte.Les claus candidates de la taula persona són : dni i CodiContr.


Desenvolupament aplicacions multiplataforma (DAM) Mòdul 2 – Bases de dades



Persona

Dni Nom DataNaix Gènere codiContr Tipus DataNaix Responsable Condicions

77455321 Anna 27/01/1980 Dona 9887646 Indefinit 01/03/2008 Recursos humans Segons conveni

69087372 Maria 27/01/1978 Dona 9858321 Indefinit 27/01/2008 Recursos humans Segons conveni

Es mantenen tots els valors, no hi ha valors NULL, i no hi ha redundància de dades.






Durada UF: 48 Hores

Durada: hores

Total hores:

Relacions 1:1 amb participació parcial i totalQuan en una relació hi ha una participació parcial d'un dels dos conjunts d'entitats, lasolució passa per a tenir dues taules: una taula per a cada conjunt d'entitats. Aquestaestratègia, com es demostrarà a continuació, minimitza el número d'atributs amb valorNULL.

El model ER ens mostra que en la nostra taula persones hi haurà persones que podenno tenir cap contracte associat.

Generació 2 taules

Quan es generen dues taules, cal tenir una relació entre ambdues, que es realitzamitjançant la clau primària o l'atribut identificador dels conjunts d'entitats. En el modelER es dedueix que tot contracte estarà associat a una persona: no hi poden haver-hicontractes anònims. Sí que hi poden haver-hi persones sense contractes. Com que laparticipació del conjunt d'entitats «Contracte» és total en la relació, l'atributidentificador del conjunt d'entitats «Contracte» es duplicarà com un camp en la taula«Persona» resultat del conjunt d'entitats «Persona»En el recuadre es mostren les taules i els seus camps resultants del conjunt d'entitats.

Persona: { dni, nom, dataNaix, gènere, contracte }

Contracte:{ codi, tipus, data, responsable, condicions }

Cal tenir en compte que l'única clau candidata i per tant, primària, de la taula«Persona» és DNI. A diferència de quan la participació és total que podem escollirqualsevol dels atributs identificadors del conjunt d'entitats relacionats com a clauprimària, en aquest cas, com que una persona no obligatòriament precisa d'uncontracte, només podem escollir com a clau primària el «DNI»: una clau primària maipot tenir associat el valor NULL; que és el valor que pendrà el camp «contracte» si lapersona no té cap contracte associat.







Durada UF: 48 Hores

Durada: hores

Total hores:

Persona

Dni Nom DataNaix Gènere Contracte

77455321 Anna 27/01/1980 Dona 9887646

69087372 Maria 27/01/1978 Dona 9858321

50967432 Pere 12/04/1950 Home NULL

Contracte

Codi Tipus DataNaix Responsable Condicions

9887646 Indefinit 01/03/2008 Recursos humans Segons conveni

9858321 Indefinit 27/01/2008 Recursos humans Segons conveni

Observem que la creació de dues taules ens genera un únic valor NULL en la taula«Persona». Aquest NULL ve determinat perquè la relació és parcial i no tota personaprecisa tenir un contracte.

Generació 1 taula

La relació entre «Persona» i «Contracte» també pot representar-se amb una única taula,que ha de ser la taula «Persona» a la qual afegim els atributs del conjunt d'entitats«Contracte». En aquest cas, i com es demostra en la següent taula generada a partirdels valors de les taules «Persona» i «Contracte» la unió d'aquestes dues taules generaun nombre important de valors NULL.


Desenvolupament aplicacions multiplataforma (DAM) Mòdul 2 – Bases de dades



Persona

Dni Nom DataNaix Gènere codiContr Tipus DataNaix Responsable Condicions

77455321 Anna 27/01/1980 Dona 9887646 Indefinit 01/03/2008 Recursos humans Segons conveni

69087372 Maria 27/01/1978 Dona 9858321 Indefinit 27/01/2008 Recursos humans Segons conveni

50967432 Pere 12/04/1950 Home NULL NULL NULL NULL NULL

Com que la persona amb DNI 50967432 no té cap contracte associat, tots els camps del contracte per la persona, s'hand'inicialitzar a valor NULL.






Durada UF: 48 Hores

Durada: hores

Total hores:

Relacions 1:1 amb participació parcialQuan la participació dels dos conjunts d'entitats és parcial i el tipus de relació és 1:1 nohi ha una única opció. El fet d'utilitzar una o altra estratègia dependrà de cada una deles situacions. A mode d'exemple utilitzem el següent disseny ER amb els atributsidentificadors i les relacions.

Generació 3 taules

La primera opció passa per a generar 3 taules. La clau primària, si els dos conjuntsd'entitats tenen el mateix nombre d'atributs identificadors, és l'atribut identificador dequalsevol d'ells. En el cas que el nombre d'atributs identificadors dels conjuntsd'entitats sigui diferent s'utilitzarà com a clau primària de la nova taula l'atributidentificador més simple.

En el nostre cas, el conjunt d'entitats «Premi» té un atribut identificador doble:«Categoria» i «Data». Per altra banda, l'atribut identificador del conjunt d'entitats«Autor» està format només per un atribut: «Pseudònim» . Donat que l'atributidentificador del conjunt d'entitats «Autor» té menys elements que el de «Premis»,utilitzarem l'atribut «Pseudònim» com a identificador o clau primària de la nova taula.

La creació d'una nova taula sempre minimitza el nombre de valors NULL: realment no hiha valors NULL resultants de la relació. El problema que té aquesta solució és que calmantenir una taula adicional i augmenta la complexitat de les consultes.

Una possible solució al model ER proposat seria:

Autor: {Pseudònim, Nom}Premis: {Categoria, Any, Import, Obra }Guanyador: { Categoria, Any, Pseudònim }

Per a comparar amb la resta de solucions possibles, s'han suposat una sèrie de valorsassociats a cada una de les taules: «Autors», «Premis» i «Guanyador».







Durada UF: 48 Hores

Durada: hores

Total hores:

Autor

Pseudònim Nom

Alsapi Albert Sánchez Piñol

Edmen Eduardo Mendoza

Issi Isabel Clara Simó

Premi

Categoria Any Import Obra

Ciència ficció 2013 15000 La pell freda

Humor 2013 13000 Sin notícias de Gurb

Drama 2013 16000 NULL

Guanyador

Categoria Any Guanyador

Ciència ficció 2013 Alsapi

Humor 2013 Edmen







Durada UF: 48 Hores

Durada: hores

Total hores:

Generació 1 única taula

Com es demostrarà a continuació , agrupar els dos conjunts d'entitats i la relació en unaúnica taula no és una solució viable. A continuació es justifica i es demostra l'afirmacióutilitzant les daes proposades anteriorment.

El disseny relacional utilitzant una única taula és el que es mostra a continuació:

Guanyador: { Categoria, Any, Pseudònim, Autor, Import, Nom, Data }

Guanyador

Categoria Any Pseudònim Import Autor Obra

Ciència ficció 2013 Alsapi 15000 Albert Sánchez Piñol La pell freda

Humor 2013 Edmen 13000 Eduardo Mendoza Sin notícias de Gurb

Drama 2013 NULL 16000 NULL NULL

NULL NULL issi NULL Isabel Clara Simó NULL

Si s'agrupen tots els atributs en una única taula «Guanyador», quan es fa larepresentació de la informació s'obtenen valors NULL per a tots els camps de la taula enalguna de les seves files. Donat que una clau primària no pot estar formada per capcamp que pugui prendre el valor NULL, el disseny de la taula «Guanyador» no éspossible.

Generació 2 taules

Si s'utilitzen dues taules es pot afegir el camp «Pseudònim» a la taula «Premi» o bé elscamps «Categoria» i «Any» a la taula «Autor».

Autor: {Pseudònim, Nom}Premis: {Categoria, Any, Import, Obra, Pseudònim }o béAutor: {Pseudònim, Nom, Categoria, Any}Premis: {Categoria, Any, Import, Obra }

Si bé qualsevol de les dues opcions em permet representar la informació , tot i queafegir els camps «Categoria» i «Any» a la taula d'«Autor» obliga a tenir 2 camps ambvalor NULL per a tots els autors que no han guanyat cap premi. La inclusió de«Pseudònim» a la taula «Premi» només inclou valor NULL per aquells premis que quedindeserts.







Durada UF: 48 Hores

Durada: hores

Total hores:

Tria d'una opcióCom s'ha vist anteriorment hi ha 2 possibilitats de resoldre el problema 1:1.

Utilitzant 2 taulesAutor: {Pseudònim, Nom}Premis: {Categoria, Any, Import, Obra, Pseudònim }Utilitzant 3 taulesAutor: {Pseudònim, Nom}Premis: {Categoria, Any, Import, Obra }Guanyador: { Categoria, Any, Pseudònim }

La selecció d'una o altra possibilitat dependrà de la resposta a la pregunta: hi ha moltspremis que quedin deserts?En el cas que la resposta sigui afirmativa la millor opció és generar 3 taules, ja que enspermet localitzar la informació de forma més ràpida en la tercera taula que a més tindràpocs valors. En el cas que la resposta sigui que no, és millor utilitzar dues taules, ja que els campsamb atributs NULL seran mínims: l'opció de la tercera taula contindria moltes files itampoc ajudaria en l'eficiència de les consultes.A nivell general, resoldre el problema utilitzant dues o tres taules, està associat alnombre de valors NULL que es generin amb dues taules: si hi hauran pocs valors NULLs'optarà per a 2 taules, en cas contrari per a 3 taules.







Durada UF: 48 Hores

Durada: hores

Total hores:

Relacions reflexivesPer a passar les relacions reflexives del model entitat relació al model relacional essegueixen les mateixes normes que les relacions no reflexives. L'única diferència és quees tracta del mateix conjunt d'entitats i, per tant, si el tipus de relació és 1 a N caldràafegir l'atribut a la mateixa taula: per tal que estigui en 1a FN serà precís canviar-li elnom.

Reflexiva 1:NPer a transformar del model entitat relació al model relacional una relació reflexiva detipus 1:N, en la taula associada al conjunt d'entitats es genera un nou camp per l'atributidentificador.Utilitzem com a exemple el model entitat relació de la imatge.

Seguint les normes de transformació cal generar una taula per a cada conjuntd'entitats. En aquest cas només hi ha un únic conjunt d'entitats «Persona» i, per tant,una única taula que també anomenarem «Persona». El següent pas és comprovar si cal afegir alguna taula més derivada de les relacions.L'única relació del model és «Responsable». Com que el tipus de relació és 1:N serànecessari afegir un camp adicional a la taula persona resultant de la transformació de larelació.

Persona: {DNI, Nom, Responsable}







Durada UF: 48 Hores

Durada: hores

Total hores:

Reflexiva N:MPer a transformar del model entitat relació al model relacional una relació reflexiva detipus N:M, cal generar una nova taula per a representar la relació..Utilitzem com a exemple el model entitat relació de la imatge.

Seguint les normes de transformació cal generar una taula per a cada conjuntd'entitats. En aquest cas només hi ha un únic conjunt d'entitats «Persona» i, per tant,una única taula que també anomenarem «Persona». El següent pas és comprovar si cal afegir alguna taula més derivada de les relacions.L'única relació del model és «Amic». Com que el tipus de relació és N:M serà necessariafegir una nova taula per a representar la relació.

Persona: {DNI, Nom}Amic: {DNI1, DNI2}







Durada UF: 48 Hores

Durada: hores

Total hores:

Transformació jerarquiesEl procés de transformació de les jerarquies del model entitat relació extès (EER) almodel relacional no té una regla fixe que determini com s'ha de fer. Així, tota jerarquiaes pot transformar utilitzant una taula per a cada subclasse associada a un conjuntd'entitats o bé una taula per a cada subclasse i una taula adicional per la superclasse.

Jerarquia disjuntaQuan la jerarquia és disjunta cal tenir present si la participació de la superclasse ésparcial o total.

Participació total

Com a exemple utilitzarem el model relacional de la imatge. En la jerarquia es potobservar que hi ha el conjunt d'entitats «Treballador» que és la superclasse i elsconjunts d'entitats «Temporal» i «Indefinit» que són les subclasses.

Creació de 2 taulesLa primera opció passa per crear 2 taules, una pel conjunt d'entitats «Temporal» i unasegona pel conjunt d'entitats «Indefinit» que són les subclasses. En cada una de lestaules generades hi hauran de constar tots els atributs propis de la subclasse i els de lasuperclasse.







Durada UF: 48 Hores

Durada: hores

Total hores:

Temporal: {NSS, DNI, Nom, DataFi, DataInici} Indefinit: {NSS, DNI, Nom, PreuHoraExtra} Nòmina: {NSS, Data, Import}

Creació de 3 taulesLa creació de 3 taules suposa establir una relació 1 a N entre la superclasse i lessubclasses. D'aquesta forma, la taula generada a partir del conjunt d'entitats que éssuperclasse («Treballador») té tots els atributs comuns , mentre que cada taulaassociada a la subclasse disposaran dels seus propis atributs i l'atribut identificador dela superclasse. La solució en 3 taules seria la següent:

Treballador {NSS, DNI, Nom}Temporal: {NSS, DataFi, DataInici} Indefinit: {NSS, PreuHoraExtra} Nòmina: {NSS, Data, Import}

Quin sistema utilitzarUn dels problemes que té l'utilització de 3 taules és que si es vol tenir tota la informaciódel conjunt d'entitats cal ajuntar la informació provinent de vàries taules, dificultantd'aquesta forma la consulta. Així, per exemple, si es volen saber totes les dades delstreballadors indefinits, cal fer la cerca a la taula «Indefinit» per a obtenir el preu del'hora extra i a la taula «Treballador» per a obtenir la resta de dades. Donat que en l'exemple la relació és disjunta i total, la millor opció és la d'utilitzar 2taules: no hi haurà informació duplicada entre les taules i la informació està mésagrupada, facilitant la consulta.

Participació parcialQuan la jerarquia és parcial i disjunta la solució consisteix en generar una taula pelconjunt d'entitats referenciada com a superclasse i una taula per a cada conjuntd'entitats que sigui subclasse. El fet que una entitat pugui no pertànyer a cap de lessubclasses, obliga a tenir un contenidor adicional (taula) on emmagatzemar aquestaentitat







Durada UF: 48 Hores

Durada: hores

Total hores:

Els treballadors externs, que no formen part de planta ni d'oficines, s'introduirien en lataula «Treballador». La solució del model EER seria:

Treballador: {NSS, DNI, Nom}Planta: {NSS, Torn} Oficines: {NSS} Tasques: {Nom}Realitza: {NSS, Tasca, Data}







Durada UF: 48 Hores

Durada: hores

Total hores:

Jerarquia solapadaQuan la jerarquia és solapada vol dir que un conjunt d'entitats pot pertànyer a diversessubclasses. Les jerarquies solapades cal que siguin resoltes creant una taula pel conjuntd'entitats que és superclasse i una taula adicional per a cada conjunt d'entitatsassociada a la superclasse. D'aquesta forma s'evita la redundància de dades.Per a fer l'anàlisi utilitzem el següent model EER.

Si es generen tres taules per a la jerarquia s'obté:

Software: {Nom, Fabricant}Windows: {Software} -- Nom del softwareLinux: {Software} -- Nom del softwareDistribució: {Nom, Versió}DisponibleLinux {Software, NomDistribució, Versió }DisponibleWin {Software, NomVersió }

La generació de només dues taules per la jerarquia suposa haver de repetir l'atribut«Nom» i «Fabricant» a cada una d'elles.







Durada UF: 48 Hores

Durada: hores

Total hores:

Amb 2 taules (solució no vàlida)Windows: {Software, Fabricant}Linux: {Software, Fabricant}Distribució: {Nom, Versió}DisponibleLinux {Software, NomDistribució, Versió }DisponibleWin {Software, NomVersió }

El fet que es dupliqui Fabricant en la taula Windows i Linux provoca que si hi ha un canvide fabricant per a un determinat software compatible amb els dos sistemes, aquestcanvi s'hagi de realitzar tant a la taula «Windows» com «Linux».







Durada UF: 48 Hores

Durada: hores

Total hores:

Webgrafiahttp://db.grussell.org/section006.html#_Toc67114425https://www.tutorialcup.com/dbms/er-model-into-tables.htmhttp://www.cs.toronto.edu/~faye/343/w08/lectures/wk6/6ERModelPart2-2up.pdf


http://www.cs.toronto.edu/~faye/343/w08/lectures/wk6/6ERModelPart2-2up.pdf

https://www.tutorialcup.com/dbms/er-model-into-tables.htm

http://db.grussell.org/section006.html#_Toc67114425

Transformació model entitat-relació al model relacional

Technology

Transcript of Transformació model entitat-relació al model relacional