Modeladodeuna

BasedeDatos

Autor:AlfonsoPalomaresCorregidoyrevisadopor:MartnBattaglia

Modelado de una base de datos by Alfonso Palomares is licensed under a Creative CommonsAtribucinNoComercialSinDerivadas3.0UnportedLicense.

Pag.159

Contenidos

ModeladodeunaBasedeDatos2.ElModelado

2.1.Porqudeborealizarunmodelo2.2.Cmomodelar

2.2.1Ejemplo2.3.DiagramaEntidadRelacin(DER)

EntidadesEjemplo

AtributosAtributosClaveoIdentificadoresAtributosCalculadosAtributosMultivaluadosAtributosCompuestos

RelacionesCardinalidaddelasRelacionesOpcionalidadGradodeunaRelacin

RelacinUnariaRelacinBinariaRelacinTernaria

AtributosenlasrelacionesEntidadesdbiles

JerarquasoHerencias2.3.1.Ejemplossimples2.3.2.Ejemplocomplejo

2.4.ModeloRelacional(MR)ElementosdelModeloRelacionalRelacionesAtributosAtributosClavesAtributosForneosAtributosClaveyforneosReglasdetranformacin.DesdeelDERalMR

DeEntidadessimplesaRelaciones.DeEntidadesyRelacionesaRelaciones.

2.4.1.Ejemplossimples2.4.2.Ejemplocomplejo

Pag.259

2.ElModeladoDesde sus comienzos, el ser humano ha intentado hacer representaciones grficas de su universo conocido, para as poder transmitir su modo de ver las cosas a otros. Conforme el 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 minimizar la cantidad de plantillas usadas, es decir, se debe contar con un reducido conjunto de elementos. Segundo, se debe dar un significado nico a cada elemento,permitiendoasunanicainterpretacin.

2.1.PorqudeborealizarunmodeloDebemos 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, probado y revisado durante aos. Si en lugar de hacer un modelado simplemente nos centramos en realizar un escrito, daramos lugar a errores de interpretacinoproblemasdellenguaje,entreotrascosas.

2.2.CmomodelarPara el caso de bases de datos, el modelo grfico conceptual ms utilizado es el Diagrama 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 objetos inanimados (accidentes geogrficos, puestos de trabajo, etc.), pero siempre sern tomadas y tratadas como colecciones de objetos. Si percibimos que debemos tener en cuenta los boletos de transporte utilizados en el mes, 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, los atributos pueden ser, da y hora de la llamada, nmero dedestino,nmeroorigen,duracindelallamada,costo,etc.

Por otra parte, las relaciones estarn signadas por la accin, vnculo, asociacin o interaccinentreentidades.

Por ejemplo, si tenemos las entidades Persona y Mascota, una relacin entre ellas podra ser es dueo de, donde indicamos que una o ms personas son dueas de una o ms mascotas. Otro ejemplo que podemos incorporar es, teniendo Persona y Boleto, 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 y sus relaciones depender exclusivamente del universoodominioqueestemosmodelandoydelcontextoenqueestoseautilizado.

2.2.1EjemploNos 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, la fecha de edicin y la compaa que hizo la edicin. Adems, queremos saber qu artistasintervienenenlasdiferentesproducciones.

Teniendo esto, podemos empezar a analizar qu elementos sern posibles entidades. Para detectar colecciones, debemos ver en el prrafo anterior, qu elementos son almacenables 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 compaa que 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 podemos definir un atributo que nos distinga si el 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

Si releemos el prrafo del problema, vemos que la compaa editorial edita los DVD, 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)

EntidadesEn 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 objetos que son inherentes a la necesidad que estamos representando en el diagrama. Si tenemos una empresa que realiza diferentes modelos de zapatos, podemos pensar en considerar como entidades a los trabajadores, con sus datos que los describen. Adems, decidimos incluir la entidad zapato, 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.

AtributosComo 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. Cabe destacar, que una entidad no puede tener dos o ms atributos con el mismo nombre, ya que estaramos almacenando dos veces el mismo dato. Por ejemplo, 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 que s puede suceder, es que dos entidades diferentes tengan, en cada una de ellas, 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

