Normalización de Bases de Datos – Formas Normales

Related Articles

Cómo enviar un enter a WhatsApp con Javascript

19/10/2020

dot dot dot … tres puntos en GO (Golang), Funciones Variádicas

24/08/2020

Cómo usar mapas de folium en PyQt5 – Python

05/08/2020

Dependencia Funcional

Es una conexión entre uno o más atributos/campos/columnas de una tabla. Por ejemplo, un DNI tiene una conexión con Apellido o Nombre, una FechaDeNacimiento con la Edad y se expresa así:

FechaDeNacimiento → Edad       Se dice entonces que Edad está incluido en FechaDeNacimiento

Existen 3 tipos de dependencia funcional:

1.- Reflexiva

Si “y” está incluido en “x” entonces x → y

A partir de cualquier atributo o conjunto de atributos siempre puede deducirse él mismo. Si la dirección o el nombre de una persona están incluidos en el DNI, entonces con el DNI podemos determinar la dirección o su nombre.

2.- Aumentativa

x → y entonces xz → yz

DNI,dirección → nombre,dirección

Si con el DNI se determina el nombre de una persona, entonces con el DNI más la dirección también se determina el nombre y su dirección.

3.- Transitiva

Sean X, Y, Z  tres atributos (o grupos de atributos) de la misma entidad. Si Y depende funcionalmente de X  y Z de Y, pero X no depende funcionalmente de Y, se dice entonces que Z depende transitivamente de X.

Simbólicamente sería:

X → Y → Z    entonces   X → Z

FechaDeNacimiento → Edad

Edad → Conducir

FechaDeNacimiento → Edad → Conducir

Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad determina a Conducir, indirectamente podemos saber a través de FechaDeNacimiento a Conducir .

Z es un dato simple (dato no primario), Y es un otro dato simple, X es la clave primaria (PK).
Decimos que Z dependerá de Y y Y dependerá funcionalmente de X.
Z tendrá una dependencia transitiva de X

Una clave primaria es el conjunto mínimo de columnas que identifica unívocamente a cada fila. La clave primaria es un identificador que va a ser siempre único para cada fila. Se acostumbra a poner la clave primaria como la primera columna de la tabla pero es más una conveniencia que una obligación. Muchas veces la clave primaria es numérica auto-incrementada, es decir, generada mediante una secuencia numérica incrementada automáticamente cada vez que se inserta una fila.

En una tabla puede que tengamos más de una columna que puede ser clave primaria por sí misma. En ese caso se puede escoger una para ser la clave primaria y las demás claves serán claves candidatas.

Primera forma normal

Condiciones

• Los datos deben ser atómicos (no separables en datos del mismo tipo) ej: más de un TE en un mismo campo.
• Identificar cada conjunto de datos relacionados con una clave primaria y que no contenga valores nulos.
• Los Campos no clave deben identificarse por la clave (Dependencia Funcional).

• Eliminar grupos repetidos de las tablas individuales.
• Crear una tabla independiente para cada conjunto de datos relacionados.

No se deben usar distintos campos/atributos para datos similares (datos con el mismo dominio como emails, teléfonos, etc).

Por ejemplo, para realizar el seguimiento de un elemento del inventario que proviene de dos orígenes posibles, un registro del inventario puede contener campos para el Código de proveedor 1 y para el Código de proveedor 2.
¿Qué ocurre cuando se agrega un tercer proveedor? Agregar un campo no es la respuesta, requiere modificaciones en las tablas y el programa, y no admite fácilmente un número variable de proveedores. En su lugar, coloque toda la información de los proveedores en una tabla independiente denominada Proveedores y después vincule el inventario a los proveedores con el número de elemento como clave, o los proveedores al inventario con el código de proveedor como clave.

Segunda forma normal

Condiciones

• Debe ser 1NF y cada campo NO clave es funcionalmente dependiente de la clave (no solo parte de ella en caso de clave  compuesta) .

