Guía del MER al MR Ing. Alfonso Vicente

1. Maestría en Bioinformática
Bases de Datos y Sistemas de Información
Del MER al MR
Ing. Alfonso Vicente, PMP
alfonso.vicente@logos.com.uy

2. Agenda
 IntroducciónConceptos
MER a MR

3. Agenda
 Entidades fuertes
 Discusión
 Entidades débiles
 Relaciones binarias
 Relaciones n-arias
 Generalización / Especialización
Conceptos
MER a MR

4. Agenda
 IntroducciónConceptos
MER a MR

5. Conceptos
Introducción
• Necesitamos desarrollar una aplicación para satisfacer
determinados requerimientos
• Por la naturaleza del problema la aplicación se beneficiaría
de utilizar un RDBMS
• Sabemos cómo realizar un modelo conceptual a partir de los
requerimientos, utilizando el MER
• Conocemos el Modelo Relacional, un modelo lógico más
cercano a la implementación de una Base de Datos

6. Conceptos
Introducción
• El paso lógico siguiente sería pasar del MER al MR
Relevamiento Modelado conceptual ???
• Necesitamos un algoritmo para hacer esto
• Hay software que permite pasar del MER al MR de forma
semi-automática (como brModelo), pero es necesario
comprender el proceso
• ¿Nos podríamos saltear el diseño conceptual y realizar
directamente el diseño lógico?
Requerimientos MER MR

7. Agenda
 Entidades fuertes
 Discusión
 Entidades débiles
 Relaciones binarias
 Relaciones n-arias
 Generalización / Especialización
Conceptos
MER a MR

8. MER a MR
Entidades fuertes
• Ejemplo: entidad CLIENTE, con atributos simples,
multivalorados, estructurados y determinantes
• Necesitamos traducir esta entidad fuerte al MR

9. MER a MR
Entidades fuertes
• Crearemos una relación por cada entidad fuerte del MER,
con el mismo nombre pero en plural
• Crearemos una columna en la relación por cada atributo
simple del MER, con el mismo nombre
• Crearemos una columna en la relación por cada hoja en la
estructura de los atributos estructurados
• Se especificarán claves correspondientes a cada conjunto
de atributos determinantes, y una de ellas se elegirá
(arbitrariamente, por ahora) como PK (Primary Key)

10. MER a MR
Entidades fuertes
• Para los atributos multivaluados:
• Se creará una nueva relación con una columna
correspondiente al atributo multivaluado
• Se agregarán las columnas correspondientes a la clave
primaria de la relación que corresponde a la entidad
fuerte, que serán una clave foránea
• Se especificará además el conjunto de todas las
columnas de la relación como una clave

11. MER a MR
Entidades fuertes
• La entidad del ejemplo, podría traducirse al MR así:

12. MER a MR
Entidades fuertes
• Se podría especificar, para cada columna, el tipo de datos y
si admite o no el valor NULL.
• Suele representarse subrayada la PK de cada relación.
• Las FKs suelen representarse como una línea entre las
relaciones participantes, terminada con el “crow’s foot” del
lado de la relación que tiene la FK.
• Más allá de las posibilidades de notación de los diagramas
de Modelo Relacional, conviene tomar nota de las claves y
claves foráneas al pie del diagrama.

13. MER a MR
Discusión
• ¿Qué hubiera pasado si la entidad CLIENTE hubiera tenido
otro atributo determinante, por ejemplo: credencial?
• Los dos hubieran constituido claves de la relación
CLIENTES, de forma que hubiéramos tenido que elegir una
de las dos claves para mantener en la relación
TELEFONOS_CLIENTE.

14. MER a MR
Discusión
• Cuando haya más de una clave candidata, las
distinguiremos en dos tipos, una será la PRIMARY KEY, y
elegiremos para esto una de las claves que no admita
valores nulos.
• A las claves restantes, admitan o no valores nulos, las
llamaremos UNIQUE KEYS.
• En nuestro ejemplo, si hubiéramos tenido un atributo
determinante credencial, pero admitiera valores nulos, la
columna cedula seguiría siendo la PRIMARY KEY, mientras
que credencial sería una UNIQUE KEY.

