Modelo Entidad-Relacin Se basa en una representacin del mundo real en que los datos se describen como entidades, relaciones

y atributos. El modelo Entidad-Relacin (ER) es uno de los modelos de datos ms populares. Se basa en una representacin del mundo real en que los datos se describen como entidades, relaciones y atributos. Este modelo se desarroll para facilitar el diseo de las bases de datos, y fue presentado por Peter Chen en 1976. 2.2.1 Concepto El modelo entidad-relacin est formado por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de representaciones grficas y lingsticas. Este modelo toma como punto de partida considerar la existencia de entidades, que representan objetos, personas, etc, sobre las que se quiere almacenar informacin relevante. Las entidades con las mismas caractersticas forman un tipo de entidad. A las caractersticas necesarias para describir completamente a cada tipo de entidad se les denominar atributo. Posteriormente, las entidades y sus atributos se representan fsicamente a travs de tablas (transformacin en un modelo relacional) en las que los datos se almacenan en dos dimensiones. Las filas de la tabla contienen los atributos de cada una de las entidades, y las columnas el conjunto de atributos del mismo tipo de cada entidad. 2.2.2 Caractersticas El principio fundamental en este modelado, que no puede obviarse de ninguna forma, es que hechos distintos deben almacenarse en objetos distintos. Es independiente de los aspectos de implementacin. Posee una notacin grfica bastante concisa y de fcil comprensin. Sus elementos representan las necesidades de la realidad. Representa el almacenamiento de los datos. Identifica las restricciones de almacenamiento. Esquematiza las relaciones entre las entidades. Muestra las operaciones que se realizan en las entidades con sus atributos.

2.2.3 Elementos El modelo entidad-relacin maneja tres elementos para su representacin que son las entidades, atributos y las relaciones. Entidades: La entidad es una "cosa" en el mundo real con existencia independiente. El principal concepto del modelo ER es la entidad, que es una "cosa" en el mundo real con existencia independiente. Una entidad puede ser un objeto fsico (una persona, un auto, una casa o un empleado) o un objeto conceptual (una compaa, un puesto de trabajo o un curso universitario). Las entidades pueden ser:

Entidad fuerte existe por s misma sin depender la existencia de alguna otra entidad. Entidad dbil depende de la existencia previa de otra entidad. Si la entidad dbil puede ser identificada sin necesidad de identificar previamente la entidad de cuya existencia depende, diremos que la entidad dbil lo es por existencia nicamente. Si la entidad dbil no puede ser identificada independientemente, sino que previamente es necesario identificar a la entidad de cuya existencia depende, diremos que la entidad dbil lo es por identificacin. El aspecto bsico para elaborar el modelo es la determinacin de entidades para lo cual se extraen de la descripcin verbal del sistema los nombres comunes y entre ellos se escogen los que claramente aporten informacin valiosa. Con el resto de nombres se utiliza el sentido comn descartando los intiles. En caso de duda, es mejor incluir una entidad que posteriormente se revele como innecesaria que perder informacin relevante al problema. Muchas veces es posible simplificar el modelo eliminando entidades innecesarias. Por EJEMPLO., si una entidad que interviene nicamente en una relacin del tipo una a una (1:1) no tiene como atributo ms que su cdigo, este atributo puede incluirse en la entidad con la que est relacionada eliminar tanto la relacin como la entidad. Caractersticas de las entidades: o o o o Debe representar objetos representativos del anlisis del problema con un nombre adecuado. No pueden existir entidades con el mismo nombre en un modelo. Deben tener ms de dos ocurrencia. Deben tener dos o ms atributos. Las entidades pueden ser:

Personas: Donde representan el rol que ocupan en el sistema a modelar. EJEMPLO: estudiante, docente, empleado, cliente... Lugares: Representan los sitios que ocupan un lugar geogrficamente. EJEMPLO: ciudad, pas, municipio... Cosas: Representan un objeto que ocupa un lugar en el espacio. EJEMPLO: carro, artculo, computador... Actividades: Representa las acciones que se realizan. EJEMPLO: profesin, compra, venta... Conceptos: Representa los documentos o elementos que se ejecutan en un sistema. EJEMPLO: descuento, factura...

Representacin grfica: Se representan grficamente mediante rectngulos y con su nombre en el interior, ste slo puede aparecer una vez en el esquema conceptual. o Entidades fuertes: se representa con un rectangulo, donde la lnea es sencilla.

