You are on page 1of 59

Modeladodeuna

BasedeDatos
Autor:AlfonsoPalomares
Corregidoyrevisadopor:MartnBattaglia

Modelado de una base de datos by Alfonso Palomares is licensed under a Creative


CommonsAtribucinNoComercialSinDerivadas3.0UnportedLicense.

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.

Para estos casos, se debe pensar que estamos diagramando objetosquesoninherentesa


la necesidad que estamos representando en el diagrama. Si tenemos una empresa que
realiza diferentes modelosdezapatos,podemospensarenconsiderarcomoentidadesalos
trabajadores, con sus datos que losdescriben.Adems,decidimosincluirlaentidadzapato,
donde almacenaremos los distintos tipos de zapatos que se fabrican en nuestra empresa.
Por ltimo, hemos incluido el transporte, para pensar en el medio que utilizaremos para
Pag.559

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

Si tomamos para cualquier objeto o instancia de la entidad una matrcula en particular,


vemosqueobtenemosunoysolounauto,
A este tipo deatributo,selodenominaIdentificadoroClave.Laformadedistinguirlodelos
otros,amodogrfico,essubrayandoelnombredelatributo.
Pag.759

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.

Cabe destacar, que podemostenermsdeunatributoclaveenunaentidad,porejemplo


la entidad Persona, que puede tener como atributos clave, el tipo y en nmero de
documento.

Figura 4. Encontramos en esta figura la entidadpersonaydosatributosclave, nmeroytipo


dedocumentoylosatributoscomunesfechadenacimientoyaltura.

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

Hay casos, dondetenemosmsdeunatributoquedistinguenicamentealoselementosde


la entidad. Por ejemplo, en los autos, tenemos la matrcula como dijimos antes, pero
tambin tenemos el nmero del motor o chasis. En estos casos debemos elegir, segn lo
que consideremos ms apropiado en el dominio de nuestro problema, qu atributos sern
finalmente los identificadores. En este ejemplo, es esencial entender que debe elegirseuno
sobre el otro y no declararlos a ambos como atributos clave. Marcando a ambos como
identificadores, daramos la pauta que se necesita el par matriculanmero de motor para
determinarunauto.

Figura 5. Vemos dosveceslamismaentidadconlosmismosatributos.LaentidadesAuto y


los atributossoncolor,nmerodemotorymatrcula.Comomatrculaynmerodemotor son
posiblesclaves,debemoselegirunauotraopcin,nuncaambas.

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.

Figura 7. Vemos dos entidades, alumno y matafuego. Con losatributoscalculados edady


clase.

Note: es importante destacar quenohace faltaexplicitarlafrmulaenelmodeloodiagrama


realizado, pero si hay que tenerla presente para el futuro, cuando de este diagrama
conceptualobtengamosellgico(olabasededatosensmisma).

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.

Figura9.Vemoscuatroejemplosdeentidadesconatributos multivaluados.La primera, esla


entidadAlumno,conelatributomultivaluadotelfono.Luegotenemoslaentidad Celular,con
el atributo multivaluado aplicacin. Tambin la entidad Silln, con el atributo color de tela,
como multivaluado, para almacenar diferentes colores para cada objeto silln. Por ltimo,
tenemos la entidad Libro, con elatributomultivaluadoescritor,paraindicar que puedetener
cadalibro,unoomsescritores.

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

entendimiento. As, podemos tener el atributo direccin que podr serelatributoagrupador


delosatributoscalle,piso,altura,departamento,etc.
La forma de graficarlo es asociando al atributo agrupador a la entidad conunalnea.Luego,
losagrupados,asociadosconunalneaalatributoagrupadorynoalaentidad.

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.

Dentro de un mismo diagrama, los nombres de las relaciones no pueden repetirse.


