El Modelo Entidad - Relación

Luego de realizar un análisis de la realidad, el primer paso que debemos hacer para lograr un buen diseño de Base de Datos es definir el Modelo Entidad-Relación (E-R).

Este pequeño tutorial muestra de manera resumida la simbología y conceptos fundamentales para generar este tipo de modelaje.

Primera Forma Normal (1FN)

 Una tabla se considera en 1FN si:

1. La tabla contiene una clave principal.
2. La clave principal no contiene atributos nulos. Esto lo hemos analizado en la unidad anterior, es fundamental que cuando determinamos que una campo será la clave de la tabla tengamos presente que éste dato no podrá quedar nunca sin completar.

3.   Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos. Dicho de otro modo, una tabla no puede tener múltiples valores en cada.

Por ejemplo, si deseáramos almacenar qué proveedores nos suministran los productos con los cuales trabajamos, podríamos pensar en registrarlo del siguiente modo:

   

(*)Código de Producto	Descripción	Precio Unitario	…	Proveedor
12332480	Tarugos 8”	1,20		1013; 1027; 2189

Este diseño, que registra más de un Número de Proveedor en la misma columna para un producto, no es eficiente. No respeta la 1FN. ¿Cuál sería el inconveniente? Pensemos qué sucederá cuando queramos relacionar este campo Número de proveedor con el existente en la tabla Proveedores, para poder saber su Razón Social; la búsqueda sería imposible ya que el SGBD tomará la cadena de caracteres “1013; 1027; 2189” como un único contenido, no pudiendo localizar quién es exactamente el proveedor 1013.

4. No debe existir variación en el número de columnas.

Siguiendo con el ejemplo anterior, esta condición se refiere por ejemplo, a registrar a los distintos proveedores del siguiente modo:

(*)Código de Producto	Descripción	Precio Unitario	…	Proveedor
12332480	Tarugos 8”	1,20		1013	1027	2189	….

            Pensar una tabla con la idea de tener “Celdas combinadas” no es un diseño viable en Base de Datos normalizadas.

5. No deben existir grupos repetidos en diferentes columnas.

Del mismo modo, deberemos evitar registrarlo de la siguiente manera:

(*)Código de Producto	Descripción	Precio Unitario	…	Prov. 1	Prov. 2	Prov. 3
12332480	Tarugos 8”	1,20		1013	1027	2189	…

  

6. Debe existir una independencia del orden tanto de las filas como de las columnas. Lo cual implica que si cambiáramos el orden de los registros o de visualización de los campos, éstos no debieran cambiar sus significados.

Para el ejemplo presentado, un diseño correcto que respetaría la 1FN sería el que relaciona la tabla Productos con la tabla Proveedores utilizando una tercera tabla (como se mencionara en la Unidad 1, llamada, tabla Unión), en la cual figuren los campos claves de las tablas a relacionar, lo que definiría el siguiente diseño:                                                                                                                                                                                                Tabla Productos

(*)Código de Producto	Descripción	Precio Unitario	…
12332480	Tarugos 8”	1,20

                                              Tabla Proveedores

(*)Número de Proveedor	Razón Social	CUIT	…
1013	Zuniga Hnos. SA	27-33333333-1

                                              Tabla Producto-Proveedor

(*)Código de Producto	(*)Número de Proveedor	Precio de Costo	…
12332480	1013	0,25
12332480	1027	0,30
12332480	2189	0,20

(*) Representa el campo clave.

De este modo, repitiendo solamente los campos claves en la nueva tabla podremos registrar todas las combinaciones posibles: un mismo producto suministrado por varios proveedores y un mismo proveedor  que suministra varios productos.

Para evitar la inconsistencia de cargar dos veces el mismo producto con el mismo proveedor (con el riesgo de registrar Precios de costo diferentes), deberemos indicar que nuestra tabla tiene una clave múltiple conformada por el Código de Producto y el Número de Proveedor.

Segunda Forma Normal (2FN)

Podemos decir que una tabla se encuentra 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.

Cuando hablamos de dependencia hablamos de Dependencia Funcional.

Una dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si conocemos el Legajo del empleado sabremos su Apellido y Nombre  ya que existe una dependencia entre ellos.

Las dependencias funcionales se indican utilizando una flecha, de la siguiente manera:

Legajo -> Apellido y Nombre

Para comprender mejor el concepto veamos un ejemplo. Supongamos que estamos registrando los empleados que se encuentran trabajando en cada departamento en una tabla con el siguiente diseño:

(*)Legajo	(*)Código Dpto.	Nombre	Departamento	Fecha de ingreso	…
1	6	Juan	Contabilidad	30/04/99
2	3	Pedro	Sistemas	02/06/90
3	2	Sonia	RRHH	23/11/12
4	3	Verónica	Sistemas	10/07/08
2	6	Pedro	Contabilidad	05/01/09

Si la clave principal de esta tabla, está formada por los campos Legajo y Código Dpto., por todo analizado anteriormente, podemos decir que la tabla se encuentra en 1FN. Analicemos entonces si también cumple la regla de la  2FN. Para ello deberemos analizar cuáles son las dependencias funcionales:
               Legajo -> Nombre
               Código Dpto.  -> Departamento
               Legajo, Código Dpto. -> Fecha de Ingreso

Como puede verse, tanto el campo Nombre como el Departamento dependen sólo de parte de la clave, mientras que la Fecha de Ingreso depende de la clave completa. De manera que con solo existir una dependencia parcial se concluye que toda la tabla no se encuentra en 2FN y deberemos normalizarla.

Cuando nos encontremos en situaciones como ésta, deberemos diseñar una tabla para cada una de las dependencias parciales:

Tabla de Empleados

(*)Legajo	Nombre
1	Juan
2	Pedro
3	Sonia
4	Verónica

Tabla de Departamentos

(*)Código Depto.	Departamento
2	I+D
3	Sistemas
6	Contabilidad
...

Mientras que en la original sólo dejaremos la clave múltiple con aquellos campos que mostraban una dependencia de la clave completa:  

Tabla Empleados por Departamento

 

(*)Legajo	(*)Código Dpto.	Fecha de ingreso	…
1	6	30/04/99
2	3	02/06/90
3	2	23/11/12
4	3	10/07/08
2	6	05/01/09