15. MER a MR
Discusión
• En ocasiones, una entidad no tiene una clave candidata
claramente identificable, o bien tiene una compuesta de
muchos atributos, y ya sabemos que la PK de una relación
se “propaga”, por ejemplo cuando hay atributos
multivaluados.
• Para estos casos puede convenir “inventar” una clave para
que funcione como PK. A esto lo llamaremos surrogate key.
• Al no tener semántica, una surrogate key podría ser
generada automáticamente por cualquier método que
asegure la unicidad (por ejemplo un número secuencial)

16. MER a MR
Discusión
• Para ilustrar el concepto de surrogate key, veremos una
debilidad del Modelo Relacional que hemos generado,
observando una instancia de la relación CLIENTES.
• ¿Qué problemas tiene esa instancia?
• ¿Cómo podríamos solucionar esos problemas?

17. MER a MR
Discusión
• Pueden existir valores para departamento que no
corresponden a un departamento (San Gregorio), valores
para ciudad que no corresponden a una ciudad (de
Polanco), y combinaciones incorrectas de departamento y
ciudad (no existe una ciudad La Paloma en Lavalleja).
• Para solucionar el problema de los datos inexistentes,
observamos que el problema radica en que los nombres de
departamentos y ciudades deben pertenecer a un dominio
mucho más reducido que el conjunto VARCHAR(30), por
ejemplo.

18. MER a MR
Discusión
• Podríamos pensar en mantener el conjunto de los nombres
válidos de departamento, en una relación con una única
columna; y lo mismo para ciudades. En cada caso, la única
columna de la relación constituirá la Primary Key de la
misma.

19. MER a MR
Discusión
• Teniendo definidas estas relaciones y especificando Foreign
Keys como las siguientes en la relación CLIENTES,
solucionamos el problema de los departamentos y ciudades
inexistentes:
• {departamento} es FK en CLIENTES, y referencia a
nombre en DEPARTAMENTOS
• {ciudad} es FK en CLIENTES, y referencia a nombre en
CIUDADES

20. MER a MR
Discusión
• Parecería que la elección de la clave primaria en
DEPARTAMENTOS y CIUDADES era la única posible, pero
en estos casos, suelen utilizarse surrogate keys,
“inventando” una columna con un código para cada uno de
los valores del dominio:

21. MER a MR
Discusión

22. MER a MR
Discusión
• Note que el MER no teníamos una entidad
DEPARTAMENTO ni una entidad CIUDAD, sino que
agregamos estas relaciones al Modelo Relacional para
solucionar el problema de restringir los dominios de algunas
columnas.
• Estas relaciones especiales con códigos y valores formando
un dominio, se conocen muchas veces como “codigueras”.
• ¿Qué ganamos al agregar la surrogate key codigo en las
nuevas relaciones?

23. MER a MR
Discusión
• Por lo pronto: espacio
• Imagine que para almacenar el nombre de una ciudad como
“San Gregorio de Polanco” se necesitan 25 bytes (uno por
cada carácter más dos para delimitar el fin de la cadena).
• Si tenemos 1.000 clientes de San Gregorio de Polanco
tendremos 25.000 bytes en la tabla CLIENTES dedicados a
mantener esta información. Si podemos tener un código
entero de 4 bytes para cada ciudad, ocuparemos 4.000
bytes en la tabla CLIENTES en lugar de 25.000 para
mantener la misma información.

24. MER a MR
Discusión
• En general as codigueras son elementos agregados en el
Modelo Relacional, porque es difícil que el MER se haya
considerado una restricción no estructural del tipo “El
atributo departamento de la entidad CLIENTE debe ser uno
de los siguientes: Montevideo, Canelones, …”; aunque es
válido que existan este tipo de restricciones.
• Las codigueras son muy comunes, y se pueden considerar
como un patrón de diseño
• [2 min] ¿Cómo evitamos las “malas combinaciones”, como:
La Paloma - Lavalleja?