Nombre_Entidad

Entidades Dbiles: se representa con un rectngulo, donde la lnea es doble.

Nombre_Entidad
Atributos: son las caractersticas de las entidades. EJEMPLO. el nombre, direccin, telfono, grado, grupo, etc. son atributos de la entidad alumno. A su vez una entidad se puede asociar o relacionar con ms entidades a travs de las relaciones. Cada uno de los atributos de una entidad posee un dominio, el que corresponde al tipo del atributo. EJEMPLO., en una universidad, "cdigo" tiene como dominio al conjunto de los enteros positivos y "nombre" tiene como dominio al conjunto de caracteres. Para todo conjunto de valores de una entidad, debe existir un atributo o combinacin de atributos, que identifique a cada entidad en forma nica. Este atributo o combinacin de atributos se denomina llave primaria. EJEMPLO., el cdigo del estudiante es una buena llave para la entidad alumno, no as el nombre, porque pueden existir dos personas con el mismo nombre. Un atributo que lgicamente pueda estar en varias entidades se ubicar finalmente en la entidad en la que sea ms fijo, es decir, en la que est ms ligado al resto de atributos de esa entidad. Por sentido comn pueden aadirse atributos que no aparezcan citados expresamente en la descripcin verbal del problema. Caractersticas de los atributos: o o Los datos almacenados en un atributo deben ser del mismo tipo. El nombre del atributo debe ser representativo con la informacin que almacena. No pueden ser sinnimos: Diferente nombre pero igual contenido. EJEMPLO: cdula e identificacin, en este caso se deja el atributo ms representativo como es identificacin. No pueden ser derivables: Se puede obtener de otro atributo que tenga la entidad. EJEMPLO: edad y fecha_nacimiento, en este caso, se deja el atributo fecha_nacimiento ya que a partir de l se puede obtener el otro, lo inverso no se puede hacer. No pueden ser homnimos: Tiene igual nombre pero contenido diferente. EJEMPLO: fecha (corresponde al ingreso) y fecha (corresponde al nacimiento), se debe colocar un nombre especfico a cada uno as: fecha_ingreso y fecha_nacimiento. No pueden ser mutuamente excluyentes: se tiene varias opciones pero solo puede tener un valor. EJEMPLO: femenino y masculino, en este caso se busca un atributo que rena a los dos como es genero.

o o

Tipos de atributos: o Segn la cardinalidad mxima del atributo (el nmero de datos almacenados), pueden ser: o Monovalorados: Almacena un solo valor. EJEMPLO: Genero. o Multivalorados: Almacena dos o ms valores. EJEMPLO: telfono (cuando se almacena ms de un nmero telefnico).

Segn el nmero de atributos que lo conforman, pueden ser: o Simples: Esta formado por un solo atributo. EJEMPLO: telfono. o Compuesta: Esta formado por dos o ms atributos. EJEMPLO: direccin, cuando esta formada por nmero, barrio y ciudad. Segn la cardinalidad mnima del atributo, pueden ser: o Opcionales: Cuando puede no almacenar dato. EJEMPLO: correo_electrnico, de un empleado y no es necesario que ellos tengan alguno. o Obligatorio: Cuando debe almacenar al menos un dato. EJEMPLO: nombre, de un estudiante y esto es necesario dentro de la entidad.

Representacin grfica de los atributos La representacin de un atributo se hace de acuerdo al tipo de atributo, hay que tener en cuenta que un atributo puede tener varias caractersticas, que cumplen con varios de los tipos propuestos anteriormente. EJEMPLO: Direccin, puede ser compuesta, y a la vez sus atributos que lo conforman pueden ser obligatorios u opcionales segn el caso. o Segn la cardinalidad mnima del atributo o Opcionales: el punto final de la lnea es un crculo vaco. Nombre_atributo o Obligatorio: el punto final de la lnea es un crculo lleno. Nombre_atributo

o Segn la cardinalidad mxima del atributo:

o

Monovalorados: No tiene ningn smbolo. Nombre_atributo

Multivalorados: Se le coloca un asterisco (*) debajo de la lnea. Nombre_atributo *

Segn el nmero de atributos que lo conforman: o Simples: No tiene ningn smbolo. Nombre_atributo o Compuesta: Se coloca un ovalo, de l parten los atributos que lo conforman. Nombre_atributo1 Nombre_atributo2 Nombre_atributo