Tampoco podemos utilizar para nombrar a una relacin, algo diferente a una frase verbal o
unverbo,yaqueeslaformadedefinirlaaccinquerepresentadicharelacin.
Para evaluar una relacin, tomamos una y solo una instancia de unaentidadyaplicamosla
accin sobre otra instancia de la otra entidad asociada. Por ejemplo, si tenemos dos
entidades, Perro y Gato, y pensamos en que estn relacionados mediante el verbo
perseguir, podemos definir la relacin persigue a, o esperseguidopor,pensandoen un
perro en particular de toda la coleccin Perro y un gato en particular de toda la coleccin
Gato.
VeamoslomismoconalgunosejemplosGrficos.

Pag.1259

Figura 12. Vemos aqu seis ejemplos ms de relaciones. La primerarelacin,Compuesta


por,esta asociada a las entidades Empresa y sucursal. Luego,la relacin Trabajaen,se
conectaconlasentidadesPersonayOrganizacin.Deformasimilarsucedeconlasdems.

Normalmente, la forma de leerdicharelacinesdeizquierdaaderecha,yde arribahacia


abajo.

Figura 13. Tomando algunas de las relaciones delafigura 12,seejemplifica cmose debe
leerlarelacinqueintervieneentrelasentidades.

Entre dos entidades de nuestro modelo, podemos tenerningunaomsrelaciones,segnla


necesidadoelproblemaqueestamosresolviendo.

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:

Figura 15. Vemos aqu tres representaciones de elementos de la entidad Lector y de la


entidad Libro. Cada representacin hace referencia a posibles conexiones entre dichos
elementos, para que podamos entender cmo funcionan las relaciones y por qu muchas
vecesdebemosdefinirmsdeunarelacinentredosentidades.

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 16.VolvemossobreelmismoejemploanteriorentreLectoryLibro, conlasrelaciones


Recomienda,Leeycomenta.Colocamos,paracadarelacinlacardinalidad.

Como en ambos extremos de la relacin tenemos N (o muchos), podemos decir que la


cardinalidaddelarelacinLeeesdemuchosamuchos,oN:N
Pag.1559

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.

Otro caso de cardinalidadpuededarsedondeunodeloselementostomadosdeunaentidad


se corresponde con un nico objeto de la segunda entidad. Esto es conocido como
cardinalidadUno.
Por ejemplo, si tenemos las entidades Localidad y Provincia, con la relacin entre ellas
Pertenece,podemosdefinirlacardinalidaddelarelacinsiguiendoestospasos:

Tomamos una localidad hipottica y transitamos la relacin hacia provincia.


Descubrimos que est relacionada con tan solo una provincia, ya que una localidad
est geogrficamente ubicada dentro de una provincia. Decimos entonces que la
cardinalidaddelarelacinPertenece,delladodeProvinciaesUno.

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.

Luego, para determinar la segunda parte de la cardinalidad, evaluemos desde la


entidad Provincia. Dada una provincia hipottica, cuntas localidades pertenecena
ella. Nos encontramosquehayunaLocalidadomsdentrodedichaProvincia,porlo
quelacardinalidaddelladodelocalidadesMuchos.

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.

Este tipo de cardinalidad, donde en un extremo de la relacin tenemos definido como


muchos y el otro extremo como uno, se define la cardinalidad como uno a muchos o
muchosauno,o1:N.
Puede existir, adems, el caso donde un elemento de una entidad se relacione conunsolo
elemento de la segunda entidad y viceversa. Por ejemplo, dada a entidad Alumno y la
entidadPersona,sedefinelarelacinentreellasEsuna.

Figura23.GraficamoslaentidadAlumnoylaentidadPersona,conlarelacinEsUna.

Veamos la cardinalidad de estarelacin.SitomamosunalumnoA,secorrespondeslocon


una persona P, ya que un alumno slo puede ser una misma persona y nunca dos o ms.
Entonces la cardinalidad de larelacindelladodePersona,esUno.Ahora,sitomamosuna
persona, siempre ser uno y slo un alumno, por lo que la cardinalidad del extremo de
AlumnotambinserUno.

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

Figura 25. Podemos observar unarelacin,quetiene marcadaen uno desus conectoresun


crculoqueidentificalaopcionalidadenlarelacin.

Algunosejemplosquesepuedenencontrar,son