25. MER a MR
Entidades débiles
• Consideremos, por ejemplo, la entidad débil SALON (débil
respecto a CENTRO).
• La entidad fuerte CENTRO, se mapearía a una relación
CENTROS, con dos columnas: nombre (que será su PK) y
dirección

26. MER a MR
Entidades débiles
• La entidad débil SALON, se mapearía a una relación
SALONES, que tendría columnas numero (la clave parcial
de la entidad débil) y capacidad.
• Pero las entidades débiles no tienen por sí mismas datos
suficientes como para poder ser identificadas, por lo que
dependen de otra, y más específicamente dependen de la
clave de esa otra entidad para poder ser identificadas.
• Por este motivo, la clave de la relación CENTROS se
propagará a la relación SALONES, y será una Foreign Key
en SALONES

27. MER a MR
Entidades débiles
• Éste es un ejemplo de cómo quedaría el MR
• El atributo nombre de la entidad CENTRO se cambió a
nom_centro, ya que por ser la PK de CENTROS, debía
propagarse a SALONES.

28. MER a MR
Entidades débiles
• El algoritmo entonces para traducir una entidad débil al
Modelo Relacional, una vez que se representó la entidad de
la que depende, podría ser el siguiente:
• Crear una relación con el mismo nombre pero en plural
• Crear una columna en la relación por cada atributo
simple, con el mismo nombre
• Agregar las columnas que formen la PK de la relación
correspondiente a la entidad de la que depende.

29. MER a MR
Entidades débiles
• Especificar como PK las columnas que sean PK de la
relación correspondiente a la entidad de la que ésta
depende, más las columnas que forman la clave parcial
de la entidad débil.
• Especificar como FK las columnas que sean PK de la
relación correspondiente a la entidad de la que ésta
depende.
• Si la entidad débil tiene atributos multivaluados o
estructurados, traducirlos de la misma manera que en el
caso de las entidades fuertes.

30. MER a MR
Relaciones binarias
• Consideraremos tres tipos de relaciones, según su
cardinalidad (1:1, 1:N y N:M)
• En el caso de la entidad débil, ya hicimos la traducción de
una relación 1:N
• La forma de traducir una relación 1:N sirve para una relación
1:1, aunque también hay otras opciones

31. MER a MR
Relaciones binarias
• Cuando tenemos relaciones 1:N :
• Agregaremos en la tabla del lado de la cardinalidad N de
la relación, la PK de la otra tabla (que será FK) y las
columnas que correspondan a atributos de la relación.
• La PK se propaga

32. MER a MR
Relaciones binarias
• El Modelo Relacional podría quedar:
• ¿Podría haber libretas sin chofer asociado? ¿Cómo
podemos asegurarnos?

33. MER a MR
Relaciones binarias
• Cuando tenemos relaciones N:M
• Crearemos una nueva tabla para representar la relación,
agregando la PK de cada una de las tablas, además de
las columnas que correspondan a atributos de la relación
• La PK de la nueva tabla será la combinación de las PK
de las tablas que participan en la relación
• Se deben especificar como FK, las PK de las tablas que
participan en la relación

34. MER a MR
Relaciones binarias
• Si tenemos, por ejemplo, que un chofer puede conducir
varios vehículos, y un vehículo puede ser conducido por
varios choferes, el MER podría ser el siguiente

35. MER a MR
Relaciones binarias
• Y el Modelo Relacional:
• También se podría utilizar para relaciones 1:N ¿con qué PK?

36. MER a MR
Relaciones binarias
• Relaciones 1:1
• Consideremos el MER que pretende modelar la siguiente
realidad:
Cada chofer se identifica por su cédula, y se mantiene su
nombre y apellido. Se desea registrar la libreta de cada
chofer, que se identifica por un número, y tiene una fecha de
emisión y una fecha de vencimiento. Es de interés llevar un
registro de dónde suele tener cada chofer su libreta
(billetera, guantera del vehículo, etc.).

37. MER a MR
Relaciones binarias
• El MER podría ser:
• En este caso observamos que la relación es total del lado de
LIBRETA. Esto significa que no es posible tener una libreta
que no tenga asociado un chofer.

