Professional Documents
Culture Documents
BasedeDatos
Autor:AlfonsoPalomares
Corregidoyrevisadopor:MartnBattaglia
Pag.159
Contenidos
Modeladodeuna
BasedeDatos
2.ElModelado
2.1.Porqudeborealizarunmodelo
2.2.Cmomodelar
2.2.1Ejemplo
2.3.DiagramaEntidadRelacin(DER)
Entidades
Ejemplo
Atributos
AtributosClaveoIdentificadores
AtributosCalculados
AtributosMultivaluados
AtributosCompuestos
Relaciones
CardinalidaddelasRelaciones
Opcionalidad
GradodeunaRelacin
RelacinUnaria
RelacinBinaria
RelacinTernaria
Atributosenlasrelaciones
Entidadesdbiles
JerarquasoHerencias
2.3.1.Ejemplossimples
2.3.2.Ejemplocomplejo
2.4.ModeloRelacional(MR)
ElementosdelModeloRelacional
Relaciones
Atributos
AtributosClaves
AtributosForneos
AtributosClaveyforneos
Reglasdetranformacin.DesdeelDERalMR
DeEntidadessimplesaRelaciones.
DeEntidadesyRelacionesaRelaciones.
2.4.1.Ejemplossimples
2.4.2.Ejemplocomplejo
Pag.259
2.ElModelado
Desde sus comienzos, el ser humano ha intentado hacer representaciones grficas de su
universo conocido, para as poder transmitir su modo de verlascosasaotros.Conformeel
ser evoluciona, tambin lo hacen sus esquemas grficos, llegando a especificar y tipificar
cada representacin. Es por esto, que la mejor manera de pensar, disear y mostrar una
basededatosseamedianteundibujo.
Como en todos los mbitos formales sucede, se cre por decisin del medio y luego de
diversas pulseadas entre diferentes corrientes, un modelo especfico para el planteo de
basesdedatos.Porlocual,setomaronalgunasprecauciones.
Primero, se debe minimizarlacantidaddeplantillasusadas,esdecir,sedebecontarconun
reducido conjunto de elementos. Segundo, se debe dar un significado nico a cada
elemento,permitiendoasunanicainterpretacin.
2.1.Porqudeborealizarunmodelo
Debemos construir un puente que nos acerque entre quien tiene una idea y aquel que la
realizar. Si debemos conectar el pensamiento entre ms de una persona, es vital que
generemos un diseo que sea lo ms universal posible, que sea fcil de comprender,
incluso hasta por aquellos que surgen de otros mbitos acadmicos. Es por ello que
debemos utilizar un modelo estndar,probadoyrevisadoduranteaos.Sien lugardehacer
unmodeladosimplementenoscentramosenrealizarunescrito,daramoslugara erroresde
interpretacinoproblemasdellenguaje,entreotrascosas.
2.2.Cmomodelar
Para el caso de bases de datos, el modelo grficoconceptualmsutilizadoeselDiagrama
EntidadRelacin,tambinconocidocomoDER.
Dentro de esta forma de modelar, se encuentran solamente dos tipos de elementos
diferentes, permitiendo transmitir un mensaje claro y preciso. Dichos elementos, son slo
deltipoEntidadyRelacin.
Las entidades indican las colecciones de objetos de los que necesitamos almacenar o
recopilar datos. Dado que son colecciones, se las denomina formalmente Conjunto de
Entidades,peroporsimplicidadseoptaporllamarlassimplementeEntidades.
Se las nombra siempre en singular y pueden representar objetos materiales (vehculos,
lugares, etc.), objetos abstractos (llamadas telefnicas, movimiento bancario, etc.), objetos
vivos (empleados, alumnos, etc.) u objetosinanimados(accidentesgeogrficos,puestos de
trabajo, etc.), pero siempre sern tomadas y tratadas como colecciones de objetos. Si
percibimos que debemos tenerencuentalosboletosdetransporteutilizadosenelmes,nos
Pag.359
surgeunaentidadllamadaBoleto,dondeseguardelacoleccindelosboletos.
Tomando esto ltimo, vemos que de alguna manera, tenemos que definir caractersticas o
atributos que describan a cada elemento de la coleccin. De aqu en ms utilizaremos el
trmino Atributo. Por ejemplo, para la entidad planteada Boleto, deberamos tener en
cuenta los atributos correspondientes al precio, el origen y destino del viaje, etc. Otro
ejemplo, para la entidad Llamada, losatributospuedenser,day horadela llamada,nmero
dedestino,nmeroorigen,duracindelallamada,costo,etc.
Por otra parte, las relaciones estarn signadas por la accin, vnculo, asociacin o
interaccinentreentidades.
Por ejemplo, si tenemoslasentidadesPersonayMascota,unarelacinentreellas podra
ser es dueo de, donde indicamos que una o ms personas son dueas de una o ms
mascotas. Otro ejemploquepodemosincorporares,teniendoPersonayBoleto,posibles
relaciones entre estas entidades seran, utiliz para sealar que una persona utiliz un
boleto, o es vendido por, para indicar que uno o ms boletos son vendidos por personas.
Por ltimo, podemos tener Persona y Auto, donde las relaciones podran ser, es dueo
de, o conduce, o le gusta o es vendido por., etc. Como vemos, normalmente las
relacionesestndefinidasconunverboounafraseverbal.
Qu determinar las entidades a considerar ysusrelacionesdependerexclusivamentedel
universoodominioqueestemosmodelandoydelcontextoenqueestoseautilizado.
2.2.1Ejemplo
Nos interesa para este ejemplo pensar en un esquema que nos permita administrar
nuestros DVD de msica y video. De los DVDs queremos contar con la informacin de: el
nombre,lafechadeedicinyla compaaquehizolaedicin.Adems,queremossaberqu
artistasintervienenenlasdiferentesproducciones.
Teniendo esto, podemos empezar a analizar qu elementossernposiblesentidades.Para
detectar colecciones, debemos ver en el prrafo anterior, qu elementossonalmacenables
y posiblemente necesitemos persistir ms de uno. Normalmente vienen denotados por un
sustantivo. Lo primero que salta a la vista, son los DVD. Luego podra ser la compaaque
hace la edicin y por ltimo, los artistas. Estas tres colecciones podramos definirlas como
entidades.
Una vez que hemos detectado las entidades, debemos proceder a reconocer los atributos
que las describan. Es importante recordar describir slo lo necesario para el dominio y
contexto de nuestro problema. Para los DVD, los atributos a considerar, podran ser: el
nombre, la fecha de edicin e incluso podemosdefinirunatributoquenosdistinga siel DVD
es una pelcula o no. Para las compaas editoras, la definicin no especifica nada, por lo
que podemos presuponer contar con al menos un nombre. Lo mismo para el caso de los
artistas.
Finalmente, queda por determinar el conjunto de relaciones, las cuales no suelen ser tan
Pag.459
explcitas en los textos como lo son las entidades, aunque muchas veces pueden
reconocerse con un verbo. Debemos recordar que las relaciones slo ocurren entre
entidades,locualnosindicaquinesparticipanalahoradepensarlarelacin.
Nota:algunoslibrosplanteanrelacionesentreotrasrelacionesperoquedaporfueradelalcancedeestetexto
Sireleemoselprrafodelproblema,vemosque lacompaaeditorialeditalosDVD,siendo
esta la relacin buscada. Luego, entre los artistas y los DVD, se descubre la relacin
participaoformapartede,determinandolaaccinentreelartistaylaobra.
2.3.DiagramaEntidadRelacin(DER)
Como anteriormente mencionamos, utilizaremos para la representacin grfica de un
modeloconceptualdebasededatos,unDiagramaEntidadRelacin(oDER)
Entidades
En este modelo las colecciones de objetos o entidades sern representadas por un
rectngulo, donde el nombre de dicha coleccin estar encerrado dentro del mismo. Este
nombreestardefinidoensingularynopodrrepetirseentodoeldiagrama.
Ejemplo
Figura1.Sepuedenvertresentidades:Trabajador,TransporteyZapato.
distribuirlosproductosyaelaboradosalastiendas.
Atributos
Como ya hemos dicho, cada entidad o coleccin de objetos tendr atributos que las
describanyadems,quedistingaacadaunodelosobjetosincluidosendichascolecciones.
Estos atributos sern dibujados con valos, conectados con una lnea a la entidad a la que
estn describiendo. Cabedestacar,queunaentidadnopuedetenerdosomsatributoscon
el mismo nombre, ya que estaramos almacenando dos veces el mismo dato.Porejemplo,
en la entidad Persona, si tenemos el atributo Nombre y lo definimos dos veces, para cada
objetodedichaentidad,tendramoseldatorepetido:
Para el objeto 1, la persona tiene como nombre Jos y para el objeto 2, el nombre Ana. Si
repetimos el atributo, tambin duplicaramos su contenido, almacenando en este caso
JosJosparaelobjeto1yAnaAna,paraelobjeto2.
Puede el lector pensar, cmo hacer en el caso de que una persona tenga dos nmeros de
telfonoadondepodercontactarla.Estoscasoslosresolveremosmsadelante.
Algo quespuedesuceder,esquedosentidadesdiferentestengan, encadaunadeellas,un
atributo con el mismo nombre. Por ejemplo, las entidades Persona y Color, ambas pueden
tenerelatributoNombre,perocadaatributoserunacaractersticapropiadecadaentidad.
Otroejemploparaverestopodrser:
Figura2.Vemosenelejemplo,dosentidades,AutoyMoto,cadaunaconsuatributocolor.
Pag.659
AtributosClaveoIdentificadores
Algunos de los atributos tienen la particularidad de ser aquellos que determinan
unvocamente a la entidad dentro del conjunto de entidades. Por ejemplo, si tenemos la
entidad Auto, con los atributos ao de fabricacin, color, puertas, marca y modelo,
debemospensarcmodistinguirlossiguientesobjetosdelacoleccinAuto.
Ao
2009
2010
2010
2009
Color
Negro
Negro
Azul
Negro
Puertas
5
5
5
5
Marca
Ford
Ford
Ford
Ford
Modelo
Focus
Focus
Focus
Focus
Vemos que si tomamos el atributo ao como atributo identificador del Auto, no logramos
tener un solo valor diferente para cada auto, ya que en el ejemplo, 2009 y 2010 se
encuentranendosobjetos(oautos)respectivamente.
Si tomamos ao y color, tampoco conseguimos distinguir a un objeto de otro, ya que por
ejemplo 2009 + Negro, se encuentra en ms de unobjetoauto.Recordemosqueelobjetivo
esdistinguirunvocamenteacadaobjetodeotro.
Probemos ahora, utilizar el caso extremo, es decir, utilizar todos los atributos. Si tomamos
2010 + Negro + 5 +Ford+Focusdescubrimosquetampocopodemosdeterminarunicidad,
yaque2009+Negro+5+Ford+Focusserepiteparadosobjetos.
Para solucionar esto, si bien tenemos determinados a aquellos atributos que describenala
entidad Auto,antenemoslanecesidadde identificarlosunvocamente.Paraelcasodeesta
entidad, pensemos qu hay en la definicin de un auto que lo identifique de forma nica.
Generalmente, estos atributos son los fundacionales del objeto a evaluar. Para el caso de
las personas, lo que la define nicamente podra ser el Documento de Identidad. Para los
autos, esta simple caracterstica nica podra ser la matricula, ya que es el atributo con el
cualsediferencianlosautomviles,quedando:
Matricula
Ao
Color
Puertas
Marca
Modelo
AAI001
2009
Negro
Ford
Focus
AAI002
2010
Negro
Ford
Focus
BBF003
2010
Azul
Ford
Focus
CCF004
2009
Negro
Ford
Focus
Figura 3. Tenemos las entidades Auto, con su atributo comn color, y su atributo clave
matrcula. Por otra parte, la entidad Monitor, con su atributo clave Nro. de serie y sus
atributosdescriptivostamaoycolor.
Tipo
Pasaporte
DNI
DNI
Nro
29111222
29111222
29111223
Nombre
JuanRodriguez
JuanaDolores
JuanRodriguez
Es importante entender que los atributos forman una nica clave en su conjunto y no
pueden considerarse en forma aislada como tales. Como vemos en este ejemplo, si
tomramossolamenteelnmerodeldocumento,obtendramosmsdeunapersonalparael
mismo valor. Lo mismosucedeconelatributotipodedocumento.Surgeque,sitomamosel
tipoyelnmerodedocumento(elpar),podemosdistinguirunvocamenteacadapersona.
Grficamente, si tenemosms deunatributoclave,debemossubrayaratodoslosatributos,
talcomohacemoscuandoexistesolouno.
Pag.859
Recordemos que solo tomamos 2 o ms atributos cuando uno solo no es suficiente para
determinarlaunicidaddelaentidad.
Ejemplos
Figura 6. Podemos ver en este grupo tres entidades con sus respectivos atributos,
destacandolosquesonclaveconunsubrayado.
AtributosCalculados
Pag.959
Los atributos calculados son aquellos que demandan un clculo a partir de otros atributos
para determinar su valor. Es decir, dependen del valor de uno a ms atributos y de la
frmulaquesedefinaparaelclculo.
Por ejemplo,elatributocalculadoEdadenlaentidadAlumno,dependedelatributofechade
nacimiento y cuyo clculo queda determinado por la diferencia entre la fecha actualylade
nacimiento (en aos). Otro ejemplo puede ser el atributo calculado clase, en la entidad
Matafuego, dependiendo del tipo de matafuego (A: incendios que implican slidos, B:
incendiosqueimplicanlquidosinflamables,etc).
Estosatributoscalculadossedibujanusandolneaspunteadasenelovalo.
AtributosMultivaluados
Un caso particular de los atributos, es que cuenten con ms de un valor paraunainstancia
de la entidad a la cual pertenecen. A modo de ejemplo, la entidad Persona, posee en el
atributo telfono, la posibilidad de tener uno o ms valores. Uno podra optar por definir un
nmero finito de atributos similares (telfono1, telfono2, etc.) o bien definir un atributo
multivaluado.
Pag.1059
Estos atributos se dibujan con dos valos concntricos. El nombre del atributo debe seren
singular, por ms que pueda almacenar ms de un valor. Este tipo de caracterstica nos
permite almacenar una indefinida cantidad de valores diferentes en dichoatributoparacada
uno de los elementos de la entidad. Por ejemplo, podemos tener para la persona Juan, los
telfonos 44444444 y 22225555, y para la persona Ana, los nmeros 55552222,
11112222,66664444.
Como vemos, en un atributo multivaluado, cada objeto de la entidad, puede tener una
cantidaddiferentedevalores.
Figura8.Aquvemostrespersonasconunacantidaddiferentesdenmerosdetelfonos.
Ejemplosdeatributosmultivaluados.
AtributosCompuestos
Por ltimo, tenemos los atributos compuestos. Estos atributos se utilizan para agrupar
atributos nicamente, colaborando a la visualizacin de la entidad y a su mejor
Pag.1159
Figura10.Enestaimagenvemosdosentidades.PrimeroAlumno, conelatributocompuesto
direccin. Este atributo est formado por calle, altura, piso y departamento. Luego,
tenemos la entidad Libro, con el atributo compuestoformato. Esteatributoestcompuesto
porlosatributoscolor,columnas,tamaodeletraytipografa.
Relaciones
Las relaciones son quienes definen las acciones entreunaentidadyotra.Sedibujanconun
rombo, con al menos dos conectores en las puntas horizontales, que servirn paraasociar
lasentidadesqueintervienenendicharelacin.
Figura 11. Vemos aqu, la forma de graficar una relacin, con sus dos conectores a los
ladoscontrazofirme.
Pag.1259
Figura 13. Tomando algunas de las relaciones delafigura 12,seejemplifica cmose debe
leerlarelacinqueintervieneentrelasentidades.
Pag.1359
Figura 14. Vemos en este ejemplo, dos entidades, Lector y Libro. Entre ellos, hay tres
relaciones que tienen significados diferentes. Las relaciones son Recomienda, Lee y
Comenta.
Esto sucede ya que, entre dos instancias de objetos de las dos entidades, pueden darse
ciertascombinacionesyciertasno,segnloquelarelacinrepresente.
Enelejemploanterior,podemospensarque:
Pag.1459
Cardinalidad
Una vez comprendido que para evaluar las relaciones tenemos que considerar las
instancias de las entidades, debemos determinar cuntas instancias de cada entidad
pueden participar de la relacin. Es lo mismo decir,sitenemosunaaccin,cuntossonlos
quepuedenprovocarlaycuantosrecibendichoefecto.
Siempre la cardinalidad se define para cada unodelasentidadesalasqueestasociadala
relacin. Entonces, si tenemos dos entidades que estn asociadas por una relacin,
tenemosqueevaluarlacardinalidaddelarelacinconrespectoaambasentidades.
Si tenemos las entidades LectoryLibro,podramos tenerlarelacinLee,paradecirqueun
lector ley algn libro. Ahora, si evaluamos la cardinalidaddelarelacin, debemostomarun
lectorhipottico(noJuan niAna)ypensarcuntoslibrospuedehaber ledo,paracomenzar
de esta forma a definir la cardinalidad de la relacin. Encontramos rpidamente que el
resultado a dicha pregunta es uno o ms libros. Entonces, dado que UN LECTOR puede
leer UNO O MS LIBROS, decimos que la cardinalidad en la relacin Lee es del tipo
Muchos,conrespectodelaentidadLibro.
Evaluemos la relacin ahora, pensando en la entidad Lector. Debemos pensar lo mismo
pero observando la accin o relacin desde el punto de vista ahora del Libro. Repitamos el
proceso entonces, yendo desde Libro a Lector, es decir, considerando la misma relacin
Lee ahora como la accin fue ledo por. Tomemos entonces un libro hipottico, y
tratemos de pensar por cuantos lectores pudo haber sido leido. Rpidamente nos damos
cuenta que un libro pudo haber sido ledo por ms de un lector, como sucede con los best
seller, por ejemplo. Encontramos queesunacardinalidadsimilaralcasoanterior.Entonces,
dado que UN LIBRO puede ser leido por UNO O MS LECTORES, decimos que la
cardinalidadenlarelacinLeeesdeltipoMuchos,conrespectodelaentidadLector.
Esta cardinalidad, definida como Muchos, se representa grficamente como una N, enel
extremocorrespondientedelarelacin(enestecasoambos).
Figura 17. Vemos un ejemplo con objetos de la entidad Lector y la entidad Libro, tomando
solo la relacin Lee.Podemosver,queJuan,leydoslibros,por lotanto lacardinalidad de
lee en Libro va a sermuchos(msdeuno).Luego,vemosque ellibro 100 Aos de soledad
fue leido por dos lectores, Juan y Ana. Entonces, la cardinalidad ser muchos del lado de
lectorparalarelacinLee.
Figura 18. Aqu vemos una relacin entre localidad y provincia, indicando que para cada
localidadslopuedeexistirunaprovincia.
Pag.1659
Figura 19. Aqu vemos un ejemplo de elementos de las entidades Localidad y Provincia.
Como eslgico, una localidad slo puedepertenecer aunaprovincia, yaqueestdentrode
ella.
Figura 20. Aqu vemos las entidades Localidad y Provincia, con la relacin pertenece y su
cardinalidadNdelladodelocalidad.
.
Figura21.Seobservaquecadaprovinciacontieneunaomslocalidades.
Finalmente,podemosverlarelacinconlacardinalidadtotalmentedefinida.
Pag.1759
Figura 22. Vemos la relacin Pertenece con la cardinalidad totalmente definida,es decir,en
todossusextremos.
Figura23.GraficamoslaentidadAlumnoylaentidadPersona,conlarelacinEsUna.
Figura24.VemoslasentidadesAlumnoyPersonaylarelacinEsUnafinalizada.
Opcionalidad
Se habla de opcionalidad en una relacin cuando alguno de los elementos intervinientes
puedeestarrelacionadoconningunooms,oceroomselementosdelasegundaentidad.
Esto se grfica haciendo un crculo sobre la lnea queconectalarelacinconlaentidadala
cualqueremosreferirlaopcionalidad.
Pag.1859
Algunosejemplosquesepuedenencontrar,son
Laopcionalidadescomplementarioalacardinalidad,porloquedebendefinirse
ambascaractersticasenunarelacin.Enesteejemplonosconcentramosnicamente
enladefinicindelaopcionalidadynodelacardinalidad,parasimplificarelconcepto.
GradodeunaRelacin
Las relaciones tambinestndefinidassegnlacantidaddeentidadesqueintervienenensu
definicin. Hasta ahora, todos los ejemplos que hemos visto, fueron elaborados en base al
casomscomn,dondeunarelacinestasociadaadosentidades.
Dado que el grado queda determinado segn la cantidad de entidades que la relacin
Pag.1959
RelacinUnaria
Como dijimos anteriormente, las relaciones unarias son aquellas que relacionan a una
mismaentidad,pudiendoserdeUnoaUno,UnoaMuchosodeMuchosaMuchos.
Para identificarlas, debemos contemplar en ladefinicindelmodelo siexisteunaaccinque
segenereenunaentidadyseapliquesobrelamisma.Casosejemplosdeestopuedenser:
Dada la entidad Persona, la relacin Es padrede, se debepartir deunainstancia
de la entidad persona y aplicar la accin en otra instancia de la misma entidad. En
estecasounapersona,espadredeotrapersona.
Figura 27. Vemos un grupo de elementos de una entidad Persona, y las conexiones entre
losprogenitoresysushijos.
Si tenemos una entidad Auto y una relacin Fabricadoa la par de, la cual indica
qu auto fue fabricadoenelmismo momentoqueotros,tambintenemosnecesidad
de utilizar una relacin unaria, ya que debemos conectar objetos deunaentidadcon
otrosobjetosdelamismaentidad.
Pag.2059
Figura 29. Muestra de una Relacin Unaria. Vemos cmo los extremosdelromboconectan
lamismaentidad.
RelacinBinaria
Paralasbinariasnodebemosagregarmsdelo antesdicho,sedebegraficarconunrombo
yluegoconectarcondoslineashorizontalesadosentidades.
Figura30.Ejemplobsicodeunarelacinbinaria.
RelacinTernaria
Las relaciones ternarias se grafican con un tringulo en lugar de un rombo, y se conecta a
lastresentidadesqueintervienenenlarelacin.
Pag.2159
Figura 31. Podemos ver cmo la forma de la relacin cambia de un rombo a un tringulo y
lastrespuntasseconectanconlasentidades.
Figura 32. Tenemos tres entidades, Persona, Celular y Compaa. La primera, relacionada
con CelularatravsdelaRelacinTieneyconCompaaatravsde larelacinContrata.
LuegoCelularyCompaaseconectanconlarelacinOperacon.
Mediante este modelo, podramos responder las siguientes preguntas: cules son los
celulares que tienen las personas, en qu compaa estn asociados los celulares y
finalmente las compaas que las personas tienen contratadas. No podramos responder
nunca de esta forma, con qu compaia tiene contratada una persona un celular
determinado.
Para resolver esto, tendramos que pensarqueunelementodePersona,llamemosloP1,un
elemento de Celular, llamemos C1, estn asociados a un elemento de Compaa E1.
Pensemos que esta asociacin, la llamamos Tiene un plan en, para determinar que, una
persona(P1)conuncelular(C1)tieneunplanenlacompaaE1.
De este anlisis surge la necesidad de utilizar una relacin ternaria, y no varias binarias
comoenelcasoanterior.
Pag.2259
Figura 34. De esta manera quedara determinada la ternaria, conectando al rectngulo que
laidentifica,conlastresentidades,persona,compaaycelular.
Veamos la cardinalidad. Para definirla correctamente tenemos que siempre tomar dos
elementos de dos entidades y evaluar cuntos le corresponden de la tercera. Ah se puede
definir si es cero, uno o muchosenlatercerentidad.Luegodebemospararnosenotrasdos
de las tres entidades y evaluar la restante. Definir si es cero uno o muchos enlarestantey
repetir el procesouna tercerayltimavez. Hagamosunejemplopararevisaresto,tomando
elcasoanterior.
Si tomamos una Compaa E1 y una Persona P1, podemos decir que la persona P1 en la
compaa E1 puede tener cero , uno o ms Celulares, por lo que la cardinalidad en Celular
esmuchos(N).
Pag.2359
Figura35.VemoslacardinalidaddelarelacinContrataparalaentidadCelular.
Luego, tomamos otro par. de Persona P1, y de Celular C1, y veamos cuantas ocurrencias
pueden tener en Compaa. Para lo cual nos debemos preguntar, la persona P1 con el
celular C1, puede estar asociada aninguna,unaomuchascompaas?Paraestecaso,la
respuestaesqueestaasociadaaningunaoauna.
PorendelacardinalidaddelarelacinenCompaaesuno.
Figura36.SeagreglacardinalidadparaCompaaenlarelacinContrata.
Finalmente, nos queda definir la cardinalidad de la relacin para la entidad Persona. Por lo
cual, tomamos las entidades opuestas yverificamos. TomamosunainstanciadeCompaa
E1 ms una instancia de Celular C1 y nos preguntamos, para la compaa E1 y el Celular
C1, cuantas personas tienen asociadas? la respuesta para este caso es una, ya que dos
personasnopuedencompartirlapropiedaddeuncelular.
Entonces la cardinalidad es uno, ya que para cada par de celular y compaa, tengo una
solapersona.
FinalmentevemosquelacardinalidadesdeMuchosaUnoyUno,oN:1:1
Pag.2459
Figura37.Tenemoslacardinalidadcompletamentedefinida.N:1:1
Rpidamenteevaluemoslaopcionalidadenestarelacin.
Comoentodosloscasosesceroouno,oceroomuchos,esopcionalentodosloscasos.
Por lo que nos queda marcado en todos las lneas de la relacinel crculoquenosindicala
opcionalidad.
Figura38.Tenemosmarcadoadems,laopcionalidadenlarelacin.
Atributosenlasrelaciones
Muchas veces, sucede que de la accin entre dos objetos se desprenden datos que para
nuestro diseo pueden ser pertinentes. Por talmotivo,deberamospodertenerlosencuenta
de forma visible, es decir, graficarlos. Si estos datos son inherentes a la relacin, deberan
asociarseaella,yaquedescribenalamisma.
Porejemplo,siestamosconsiderandolasentidadesPerroyGatoylarelacinMordia
Figura39.EntidadPerrorelacionadaconlaentidadGato,mediantelarelacinMordia.
La informacin que nos da, nos indica cules perros mordieron a qu gatos. pero nos
gustara ahora podersabercundo.Esafecha,nopodraestarenlaentidadPerro,dadoque
nopodramosdistinguirenqufechalainstanciadeperromordiaqugato.
Pag.2559
Tampoco podra estar en la entidad Gato el atributo fecha, ya que no podramos distinguir
quperromordiaesegatoenesafecha.
Figura 40. Si asignamos la fecha en que el perro muerde al gato en la entidad Perro, no
sabramosenquefechamordiacadagato.
Figura 41. Se la fecha estuviera en la entidad Gato, y dos perros, por ejemplo el 1 y el 2
mordieran al mismo gato, no sabramos si la fecha corresponde a la mordidadelperro1o
del2.
Pag.2659
Figura 42. En este caso, si asignamos fechas a la accin, mordi a podemos determinar
cuandounperromordiaundeterminadogatoycuandomordiaotro.
Para graficar esto, debemos dibujar un atributo con un valo de la misma manera que
dibujamos los atributos de las entidades, pero en lugar de conectarlo con una lnea recta
firmeaunaentidad,vamosaconectarloalarelacinalaquepertenece.
Figura43.Vemoscomoelovaloseasociaalrombodelarelacinconunalineafirme.
Paraelejemploanterior,engrficoquedaradelasiguientemanera.
AtributosClaveenlasrelaciones
Existe un casoparticularparalas relacionesconatributos,yescuandoqueremosqueelpar
de objetos de las dos entidades participantes de la relacinsediferencienporcadavezque
se genera la accin que implica dicha relacin. Esto se debe a que la instancia de relacin
carece de identidad propia, a diferencia de las entidades. Una instancia de relacin se
identificautilizandolosatributosclavedelasentidadesquerelaciona.
Pag.2759
Por ejemplo, pensemos el caso que un alumno rinda un examen. Deberamos modelar la
entidad Alumno y la entidad Materia, con los atributos claves DNI y COD_MAT
respectivamente. Unidas las entidades a travs de la relacin Rinde. Podemos, a esta
relacin, agregarle el atributo Nota. Pero qu sucede si el alumno rindi ms de una vezel
exmen. Bien, agregamos un atributo Fecha. Una instancia de la relacin, en este caso un
exmen rendido, queda identificado por un alumno y por la materia nicamente. Dado que
los alumnos pueden rendir varias veces la misma materia, queremos distinguir
unvocamentecadaexmen.
Para solucionar esto, deberamos tomar un atributo de la relacin Rinde y definirlo como
clave de la relacin. Esto es til para estos casos, donde queremos extender las claves
propuestasporlasentidadesintervinienteshaciendousodeestanuevaclaveparcial.
Si decidiramos tomar el atributo Nota como para agregar a la clave, no sera correcto, ya
que una misma persona, para una misma materia, puede tener la misma nota dos o ms
veces.
Veamos con el atributo Fecha. Si identificamos a la relacin con el alumno, la persona y
ahora adems la fecha, podemos decir que la persona con DNI 12345678 rindi la materia
M1 los das 05/01/2011 y los das 06/03/2011.Ahorasipodemosdistinguirlosmomentosen
queocurrieronlosdosexmenes,guindonosenlapersona,lamateriaylafecha.
Figura 45. Tenemos las Entidades Alumno y Materia. Cada unacon susatributos. Luego,la
relacin Rindi, con sus atributos Fecha y Nota. Para distinguir cul es clave,se losubraya
aligualqueenunaentidad.
Entidadesdbiles
Hay veces que al generar unmodelo,nosdamoscuentaqueciertasentidadesdependende
laexistenciadealgunaotraentidadparapoderexistireneldominiodenuestro problema.Por
otra parte, no pueden identificarse por s solas, sino que requieren de esa otra para poder
hacerlo. Es decir, que sin tener la otraentidadalaqueestfuertementeligada, estaentidad
notendrarazndeser.Aestasentidades,lasllamaremosentidadesdbiles.
Un ejemplo clsico podra ser el diagrama de una biblioteca, donde se tienen las entidades
Ejemplar y Libro. En este caso, la entidad fuerte es el Libro, donde se determinan los
Pag.2859
atributos pertinentes a la publicacin (nombre, autor, ISBN, etc.). Por otra parte, nuestra
biblioteca disponedediversosejemplaresdelmismo libro.Necesitamosalmacenardatosde
los ejemplares comoser:nmerodeejemplar,estado,alumnoquelotieneprestado,etc.En
este caso, un ejemplar no tendra razn de ser sin el libro correspondiente. Si no existe el
libro, no existen losejemplares.QuedadeterminadodeestamaneraquelaentidadEjemplar
esunaentidaddbil.
Figura 47. Si agrupamos el nmero de ISBN y el cdigo de ejemplar, vemos que se forma
entrelosdos,unaclavenica,pudiendoasdistinguircadaunodelosejemplares.
Los atributos que permiten diferenciar las distintas instancias de las entidades dbiles se
denominan discriminantes. Finalmente, una entidad dbil queda identificada unvocamente
por los atributos identificadores de la fuerte relacionada, ms los discriminantes que ella
defina.
Pag.2959
Figura 48. Entidades Ejemplar y Libro. Tenemos doble rectngulo sobre Ejemplar, para
definirlacomodbil.Eldiscriminantesemarcacomounatributoidentificadornormal.
Es importante destacar que los atributos identificadores de la entidad fuerte que la dbil
hereda no deben ser indicados en el diagrama, ya que se asumen de la relacin. En
nuestroejemplo,vemosquenodebemosagregarunatributoISBNenlaentidadEjemplar.
Por otra parte, una entidad dbil podra relacionarse con ms de una fuerte, quedando
identificadaporlatotalidaddelosidentificadoresdelasfuertesmslosdiscriminantes.
Figura49.Ejemplosdeentidadesdbiles.
Pag.3059
JerarquasoHerencias
Una jerarqua o herencia aparece en nuestro modelo cuando dos o ms entidades tienen
ciertosatributosencomn,yotrostantosespecficosacadaunadeellas.
Ilustrando el concepto con un ejemplo, pensemos las entidades Auto y mnibus, cada una
con los siguientes atributos: Para Auto, nro_patente, nro_motor, cantidad de puertas,
espacio_en_baul y color, mientras que para el mnibus tenemos nro_patente, nro_motor,
cantidaddebutacas,bao,televisorycolor.
Como se observa, muchos atributos son comunes aambasentidades,porloquepodemos
idear una entidad padre, tambin conocida como supraentidad o superentidad, que
agrupe a estos atributos. Normalmente, se define un nombre para esta nueva entidad,
comn a ambas (para nuestro ejemplo Medio de transporte). Luego tendremos las
entidades especficas, tambin conocidas como subentidades, quienes contendrn
nicamentelosatributosespecficos.
Una caracterstica importante de las jerarquas esquelassubentidadesnoposeenatributos
identificadores, sino que los heredan de la supraentidad. Es por ello, que al momento de
jerarquizar, debern seleccionarse en la supraentidad nicamente aquellos atributos que
seanclave.
Figura50a.TenemoslasentidadesAutoyOmnibus.Ambasconsusatributos.
Figura50b.Tenemoslosatributoscomunes,ylosdesplazamosalanuevaentidad.
Pag.3159
Figura50c.Resultadodelajerarquizacindemediosdetransporte
Solapamiento
Una vez que tenemos definidas la supraentidad y las subentidades, debemos pensar si las
subentidades son solapables o no. En otras palabras, si una subentidad puedeserasuvez
otrasubentidaddiferente.
En el caso de los Medios de transporte, esto es imposible, ya que un vehculo especfico, o
es Auto o es Omnibus (nunca ambos). Para estos casos, decimos que la jerarqua es
exclusivao sin solapamiento.Estarestriccindelasjerarquassesimbolizanconunarco,
segnpuedeverseenelejemplo.
Figura51.Ejemplodejerarquaexclusivaosinsolapamiento
Un ejemplo de jerarqua inclusiva o con solapamiento podra ser el caso de tener una
supraentidad Persona y las subentidades Alumno y Docente. Dado que la misma persona
puede ser Alumno y Docente a la vez, consideramos que en este caso puede haber
Pag.3259
Particin
Lasiguienterestriccinquedebeplantearseenunajerarquaeslaparticin.Unajerarquase
laconsideradeparticintotalcuandotodasupraentidaddebeteneralmenosuna
subentidadquelaespecifica.Encambio,enunaparticinparcial,unasupraentidadpodra
llegaraexistirsinsubentidadalguna.Esimportanteentenderqueesteconceptoes
independientedelsolapamiento.
Para nuestro ejemplo, un medio de transporte tiene que ser auto u mnibus. No hay
conceptualmente medios de transporte que no sean alguno de estos dos. Por ende,
hablamos de una particin total. Simbolizamos esta restriccin con una doble lnea hacia la
supraentidad,segnvemosenelejemplo.
Figura51.Ejemplodejerarquaconparticintotal
Un caso de particin parcial podra ser dado por la supraentidad Empleado y las
subentidades Administrativo y Programador, cada una de estas ltimas con sus atributos
especficos. Podramos llegar a tener en nuestra empresa otros empleados que no sean ni
administrativos ni programadores (ej: limpieza) por lo que existiran instancias de entidades
Empleadosincontenerinstanciasenalgunasubentidad.
Al igual que en el caso de solapamiento, dado que la particin parcial es menos restrictiva
que la total, simplemente no se simboliza este caso en el diagrama. Se traza una lnea
simpleenlugardedoble.
Pag.3359
AtributodeJerarquaoDiscriminante
Si nos encontramos en el caso ms restrictivo posible de jerarqua (particin total, sin
solapamiento), podemos optar por la definicin de un atributo de jerarqua o discriminante.
Este atributo permitir, desde el punto de vista de la supraentidad, determinarlasubentidad
que la especifica. Este atributo puede ser uno ya existente en lasupraentidad, obienpuede
definirseenestemomento.
Dado que nuestro ejemplo posee este tipo de restricciones, definiremos un atributo que
permita identificar el tipo de medio de transporte que se especifica. Este atributo se dibuja
con un smbolo particular (cpsula) entre la supraentidad y las subentidades, segn
podemosapreciarenelejemplo.
Cabe destacar que, como este concepto aplica unicamente para esta forma de restriccin
(particin total, sin solapamiento), pueden omitirse los smbolos particulares de las
restriccionesyaquequedadeterminadoporeldelatributo.
Pag.3459
2.3.1.Ejemplossimples
1.Realiceundiagramasegnlasiguientedefinicin:
Los profesores de la ctedra de Computacin 1 nos encargaron realizar una
base de datos para administrar los alumnos que cursan la materia en el ao
en curso, para de esa manera poder llevar un control de la asistencia, de los
trabajos prcticos entregados (este ao solo habr trabajos prcticos
individuales)ydelasnotasdelosparciales(yrecuperatorios)decadauno.
Primero, debemos realizar un pequeo anlisis, lo cual nos lleva a identificar las posibles
entidades. A simple vista, leyendo el enunciado, debemos buscar aquellas posibles
coleccionesdecosasuobjetosoelementos.PodemostomaralosProfesores,lactedrano
es necesaria por ser una sola, losalumnos,elcontroldelaasistencia, lostrabajosprcticos
y las notas. Dado que no hay definicin de cmo interactan los profesores, ni con los
trabajosprctico,sniconlacorreccin,lospodemosdescartar.
Refinando un poco esteanlisis, detectamosque,paraalmacenarlaasistencia,lasnotasde
los parciales y el estado delostrabajosprcticos,debemosconsiderarunaentidadAlumno.
Para validar la asistencia, deberamos tener una entidad Clase, ya que Asistir es una
accin del alumno con respecto a la clase. Siguiendo esta lnea de pensamiento, podemos
tener una entidad Parcial, donde almacenar el parcial en s y luego mediante una relacin
conectar al alumno con el parcial, para definir la presentacin y la nota que tuvo en dicho
parcial.Lomismopodemoshacerparalostrabajosprcticos.
Veamoscomonosquedaraeldiagrama.
Pag.3559
2.Realiceundiagramasegnlasiguientedefinicin:
Se tiene un equipo de ftbol, el cual consta de Director tcnico, jugadores de
campo, ayudante de campo, preparadores fsicos, arqueros. Los jugadores,
pueden alternar la posicin de arquero con ladejugadordecampo.Detodos,
queremossaberlosnombres,apellidos,nacionalidadyfechadenacimiento.
Para los jugadores, queremos saber qu posicin ocupa en la cancha, y qu
nmero de camiseta tiene. Paraelcuerpotcnico,esdecireldirectortcnico,
el ayudante de campo y los preparadores fsicos, se desea almacenar, el
sueldoylafechadeingresoalclub.
Primero, debemos detectar las posibles entidades. Vemos que hay diferentes roles o
puestos dentro del club, que se puedenagruparen:Losjugadoresylostcnicos.Ambos
comparten cierta cantidad de atributos y luego tienen atributos especficos. Adems,
presuponemos que un jugador no ser al mismo tiempo tcnico y viceversa. Para esto,
debemos hacer una jerarqua. Como una persona no puede ser jugador y tcnico a la vez,
determinamos que ser sin solapamiento. Por otra parte, toda persona debe ser jugador o
ser parte del cuerpo tcnico (particin total). Esto nos lleva al caso ms restrictivo, por lo
quedefinimosunatributodiscriminanteparadeterminarelTipodepersona.
Pag.3659
2.3.2.Ejemplocomplejo
Se desea confeccionar un nuevo sistema para poder almacenarlas llamadasquerecibeel
Call Center de la empresa Compre YA S.A.. Los llamados pueden corresponderse con
compras de productos o bien reclamos que se realicen de los mismos. Cada llamadaser
registrada con una identificacin que corresponder con CR+Nro.Unvoco(porejemplo,
C101 corresponde a una compra101yR102correspondeconunreclamo102).Adems,la
llamada registraelnmerodetelfonodelcualprovinolallamada,lafechayhoradellamado
y nmero de lnea interna por la que ingres el llamado. Otro de los datos a registrar, es la
persona que ha realizado el llamado, la cual llamaremos Contacto. Todo contacto debe
identificarse a travs del tipo y nmero de documento y adems, deberemos registrar su
nombre,apellido,fechadenacimientoydatosdomiciliariosparapoderenviarelpedido.
Tanto las compras como los reclamos se registrarn con una codificacin unvoca para
poderidentificarlosanteunsiguientellamado.
Para el caso de los reclamos, se deber registrar cada uno de los comentarios querealice
el contacto en forma explcita. Si una persona vuelve a llamar para ver el avance de su
reclamo, deber indicarnos el nmero de reclamo y podremos verificar su estado (R:
resuelto, E: en evolucin, S: sin analizar). Si lo desea, el contacto podr adjuntarnos un
nuevo comentario de ese reclamo en cada una delasllamadas.Todallamada,debeindicar
elcomentarioqueharealizadosobreundeterminadoreclamo.
Para el caso de las compras, deber indicar la fecha de realizacin de la compra,elmedio
de pago y si es necesario, persona autorizada para recibir el pedido. Si la compra se
concreta, se generarlafacturaindicandotodoslosproductosquehayacomprado.Sedebe
tener en cuenta quelasfacturasdebenposeerunnmerounvoco,fechadecompraydatos
que identifiquen a lapersonaquelocompr.Notodaslascompraspudieronhabergenerado
lafactura,yaquealderivarsealsectordecompras,analizarnyautorizarnlacompra.
Las llamadas son atendidas por operadores, los cuales poseen una identificacin, fechade
ingreso a la empresa, nombre, apellido, tipo y nmero de documento. Existen operadores
Junior y Senior. Cualquier operador podr atender una llamada, pero slo a los operadores
Senior se le podrn derivar los reclamos para que luego realicen el seguimiento. De los
operadores Junior queremos saber la antigedad en la empresa. Existen operadores
coordinadores,loscualesposeenungrupodeoperadoresasucargo.
Pag.3759
Pag.3859
2.4.ModeloRelacional(MR)
Como parte del proceso de diseo de una base de datos, unavezobtenidonuestromodelo
conceptual, abstracto o de alto nivel (DER), debemos proceder a transformarlo en un
modelo lgico llamado Modelo Relacional (MR). Este modelo derivar finalmente en aquel
queimplementaremosennuestrabasededatos.
Existen hoy en da muchas herramientas que, adems de permitirnos graficar el Diagrama
Entidad Relacin, nos sirven para generar de forma automtica elModeloRelacional.Estas
herramientas se llaman Herramientas CASE (por Computer Aided SoftwareEngineering,
oIngenieradeSoftwareAsistidaporComputadora).
Como podemos vislumbrar, si esta conversin la puede realizarunprograma, esporquees
en base a un procedimiento ya establecido y pensado. Por ende,iremosdescubriendoeste
pasaje en forma detallada, indicando los pasos a realizar y observando los diferentes
elementosquecomponenstemodelo.
ElementosdelModeloRelacional
El modelo relacional consta de Relaciones, Atributos y Restricciones de estos, por ende,
todo elemento del DER, derivar en algunos de estos. Este modelo tiene como
particularidadqueesunmodeloescrito,nogrfico.
Relaciones
Una Relacin es un conjunto de instancias del mismo tipo, definido en base a los atributos
que la componen. Tambin se conocen en este modelo como tablas. Las mismas se
describen a travs de los atributos o campos y a las diferentes instancias que las
componenselasdenominatuplasofilas.
No deben confundirse este tipo de relaciones del MR (del ingls Relation) con las del DER
(delinglsRelationship).
Porejemplo,sonrelacionesdeunMR:Persona,Gato,Empleado,Oficina,etc.
Sealaremos nuestras relaciones dentro del modelo con el nombre de la relacin, con su
primera letra en mayscula y el resto en minscula. Si el nombre consta de ms de una
palabra, suprimiremos el o los espacios entre las palabras y los reemplazaremos por
guiones bajos. Luego del nombre, encerraremos a los atributos que la componen entre
parntesis.
Relacin(atributos)
Persona(...)
Auto(...)
Telefono(...)
Pag.3959
Atributos
Al igual que en las entidades, los atributos son quienesdescribenydiferencialasinstancias
entre las distintasrelaciones.Seescribenaladerechadelarelacin,separadosporcomas,
normalmente en minsculas. Al igual que los nombres de las relaciones, si tienen mas de
una palabra, no se pueden utilizar espacios, por lo que se pueden reemplazar por guiones
bajos.
Laformadedistinguirunatributodeotroesporsunombre,por loquenopodemostenerdos
atributosconelmismonombre.
Persona(nombre,apellido,color_de_ojos,color_de_pelo)
Auto(color,marca,modelo,cantidad_de_puertas,nro_de_motor)
Telefono(numero,dueo,)
Pais(nombre,continente)
ClavePrimaria(PK)
La primera de las restricciones a tratar, es la denominada clave primaria (PK, del ingls
Primary Key). La misma esta formada por atributos clave, quienes identifican y diferencian
las distintas instancias o tuplas de la relacin. Puede existir ms de un atributo clave por
relacin, de la misma manera que suceda en las entidades del modelo relacional. En este
caso,elconjuntodeatributos,determinarlaclaveprimaria.
La forma de diferenciar un atributo clave de uno que no lo es, es subrayando con una lnea
firmedebajodelatributoclave.
Empleado(legajo,nombre,apellido,edad,nro_documento)
Departamento(codigo,piso,nombre,lugar)
Projecto(Proj_nro,nombre)
Persona(tipo_doc,nrodoc,nombre,apellido,edad,nacionalidad)
Vemos que en Empleado, podran distinguirsenicamentelasinstanciasdelarelacintanto
por el legajo como por el nmero de documento. Por lo tanto debemos elegir uno sobre el
otro.
Para el caso de persona, se decidi tomar el tipoyelnmero dedocumentoparaidentificar
a una persona de forma nica, ya que con solo el nmero de documento no nos alcanza
paraidentificarla.Ambosformanlaclaveprimaria.
Pag.4059
Pag.4159
ClavesFornea(FK)
Otra de las restriccionesquepermitegarantizarlaconsistenciadenuestra basededatoses
la clave fornea (FK, del ingls Foreign Key). Esto implica transportar los atributos que
componen la clave primaria de una relacin a otra relacin, para que esta segunda slo
tomevaloresvlidos,queseencuentrenenlaprimera.
Si por ejemplo tenemos la relacin Pas, con el atributo nombre, este atributo ser clave o
identificadordelarelacin
Pas(nombre)
Luego, tendremos la relacin Televisor, con los atributos nmero de serie (como
identificador),modeloypulgadas.
Televisor(nroSerie,modelo,pulgadas)
Si queremos sealar donde fue armado el televisor, deberamos tener un atributo
armado_en,dondecolocaramoselpas.
Televisor(nroSerie,modelo,pulgadas,armado_en)
Figura56.VemosejemplosdeobjetosdelasrelacionesTelevisoryPas.
Pag.4259
Si queremos que las nicas posibilidades para completar el campo armado en sean
aquellas instancias de la relacin Pas, deberamos definir una clave fornea incluyendo a
esteatributo.Consoloindicarlo,quedarestablecidalarestriccin.
Figura57.Vemoselementoscorrectosyunoincorrecto.
ClavePrimariayFornea
Existe la posibilidad de que tengamos un caso donde un atributo identificador tambin sea
obtenido de otra relacin y que cumpla con ambas condiciones. Por ende, estamos
definiendodosrestriccionesaunsoloatributoogrupodeatributos.
Veamosunejemplodondesecumpleestacondicin,
Pag.4359
Figura 58. Tenemos tres instancias en la relacin Persona. Las dos primerasparticipande
la relacin Alumno y la ltima de la relacin Docente. Vemos que DNI es clave en las tres
entidades,peroenAlumnoyDocenteademsesforneo.
Para visualizarlos a la hora de hacer el MR, hacemos el subrayado habitual para los
atributos claves ypodemoso colocarlos ademsennegritaotambinagregarunsubrayado
punteado.Lafigura68quedaradelasiguienteformaelMR.
Persona(dni,nombre,apellido,fec_nac)
Docente(dni,cargo,fec_ingr)
Alumno(dni,promedio,sexo)
Pag.4459
Reglasdetransformacin.DesdeelDERalMR
Las reglas de transformacin nos guan para mostrarnos la conversin entre un Diagrama
EntidadRelacin y un Modelo Relacional. Aplicando una sucesin de pasos, obtendremos
unnicoMRapartirdeunDER.
DeEntidadessimplesaRelaciones.
Todas las entidades que tenemos en nuestro DER se transformarn en Relaciones dentro
de nuestro MR. Tomaremos el nombre de la entidad como nombre de la relacin, los
atributos claves para definir la PK, y el resto de atributos de la entidad tambin sern
incluidosdentrodelarelacinresultante.
Figura 59. Transformamos la Entidad Auto del DER en la relacin Autoen elMR.Tomamos
elnombredelaentidad,suclaveyelrestodeatributos.
DeEntidadesyRelacionesaRelaciones.
Si tenemos un caso de dos entidades y entre ellas una relacin y queremos proceder a la
traduccin al modelo relacional, deberemos tener encuentalacardinalidadylaopcionalidad
delarelacinparasabercmoproceder.
VeamoselcasodelasrelacionesBinariasde1:1sinopcionalidad.
Se crearn las relaciones correspondientes a cada entidad y luego, para la relacin
propiamente dicha, debemos crear un atributo forneo en una de las dos relaciones para
simbolizar la relacin existente entre las entidades. Este atributo foraneo, podemos incluirlo
encualquieradelasdosrelacionesresultantes,peronoenambas(unauotra)
Pag.4559
Figura 60. Tenemos Dos Entidades y una relacin gua (1:1) en un DER. Podemos traducir
en caso izquierdo, donde colocamos un atributo forneo en Aprendiz, o en caso derecho,
dondecolocamoselatributoforneoenTutor.
Por ltimo, el caso dondetenemos una relacin Binaria 1:1 con opcionalidad en slo
Pag.4659
Figura62.Vemoselcasodeunarelacinunariaconopcionalidadenunsoloextremo.
Siguiendo este camino, tomaremos ahora el caso de las relaciones Binarias con
cardinalidad1:N.
Cuando las relaciones son 1:N, no se tiene en cuenta la opcionalidad al hacer la
transformacin. Siempre debemos tomar el/los atributo/s clave de la entidad que se
encuentra del lado de la cardinalidad 1 y transportarlos a la relacinresultante delaEntidad
que tiene la cardinalidad N. Es decir, se agregan nuevos atributos en la relacin
correspondientealladodelaN.
Pag.4759
Figura63.VemosunejemplodedosentidadesyunarelacinN:1ysutransformacinaMR
AnalizamoselcasodelasrelacionesBinariasconcardinalidadN:N.
Cuando tenemos este tipo de relaciones Binarias, debemos crear una nueva relacin en el
MR, con el nombre de la relacin N:N. Esta nueva relacin, contendr como atributos los
atributos claves de las entidades que intervienen en la N:N. y estos a su vez, formarn las
clavesforneascorrespondientesalasrelacionesquereferencian..
Figura65.RelacinbinariaN:N
Pag.4859
Figura66.Ejemplodeinstanciasdelafigura65.
En el caso en que la Binaria N:N tenga un atributo, ese atributo formar parte de la nueva
relacincreada.
Figura 67. Tenemos una Relacin de un DER con atributo y lo agregamos a la relacin
resultanteenelMR.
Siunodelosatributosdelarelacinfueraclave,tambinserclaveenlanuevarelacin.
Pag.4959
Figura68.VemosalaRelacinExamenenelDERyefectuamoslatraduccinaMR.
Figura69.Transformacindeunaentidadconunarelacinunaria.
Lamismatraduccinharemoscuandoseauna1:N,tenganonoopcionalidad.
Pag.5059
En el caso de las relaciones Unarias N:N, realizaremos el mismo procedimiento que las
binarias de igual cardinalidad. Como solo tenemos una entidad, tomamos la clave de dicha
entidad, pero recordando que interviene dosveces,porloquedebemostomardosveces
laclavededichaentidad.
Figura70.GeneramoslaRelacinenelMRenbasealarelacindelDER.
Figura71.DetalledelatransformacindeunatributocompuestoaMR.
Pag.5159
Figura72.Transformacindeatributomultivaluadoaentidaddbil.
Ahora si,sabiendocmotransformarunatributomultivaluadoenentidaddbil,analicemosel
casodetransformacindeunaentidaddbilalMR.
Lo que tenemos que hacer, es partir nuevamente de la base provista por las relaciones
binarias, ya que para que exista una entidad dbil debe existir una relacin binaria que la
relacioneconlaentidadfuerte.
En prinicipio bastara con realizar las transformaciones ya vistas de entidades y de
relaciones binarias. Pero, en una entidad dbil, la clave es incompleta o parcial, ya que
depende de una fuerte para su existencia. Por lo tanto, para que esto se cumpla, debemos
definir tambin como parte de la clave primaria, al atributo forneo que acabamosdeincluir
enlarelacinqueprovienedelaentidaddbil.
Pag.5259
Figura73.TransformandounaentidaddbilaMR
Para el caso de las relaciones ternarias, siempre generaremos una relacin extra,esdecir,
al traducir del DER al MR tendremos como resultado 3 relaciones por las tres entidades y
unarelacindelMRextrapararepresentarlarelacindelDER.
La cardinalidad de la relacin ternaria ser quien defina la forma de definicindelaclaveen
larelacinresultante.
Empezemos por la relacinternariaN:N:N. Tendremos por resultadoparaestecaso,una
relacin extra que tenga los atributos clave de las tres entidades como forneos. Adems,
para que se cumpla la condicin propuesta por la ternaria, se deben tomar las tres claves
forneascomoclavesprimarias.
Figura74.PasajedeunaternariaN:N:NaMR.
Pag.5359
Figura 75. Como vemos, tomando algunos datos de las relaciones empleado, proyecto y
perfil, armamos las posibles ocurrencias en asignado. donde no se permiten dos filas
idnticas,yaquetodoslosatributossonclave.
En el caso de que la ternaria sea 1:N:N, se generar al igual que el caso anterior, una
nuevarelacindelamismaforma.
La diferencia est al definir la clave.Sloformarn laclaveprimariaaquellosatributosque
provienen de los extremos N omuchos. Es decir, que formaremos la clave con dos de
tresatributosforneos.
Figura76.TernariaaMR.Caso1:N:N.
Pag.5459
Figura77.Ejemploconobjetosdelascuatrorelacionesresultantes.
Luego,tenemoselcasodelasternarias1:1:N.
Nuevamente, aplicamos la misma transformacin pero al definir la clave primaria debemos
tomar, como en el caso de las ternarias 1:N:N, dos atributos forneos como clave de
nuestra nueva relacin. En estecaso,tomarelque provienede laentidadNy algunode
losotrosdosrestantes(cualquieradelosdos).
Figura78.Transformacindeuna1:1:NaMR
Pag.5559
El ltimo de los casos es la ternaria 1:1:1. En este caso, no tenemos ninguna entidad
mandatoria para la definicin de la clave. Como el mnimo de atributos adefinirparaquese
cumpla la relacin ternaria son dos, debemos elegir cualquier par de atributos para
definirlaclave.
Figura80.Definimoseltraspasodeunaternaria1:1:1aMR
Pag.5659
Figura 81. Ejemplo con elementos de las relacionesparavisualizarel casopreciso para ver
comoaplicalaclaveenestetipoderelaciones.
Finalmente, nos quedan por transformar las jerarquas. Dado que las restricciones
(solapamiento y particin) no inciden en la transformacin, realizaremos un procedimiento
generalparacualquiertipodeellas.
Se deber crear una relacin por la supraentidad y una por cada subentidad, de la misma
manera que para entidades comunes. Dadoquelassubentidadesnoposeenexplcitamente
atributos identificadores, se debern agregar en cada una de ellas, todos los atributos
marcados como clave en la supraentidad.Estoscampos,noslosernlaclaveprimariade
lassubentidades,sinoqueademsformarnunaclaveforneaalasupraentidad.
En el caso especfico de utilizacin de un atributo de jerarqua o discriminante, el mismo
deberagregarsealarelacinresultantedelasupraentidad.
Figura82.TransformacindeunajerarquatotalaMR
Pag.5759
2.4.1.Ejemplossimples
TraduciremoslosejemplossimplesdeDERplanteadosenlasseccionesanteriores(2.3.1).
1.MRResultante:
Tp(nro,descrip,fecha_entrega)
Parcial(nro,fecha)
Alumno(legajo,apellido,nombre)
Clase(fecha,contenido)
Entrega(f_entrega,nota,tp_nro,al_legajo)
Rinde(nota,al_legajo,par_nro)
Asiste(al_legajo,cl_fecha)
Pregunta(par_nro,pregunta)
Hastaclase,tenemostraducidaslasentidadesquevemosenelDER.
Entrega,RindeyAsiste,tienencomoforneoslasclavesdelasentidadesalasqueestan
relacionadas,lascualesestnmarcadasconnegrita.
Luego,pregunta,esunarelacinquesecreaapartirdelatributomultivaluado.
2.MRResultante:
Persona(legajo,nombre,apellido,nacionalidad,f_nacimiento,tipo)
Jugador(legajo,camiseta,posicin)
Tecnico(legajo,sueldo,f_ingreso)
2.4.2.Ejemplocomplejo
TomandoelejemplocomplejodelaseccindeDER,traduciremosdichoresultadoaun
ModeloRelacional.
Contacto(nroDoc,tipoDoc,nomape,calle,nro,cp)
Operador(id,nroDoc,tipoDoc,nomape,f_ingr,
op_coordinador,tipo)
Junior(id)
Senior(id)
Llamada(nro,cont_nroDoc,cont_tipoDoc,operador_id)
Reclamo(nro,estado_cod,senior_id)
Estado(cod,descr)
Comentario(reclamo_nro,item,texto,llamada_nro)
Compra(nro,pers_autorizada,medio_pago,fecha,
llamada_nro,factura_nro)
Factura(nro)
Item_factura(factura_nro,item,cantidad,prod_codigo)
Producto(codigo,descr)
Pag.5859
Pag.5959