AtributosClaveoIdentificadoresAlgunos 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 Color Puertas Marca Modelo2009 Negro 5 Ford Focus2010 Negro 5 Ford Focus2010 Azul 5 Ford Focus2009 Negro 5 Ford 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 un objeto auto. Recordemos que el objetivo esdistinguirunvocamenteacadaobjetodeotro.Probemos ahora, utilizar el caso extremo, es decir, utilizar todos los atributos. Si tomamos 2010 + Negro + 5 + Ford + Focus descubrimos que tampoco podemos determinar unicidad, yaque2009+Negro+5+Ford+Focusserepiteparadosobjetos.

Para solucionar esto, si bien tenemos determinados a aquellos atributos que describen a la entidad Auto, an tenemos la necesidad de identificarlos unvocamente. Para el caso de esta 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 5 Ford Focus

AAI002 2010 Negro 5 Ford Focus

BBF003 2010 Azul 5 Ford Focus

CCF004 2009 Negro 5 Ford Focus

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

A este tipo de atributo, se lo denomina Identificador o Clave. La forma de distinguirlo de los 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 podemos tener ms de un atributo clave en una entidad, por ejemplo la entidad Persona, que puede tener como atributos clave, el tipo y en nmero de documento.

Figura 4. Encontramos en esta figura la entidad persona y dos atributos clave, nmero y tipo dedocumentoylosatributoscomunesfechadenacimientoyaltura.

Tipo Nro NombrePasaporte 29111222 JuanRodriguezDNI 29111222 JuanaDoloresDNI 29111223 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 tomramos solamente el nmero del documento, obtendramos ms de una personal para el mismo valor. Lo mismo sucede con el atributo tipo de documento. Surge que, si tomamos el tipoyelnmerodedocumento(elpar),podemosdistinguirunvocamenteacadapersona.

Grficamente, si tenemos ms de un atributo clave, debemos subrayar a todos los atributos, talcomohacemoscuandoexistesolouno.

Pag.859

Hay casos, donde tenemos ms de un atributo que distingue nicamente a los elementos de 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 elegirse uno 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 dos veces la misma entidad con los mismos atributos. La entidad es Auto y los atributos son color, nmero de motor y matrcula. Como matrcula y nmero de motor 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, el atributo calculado Edad en la entidad Alumno, depende del atributo fecha de nacimiento y cuyo clculo queda determinado por la diferencia entre la fecha actual y la de 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 los atributos calculados edad y clase.

Note: es importante destacar que no hace falta explicitar la frmula en el modelo o diagrama realizado, pero si hay que tenerla presente para el futuro, cuando de este diagrama conceptualobtengamosellgico(olabasededatosensmisma).

AtributosMultivaluadosUn caso particular de los atributos, es que cuenten con ms de un valor para una instancia 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 ser en singular, por ms que pueda almacenar ms de un valor. Este tipo de caracterstica nos permite almacenar una indefinida cantidad de valores diferentes en dicho atributo para cada 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.

Figura 9. Vemos cuatro ejemplos de entidades con atributos multivaluados. La primera, es la entidad Alumno, con el atributo multivaluado telfono. Luego tenemos la entidad 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 el atributo multivaluado escritor, para indicar que puede tener cadalibro,unoomsescritores.

AtributosCompuestosPor 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 ser el atributo agrupador delosatributoscalle,piso,altura,departamento,etc.La forma de graficarlo es asociando al atributo agrupador a la entidad con una lnea. Luego, losagrupados,asociadosconunalneaalatributoagrupadorynoalaentidad.

Figura 10. En esta imagen vemos dos entidades. Primero Alumno, con el atributo compuesto direccin. Este atributo est formado por calle, altura, piso y departamento. Luego, tenemos la entidad Libro, con el atributo compuesto formato. Este atributo est compuesto porlosatributoscolor,columnas,tamaodeletraytipografa.

RelacionesLas relaciones son quienes definen las acciones entre una entidad y otra. Se dibujan con un rombo, con al menos dos conectores en las puntas horizontales, que servirn para asociar 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 una entidad y aplicamos la 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 es perseguido por, pensando en 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 primera relacin, Compuesta por, esta asociada a las entidades Empresa y sucursal. Luego, la relacin Trabaja en, se conectaconlasentidadesPersonayOrganizacin.Deformasimilarsucedeconlasdems.