o Llaves primarias: Se identifican como un atributo obligatorio,

atravesndole una lnea. Nombre_atributo

Relaciones: se puede definir como una asociacin entre entidades. Por EJEMPLO: la entidad "libro" puede estar relacionada con la entidad "persona" por medio de la relacin "est pedido". La entidad "alumno" puede estar relacionada con la entidad "curso" por la relacin "est inscrito". Una relacin tambin puede tener atributos. Por EJEMPLO., la relacin "est inscrito" puede tener los atributos "semestre" y "nota de aprobacin". Caractersticas de las relaciones: o o o o Deben tener sentido en el problema planteado. Tienen dos direcciones. Pueden tener atributos. Deben tener un nombre que puede ser un verbo o una frase, es conveniente usar trminos que sean claros y especficos de la relacin, no usar tiene o debe, ya que estas denominaciones no son exactas.

Tipos de Relaciones: Los tipos de relaciones a partir de diferentes aspectos como son: el nmero de registros asociados y el nmero de entidades relacionadas. o Segn el nmero de registros asociados: en este tipo se definen dos subtipos como son la cardinalidad mxima y calidad mnima. o Cardinalidad mxima: Para definir la cardinalidad es importante tener en cuenta que tiene dos direcciones la relacin y que se deben analizar por separado, para esto, se debe hacer la siguiente pregunta Un registro de la entidad1 cuntos registros tiene asociados de la entidad2? y viceversa. Uno a Uno: En este tipo de relacin, una vez fijado un elemento de una entidad se conoce la otra. Es cuando la respuesta en ambos sentidos es Uno. Uno a Muchos: En este tipo de relacin, un elemento de la entidad1 se puede relacionar con dos ms de la entidad2 y un elemento de la entidad2 se puede relacionar con uno de la entidad1. Es cuando la respuesta en un sentido es Uno y en el otro sentido es Muchos. Muchos a uno. Simetra respecto al tipo anterior segn el punto de vista de una u otra entidad. Muchos a Muchos: En este tipo de relacin, un elemento de la entidad1 se puede relacionar con dos o ms de la entidad2, y paralelamente, un elemento o atributo de la entidad2 se puede relacionar con dos o ms de la entidad1. En este caso la respuesta en ambos sentidos es Muchos. o Cardinalidad mnima: Para definir la cardinalidad es importante tener en cuenta que tiene dos direcciones la relacin y que se deben analizar por separado, para esto, se debe hacer la siguiente pregunta Un registro de la entidad1 debe tener mnimo asociado cuantos registros de la entidad2? y viceversa. Pueden existir relaciones que en ambos sentidos sean del mismo tipo o no. Opcional: cuando no tiene en algn caso asociado otro registro en la relacin. Se da cuando la respuesta de la pregunta es Ninguno.

Obligatorio: cuando debe tener al menos un registro asociado en la relacin. Se da cuando la respuesta es un valor. Segn el nmero de entidades relacionadas: existen tres tipos de relaciones unarias, binarias y n-arias. o Unarias o Recursivas: Relaciona una entidad consigo misma. EJEMPLO: empleados que pueden ser jefes de otros empleados. o Binarias: Es la ms comn, se cuando se relacionan dos entidades. o N-arias o Ternaria: Asociacin de tres o ms entidades. La forma de hallar cardinalidades en las relaciones ternarias es fijar una combinacin de elementos en dos de los extremos de la relacin y obtener lgicamente las cardinalidades mnima y mxima en el otro extremo libre. EJEMPLO: el ttulo de un libro, un autor y una editorial se relacionan las tres mediante la accin de publicar el libro (en un ao concreto, con un ISBN y con un determinado nmero de pginas en la edicin). No son comunes y se aconseja que si se pueden dividir en relaciones binarias se haga.

Extensiones de las relaciones. Por ser un modelo orientado a objetos existen dos tipos de relaciones especiales como son las siguientes:

o Generalizacin

(enfatiza semejanzas): Dos o ms entidades comparten varios atributos y/o relaciones, de donde se deduce la existencia de una entidad de nivel superior (super-tipo) que contiene los atributos y las relaciones comunes a todos los subtipos. Especializacin (enfatiza diferencias): Una entidad tiene ciertos atributos y/o relaciones que tienen sentido para unos ejemplares pero no para otros, por lo que es conveniente definir uno o varios subtipos que contengan esos atributos y/o relaciones especficas, dejando en el super-tipo los que son comunes.

