Programacion paralela

Diseño de BD utilizando el Modelo Relacional

Convertir modelo Entidad – Vínculo a modelo relacional

Se logra realizando los siguientes pasos:

Nota: Se usará la figura 24, pero a continuación se muestra con cardinalidades y llaves.

Figura 39

1. Una entidad es convertida en una relación y cada atributo es un campo de la misma ( solo atributos simples ).

Los tipos de datos asignados a los campos deben de corresponder con el tipo de dato que exista en el ABDR.

Evitar tener nombres de campos con espacios en blanco internos, en su representación se pondrán guiones bajos ( _ ).

Tipos( nombre:string, costo:money, dias:int )

Peliculas( codigo:int, título:string, genero: string, clasificacion:string,

codigos_cintas:string, nomtipo: string )

Clientes( codigo_barras:string, nombre:string, ap_paterno:string, ap_materno:string, direccion:string, telefono:string )

2. Las llaves de cada entidad son las llaves de la tabla.

Es común subrayar todos los campos que pertenecen a la llave primaria.

Un campo compuesto es una llave primaria indica que todos los campos simples que lo integran formarán la llave primaria de la tabla.

No se tienen varias llaves primarias en una tabla, es solo UNA, pero esta puede estar formada por varios campos ( llave compuesta ).

Las llaves candidatas establecidas en el modelo Entidad – Vínculo permanecen y pueden ser subrayadas con lineas entrecortadas.

Las llaves foráneas pueden ser encerradas en círculos y no tiene obligatoriamente que llamarse igual que las llaves primarias a las cuales hacen referencia.

Figura 40

3. Los atributos multivaluados deben ser eliminados de la siguiente forma:

1. Definir una nueva tabla

2. Quitar el atributo multivaluado de la tabla y agregarlo en la nueva tabla

3. Copiar la llave primaria ( los campos que la formen ) a la nueva tabla y en ella son definidos como llave foránea.

4. Definir la llave primaria de la tabla como todos los campos que la integran

Figura 41

Con esta modificación se logra que en la nueva tabla ( Pel_Invent ), al ser la llave primaria la combinación de los campos de la llave primaria anterior y el multivaluado, se pueda registrar en cada registro un valor diferente para el campo multivaluado, pero sin perder la referencia a la anterior tabla y sin embargo la llave primaria no se repite ya que la conforman la combinación de los campos anteriormente mencionados.

Por ejemplo: Tabla clientes, antes de la modificación, implicaba que se anotarán varios telefonos en el mismo espacio lo cual es erroneo e inválido. ( figura 42 ). Al realizar las modificaciones se permite que exista un registro para cada teléfono en la tabla Client_tel, con la mínima repetición que consiste en el código de barras del cliente, esto es inevitable ya que de quitar este campo en la tabla Client_tel, se pierde la referencía del cliente al cual pertenece el teléfono. ( figura 43 ).

Caso 1:

Si el campo multivaluado puede tener nulos ( o desconocerse su valor ), otro beneficio que se gana es que en la tabla nueva generada para él, no tienen porque aparecer registros que no contengan datos, en otras palabras: los clientes que no tengan teléfono no aparecerán en ella.

Figura 42

Figura 43

Caso 2:

Si el campo multivaluado, contiene datos que son irrepetibles, o que constituyen una llave candidata de la tabla de la cual salieron, en la tabla nueva que se genera; ellos son los únicos que forman parte de la llave primaria.

Este es el caso de la tabla Peliculas y Pel_Invent, ya que el código de la cinta es irrepetible.

Figura 44

4. Para las entidades debiles, se define su tabla con todos sus atributos, y la llave primaria será la combinación de la llave primaria de la entidad debil más la llave primaria de la entidad fuerte, de la cual deriva.

Tomando como ejemplo la figura 28.

Figura 45

Caso 1: Si la llave primaria de la entidad debil es irrepetible, sin necesidad de la llave primaria de la entidad fuerte, puede conservarse como estaba; solo se agrega como llave foránea la llave primaria de la entidad fuerte para no perder la referencia.

5. En las vínculos, el análisis se basa en su cardinalidad:

1. Cardinalidad 1:1: Se escoge una de las entidades que intervienen para que en ella se deposite la llave primaria de la otra como llave foranea. Teniendo cuidado en evitar casos de nulos.Tomándo como ejemplo la figura 26. Las tablas pueden ser:

Figura 46

Figura 47

¿De que dependerá la elección? De la realidad. Se decidirá de acuerdo a la combinación que menos posibilidades tenga de generar valores nulos en la llave foránea.

Para este ejemplo se hace la siguiente pregunta:

¿Qué es más factible en la compañía: que un trabajador no tenga un carro asignado ( por cualquier motivo ) o que un carro no tenga asignado un trabajador?

2. Cardinalidad 1:N: La entidad de lado del 1 es la que cede su llave primaria para la otra entidad que la conserve como llave foranea. ( ver figura 40 )

3. Cardinalidad N:M: En este caso se define una nueva tabla que tendrá como campos, los atributos que se le hayan conferido especificamente ( si el vínculo tenía atributos ) y los campos que formen parte de las llaves primarias de las entidades que participan en el vínculo ( que son llaves foráneas ). ( ver figura 39 )

Es el caso del vínculo rentar:

rentar ( folio: int, fecha:date, total:money, cod_barras:string, codigo: int )

La llave primaria esta formada por los campos que llegarón como llaves foráneas y si es necesario algún/os atributo/s del vínculo. En este caso, la figura siguiente muestra que es necesario incorporar a la llave primaría el campo fólio, ya que puede darse el caso que el mismo cliente rente la misma película en diferentes ocasiones, solo haría distinción la factura en la cual las rentó.

Figura 48

Caso 1:

Existe un conjunto de campos del vínculo ( sin las llaves foráneas ) que pueden ser considerados como la llave primaria.

En este ejemplo, el fólio de la factura es un número que en la realidad no se puede repetir, es decir por cada renta se genera una factura cuyo número es irrepetible, este puede ser nuestra llave primaria.

Figura 49

Caso 2

En los vínculos con cardinalidad “muchos a muchos”, algunos campos que llegan como llaves foráneas ( de las entidades que relaciona el vínculo ) en la acción que representa el vínculo, pueden tomar muchos valores. En otras palabras con campos multivaluados. Por lo tanto se realiza el paso 3.

Figura 50

El campo código ( es el código del título de la película que se rento ) es multivaluado, porque un cliente puede rentar varias películas en la misma factura.

Referencias

[ 1 ] Elmasri & Navathe. (2000). Sistemas de Bases de Datos Conceptos Fundamentales. 2da. Edición. Pearson Education.

[ 2 ] Date, C. J. . ( 1993 ). Introducción a los Sistemas de Bases de Datos. 5ta. Edición. Addison – Wesley Iberoamericana.