Solución

• Crear tablas independientes para conjuntos de valores que se apliquen a varios registros.
• Relacione estas tablas con una clave externa – es decir, la segunda tabla posee en uno de sus campos, la clave primaria de la primera.

Los registros no deben depender de nada que no sea una clave principal de una tabla, una clave compuesta si es necesario. Por ejemplo, considere la dirección de un cliente en un sistema de contabilidad. La dirección se necesita en la tabla Clientes, pero también en las tablas Pedidos, Envíos, Facturas, Cuentas por cobrar y Colecciones. En lugar de almacenar la dirección de un cliente como una entrada independiente en cada una de estas tablas, almacénela en un lugar, ya sea en la tabla Clientes o en una tabla Direcciones independiente.

Tercera forma normal

Condición

• Debe ser 2FN y los campos NO clave deben ser mutuamente independientes o no debe haber dependencias transitivas

Solución

• Eliminar los campos que no dependan de la clave.

Los valores de un registro que no sean parte de la clave de ese registro no pertenecen a la tabla. En general, siempre que el contenido de un grupo de campos pueda aplicarse a más de un único registro de la tabla, considere colocar estos campos en una tabla independiente. Por ejemplo, en una tabla Contratación de empleados, puede incluirse el nombre de la universidad y la dirección de un candidato. Pero necesita una lista completa de universidades para enviar mensajes de correo electrónico en grupo. Si la información de las universidades se almacena en la tabla Candidatos, no hay forma de enumerar las universidades que no tengan candidatos en ese momento. Cree una tabla Universidades independiente y vincúlela a la tabla Candidatos con el código de universidad como clave.
EXCEPCIÓN: cumplir la tercera forma normal, aunque en teoría es deseable, no siempre es práctico. Si tiene una tabla Clientes y desea eliminar todas las dependencias posibles entre los campos, debe crear tablas independientes para las ciudades, códigos postales, representantes de venta, clases de clientes y cualquier otro factor que pueda estar duplicado en varios registros. En teoría, la normalización merece el trabajo que supone. Sin embargo, muchas tablas pequeñas pueden degradar el rendimiento o superar la capacidad de memoria o de archivos abiertos.
Puede ser más factible aplicar la tercera forma normal sólo a los datos que cambian con frecuencia. Si quedan algunos campos dependientes, diseñe la aplicación para que pida al usuario que compruebe todos los campos relacionados cuando cambie alguno.

Normalizar una tabla de ejemplo

Tabla sin normalizar:

Primera forma normal: no debe haber campos repetidos

Un alumno tiene varias clases, estas clases deben aparecer en una tabla independiente. Los campos Clase1, Clase2 y Clase3 de los registros anteriores surgen de un problema de diseño.

Otra forma de verlo es con la cardinalidad, una relación de uno a varios, poniendo los ítems varios en una tabla distinta. Así crear otra tabla en la primera forma normal eliminando el grupo repetido (Nº clase), según se muestra a continuación:

Segunda forma normal: eliminar los datos redundantes

Identificando el Nº alumno como clave principal, se observa que el Nº clase no depende funcionalmente de Nº alumno, por lo que no cumple la segunda forma normal.

Por tanto habrá que separar las tablas Alumno y Registro

Alumnos:

Registro:

Tercera forma normal: eliminar los datos no dependientes de la clave

En el último ejemplo, Despacho-Tut (el número de despacho del tutor) es funcionalmente dependiente del atributo Tutor. La solución es pasar ese atributo de la tabla Alumnos a la tabla Tutor, según se muestra a continuación:

Alumnos:

Tutor:

Términos usados y sus sinónimos

Relación = Tabla
Registro = tupla
Clave = llave o código de identificación
Atributo = Columna, campo
Clave Primaria = Clave candidata elegida
Clave Externa = Clave ajena o foránea
Clave Alternativa = Clave Secundaria