Si se mira los subtipos hacia el super-tipo es una generalizacin; mientras si se identifica el super-tipo y, a partir de l, se llega a los subtipo, se trata de una especializacin. Representacin grfica de las relaciones o Segn el nmero de registros asociados. o Cardinalidad mxima

Entidad1

Uno a Uno: se representa a travs de una flecha con punta sencilla.

Nombre_relaci n

Entidad2

Uno a Muchos: la punta que donde llega la relacin a uno se coloca sencilla y la punta que llega la relacin muchos se coloca doble.
Nombre_relaci n

Entidad1

Entidad2


Entidad1

Muchos a Muchos: las puntas en ambos sentidos es doble.

Nombre_relaci n

Entidad2

o Cardinalidad mnima: puede existir relaciones que tengan en

ambos sentidos el mismo tipo de cardinalidad. Obligatorio: se representa con un punto en el rombo. Obligatorio: no se ubica ningn punto. Entidad1
No se coloca aqu ya que la entidad1 no tiene asociado ningn registro de la entidad2. Nombre_relaci n

Entidad2
Se coloca aqu ya que la entidad2 tiene asociado al menos uno de la entidad1

Segn el nmero de entidades relacionadas. o Unarias o Recursivas.

Nombre_relaci n

Entidad1

o Binarias.
Entidad1
Nombre_relaci n

Entidad2

o N-arias o Ternaria.
Nombre_relaci n

Entidad1

Entidad2

Entidad2

o Jerarquas de Generalizacin: Un tipo de entidad E es una

generalizacin de un conjunto de tipos de entidades E1,E2,...,En, llamadas de categoras de E, si cada instancia(entidad) de E1 o E2 o ... o En es tambin una instancia de E. E Super-tipo

Generalizacin

E1

E2

E3 Sub-tipos

Especializacin

EJEMPLO: Un aficionado a la msica que posee una gran discoteca de msica popular, desea crear una base de datos en la cual pueda registrar todas sus grabaciones (discos de vinilo, CDs y cintas) y obtener una serie de informaciones sobre ellos. Al analizar esta aplicacin, fue posible establecer las siguientes afirmaciones: Para cada grabacin debern constar, obligatoriamente, el cdigo del catlogo, el ttulo, el gnero, las msicas y, opcionalmente, la grabadora y el ao de grabacin. Si la grabacin es un disco de vinilo deben ser identificadas las msicas de acuerdo al lado. El cdigo del catlogo es nico para cada grabacin. Para cada disquera debern constar, obligatoriamente, un nmero de identificacin, el nombre y opcionalmente, la direccin. El nmero de identificacin es nico para cada disquera. Para cada msica debern constar, obligatoriamente, el ttulo y los compositores y, opcionalmente, el ao en que fue compuesto. Toda msica posee, por lo menos un compositor. Toda grabacin contiene grabaciones de un nico intrprete. Para cada compositor, lo mismo que para cada intrprete, debern constar, obligatoriamente, el nombre y, opcionalmente, el lugar y la fecha de nacimiento. Existen compositores que tambin son intrpretes.

Si al disear la base de datos se considera otras afirmaciones adems de las anteriores, se deben mencionar.

SOLUCIN: Para una mejor comprensin y solucin del ejercicio es bueno seguir los siguientes aspectos: Leer cuidadosamente todo el texto. Seleccionar las entidades, teniendo en cuenta las caractersticas dadas anteriormente. En el caso del ejemplo seran: Grabacin Msica Disquera Compositor Intrprete Todas las entidades son fuerte, ya que ninguna depende de otra. Indicar los atributos de cada una de las entidades. Segn el ejemplo propuesto seran: Grabacin: cdigo, ttulo, gnero, tipo (corresponde al tipo de msica), aoGrabacin Msica: ttulo, aoComposicin. Le falta un campo identificacin se le agrega cdigo. Disquera: nmero, nombre y direccin. Compositor: nombre, lugarNacimiento y fechaNacimiento. Intrprete: nombre, lugarNacimiento y fechaNacimiento. Debido que compositor ni interprete tiene un atributo identificador, se agrega cdigo.

 Identificar las relaciones entre las entidades y realizar el modelo entidadrelacin. Segn el ejemplo encontramos una Generalizacin formada por Compositor e intrprete ya que ambos son Artistas y tienen los mismos atributos. Para establecer las relaciones de asociacin se tuvo en cuenta el enunciado as: Existe una relacin de grabacin con msica, donde se debe identificar las msicas de acuerdo al lado. Se sabe que una msica esta en varias grabaciones y una grabacin esta en varias msicas. Adems una msica debe estar en una grabacin y la grabacin debe tener al menos una msica. Toda msica posee al menos un compositor, eso hace obligatoria la relacin en ese sentido, adems una msica es de varios compositores y un compositor puede tener varias msicas. El compositor registrado no necesariamente tiene una msica registrada. (Esta ltima es un supuesto, ya que el compositor puede ser intrprete). Toda grabacin contiene grabaciones de un nico intrprete, y el intrprete tiene varias grabaciones. Se supuso que el intrprete no necesariamente tiene una grabacin registrada, ya que puede ser un compositor. El modelo final quedara:
Cdigo Titulo AoComp Cdigo Titulo GneroTipo AoGra b

Lado

MUSICA

Posee Nombr e Codig LugarNac o FechaNac

GRABACIN

Compone ARTISTA

Interpreta

Grabado Direccin Nombr e

Nme ro (o)

COMPOSITOR

INTERPRETE

DISQUERA

2.3 MODELO RELACIONAL Al empezar hablar sobre modelos de datos surgi simultneamente en el momento en que Ted Codd propuso el modelo relacional de datos, despus de que los modelos jerrquico y de red estuvieran en uso. Posteriormente, estos dos modelos fueron definidos independientemente de los lenguajes y sistemas usados para implementarlos. Con anterioridad no eran ms que colecciones de estructuras de datos y lenguajes sin una teora definida. En cuanto al modelo relacional, no se puede decir que sea en s un modelo semntico de datos. Su enorme xito no se

debe a que permite de forma implcita operaciones conceptualmente abstractas sobre los datos, sino a los altos niveles de fiabilidad e integridad que aporta en el manejo de grandes cantidades de datos. Desde su comienzo en 1970 y durante mucho tiempo despus, los sistemas gestores de bases de datos relacionales (RDBMS : Relational Database Management System) estuvieron restringidos al mbito de los mainframes y mini-ordenadores. Con el surgimiento masiva en el mercado de los computadores personales, aparecieron algunas implementaciones de RDBMS que intentaban emular las propiedades de los grandes sistemas, aunque no contaban con la mayor parte de las caractersticas necesarias para ser denominados "relacionales", especialmente en lo que se refiere al cumplimiento de las reglas de integridad relacional. Hoy en da hay RDBMS para computadores personales que s son considerados totalmente relacionales y que, si bien no llegan alcanzar las prestaciones de los grandes sistemas en cuanto a velocidad de ejecucin, seguridad, integridad de datos, recuperacin y estabilidad, no tienen nada que envidiar a stos cualitativamente, y sus deficiencias se deben sobre todo al tipo de mquina en el que funcionan y a los sistemas operativos que estas mquinas utilizan. Lo que realmente marca la diferencia entre los sistemas relacionales y los sistemas anteriores es el hecho de que su creador, Ted Codd, bas expresamente su funcionamiento sobre un modelo matemtico muy especfico: el lgebra relacional y el clculo relacional, as como la progresiva adopcin, por parte de su creador y algunos colaboradores, de un nmero de Reglas de Integridad Relacional y de Formas Normales. Los lenguajes matemticos sobre los que se asienta el modelo relacional, el lgebra y el clculo relacionales, aportan un sistema de acceso y consultas orientado al conjunto. La repercusin del modelo en los DBMS comerciales actuales ha sido enorme, estando hoy en da la gran mayora de los gestores de bases de datos basados en mayor o menor medida en el modelo relacional. 2.3.1 Concepto Se puede definir el modelo relacional como un conjunto de tablas normalizadas que estn relacionadas entre s, que varan con el tiempo tanto en tamao como en valores. Es uno de los modelos de mayor aceptacin. La mayora de los SGBD, actuales son relaciones. Los objetivos de este modelo son: Independencia fsica Independencia Lgica Flexibilidad Uniformidad

Conceptos bsicos

Dominio: Es un conjunto finito de datos. Puede incluir el vaco. Los dominios que forman una relacin no son necesariamente diferentes. Instancia de una relacin: tabla con filas y columnas Conjuntos de estas instancias: extensin de la Base de Datos. Esquema de una relacin: descripcin de la tabla.

