Ejemplo modelo relacional
Se partirá de un modelo entidad-relación
Paso 1. Pasar entidades a tablas.
Contacto (IdContacto, Nombre, Apellido, Calle, Número, Colonia, CP)
Correo (DirCorreo, Tipo)
Telefono (No_Telefono, Tipo)
Nótese que:
1. El atributo compuesto dirección se pasó a tabla poniendo como atributos los
elementos que lo conforman. Se omitió poner Dirección.
2. Toda tabla tiene resaltado con negritas y subrayado el atributo clave.
3. Es buena práctica pensar en la implementación por eso se omite en nombres de
entidades y atributos el uso de acentos y espacios.
Paso 2. Pasar relaciones a tablas
Se empezará con las relaciones N:M en este caso Tiene entre Contacto y teléfono.
ContactoTelefono (IdContacto, No_Telefono)
Nótese que:
1. El nombre de la tabla puede ser el nombre de las entidades junto. También se puede
utilizar el nombre de la relación.
2. Los atributos de esta tabla deben ser los atributos clave de las entidades relacionadas.
3. El atributo clave de la tabla generada es la combinación de los atributos clave de las
entidades relacionadas.
4. En caso de que la relación tuviera atributos se deberían agregar a esta tabla.
Después se procede con las relaciones 1:N o N:1, en este caso tenemos Tiene entre Contacto y
Correo.
Correo (DirCorreo, Tipo, IdContacto)
Nótese que:
1. Las relaciones N:1 y 1:N no es necesario crear una nueva tabla. Se debe pasar el
atributo clave de la entidad del lado de 1 como atributo a la del lado de N. En caso de
que una relación de este tipo tenga atributos se procede como las relaciones N:M.
2. El atributo clave de Correo sigue siendo el mismo.
3. IdContacto se considerará una llave foránea.
Por último, se pasan las relaciones 1:1. Este caso no cuenta con este tipo de relación.
Peros se se procede con un ejemplo:
Después del paso de entidades de tabla se tendrá:
Entidad A (IdA, Atr_1a, Atr_2a)
Entidad B (IdB, Atr_1b, Atr_2b)
Para pasar la relación 1:1 a tablas se tendrá que:
Entidad B (IdB, Atr_1b, Atr_2b, IdA)
Nótese que:
1. El atributo clave de una entidad pasará como atributo a la otra. No importa cuál se
elija.
Al finalizar los primeros dos pasos se tiene el modelo relacional. Para este caso estará formado
por 4 tablas con la estructura siguiente:
Contacto (IdContacto, Nombre, Apellido, Calle, Número, Colonia, CP)
Correo (DirCorreo, Tipo, idCotacto)
Telefono (No_Telefono, Tipo)
ContactoTelefono (IdContacto, No_Telefono)
Un paso adicional es la normalización para asegurar la no redundancia de la información.
Paso 3. Normalización
El último paso es normalizar las tablas. (Se recomienda ver el sitio siguiente
http://cidecame.uaeh.edu.mx/lcc/mapa/PROYECTO/libro14/42_normalizacin_de_tablas_relaci
onales.html ):
1FN.
Asegurar que cada tabla obtenida del modelo relacional cumpla con:
1. Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio
son indivisibles, mínimos.
2. La tabla contiene una clave primaria única.
3. La clave primaria no contiene atributos nulos.
4. No debe existir variación en el número de columnas.
5. Los Campos no clave deben identificarse por la clave (Dependencia Funcional)
6. Debe Existir una independencia del orden tanto de las filas como de las columnas, es
decir, si los datos cambian de orden no deben cambiar sus significados
7. Una tabla no puede tener múltiples valores en cada columna.
8. Los datos son atómicos (a cada valor de X le pertenece un valor de Y y viceversa).
Al considerar lo anterior se nota que el atributo Apellido en la tabla contacto no cumple con la
regla 1 de la primera forma normal ya que se puede descomponer en ApellidoPaterno y
ApellidoMaterno por tanto se transformará en:
Contacto (IdContacto, Nombre, ApellidoPaterno, ApellidoMaterno, Calle, Número,
Colonia, CP)
Las demás tablas cumplen las 8 reglas.
2FN:
Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave
dependen de forma completa de la clave principal. Es decir que no existen dependencias
parciales. (Todos los atributos que no son clave principal deben depender únicamente de la
clave principal).
Al considerar lo anterior se debe examinar las tablas cuya clave primaria sea de más de un
atributo y asegurar que los atributos que no sean parte de la clave dependan forzosamente de
la combinación y no solo de uno. La única tabla con llave compuesta es CorreoTelefono pero al
no tener atributos cumple con la regla.
Un ejemplo de tabla que no cumple con esta sería:
Proveedor (codProveedor, CodArtículo, direccionProveedor, precio)
No cumple con la segunda forma normal ya que el atributo direcciónProveedor solo depende
codProveedor y no de CodArtículo a diferencia de precio que depende tanto de codProveedor
y CodArtículo. Para solucionarlo se descompone la tabla en dos:
Proveedor (CodProveedor, direccionProveedor)
ProveeArtículos (codProveedor,CodArtículo, precio)
3FN:
Una relación está en tercera forma normal si y solo si:
La relación está en 2FN
Todo atributo que no pertenece a la clave no depende de un atributo que no es clave.
En este caso todas las tablas cumplen con la 3FN. Un ejemplo de tabla que no cumple sería:
Carro (Placa, Marca, Modelo, Color)
Está en 2FN, pero no en tercera ya que el atributo marca depende del modelo y este
no es parte de la clave primaria, para normalizar se procede a separarla en dos tablas.
Carro (Placa, Modelo, Color)
ModelosDeCarros (Modelo, marca)
Al finalizar los 3 pasos se contará con el modelo relacional normalizado listo para pasar a la
tercera etapa del diseño de bases de datos.
Resultado final del ejercicio:
El modelo relacional normalizado para el caso de agenda es:
Contacto (IdContacto, Nombre, ApellidoPaterno, ApellidoMaterno, Calle, Número,
Colonia, CP)
Correo (DirCorreo, Tipo, idCotacto)
Telefono (No_Telefono, Tipo)
ContactoTelefono (IdContacto, No_Telefono)