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
 Agenda

Conceptos  Introducción
MER a MR
 Agenda

Conceptos  Entidades fuertes

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

Conceptos  Introducción
MER a MR
 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
 Conceptos
Introducción

• El paso lógico siguiente sería pasar del MER al MR

Relevamiento Modelado conceptual MER ??? MR
Requerimientos

• 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?
 Agenda

Conceptos  Entidades fuertes

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

• Ejemplo: entidad CLIENTE, con atributos simples,

multivalorados, estructurados y determinantes

• Necesitamos traducir esta entidad fuerte al MR

 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)
 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
 MER a MR
Entidades fuertes

• La entidad del ejemplo, podría traducirse al MR así:

 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.
 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.
 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.
 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)
 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?

 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.
 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.
 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
 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:
 MER a MR
Discusión
 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?
 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.
 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?
 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
 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
 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.
 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.
 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.
 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
 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
 MER a MR
Relaciones binarias

• El Modelo Relacional podría quedar:

• ¿Podría haber libretas sin chofer asociado? ¿Cómo

podemos asegurarnos?
 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
 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
 MER a MR
Relaciones binarias

• Y el Modelo Relacional:

• También se podría utilizar para relaciones 1:N ¿con qué PK?

 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.).
 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.
 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).
 MER a MR
Relaciones binarias

• ¿Podríamos haberlo hecho al revés?

 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
 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)
 MER a MR
Relaciones binarias

• En resumen, las posibilidades son

Nueva tabla Propagar PK Unificar
1:1 SI SI * SI * +
1:N SI SI *
N:N SI
(*) 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)
 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

 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
 MER a MR
Generalización / especialización

• Tenemos varias opciones para transformar una

generalización
 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
 MER a MR
Generalización / especialización

• Opción 1

FK1: Estudiantes(cedula) references Personas(cedula)

FK2: Docentes(cedula) references Personas(cedula)
 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?
 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’)

 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