Conjuntos de estos esquemas: esquema de la Base de Datos o intensin. Clave: es el identificador del modelo ER. Valores nulos: Valor desconocido o no se aplica. Complican la manipulacin.

3.3.2 Caractersticas Basado en el concepto de relacin y en la teora de conjuntos. No existen tuplas duplicadas. El orden de las tuplas es segn el orden de almacenamiento. En la interseccin de una fila y una columna no pueden existir varios valores. Toda tabla debe tener un identificador o llave primaria. Las tablas deben estar relacionadas en un orden lgico. La redundancia es minima, y se establece para relacionar las tablas.

2.3.3 Elementos El modelo relacional esta formado por los siguientes elementos: Tablas: Es el conjunto de datos, que estn estructurados a travs de columnas. Se denominan tambin relaciones. Columnas: Son las propiedades o caractersticas de las tablas. Tuplas: Son la instancia de una entidad. Es el registro de datos de una tabla. Un esquema de tupla, t, es un conjunto de pares de la forma: t = {(A1, D1), (A2, D2),, (An, Dn)} donde: {A1, A2, , An} (n > 0) es el conjunto de nombres de atributos del esquema, necesariamente distintos. D1, D2 , Dn son los dominios asociados a dichos atributos que no tienen que ser necesariamente distintos.

Relaciones: Es la asociacin entre tablas, la cual puede ser una nueva tabla o un campo nuevo. Es el elemento ms importante del modelo. Una relacin es definida como un conjunto de tuplas sin ningn orden entre ellas (a nivel lgico). Propiedades de las relaciones:

o Grado: nmero de atributos de su esquema o Cardinalidad: nmero de tuplas que la forman o Compatibilidad: dos relaciones R y S son compatibles si sus
esquemas son idnticos. Llaves: son aquellos atributos especiales que tienen una tarea especfica as: o o Llave primaria: es el atributo o atributos que hacen que la tupla no se repita en una tabla. Slo puede existir una llave primaria por tabla. Llave candidata: es aquel atributo que cumple con las mismas propiedades de la llave primaria. EJEMPLO: la tabla estudiante, tiene dos atributos cdigo e identificacin, ambos podran ser la llave primaria, pero se debe seleccionar el atributo caracterstico de la entidad en este caso sera Cdigo y la identificacin sera una llave candidata.

Llave fornea: es aquel atributo o atributos que enlazan una tabla con otra tabla. Se llama fornea, porque viene de otra tabla. EJEMPLO: teniendo la tabla estudiante y programa, para relacionarla debe existir atributos en comn como sera en la tabla estudiante colocar el cdigo del programa (este sera la llave fornea).