Figura 26. Tenemos en esta imgen 4 entidades, Oficina, Empleado, Pc y Secretaria.Entre


OficinayEmpleado,larelacinOcupadaporque,alestarmarcadacon opcionalidad,indica
que la oficina puede estar vacia, sinempleadosque laocupen. Mientras que elotro extremo
de la misma relacin, nos indica que todos los empleados estn ocupando una oficina.
Luego, Entre Empleado y Pc, tenemos la relacin Asignado A, que nos indica que una Pc
siempre esta asignada a un empleado, mientras que no todos los empleados tienen
asignadaunapc.
Por ltimo, Entre Secretaria y Empleado, tenemos la relacin Trabaja Para, que tiene
marcadalaopcionalidadenambosextremos.Estonosindicaqueun elementodela entidad
Secretariapuedeestaronoasignadaaunempleadoyviceversa.

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

conecta, las vistas hastaelmomento,dondelarelacin conectadosentidadesdiferentesse


lasconocecomoBinariasogradodos.
Luego tenemos las Unarias o de grado uno, donde la relacin conecta dos veces a la
misma entidad. Pensemos en la entidad Empleado y la relacin Es jefe de. Esta relacin,
necesariamente tiene que tener ambosextremosconectadosalaentidadEmpleado,yaque
unempleadopuedeserjefedeotrosempleados.
Por ltimo, tenemos las relaciones de grado tres o Ternarias, trmino utilizado para
referirsealasrelacionesqueconectanatresentidades(nonecesariamentediferentes).
Por motivos de simplicidad, este modelo no permite un grado mayor que tres para sus
relaciones. Casos donde una relacin de mayor grado sea requerida, deber plantearse la
posibilidaddeconvertirdicharelacinenunaentidadconcreta.

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 28. Tenemos varias ocurrencias delaentidadAuto,yvemoscualesfueronrealizadas


almismotiempo.

La forma de graficar estasrelaciones,siguesiendounromboconectandosus extremosala


mismaentidad.

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.

Para sabersitenemosnecesidadde unarelacinternariadebemosplantearnoslosiguiente:


La accin necesita de uno omsobjetosdedosentidadespararealizarlaaccinsobreuna
tercera.
Veamos esto en un ejemplo: supongamos que deseamos saber, para una persona dada,
qu celular posee en cada compaa. Planteando el problema con relaciones binarias
tendramosalgocomoesto:

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 33. tenemos aizquierda,ejemplosdeinstanciasparalas entidades Celular,Persona


y Compaa. Luego, a derecha, tres ejemplos que combinan una instancia de celular, con
unainstanciadepersona,paradeterminarenquempresasetieneelplan.

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.

Entonces, debemos agregar un atributo en la RelacinMordia,assabemosqueelperro


PmordialgatoGenlafechaindicadaeneseatributo.

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.

Figura 44. Tenemos la entidad Perro ylaentidadGato.LarelacinMordia conunatributo


fecha.LarelacinesN:N

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.

Este concepto se entender mejor cuando ms adelante tratemos la transformacin hacia


unmodelolgicooModeloRelacional(MR).

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 46. Vemos instancias de libro y de Ejemplar. Como vemos,ejemplarno puedetener


alcodigodeejemplarcomoidentificador,porqueserepite.

Entonces tenemos para cada libro, almenosunejemplar,porloqueelcdigo1deejemplar


se repetira para cada uno de los librosqueexistanennuestroesquema.Esporelloquelas
instancias de las entidades dbiles quedan identificadas, en parte, por el identificador de la
fuertecorrespondiente.

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

Las entidades dbiles se graficanconundoblerectnguloconlneasfirmes,manteniendoel


nombre de la entidad dentro de los rectngulos. Se debe indicar adems con doble lnea la
relacinhacialafuertecorrespondiente.

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

solapamiento. Estos casosnorequierenadicionarnadaalgrfico,yaqueson elcasomenos


restrictivo,porloquesimplementenodibujamoselarco.

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.