Normalmente, la forma de leer dicha relacin es de izquierda a derecha, y de arriba hacia abajo.

Figura 13. Tomando algunas de las relaciones de la figura 12, se ejemplifica cmo se debe leerlarelacinqueintervieneentrelasentidades.

Entre dos entidades de nuestro modelo, podemos tener ninguna o ms relaciones, segn la 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

CardinalidadUna 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, si tenemos una accin, cuntos son los quepuedenprovocarlaycuantosrecibendichoefecto.Siempre la cardinalidad se define para cada uno de las entidades a las que est asociada la relacin. Entonces, si tenemos dos entidades que estn asociadas por una relacin, tenemosqueevaluarlacardinalidaddelarelacinconrespectoaambasentidades.

Si tenemos las entidades Lector y Libro, podramos tener la relacin Lee, para decir que un lector ley algn libro. Ahora, si evaluamos la cardinalidad de la relacin, debemos tomar un lector hipottico (no Juan ni Ana) y pensar cuntos libros puede haber ledo, para comenzar 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 que es una cardinalidad similar al caso anterior. 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, en el extremocorrespondientedelarelacin(enestecasoambos).

Figura 16. Volvemos sobre el mismo ejemplo anterior entre Lector y Libro, con las relaciones 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. Podemos ver, que Juan, ley dos libros, por lo tanto la cardinalidad de lee en Libro va a ser muchos (ms de uno). Luego, vemos que el libro 100 Aos de soledad fue leido por dos lectores, Juan y Ana. Entonces, la cardinalidad ser muchos del lado de lectorparalarelacinLee.

Otro caso de cardinalidad puede darse donde uno de los elementos tomados de una entidad 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 es lgico, una localidad slo puede pertenecer a una provincia, ya que est dentro de ella.

Luego, para determinar la segunda parte de la cardinalidad, evaluemos desde la entidad Provincia. Dada una provincia hipottica, cuntas localidades pertenecen a ella. Nos encontramos que hay una Localidad o ms dentro de dicha Provincia, por lo 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 con un solo elemento de la segunda entidad y viceversa. Por ejemplo, dada a entidad Alumno y la entidadPersona,sedefinelarelacinentreellasEsuna.

Figura23.GraficamoslaentidadAlumnoylaentidadPersona,conlarelacinEsUna.

Veamos la cardinalidad de esta relacin. Si tomamos un alumno A, se corresponde slo con una persona P, ya que un alumno slo puede ser una misma persona y nunca dos o ms. Entonces la cardinalidad de la relacin del lado de Persona, es Uno. Ahora, si tomamos una persona, siempre ser uno y slo un alumno, por lo que la cardinalidad del extremo de AlumnotambinserUno.

Figura24.VemoslasentidadesAlumnoyPersonaylarelacinEsUnafinalizada.

OpcionalidadSe habla de opcionalidad en una relacin cuando alguno de los elementos intervinientes puedeestarrelacionadoconningunooms,oceroomselementosdelasegundaentidad.Esto se grfica haciendo un crculo sobre la lnea que conecta la relacin con la entidad a la cualqueremosreferirlaopcionalidad.

Pag.1859

Figura 25. Podemos observar una relacin, que tiene marcada en uno de sus conectores un crculoqueidentificalaopcionalidadenlarelacin.

Algunosejemplosquesepuedenencontrar,son

Figura 26. Tenemos en esta imgen 4 entidades, Oficina, Empleado, Pc y Secretaria.Entre Oficina y Empleado, la relacin Ocupada por que, al estar marcada con opcionalidad, indica que la oficina puede estar vacia, sin empleados que la ocupen. Mientras que el otro 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 marcada la opcionalidad en ambos extremos. Esto nos indica que un elemento de la entidad Secretariapuedeestaronoasignadaaunempleadoyviceversa.