2.3.4 Representacin Grfica El modelo relacional tiene diferentes representaciones, pero el caso de estudio, se tomar la que ms ha tenido aplicacin, la cual es la utilizada en las herramientas CASE, especialmente la de Oracle el DESIGNER, denominada Diagrama Entidadrelacin. Sus smbolos son los siguientes: Tablas: se representan a travs de las entidades, a travs de un rectngulo divido en dos secciones, en la primera se coloca el nombre de la tabla y en la segunda los campos o columnas que la conforman. Columnas o campos: segn las caractersticas que tengan tiene smbolos propios as: o Llave primaria: se antepone el smbolo nmero (#) al nombre del atributo. o Llave candidata: se antepone el smbolo nmero (#) entre parntesis al nombre del atributo. o Campo Obligatorio: se antepone el smbolo asterisco (*) al nombre del atributo. o Campo Opcional: se antepone la o al nombre del atributo. A diferencia del modelo entidad-relacin no existen atributos multivaluados, ni atributos compuestos. Relaciones: segn la cardinalidad de la relacin tiene su simbologa as: o Cardinalidad mxima: Muchos: se coloca la patica de gallina a la tabla que le llega la relacin a muchos. ( ). Uno: se coloca la lnea sencilla a la tabla que le llega la relacin a uno. ( ). o Cardinalidad mnima: Obligatoria: la lnea es continua. Opcional: la lnea es discontinua. Existen los mismos tipos de relaciones del modelo entidad-relacin, excepto, la relacin muchos a muchos. 2.3.5. Conversin del Modelo Entidad-Relacin a Modelo Relacional Para convertir el modelo entidad-relacin a relacional seguir los siguientes tems:

Empezar por las entidades que solo le lleguen relaciones a UNO. Campos Compuestos: se crea los atributos que estn formando el atributo compuesto. EJEMPLO: Direccin formado por nmero y barrio, para este caso se crea dir_numero y dir_barrio, con la caracterstica que tenga cada uno (Obligatorio u opcional). Campos Multivaluados: se crea una nueva tabla formada por el campo multivaluado, la llave primaria de la tabla de donde viene (la cual ser la

llave fornea) y se agrega un campo adicional que ser la llave primaria de la nueva tabla. Adems se establece la relacin entre las tablas teniendo en cuenta que si el atributo es obligatorio, la relacin es totalmente obligatoria, pero si el atributo es opcional, la relacin es opcional la primera parte de la relacin es opcional (la que sale de la tabla inicial) y la segunda parte obligatoria (la que llega a la tabla nueva). Generalizacin: se crean las tablas que forman la generalizacin con los campos de la entidad padre y los de cada una de ellas. Relaciones Uno a Uno: se coloca un nuevo campo en cualquiera de las dos tablas relacionadas, teniendo en cuenta colocarla en aquella donde la relacin sea obligatoria (ya que se aconseja que la mayora de los campos sean obligatorios, para aprovechar el espacio asignado), este campo es igual al tipo de dato y tamao de la llave primaria de donde viene la relacin, el cual ser nico y si es obligatorio tambin, este ser la llave fornea de la relacin. La lnea de enlace de las tablas ser continua o discontinua segn la obligatoriedad de la relacin y los extremos sern lneas sencillas. Relaciones Muchos a Uno / Uno a Muchos: se coloca un nuevo campo en la tabla donde llega la relacin a muchos, este campo es igual al tipo de dato y tamao de la llave primaria de donde viene la relacin, ser obligatorio u opcional dependiendo si la relacin de llegada es obligatoria o no. La lnea de enlace se representar continua o discontinua segn la obligatoriedad de la relacin, el extremo donde llega el muchos ser la patica de gallina y el otro extremo ser lnea continua. Relaciones Muchos a Muchos: debido a que no existe este tipo de relacin, se debe romper, creando una nueva tabla formada por las llaves primarias de las tablas relacionadas (siempre sern obligatorias). Si la combinacin de las llaves sus tuplas no se repiten formarn la llave primaria de la nueva tabla, de lo contrario, se debe crear un nuevo campo que ser la llave primaria de la nueva tabla. La lnea de enlace a la nueva tabla siempre es obligatoria en la llegada a la nueva tabla y la otra parte de la lnea depende de la obligatoriedad de la relacin. El extremo de la lnea que llega a la tabla nueva ser la patica de gallina y el otro la lnea sencilla. Atributos en la relacin. Se colocarn los atributos en la tabla donde se coloca la llave fornea, con las caractersticas que tenga.

EJEMPLO: Tomando como referencia el ejemplo propuesto en el punto 2.2.3, el cual se convertir a modelo relacional utilizando la notacin grfica de la herramienta case de Oracle, quedar as: Se empieza por la entidad Disquera o por interprete, ya que ha ambas le llegan relaciones a uno solamente. GRABACIN DISQUERA podra seguir por las dems entidades, Cdigo sus relaciones son Luego se # ya que muchos una tabla intermedia. # Nmero a muchos, y ellas exigen la creacin de * Titulo Por ltimo se crean las tablas intermedias deGnero * Nombre * las relaciones muchos a muchos. o Direccin * Tipo INTERPRETE # Cdigo * Nombre o LugarNacimento o FechaNacimiento * AoGrabacin o NmeroDisquera * CdigoInterprete GRABACINMUSICA # CdigoMsica # CdigoGrabacin o Lado COMPOSITORMUSICA # CdigoMsica # CdigoCompositor

COMPOSITOR # Cdigo * Nombre o LugarNacimento o FechaNacimiento

MSICA # Cdigo * Titulo * AoComposicin

Nota: En el caso anterior las llaves primarias de las tablas intermedias son las mismas llaves forneas ya que en ambos casos no se repite su combinacin (Una msica en una grabacin esta una sola vez, y una msica con un compositor es nico). Adems el atributo lado se coloca en la tabla de la relacin. Recordar que las lneas discontinuas indican relaciones opcionales (de compositor a compositorMusica, de interprete a grabacin y por ltimo, de grabacin a disquera) y las lneas continuas relaciones obligatorias.