Bases De Datos Resueltos

Tecnólogo en Informática – Base de Datos 1 – Teórico

Teórico 9 – Del MER al MR
Introducción
Veremos cómo traducir un modelo conceptual, en forma de Modelo Entidad-Relación, en un modelo lógico de base de datos, en forma de Modelo Relacional. Para esto, estudiaremos cómo traducir cada uno de los conceptos del MER, en orden creciente de complejidad.

Entidades fuertes
Consideremos unaempresa que quiere mantener datos de sus clientes. Se debe mantener la cédula de los clientes, que los determina. Se desea mantiener además el nombre, apellido, sexo, fecha de nacimiento, dirección completa (con departamento, ciudad, calle, número y apartamento si corresponde) y números de teléfono (que pueden ser más de uno). El siguiente podría ser parte del MER, donde se reflejan los datosrelevantes del cliente.

Como se ve, hay una entidad fuerte con atributos simples, atributos estructurados y atributos multivaluados. Para traducir una entidad fuerte al Modelo Relacional, procederemos de la siguiente manera: • 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 mismonombre 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 clave primaria (primary key) Para los atributos multivaluados, se creará una nueva relación con una columna correspondiente al atributo multivaluado, seagregará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 y se especificará además el conjunto de todas las columnas de la relación como una clave.

•

•

•

•

Página 1 de 5

Tecnólogo en Informática – Base de Datos 1 – Teórico

Para el caso del ejemplo, al pasar al Modelo Relacional tendremos algocomo lo siguiente:

Esta notación (conocida como crow’s foot) es un estándar de facto entre las herramientas que permiten trabajar con el Modelo Relacional. Las relaciones se muestran como cajas con dos secciones, una para el nombre de la relación, y otra para el nombre de las columnas. Opcionalmente se podría especificar, para cada columna, el tipo de datos y si admite o no el valor NULL. A vecessuele representarse de una forma especial (en negritas o con subrayado) la clave primaria de cada relación. Las relaciones de dependencia dadas por la Foreign Keys, suelen representarse como una línea entre las relaciones participantes, terminada en un símbolo como una pata de pájaro, del lado de la relación que tiene la FK. Opcionalmente, las FK pueden tener un nombre sobre la línea que lasrepresenta. 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. Notaremos algunas cuantas cosas del ejemplo antes de seguir adelante. En primer lugar, pensemos que hubiera pasado si la entidad CLIENTE hubiera tenido otro atributo determinante, por ejemplo: credencial. Los dos hubieran constituidoclaves 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. 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 nuestroejemplo, si hubiéramos tenido un atributo determiante credencial, pero admitiera valores nulos, la columna cedula seguiría siendo la PRIMARY KEY, mientras que credencial sería una UNIQUE KEY. 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...