Laopcionalidadescomplementarioalacardinalidad,porloquedebendefinirseambascaractersticasenunarelacin.Enesteejemplonosconcentramosnicamenteenladefinicindelaopcionalidadynodelacardinalidad,parasimplificarelconcepto.

GradodeunaRelacinLas relaciones tambin estn definidas segn la cantidad de entidades que intervienen en su 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 hasta el momento, donde la relacin conecta dos entidades diferentes se 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 ambos extremos conectados a la entidad Empleado, ya que 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.

RelacinUnariaComo dijimos anteriormente, las relaciones unarias son aquellas que relacionan a una mismaentidad,pudiendoserdeUnoaUno,UnoaMuchosodeMuchosaMuchos.Para identificarlas, debemos contemplar en la definicin del modelo si existe una accin que segenereenunaentidadyseapliquesobrelamisma.Casosejemplosdeestopuedenser:

Dada la entidad Persona, la relacin Es padre de, se debe partir de una instancia 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 Fabricado a la par de, la cual indica qu auto fue fabricado en el mismo momento que otros, tambin tenemos necesidad de utilizar una relacin unaria, ya que debemos conectar objetos de una entidad con otrosobjetosdelamismaentidad.

Pag.2059

Figura 28. Tenemos varias ocurrencias de la entidad Auto, y vemos cuales fueron realizadas almismotiempo.

La forma de graficar estas relaciones, sigue siendo un rombo conectando sus extremos a la mismaentidad.

Figura 29. Muestra de una Relacin Unaria. Vemos cmo los extremos del rombo conectan lamismaentidad.

RelacinBinariaPara las binarias no debemos agregar ms de lo antes dicho, se debe graficar con un rombo yluegoconectarcondoslineashorizontalesadosentidades.

Figura30.Ejemplobsicodeunarelacinbinaria.

RelacinTernariaLas 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 saber si tenemos necesidad de una relacin ternaria debemos plantearnos lo siguiente: La accin necesita de uno o ms objetos de dos entidades para realizar la accin sobre una 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 Celular a travs de la Relacin Tiene y con Compaa a travs de la relacin Contrata. 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 pensar que un elemento de Persona, llamemoslo P1, 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 a izquierda, ejemplos de instancias para las 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 muchos en la tercer entidad. Luego debemos pararnos en otras dos de las tres entidades y evaluar la restante. Definir si es cero uno o muchos en la restante y repetir el proceso una tercera y ltima vez. Hagamos un ejemplo para revisar esto, 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 a ninguna, una o muchas compaas? Para este caso, 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 y verificamos. Tomamos una instancia de Compaa 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 relacin el crculo que nos indica la opcionalidad.

Figura38.Tenemosmarcadoadems,laopcionalidadenlarelacin.

AtributosenlasrelacionesMuchas veces, sucede que de la accin entre dos objetos se desprenden datos que para nuestro diseo pueden ser pertinentes. Por tal motivo, deberamos poder tenerlos en cuenta 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 poder saber cundo. Esa fecha, no podra estar en la entidad Perro, dado que 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 mordida del perro 1 o del2.

Entonces, debemos agregar un atributo en la Relacin Mordi a, as sabemos que el perro 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 y la entidad Gato. La relacin Mordi a con un atributo fecha.LarelacinesN:N

AtributosClaveenlasrelacionesExiste un caso particular para las relaciones con atributos, y es cuando queremos que el par de objetos de las dos entidades participantes de la relacin se diferencien por cada vez que 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 vez el 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. Ahora si podemos distinguir los momentos en queocurrieronlosdosexmenes,guindonosenlapersona,lamateriaylafecha.

Figura 45. Tenemos las Entidades Alumno y Materia. Cada una con sus atributos. Luego, la relacin Rindi, con sus atributos Fecha y Nota. Para distinguir cul es clave, se lo subraya aligualqueenunaentidad.

Este concepto se entender mejor cuando ms adelante tratemos la transformacin hacia unmodelolgicooModeloRelacional(MR).