38. MER a MR
Relaciones binarias
• Supongamos que ya se tradujeron las entidades fuertes:
• Podemos agregar en la tabla con participación total, las
columnas que correspondan a la PK de la otra tabla y
columnas para los atributos de la relación (si los hay).

39. MER a MR
Relaciones binarias
• ¿Podríamos haberlo hecho al revés?

40. MER a MR
Relaciones binarias
• Otra opción, sería fundir las tablas, manteniendo la PK de la
tabla que no tiene participación total, y dejando la PK de la
tabla que tiene participación total como UK.
• Note que esta opción
implica que se deban
permitir valores nulos
• Podríamos tener valores no
nulos para las fechas de
emisión y vencimiento, y no
tener un número de libreta

41. MER a MR
Relaciones binarias
• Cuando no hay ninguna tabla con participación total se
puede elegir arbitrariamente una de las tablas para agregar
en ella la PK de la otra, y definirla como FK, además de las
columnas que correponden a atributos de la relación (igual a
cuando había una tabla con participación total), aunque se
debe considerar en este caso que los valores pueden ser
nulos.
• Otra opción es crear una tabla para la relación, que
mantenga las PK de las dos tablas además de las columnas
que corresponden a atributos de la relación (como en N:N)

42. MER a MR
Relaciones binarias
• En resumen, las posibilidades son
(*) Cuidado con los NULL si no hay totalidad
(+) Cuidado al elegir la PK
• Es un buen momento para preguntarse si no podría haber
un cambio de requerimientos que determine un cambio en la
cardinalidad (e.g. de una libreta por chofer a más de una, de
autos no-compartidos a compartidos)
Nueva tabla Propagar PK Unificar
1:1 SI SI * SI * +
1:N SI SI *
N:N SI

43. MER a MR
Relaciones n-arias (n > 2)
• Siempre se creará una nueva tabla
• Su clave será la unión de las claves de las entidades
participantes de la relación (la excepción es cuando hay
una cardinalidad 1, en ese caso, la clave será la que
corresponde a la entidad del lado de la cardinalidad 1)
• Se definirán las correspondientes claves foráneas
• Sus agregarán los atributos de la relación, si los hubiera

44. MER a MR
Agregación
• Se traduce primero la relación interna de la agregación, lo
que dará lugar a una tabla T cuya PK permita identificar las
instancias de la relación (sea una nueva tabla, una de las ya
existentes en la que se propagó la PK de la otra o una
unificación)
• Luego se traduce la relación de la que participa la
agregación, considerando que participa con T

45. MER a MR
Generalización / especialización
• Tenemos varias opciones para transformar una
generalización

46. MER a MR
Generalización / especialización
• Opción 1
• Creamos una tabla para la entidad más general, como si
fuera una entidad fuerte cualquiera
• Creamos una tabla para cada sub-entidad, con sus
atributos, y propagamos la PK de la entidad más general
• Definimos las FKs desde las PKs de éstas últimas tablas,
a la PK de la tabla que corresponde a la entidad más
general

47. MER a MR
Generalización / especialización
• Opción 1
FK1: Estudiantes(cedula) references Personas(cedula)
FK2: Docentes(cedula) references Personas(cedula)

48. MER a MR
Generalización / especialización
• Opción 2
• Crear una tabla por cada sub-entidad, con sus atributos
más los atributos de la entidad más general
• ¿Qué sucede si un docente
es también estudiante?
• ¿Qué sucede si un docente
no puede ser estudiante?
• ¿Reporte de direcciones?

49. MER a MR
Generalización / especialización
• Opción 3
• Crear una sola tabla con todos los atributos
(los de la entidad más general y los de las
subentidades) más un atributo “tipo” que
permita diferenciar las sub-entidades
• Sólo para sub-entidades disjuntas
CHECK: tipo in (‘Docente’, ‘Estudiante’)

50. MER a MR
Generalización / especialización
• Opción 4
• Crear una sola tabla con todos los atributos
(los de la entidad más general y los de las
subentidades) más un atributo “es_X” por
cada sub-entidad X
• Permite sub-entidades no disjuntas