Figura 51. Ejemplo de atributo de jerarqua odiscriminante.En estecaso,elatributoTipo permite reconocer


lasubentidadcorrespondientealmediodetransporte.

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

Figura 54. Tenemos un grupo de instancias de la relacinEmpleado, eintentamosagregar


instancias nuevas. Vemos que podemos tener valores repetidos en cualquier atributo,
menosenlaclave.

Figura 55. Ejemplo de instancias de laentidadPersona,dondevemos una instanciaqueno


puedeseragregadaylaexplicacindeporqusisonvlidaslasyaexistentes.

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.

La forma de discriminar estos atributos forneos de otros, es escribiendolos en negrita o


haciendounsubrayadopunteadodebajodelatributo.
Muchas veces, se define el nombrededicho atributoanteponiendoelnombredelaRelacin
a la que apunta, y luego el nombre pensado para dicho atributo, pudiendo as identificar
rpidamenteaqurelacinseestaasociandodichoatributo.
Tomandoloanterior,nosquedara
Pais(nombre)
Televisor(nroSerie,modelo,pulgadas,armado_en)
En caso de que armemos el nombre del atributo de la clave fornea en base a la relacin
quereferencia,podradefinirsedelasiguientemanera
Pais(nombre)
Televisor(nroSerie,modelo,pulgadas,pais_armado)

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.

En el caso de las relaciones Binarias de 1:1 conopcionalidad enambos extremos, la


traduccinesequivalentealoantesvisto.

Figura 61. En un DER con una Relacin conambasconexionescomo opcionales,tenemos


lamismasolucinqueenelcasoanterior.

Por ltimo, el caso dondetenemos una relacin Binaria 1:1 con opcionalidad en slo

Pag.4659

un extremo. Aqu, tenemos una entidad mandatoria y es aquella donde no se seala la


opcionalidad. En este caso, debemos definir elatributoforneo enlarelacinresultantedel
MRquetieneasociadalaopcionalidad.

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

Figura 64. Tenemos una relacin con opcionalidad a ambos lados.Enviamoslasclavesde


laentidaddelladodeSecretariaaJefe.

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.

Nos enfocaremos ahora en el caso de las relaciones Unarias 1:1 y1:N.Enestecaso,no


debemospreocuparnosnipor lacardinalidadnipor laopcionalidad.Siemprelatraduccinse
hardelamismamanera,salvoenelcasodelasunariasN:N.
La forma de realizar el traspaso de las unarias es generar un nuevo atributo en la relacin
resultante que represente la relacin unaria,yquesermarcadocomoforneo,peroqueen
realidadreferiralaclavededichaentidad.
Veamos un ejemplo. Si tenemos la entidad Persona con los atributos DNI como clave,
nombre y apellido y la relacin unaria Casado_con. Al traducir al MR, debemos tomarlos
atributos de la entidad Persona, dni, nombre y apellido. Luego, debemos traducir
casado_con. Si mantenemos la idea de las binarias, es decir, agregar un atributo en una
de las relaciones resultantes, aqudeberamos hacerlomismo.Dadoqueslotenemosuna
relacin resultante, es ah donde debemos colocar el atributo forneo, que hace referencia,
enlugardeaunaclavedeotrarelacin,alaclavedelamismarelacin.

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.

En caso de poseer atributos compuestos en nuestra entidad, los transformamos a MR


comolosatributoscomunes,eliminandoelagrupador.

Figura71.DetalledelatransformacindeunatributocompuestoaMR.

Si tenemos un atributo multivaluado, debemos transformarlo primero enunaentidaddbil


y luego transformarlo al MR. En primer lugar, analizaremos la conversin del atributo
multivaluado a entidad dbil. Para lograr esto, debemos crear una entidad dbil con el
nombre del atributo multivaluado y un nico atributo, que ser discriminante. Luego,
relacionamosdichaentidaddbilconlaentidadoriginal.Estanuevarelacinserde1:N.

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

Figura 79. Ejemplo de instancias para las relacionesqueintervienen altraducirunaternaria


1:1:N

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

You might also like