EntidadesdbilesHay veces que al generar un modelo, nos damos cuenta que ciertas entidades dependen de la existencia de alguna otra entidad para poder existir en el dominio de nuestro 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 otra entidad a la que est fuertemente ligada, esta entidad 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 dispone de diversos ejemplares del mismo libro. Necesitamos almacenar datos de los ejemplares como ser: nmero de ejemplar, estado, alumno que lo tiene prestado, etc. En este caso, un ejemplar no tendra razn de ser sin el libro correspondiente. Si no existe el libro, no existen los ejemplares. Queda determinado de esta manera que la entidad Ejemplar esunaentidaddbil.

Figura 46. Vemos instancias de libro y de Ejemplar. Como vemos, ejemplar no puede tener alcodigodeejemplarcomoidentificador,porqueserepite.

Entonces tenemos para cada libro, al menos un ejemplar, por lo que el cdigo 1 de ejemplar se repetira para cada uno de los libros que existan en nuestro esquema. Es por ello que las 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 grafican con un doble rectngulo con lneas firmes, manteniendo el 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

JerarquasoHerenciasUna 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 a ambas entidades, por lo que podemos 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 es que las subentidades no poseen atributos 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

SolapamientoUna vez que tenemos definidas la supraentidad y las subentidades, debemos pensar si las subentidades son solapables o no. En otras palabras, si una subentidad puede ser a su vez 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 exclusiva o sin solapamiento. Esta restriccin de las jerarquas se simbolizan con un arco, 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 casos no requieren adicionar nada al grfico, ya que son el caso menos restrictivo,porloquesimplementenodibujamoselarco.

ParticinLasiguienterestriccinquedebeplantearseenunajerarquaeslaparticin.Unajerarquaselaconsideradeparticintotalcuandotodasupraentidaddebeteneralmenosunasubentidadquelaespecifica.Encambio,enunaparticinparcial,unasupraentidadpodrallegaraexistirsinsubentidadalguna.Esimportanteentenderqueesteconceptoesindependientedelsolapamiento.

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

AtributodeJerarquaoDiscriminanteSi 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, determinar la subentidad que la especifica. Este atributo puede ser uno ya existente en la supraentidad, o bien puede 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 o discriminante. En este caso, el atributo Tipo 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.Ejemplossimples1.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 colecciones de cosas u objetos o elementos. Podemos tomar a los Profesores, la ctedra no es necesaria por ser una sola, los alumnos, el control de la asistencia, los trabajos prcticos y las notas. Dado que no hay definicin de cmo interactan los profesores, ni con los trabajosprctico,sniconlacorreccin,lospodemosdescartar.Refinando un poco este anlisis, detectamos que, para almacenar la asistencia, las notas de los parciales y el estado de los trabajos prcticos, debemos considerar una entidad Alumno. 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 la de jugador de campo. De todos, queremossaberlosnombres,apellidos,nacionalidadyfechadenacimiento.Para los jugadores, queremos saber qu posicin ocupa en la cancha, y qu nmero de camiseta tiene. Para el cuerpo tcnico, es decir el director tcnico, 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 pueden agrupar en: Los jugadores y los tcnicos. 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.EjemplocomplejoSe desea confeccionar un nuevo sistema para poder almacenar las llamadas que recibe el 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 llamada ser registrada con una identificacin que corresponder con C R + Nro. Unvoco (por ejemplo, C101 corresponde a una compra 101 y R102 corresponde con un reclamo 102). Adems, la llamada registra el nmero de telfono del cual provino la llamada, la fecha y hora de llamado 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 que realice 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 de las llamadas. Toda llamada, debe indicar elcomentarioqueharealizadosobreundeterminadoreclamo.Para el caso de las compras, deber indicar la fecha de realizacin de la compra, el medio de pago y si es necesario, persona autorizada para recibir el pedido. Si la compra se concreta, se generar la factura indicando todos los productos que haya comprado. Se debe tener en cuenta que las facturas deben poseer un nmero unvoco, fecha de compra y datos que identifiquen a la persona que lo compr. No todas las compras pudieron haber generado lafactura,yaquealderivarsealsectordecompras,analizarnyautorizarnlacompra.Las llamadas son atendidas por operadores, los cuales poseen una identificacin, fecha de 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, una vez obtenido nuestro modelo 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 el Modelo Relacional. Estas herramientas se llaman Herramientas CASE (por Computer Aided Software Engineering, oIngenieradeSoftwareAsistidaporComputadora).Como podemos vislumbrar, si esta conversin la puede realizar un programa, es porque es en base a un procedimiento ya establecido y pensado. Por ende, iremos descubriendo este pasaje en forma detallada, indicando los pasos a realizar y observando los diferentes elementosquecomponenstemodelo.

