Bases de Datos y Sistemas de Información Del MER al MR - Pedeciba
Bases de Datos y Sistemas de Información Del MER al MR - Pedeciba
Bases de Datos y Sistemas de Información Del MER al MR - Pedeciba
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Maestría en Bioinformática<br />
<strong>Bases</strong> <strong>de</strong> <strong>Datos</strong> y <strong>Sistemas</strong> <strong>de</strong> Información<br />
<strong>Del</strong> <strong>MER</strong> <strong>al</strong> <strong>MR</strong><br />
Ing. Alfonso Vicente, PMP<br />
<strong>al</strong>fonso.vicente@logos.com.uy
Agenda<br />
Conceptos<br />
<strong>MER</strong> a <strong>MR</strong><br />
‣ Introducción
Agenda<br />
Conceptos<br />
<strong>MER</strong> a <strong>MR</strong><br />
‣ Entida<strong>de</strong>s fuertes<br />
‣ Discusión<br />
‣ Entida<strong>de</strong>s débiles<br />
‣ Relaciones binarias<br />
‣ Relaciones n-arias<br />
‣ Gener<strong>al</strong>ización / Especi<strong>al</strong>ización
Agenda<br />
Conceptos<br />
<strong>MER</strong> a <strong>MR</strong><br />
‣ Introducción
Conceptos<br />
Introducción<br />
• Necesitamos <strong>de</strong>sarrollar una aplicación para satisfacer<br />
<strong>de</strong>terminados requerimientos<br />
• Por la natur<strong>al</strong>eza <strong>de</strong>l problema la aplicación se beneficiaría<br />
<strong>de</strong> utilizar un RDBMS<br />
• Sabemos cómo re<strong>al</strong>izar un mo<strong>de</strong>lo conceptu<strong>al</strong> a partir <strong>de</strong> los<br />
requerimientos, utilizando el <strong>MER</strong><br />
• Conocemos el Mo<strong>de</strong>lo Relacion<strong>al</strong>, un mo<strong>de</strong>lo lógico más<br />
cercano a la implementación <strong>de</strong> una Base <strong>de</strong> <strong>Datos</strong>
Conceptos<br />
Introducción<br />
• El paso lógico siguiente sería pasar <strong>de</strong>l <strong>MER</strong> <strong>al</strong> <strong>MR</strong><br />
Relevamiento Mo<strong>de</strong>lado conceptu<strong>al</strong> ???<br />
Requerimientos <strong>MER</strong> <strong>MR</strong><br />
• Necesitamos un <strong>al</strong>goritmo para hacer esto<br />
• Hay software que permite pasar <strong>de</strong>l <strong>MER</strong> <strong>al</strong> <strong>MR</strong> <strong>de</strong> forma<br />
semi-automática (como brMo<strong>de</strong>lo), pero es necesario<br />
compren<strong>de</strong>r el proceso<br />
• ¿Nos podríamos s<strong>al</strong>tear el diseño conceptu<strong>al</strong> y re<strong>al</strong>izar<br />
directamente el diseño lógico?
Agenda<br />
Conceptos<br />
<strong>MER</strong> a <strong>MR</strong><br />
‣ Entida<strong>de</strong>s fuertes<br />
‣ Discusión<br />
‣ Entida<strong>de</strong>s débiles<br />
‣ Relaciones binarias<br />
‣ Relaciones n-arias<br />
‣ Gener<strong>al</strong>ización / Especi<strong>al</strong>ización
<strong>MER</strong> a <strong>MR</strong><br />
Entida<strong>de</strong>s fuertes<br />
• Ejemplo: entidad CLIENTE, con atributos simples,<br />
multiv<strong>al</strong>orados, estructurados y <strong>de</strong>terminantes<br />
• Necesitamos traducir esta entidad fuerte <strong>al</strong> <strong>MR</strong>
<strong>MER</strong> a <strong>MR</strong><br />
Entida<strong>de</strong>s fuertes<br />
• Crearemos una relación por cada entidad fuerte <strong>de</strong>l <strong>MER</strong>,<br />
con el mismo nombre pero en plur<strong>al</strong><br />
• Crearemos una columna en la relación por cada atributo<br />
simple <strong>de</strong>l <strong>MER</strong>, con el mismo nombre<br />
• Crearemos una columna en la relación por cada hoja en la<br />
estructura <strong>de</strong> los atributos estructurados<br />
• Se especificarán claves correspondientes a cada conjunto<br />
<strong>de</strong> atributos <strong>de</strong>terminantes, y una <strong>de</strong> ellas se elegirá<br />
(arbitrariamente, por ahora) como PK (Primary Key)
<strong>MER</strong> a <strong>MR</strong><br />
Entida<strong>de</strong>s fuertes<br />
• Para los atributos multiv<strong>al</strong>uados:<br />
• Se creará una nueva relación con una columna<br />
correspondiente <strong>al</strong> atributo multiv<strong>al</strong>uado<br />
• Se agregarán las columnas correspondientes a la clave<br />
primaria <strong>de</strong> la relación que correspon<strong>de</strong> a la entidad<br />
fuerte, que serán una clave foránea<br />
• Se especificará a<strong>de</strong>más el conjunto <strong>de</strong> todas las<br />
columnas <strong>de</strong> la relación como una clave
<strong>MER</strong> a <strong>MR</strong><br />
Entida<strong>de</strong>s fuertes<br />
• La entidad <strong>de</strong>l ejemplo, podría traducirse <strong>al</strong> <strong>MR</strong> así:
<strong>MER</strong> a <strong>MR</strong><br />
Entida<strong>de</strong>s fuertes<br />
• Se podría especificar, para cada columna, el tipo <strong>de</strong> datos y<br />
si admite o no el v<strong>al</strong>or NULL.<br />
• Suele representarse subrayada la PK <strong>de</strong> cada relación.<br />
• Las FKs suelen representarse como una línea entre las<br />
relaciones participantes, terminada con el “crow’s foot” <strong>de</strong>l<br />
lado <strong>de</strong> la relación que tiene la FK.<br />
• Más <strong>al</strong>lá <strong>de</strong> las posibilida<strong>de</strong>s <strong>de</strong> notación <strong>de</strong> los diagramas<br />
<strong>de</strong> Mo<strong>de</strong>lo Relacion<strong>al</strong>, conviene tomar nota <strong>de</strong> las claves y<br />
claves foráneas <strong>al</strong> pie <strong>de</strong>l diagrama.
<strong>MER</strong> a <strong>MR</strong><br />
Discusión<br />
• ¿Qué hubiera pasado si la entidad CLIENTE hubiera tenido<br />
otro atributo <strong>de</strong>terminante, por ejemplo: cre<strong>de</strong>nci<strong>al</strong>?<br />
• Los dos hubieran constituido claves <strong>de</strong> la relación<br />
CLIENTES, <strong>de</strong> forma que hubiéramos tenido que elegir una<br />
<strong>de</strong> las dos claves para mantener en la relación<br />
TELEFONOS_CLIENTE.
<strong>MER</strong> a <strong>MR</strong><br />
Discusión<br />
• Cuando haya más <strong>de</strong> una clave candidata, las<br />
distinguiremos en dos tipos, una será la PRIMARY KEY, y<br />
elegiremos para esto una <strong>de</strong> las claves que no admita<br />
v<strong>al</strong>ores nulos.<br />
• A las claves restantes, admitan o no v<strong>al</strong>ores nulos, las<br />
llamaremos UNIQUE KEYS.<br />
• En nuestro ejemplo, si hubiéramos tenido un atributo<br />
<strong>de</strong>terminante cre<strong>de</strong>nci<strong>al</strong>, pero admitiera v<strong>al</strong>ores nulos, la<br />
columna cedula seguiría siendo la PRIMARY KEY, mientras<br />
que cre<strong>de</strong>nci<strong>al</strong> sería una UNIQUE KEY.
<strong>MER</strong> a <strong>MR</strong><br />
Discusión<br />
• En ocasiones, una entidad no tiene una clave candidata<br />
claramente i<strong>de</strong>ntificable, o bien tiene una compuesta <strong>de</strong><br />
muchos atributos, y ya sabemos que la PK <strong>de</strong> una relación<br />
se “propaga”, por ejemplo cuando hay atributos<br />
multiv<strong>al</strong>uados.<br />
• Para estos casos pue<strong>de</strong> convenir “inventar” una clave para<br />
que funcione como PK. A esto lo llamaremos surrogate key.<br />
• Al no tener semántica, una surrogate key podría ser<br />
generada automáticamente por cu<strong>al</strong>quier método que<br />
asegure la unicidad (por ejemplo un número secuenci<strong>al</strong>)
<strong>MER</strong> a <strong>MR</strong><br />
Discusión<br />
• Para ilustrar el concepto <strong>de</strong> surrogate key, veremos una<br />
<strong>de</strong>bilidad <strong>de</strong>l Mo<strong>de</strong>lo Relacion<strong>al</strong> que hemos generado,<br />
observando una instancia <strong>de</strong> la relación CLIENTES.<br />
• ¿Qué problemas tiene esa instancia?<br />
• ¿Cómo podríamos solucionar esos problemas?
<strong>MER</strong> a <strong>MR</strong><br />
Discusión<br />
• Pue<strong>de</strong>n existir v<strong>al</strong>ores para <strong>de</strong>partamento que no<br />
correspon<strong>de</strong>n a un <strong>de</strong>partamento (San Gregorio), v<strong>al</strong>ores<br />
para ciudad que no correspon<strong>de</strong>n a una ciudad (<strong>de</strong><br />
Polanco), y combinaciones incorrectas <strong>de</strong> <strong>de</strong>partamento y<br />
ciudad (no existe una ciudad La P<strong>al</strong>oma en Lav<strong>al</strong>leja).<br />
• Para solucionar el problema <strong>de</strong> los datos inexistentes,<br />
observamos que el problema radica en que los nombres <strong>de</strong><br />
<strong>de</strong>partamentos y ciuda<strong>de</strong>s <strong>de</strong>ben pertenecer a un dominio<br />
mucho más reducido que el conjunto VARCHAR(30), por<br />
ejemplo.
<strong>MER</strong> a <strong>MR</strong><br />
Discusión<br />
• Podríamos pensar en mantener el conjunto <strong>de</strong> los nombres<br />
válidos <strong>de</strong> <strong>de</strong>partamento, en una relación con una única<br />
columna; y lo mismo para ciuda<strong>de</strong>s. En cada caso, la única<br />
columna <strong>de</strong> la relación constituirá la Primary Key <strong>de</strong> la<br />
misma.
<strong>MER</strong> a <strong>MR</strong><br />
Discusión<br />
• Teniendo <strong>de</strong>finidas estas relaciones y especificando Foreign<br />
Keys como las siguientes en la relación CLIENTES,<br />
solucionamos el problema <strong>de</strong> los <strong>de</strong>partamentos y ciuda<strong>de</strong>s<br />
inexistentes:<br />
• {<strong>de</strong>partamento} es FK en CLIENTES, y referencia a<br />
nombre en DEPARTAMENTOS<br />
• {ciudad} es FK en CLIENTES, y referencia a nombre en<br />
CIUDADES
<strong>MER</strong> a <strong>MR</strong><br />
Discusión<br />
• Parecería que la elección <strong>de</strong> la clave primaria en<br />
DEPARTAMENTOS y CIUDADES era la única posible, pero<br />
en estos casos, suelen utilizarse surrogate keys,<br />
“inventando” una columna con un código para cada uno <strong>de</strong><br />
los v<strong>al</strong>ores <strong>de</strong>l dominio:
Discusión<br />
<strong>MER</strong> a <strong>MR</strong>
<strong>MER</strong> a <strong>MR</strong><br />
Discusión<br />
• Note que el <strong>MER</strong> no teníamos una entidad<br />
DEPARTAMENTO ni una entidad CIUDAD, sino que<br />
agregamos estas relaciones <strong>al</strong> Mo<strong>de</strong>lo Relacion<strong>al</strong> para<br />
solucionar el problema <strong>de</strong> restringir los dominios <strong>de</strong> <strong>al</strong>gunas<br />
columnas.<br />
• Estas relaciones especi<strong>al</strong>es con códigos y v<strong>al</strong>ores formando<br />
un dominio, se conocen muchas veces como “codigueras”.<br />
• ¿Qué ganamos <strong>al</strong> agregar la surrogate key codigo en las<br />
nuevas relaciones?
<strong>MER</strong> a <strong>MR</strong><br />
Discusión<br />
• Por lo pronto: espacio<br />
• Imagine que para <strong>al</strong>macenar el nombre <strong>de</strong> una ciudad como<br />
“San Gregorio <strong>de</strong> Polanco” se necesitan 25 bytes (uno por<br />
cada carácter más dos para <strong>de</strong>limitar el fin <strong>de</strong> la ca<strong>de</strong>na).<br />
• Si tenemos 1.000 clientes <strong>de</strong> San Gregorio <strong>de</strong> Polanco<br />
tendremos 25.000 bytes en la tabla CLIENTES <strong>de</strong>dicados a<br />
mantener esta información. Si po<strong>de</strong>mos tener un código<br />
entero <strong>de</strong> 4 bytes para cada ciudad, ocuparemos 4.000<br />
bytes en la tabla CLIENTES en lugar <strong>de</strong> 25.000 para<br />
mantener la misma información.
<strong>MER</strong> a <strong>MR</strong><br />
Discusión<br />
• En gener<strong>al</strong> as codigueras son elementos agregados en el<br />
Mo<strong>de</strong>lo Relacion<strong>al</strong>, porque es difícil que el <strong>MER</strong> se haya<br />
consi<strong>de</strong>rado una restricción no estructur<strong>al</strong> <strong>de</strong>l tipo “El<br />
atributo <strong>de</strong>partamento <strong>de</strong> la entidad CLIENTE <strong>de</strong>be ser uno<br />
<strong>de</strong> los siguientes: Montevi<strong>de</strong>o, Canelones, …”; aunque es<br />
válido que existan este tipo <strong>de</strong> restricciones.<br />
• Las codigueras son muy comunes, y se pue<strong>de</strong>n consi<strong>de</strong>rar<br />
como un patrón <strong>de</strong> diseño<br />
• [2 min] ¿Cómo evitamos las “m<strong>al</strong>as combinaciones”, como:<br />
La P<strong>al</strong>oma - Lav<strong>al</strong>leja?
<strong>MER</strong> a <strong>MR</strong><br />
Entida<strong>de</strong>s débiles<br />
• Consi<strong>de</strong>remos, por ejemplo, la entidad débil SALON (débil<br />
respecto a CENTRO).<br />
• La entidad fuerte CENTRO, se mapearía a una relación<br />
CENTROS, con dos columnas: nombre (que será su PK) y<br />
dirección
<strong>MER</strong> a <strong>MR</strong><br />
Entida<strong>de</strong>s débiles<br />
• La entidad débil SALON, se mapearía a una relación<br />
SALONES, que tendría columnas numero (la clave parci<strong>al</strong><br />
<strong>de</strong> la entidad débil) y capacidad.<br />
• Pero las entida<strong>de</strong>s débiles no tienen por sí mismas datos<br />
suficientes como para po<strong>de</strong>r ser i<strong>de</strong>ntificadas, por lo que<br />
<strong>de</strong>pen<strong>de</strong>n <strong>de</strong> otra, y más específicamente <strong>de</strong>pen<strong>de</strong>n <strong>de</strong> la<br />
clave <strong>de</strong> esa otra entidad para po<strong>de</strong>r ser i<strong>de</strong>ntificadas.<br />
• Por este motivo, la clave <strong>de</strong> la relación CENTROS se<br />
propagará a la relación SALONES, y será una Foreign Key<br />
en SALONES
<strong>MER</strong> a <strong>MR</strong><br />
Entida<strong>de</strong>s débiles<br />
• Éste es un ejemplo <strong>de</strong> cómo quedaría el <strong>MR</strong><br />
• El atributo nombre <strong>de</strong> la entidad CENTRO se cambió a<br />
nom_centro, ya que por ser la PK <strong>de</strong> CENTROS, <strong>de</strong>bía<br />
propagarse a SALONES.
<strong>MER</strong> a <strong>MR</strong><br />
Entida<strong>de</strong>s débiles<br />
• El <strong>al</strong>goritmo entonces para traducir una entidad débil <strong>al</strong><br />
Mo<strong>de</strong>lo Relacion<strong>al</strong>, una vez que se representó la entidad <strong>de</strong><br />
la que <strong>de</strong>pen<strong>de</strong>, podría ser el siguiente:<br />
• Crear una relación con el mismo nombre pero en plur<strong>al</strong><br />
• Crear una columna en la relación por cada atributo<br />
simple, con el mismo nombre<br />
• Agregar las columnas que formen la PK <strong>de</strong> la relación<br />
correspondiente a la entidad <strong>de</strong> la que <strong>de</strong>pen<strong>de</strong>.
<strong>MER</strong> a <strong>MR</strong><br />
Entida<strong>de</strong>s débiles<br />
• Especificar como PK las columnas que sean PK <strong>de</strong> la<br />
relación correspondiente a la entidad <strong>de</strong> la que ésta<br />
<strong>de</strong>pen<strong>de</strong>, más las columnas que forman la clave parci<strong>al</strong><br />
<strong>de</strong> la entidad débil.<br />
• Especificar como FK las columnas que sean PK <strong>de</strong> la<br />
relación correspondiente a la entidad <strong>de</strong> la que ésta<br />
<strong>de</strong>pen<strong>de</strong>.<br />
• Si la entidad débil tiene atributos multiv<strong>al</strong>uados o<br />
estructurados, traducirlos <strong>de</strong> la misma manera que en el<br />
caso <strong>de</strong> las entida<strong>de</strong>s fuertes.
<strong>MER</strong> a <strong>MR</strong><br />
Relaciones binarias<br />
• Consi<strong>de</strong>raremos tres tipos <strong>de</strong> relaciones, según su<br />
cardin<strong>al</strong>idad (1:1, 1:N y N:M)<br />
• En el caso <strong>de</strong> la entidad débil, ya hicimos la traducción <strong>de</strong><br />
una relación 1:N<br />
• La forma <strong>de</strong> traducir una relación 1:N sirve para una relación<br />
1:1, aunque también hay otras opciones
<strong>MER</strong> a <strong>MR</strong><br />
Relaciones binarias<br />
• Cuando tenemos relaciones 1:N :<br />
• Agregaremos en la tabla <strong>de</strong>l lado <strong>de</strong> la cardin<strong>al</strong>idad N <strong>de</strong><br />
la relación, la PK <strong>de</strong> la otra tabla (que será FK) y las<br />
columnas que correspondan a atributos <strong>de</strong> la relación.<br />
• La PK se propaga
<strong>MER</strong> a <strong>MR</strong><br />
Relaciones binarias<br />
• El Mo<strong>de</strong>lo Relacion<strong>al</strong> podría quedar:<br />
• ¿Podría haber libretas sin chofer asociado? ¿Cómo<br />
po<strong>de</strong>mos asegurarnos?
<strong>MER</strong> a <strong>MR</strong><br />
Relaciones binarias<br />
• Cuando tenemos relaciones N:M<br />
• Crearemos una nueva tabla para representar la relación,<br />
agregando la PK <strong>de</strong> cada una <strong>de</strong> las tablas, a<strong>de</strong>más <strong>de</strong><br />
las columnas que correspondan a atributos <strong>de</strong> la relación<br />
• La PK <strong>de</strong> la nueva tabla será la combinación <strong>de</strong> las PK<br />
<strong>de</strong> las tablas que participan en la relación<br />
• Se <strong>de</strong>ben especificar como FK, las PK <strong>de</strong> las tablas que<br />
participan en la relación
<strong>MER</strong> a <strong>MR</strong><br />
Relaciones binarias<br />
• Si tenemos, por ejemplo, que un chofer pue<strong>de</strong> conducir<br />
varios vehículos, y un vehículo pue<strong>de</strong> ser conducido por<br />
varios choferes, el <strong>MER</strong> podría ser el siguiente
<strong>MER</strong> a <strong>MR</strong><br />
Relaciones binarias<br />
• Y el Mo<strong>de</strong>lo Relacion<strong>al</strong>:<br />
• También se podría utilizar para relaciones 1:N ¿con qué PK?
<strong>MER</strong> a <strong>MR</strong><br />
Relaciones binarias<br />
• Relaciones 1:1<br />
• Consi<strong>de</strong>remos el <strong>MER</strong> que preten<strong>de</strong> mo<strong>de</strong>lar la siguiente<br />
re<strong>al</strong>idad:<br />
Cada chofer se i<strong>de</strong>ntifica por su cédula, y se mantiene su<br />
nombre y apellido. Se <strong>de</strong>sea registrar la libreta <strong>de</strong> cada<br />
chofer, que se i<strong>de</strong>ntifica por un número, y tiene una fecha <strong>de</strong><br />
emisión y una fecha <strong>de</strong> vencimiento. Es <strong>de</strong> interés llevar un<br />
registro <strong>de</strong> dón<strong>de</strong> suele tener cada chofer su libreta<br />
(billetera, guantera <strong>de</strong>l vehículo, etc.).
<strong>MER</strong> a <strong>MR</strong><br />
Relaciones binarias<br />
• El <strong>MER</strong> podría ser:<br />
• En este caso observamos que la relación es tot<strong>al</strong> <strong>de</strong>l lado <strong>de</strong><br />
LIBRETA. Esto significa que no es posible tener una libreta<br />
que no tenga asociado un chofer.
<strong>MER</strong> a <strong>MR</strong><br />
Relaciones binarias<br />
• Supongamos que ya se tradujeron las entida<strong>de</strong>s fuertes:<br />
• Po<strong>de</strong>mos agregar en la tabla con participación tot<strong>al</strong>, las<br />
columnas que correspondan a la PK <strong>de</strong> la otra tabla y<br />
columnas para los atributos <strong>de</strong> la relación (si los hay).
<strong>MER</strong> a <strong>MR</strong><br />
Relaciones binarias<br />
• ¿Podríamos haberlo hecho <strong>al</strong> revés?
<strong>MER</strong> a <strong>MR</strong><br />
Relaciones binarias<br />
• Otra opción, sería fundir las tablas, manteniendo la PK <strong>de</strong> la<br />
tabla que no tiene participación tot<strong>al</strong>, y <strong>de</strong>jando la PK <strong>de</strong> la<br />
tabla que tiene participación tot<strong>al</strong> como UK.<br />
• Note que esta opción<br />
implica que se <strong>de</strong>ban<br />
permitir v<strong>al</strong>ores nulos<br />
• Podríamos tener v<strong>al</strong>ores no<br />
nulos para las fechas <strong>de</strong><br />
emisión y vencimiento, y no<br />
tener un número <strong>de</strong> libreta
<strong>MER</strong> a <strong>MR</strong><br />
Relaciones binarias<br />
• Cuando no hay ninguna tabla con participación tot<strong>al</strong> se<br />
pue<strong>de</strong> elegir arbitrariamente una <strong>de</strong> las tablas para agregar<br />
en ella la PK <strong>de</strong> la otra, y <strong>de</strong>finirla como FK, a<strong>de</strong>más <strong>de</strong> las<br />
columnas que correpon<strong>de</strong>n a atributos <strong>de</strong> la relación (igu<strong>al</strong> a<br />
cuando había una tabla con participación tot<strong>al</strong>), aunque se<br />
<strong>de</strong>be consi<strong>de</strong>rar en este caso que los v<strong>al</strong>ores pue<strong>de</strong>n ser<br />
nulos.<br />
• Otra opción es crear una tabla para la relación, que<br />
mantenga las PK <strong>de</strong> las dos tablas a<strong>de</strong>más <strong>de</strong> las columnas<br />
que correspon<strong>de</strong>n a atributos <strong>de</strong> la relación (como en N:N)
<strong>MER</strong> a <strong>MR</strong><br />
Relaciones binarias<br />
• En resumen, las posibilida<strong>de</strong>s son<br />
Nueva tabla Propagar PK Unificar<br />
1:1 SI SI * SI * +<br />
1:N SI SI *<br />
N:N<br />
SI<br />
(*) Cuidado con los NULL si no hay tot<strong>al</strong>idad<br />
( + ) Cuidado <strong>al</strong> elegir la PK<br />
• Es un buen momento para preguntarse si no podría haber<br />
un cambio <strong>de</strong> requerimientos que <strong>de</strong>termine un cambio en la<br />
cardin<strong>al</strong>idad (e.g. <strong>de</strong> una libreta por chofer a más <strong>de</strong> una, <strong>de</strong><br />
autos no-compartidos a compartidos)
Relaciones n-arias (n > 2)<br />
<strong>MER</strong> a <strong>MR</strong><br />
• Siempre se creará una nueva tabla<br />
• Su clave será la unión <strong>de</strong> las claves <strong>de</strong> las entida<strong>de</strong>s<br />
participantes <strong>de</strong> la relación (la excepción es cuando hay<br />
una cardin<strong>al</strong>idad 1, en ese caso, la clave será la que<br />
correspon<strong>de</strong> a la entidad <strong>de</strong>l lado <strong>de</strong> la cardin<strong>al</strong>idad 1)<br />
• Se <strong>de</strong>finirán las correspondientes claves foráneas<br />
• Sus agregarán los atributos <strong>de</strong> la relación, si los hubiera
<strong>MER</strong> a <strong>MR</strong><br />
Agregación<br />
• Se traduce primero la relación interna <strong>de</strong> la agregación, lo<br />
que dará lugar a una tabla T cuya PK permita i<strong>de</strong>ntificar las<br />
instancias <strong>de</strong> la relación (sea una nueva tabla, una <strong>de</strong> las ya<br />
existentes en la que se propagó la PK <strong>de</strong> la otra o una<br />
unificación)<br />
• Luego se traduce la relación <strong>de</strong> la que participa la<br />
agregación, consi<strong>de</strong>rando que participa con T
<strong>MER</strong> a <strong>MR</strong><br />
Gener<strong>al</strong>ización / especi<strong>al</strong>ización<br />
• Tenemos varias opciones para transformar una<br />
gener<strong>al</strong>ización
<strong>MER</strong> a <strong>MR</strong><br />
Gener<strong>al</strong>ización / especi<strong>al</strong>ización<br />
• Opción 1<br />
• Creamos una tabla para la entidad más gener<strong>al</strong>, como si<br />
fuera una entidad fuerte cu<strong>al</strong>quiera<br />
• Creamos una tabla para cada sub-entidad, con sus<br />
atributos, y propagamos la PK <strong>de</strong> la entidad más gener<strong>al</strong><br />
• Definimos las FKs <strong>de</strong>s<strong>de</strong> las PKs <strong>de</strong> éstas últimas tablas,<br />
a la PK <strong>de</strong> la tabla que correspon<strong>de</strong> a la entidad más<br />
gener<strong>al</strong>
<strong>MER</strong> a <strong>MR</strong><br />
Gener<strong>al</strong>ización / especi<strong>al</strong>ización<br />
• Opción 1<br />
FK1: Estudiantes(cedula) references Personas(cedula)<br />
FK2: Docentes(cedula) references Personas(cedula)
<strong>MER</strong> a <strong>MR</strong><br />
Gener<strong>al</strong>ización / especi<strong>al</strong>ización<br />
• Opción 2<br />
• Crear una tabla por cada sub-entidad, con sus atributos<br />
más los atributos <strong>de</strong> la entidad más gener<strong>al</strong><br />
• ¿Qué suce<strong>de</strong> si un docente<br />
es también estudiante?<br />
• ¿Qué suce<strong>de</strong> si un docente<br />
no pue<strong>de</strong> ser estudiante?<br />
• ¿Reporte <strong>de</strong> direcciones?
<strong>MER</strong> a <strong>MR</strong><br />
Gener<strong>al</strong>ización / especi<strong>al</strong>ización<br />
• Opción 3<br />
• Crear una sola tabla con todos los atributos<br />
(los <strong>de</strong> la entidad más gener<strong>al</strong> y los <strong>de</strong> las<br />
subentida<strong>de</strong>s) más un atributo “tipo” que<br />
permita diferenciar las sub-entida<strong>de</strong>s<br />
• Sólo para sub-entida<strong>de</strong>s disjuntas<br />
CHECK: tipo in (‘Docente’, ‘Estudiante’)
<strong>MER</strong> a <strong>MR</strong><br />
Gener<strong>al</strong>ización / especi<strong>al</strong>ización<br />
• Opción 4<br />
• Crear una sola tabla con todos los atributos<br />
(los <strong>de</strong> la entidad más gener<strong>al</strong> y los <strong>de</strong> las<br />
subentida<strong>de</strong>s) más un atributo “es_X” por<br />
cada sub-entidad X<br />
• Permite sub-entida<strong>de</strong>s no disjuntas