Normalización de bases de datos.
agosto 21, 2020
4.1 Conceptos básicos.
Normalización.
Es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos más pequeñas, que además de ser más simples y más estables, son más fáciles de mantener. También se puede entender la normalización como una serie de reglas que sirven para ayudar a los diseñadores de bases de datos a desarrollar un esquema que minimice los problemas de lógica. Cada regla está basada en la que le antecede. La normalización se adoptó porque el viejo estilo de poner todos los datos en un solo lugar, como un archivo o una tabla de la base de datos, era ineficiente y conducía a errores de lógica cuando se trataban de manipular los datos.
Grados de normalización.
Existen básicamente tres niveles de normalización:
- Primera forma Normal (1FN): Incluye la eliminación de todos los grupos repetidos.
- Segunda forma normal (2FN): Asegura que todas las columnas que no son llave sean completamente dependientes de la llave primaria (PK).
- Tercera forma Normal (3FN): Elimina cualquier dependencia transitiva. Una dependencia transitiva es aquella en la cual las columnas que no son llave son dependientes de otras columnas que tampoco hijo llave.
Cada una de estas formas tiene propias reglas. Cuando uno base de datos se confirma a un nivel, se considera normalizada en el nivel más alto de normalización, puede llevar a un nivel de complejidad que pudiera ser evitado si estaba en un nivel más bajo de normalización.
4.2 Primera forma normal.
Una relación está en primera forma normal cuando todos sus atributos son atómicos. Una tabla está en Primera Forma Normal si:
- Todos los atributos son atómicos, (un atributo es atómico si los elementos del dominio son indivisibles, mínimos).
- La tabla contiene una clave primaria única.
- La clave primaria no contiene atributos nulos.
- No debe existir variación en el número de columnas.
- Los campos no clave deben identificarse por la clave (Dependencia funcional).
- 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.
- Una tabla no puede tener múltiples valores en cada columna.
- Los datos son atómicos (a cada valor de "x" le pertenece un valor de "y" y viceversa).
 |
| Esta forma normal elimina los valores repetidos dentro de una Base de Datos. |
4.3 Dependencias funcionales y transitivas.
Dependencia funcional completa.
En una dependencia funcional "x" → "y", cuando "x" es un conjunto de atributos, decimos que la dependencia funcional es completa, si sólo depende de "x", y no de ningún subconjunto de "x". Estas dependencias son consecuencia de la estructura de la base de datos y de los objetos del mundo real que describe, y no de los valores actualmente almacenados en cada relación. Por ejemplo si conocemos el valor de FechaDeNacimiento podemos conocer el valor de edad.
 |