ElementosdelModeloRelacionalEl 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.

RelacionesUna 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

AtributosAl igual que en las entidades, los atributos son quienes describen y diferencia las instancias entre las distintas relaciones. Se escriben a la derecha de la relacin, separados por comas, 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.

La forma de distinguir un atributo de otro es por su nombre, por lo que no podemos tener dos 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 distinguirse nicamente las instancias de la relacin tanto 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 tipo y el nmero de documento para identificar 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 relacin Empleado, e intentamos agregar instancias nuevas. Vemos que podemos tener valores repetidos en cualquier atributo, menosenlaclave.

Figura 55. Ejemplo de instancias de la entidad Persona, donde vemos una instancia que no puedeseragregadaylaexplicacindeporqusisonvlidaslasyaexistentes.

Pag.4159

ClavesFornea(FK)Otra de las restricciones que permite garantizar la consistencia de nuestra base de datos es 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 nombre de dicho atributo anteponiendo el nombre de la Relacin 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)

ClavePrimariayForneaExiste 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 primeras participan de 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 y podemos o colocarlos adems en negrita o tambin agregar un subrayado punteado.Lafigura68quedaradelasiguienteformaelMR.

Persona(dni,nombre,apellido,fec_nac)Docente(dni,cargo,fec_ingr)Alumno(dni,promedio,sexo)

Pag.4459

Reglasdetransformacin.DesdeelDERalMRLas 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 Auto en el MR. 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 en cuenta la cardinalidad y la opcionalidad 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 con opcionalidad en ambos extremos, la traduccinesequivalentealoantesvisto.

Figura 61. En un DER con una Relacin con ambas conexiones como opcionales, tenemos lamismasolucinqueenelcasoanterior.

Por ltimo, el caso donde tenemos 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 el atributo forneo en la relacin resultante del 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 relacin resultante de la Entidad 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. Enviamos las claves de 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 y 1:N. En este caso, no debemos preocuparnos ni por la cardinalidad ni por la opcionalidad. Siempre la traduccin se 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, y que ser marcado como forneo, pero que en 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 tomar los 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, aqu deberamos hacer lo mismo. Dado que slo tenemos una 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 dos veces, por lo que debemos tomar dos veces 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 en una entidad dbil 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, sabiendo cmo transformar un atributo multivaluado en entidad dbil, analicemos el 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 acabamos de incluir enlarelacinqueprovienedelaentidaddbil.

Pag.5259

Figura73.TransformandounaentidaddbilaMR

Para el caso de las relaciones ternarias, siempre generaremos una relacin extra, es decir, 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 definicin de la clave en larelacinresultante.

Empezemos por la relacin ternaria N:N:N. Tendremos por resultado para este caso, 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. Slo formarn la clave primaria aquellos atributos que provienen de los extremos N o muchos. 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 este caso, tomar el que proviene de la entidad N y alguno de losotrosdosrestantes(cualquieradelosdos).

Figura78.Transformacindeuna1:1:NaMR

Pag.5559

Figura 79. Ejemplo de instancias para las relaciones que intervienen al traducir una ternaria 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 a definir para que se 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 relaciones para visualizar el caso preciso 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. Dado que las subentidades no poseen explcitamente atributos identificadores, se debern agregar en cada una de ellas, todos los atributos marcados como clave en la supraentidad. Estos campos, no slo sern la clave primaria de 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.EjemplossimplesTraduciremoslosejemplossimplesdeDERplanteadosenlasseccionesanteriores(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,tienencomoforneoslasclavesdelasentidadesalasqueestanrelacionadas,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.EjemplocomplejoTomandoelejemplocomplejodelaseccindeDER,traduciremosdichoresultadoaunModeloRelacional.

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