Maestría en Bioinformática

Bases de Datos y Sistemas de Información

Del MER al MR

Ing. Alfonso Vicente, PMPalfonso.vicente@logos.com.uy

Agenda

IntroducciónConceptos

MER a MR

Agenda

Entidades fuertes

Discusión

Entidades débiles

Relaciones binarias

Relaciones n-arias

Generalización / Especialización

Conceptos

MER a MR

Agenda

IntroducciónConceptos

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

• 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

Agenda

Entidades fuertes

Discusión

Entidades débiles

Relaciones binarias

Relaciones n-arias

Generalización / Especialización

Conceptos

MER a MR

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

(*) 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

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