| Las dependencias funcionales del sistema se escriben utilizando una flecha |
Dependencia funcional reflexiva.
Si “y” está incluido en “x”, entonces "x" → "y"
A partir de cualquier atributo o conjunto de atributos siempre puede deducirse el mismo; y si la dirección o el nombre de una persona están incluidos en una cédula, entonces en esa cédula se puede determinar la dirección o su nombre. Por ejemplo: si el nombre y/o la fecha de nacimiento de una persona están en su CURP, entonces con la CURP podemos determinar su fecha de nacimiento y/o su nombre.
Dependencia funcional elemental.
Si tenemos una dependencia completa "x" → "y", diremos que es una dependencia funcional elemental si "y" es un atributo, y no un conjunto de ellos.
Dependencia funcional trivial.
Una dependencia funcional "x" → "y" es trivial cuando "y" es parte de "x". Esto sucede cuando "x" es un conjunto de atributos, y "y" es a su vez un subconjunto de "x".
Ejemplo: cod libro → cod libro | articulo, revista → revista.
Dependencia funcional transitiva.
Imaginemos que tenemos una relación con tres conjuntos de atributos: "x", "y" y "z", y las siguientes dependencias "x" → "y", "y" → "z", "y" → "x". Es decir, "x" determina "y" e "y" determina "z", pero "y" no determina "x". En ese caso, decimos que "z" tiene dependencia transitiva con respecto a "x", a través de "y".
4.4 Segunda forma normal.
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), si hay atributos que depende sólo de parte de la clave, entonces esa parte de la clave y esos atributos formarán otra tabla
En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional.
Esta regla significa que en una relación sólo se debe almacenar información sobre un tipo de entidad, y se traduce en que los atributos que no aporten información directa sobre la clave principal deben almacenarse en una relación separada.
Lo primero que necesitamos para aplicar esta forma normal es identificar las claves candidatas. Además, podemos elegir una clave principal, que abreviaremos como PK, (las iniciales de PrimaryKey). Pero esto es optativo, el modelo relacional no obliga a elegir una clave principal para cada relación, sino tan sólo a la existencia de al menos una clave candidata.
La inexistencia de claves candidatas implica que la relación no cumple todas las normas para ser parte de una base de datos relacional, ya que la no existencia de claves implica la repetición de tuplas.
4.5 Tercera forma normal.
La tercera forma normal consiste en eliminar las dependencias transitivas.
Una base de datos que está en 3FN igual lo está en 2FN y además todas las columnas que no sean claves dependen de la clave completa de forma no transitiva. Cuando las tablas están en la Tercera Forma Normal se previenen errores de lógica cuando se insertan o borran registros. Cada columna en una tabla está identificada de manera única por la llave primaria, y no debe haber datos repetidos. Esto provee un esquema limpio y elegante, que es fácil de trabajar y expandir.
4.6 Forma normal de Boyce-Codd.
Es un esquema de relación "r" que está en Forma Normal de Boyce-Codd si siempre y cuando una dependencia no trivial "x" → "a" es válida en "r", entonces "x" es una superclave de "r". A diferencia de la 3FN, no se permite que si "a" es primo.
Esto significa que no deben existir interrelaciones entre atributos fuera de las claves candidatas.
4.7 Otras formas normales.
Quinta forma normal 5FN.
Tambien llamada Forma Normal de Proyección-Unión, sirve para eliminar dependencias de proyección o reunión, esta se debe encontrar en 4FN y las únicas dependencias que deben existir son las denominadas dependencias de Join de una tabla con sus proyecciones, relacionándose entre sí mediante la clave primaria, o cualquier clave alternativa.
Se dice que hay dependencia de Join entre una tabla y sus proyecciones, si es posible obtener la tabla original por medio de la unión de dichas proyecciones.
Sexta forma normal 6FN.
La sexta forma normal está destinada a descomponer las variables de relación en componentes irreducibles. Aunque esto puede ser relativamente poco importante para las variables de relación no temporal, puede ser importante cuando se trata de variables temporales u otros datos de intervalo. Por ejemplo, si una relación comprende el nombre, el estado y la ciudad de un proveedor, es posible que también deseemos agregar datos temporales, como el tiempo durante el cual estos valores son, o fueron, válidos (por ejemplo, para datos históricos) pero los tres valores puede variar independientemente uno del otro y a diferentes velocidades. Podemos, por ejemplo, desear rastrear el historial de cambios a Status; Una revisión de los costos de producción puede revelar que un cambio fue causado por un proveedor que cambió de ciudad y, por lo tanto, lo que cobraron por la entrega.
Forma normal DNFN.
La forma normal de dominio/clave (DKNF) es una forma normal usada en normalización de bases de datos que requiere que la base de datos contenga restricciones de dominios y de claves.
Es mucho más fácil construir una base de datos en forma normal de dominio/clave que convertir pequeñas bases de datos que puedan contener numerosas anomalías. Sin embargo, construir con éxito una base de datos en forma normal de dominio/clave sigue siendo una tarea difícil, incluso para programadores experimentados de bases de datos. Así, mientras que la forma normal de dominio/clave elimina los problemas encontrados en la mayoría de las bases de datos, tiende para ser la forma normal más costosa de alcanzar. Sin embargo, el no poder alcanzar la forma normal de dominio/clave puede llevar costos ocultos a largo plazo, debido a anomalías que aparecen con el tiempo en las bases de datos que solamente se adhieren a formas normales más bajas.
Una restricción del dominio especifica los valores permitidos para un atributo dado, mientras que una restricción clave especifica los atributos que identifican únicamente una fila en una tabla dada.
Esta es el santo grial de la Base de datos y es alcanzado cuando cada restricción en la relación es una consecuencia lógica de la definición de claves y dominios, y, haciendo cumplir las restricciones y condiciones de la clave y del dominio, causa que sean satisfechas todas las restricciones. Así, esto evita todas las anomalías no-temporales.
. . .
Si te a servido de utilidad la información que haz encontrado aquí acerca del tema cuatro de Fundamentos de Base de Datos y te gustaría complementar lo que ya has visto, te invitamos a que nos escuches en el Podcast de Encoders justo aquí: https://bit.ly/2Tn13Ms
0 comentarios