Normalización de la base de datos

Una base de datos completamente normalizada puede ampliarse para admitir nuevos tipos de datos con cambios mínimos en su estructura existente. Como resultado, las aplicaciones que interactúan con la base de datos se ven mínimamente afectadas.

Las relaciones normalizadas y las relaciones entre ellas reflejan conceptos del mundo real y sus interrelaciones.

Supongamos que existe una tabla de base de datos con la siguiente estructura, que describe un libro: ^{[ 10 ]}

En este ejemplo se supone que cada libro tiene un solo autor.

Una tabla que se ajusta al modelo relacional tiene una clave primaria que identifica de forma única una fila. En nuestro ejemplo, la clave primaria es una clave compuesta de {Título, Formato} , indicada mediante subrayado:

En la primera forma normal, cada campo contiene un único valor. Un campo no puede contener un conjunto de valores ni un registro anidado. El campo Subject contiene un conjunto de valores de sujeto, lo que significa que no cumple con la condición. Para resolver el problema, los sujetos se extraen a una tabla de sujetos separada : ^{[ 10 ]}

En lugar de una tabla en forma no normalizada , ahora hay dos tablas que se ajustan a la primera forma normal (1NF).

Recordemos que la tabla Libro que se muestra a continuación tiene una clave compuesta de {Título, Formato} , que no cumplirá con la 2NF si algún subconjunto de esa clave es un determinante. En este punto de nuestro diseño, la clave no está definida como clave primaria , por lo que se la denomina clave candidata . Consideremos la siguiente tabla:

Todos los atributos que no forman parte de la clave candidata dependen de Título , pero solo Precio también depende de Formato . Para cumplir con la segunda forma normal (2NF) y eliminar duplicados, cada atributo que no sea clave candidata debe depender de la clave candidata completa, no solo de una parte.

Para normalizar esta tabla, convierta {Título} en una clave candidata (simple) (la clave primaria) de modo que cada atributo que no sea clave candidata dependa de la clave candidata completa, y elimine Precio y colóquelo en una tabla separada para que se pueda preservar su dependencia de Formato :

Ahora, tanto la tabla de Libros como la de Precios cumplen con la 2NF .

La tabla Libro aún presenta una dependencia funcional transitiva ({Nacionalidad del autor} depende de {Autor}, que a su vez depende de {Título}). Existen violaciones similares para la editorial ({País de la editorial} depende de {Editorial}, que a su vez depende de {Título}) y para el género ({Nombre del género} depende de {ID del género}, que a su vez depende de {Título}). Por lo tanto, la tabla Libro no está en 3NF. Para resolver esto, podemos colocar {Nacionalidad del autor}, {País de la editorial} y {Nombre del género} en sus respectivas tablas, eliminando así las dependencias funcionales transitivas.

La forma normal de clave elemental (EKNF) se sitúa estrictamente entre la 3NF y la BCNF y no se discute mucho en la literatura. Su objetivo es capturar las cualidades más destacadas de ambas, evitando sus problemas (a saber, que la 3NF es demasiado permisiva y la BCNF es propensa a la complejidad computacional). Dado que rara vez se menciona en la literatura, no se incluye en este ejemplo.

Supongamos que la base de datos pertenece a una franquicia de librerías que cuenta con varios franquiciados con tiendas en diferentes ubicaciones. Por lo tanto, la librería decidió agregar una tabla que contiene datos sobre la disponibilidad de los libros en las distintas ubicaciones:

Como esta estructura de tabla consta de una clave primaria compuesta , no contiene ningún atributo que no sea clave y ya está en BCNF (y, por lo tanto, también satisface todas las formas normales anteriores ). Sin embargo, suponiendo que todos los libros disponibles se ofrecen en cada área, el título no está vinculado de forma inequívoca a una ubicación determinada y, por lo tanto, la tabla no satisface la 4NF .

Eso significa que, para satisfacer la cuarta forma normal , esta tabla también necesita ser descompuesta:

Ahora, cada registro se identifica inequívocamente mediante una superclave , por lo tanto, se cumple la 4NF .

Supongamos que los franquiciados también pueden pedir libros a diferentes proveedores. Sea la relación sujeta además a la siguiente restricción:

• Si un determinado proveedor suministra un determinado título
• y el título se entrega al franquiciado.
• y el franquiciado está siendo abastecido por el proveedor,
• Luego, el proveedor entrega el título al franquiciado . ^{[ 12 ]}

Esta tabla está en 4NF , pero el ID del proveedor es igual a la unión de sus proyecciones: {{ID del proveedor, Título}, {Título, ID del franquiciado}, {ID del franquiciado, ID del proveedor}} . Ningún componente de esa dependencia de unión es una superclave (la única superclave es el encabezado completo), por lo que la tabla no satisface la ETNF y puede descomponerse aún más: ^{[ 12 ]}

La descomposición produce conformidad con ETNF.

Para detectar una tabla que no cumple con la 5NF , generalmente es necesario examinar los datos minuciosamente. Supongamos la tabla del ejemplo de 4NF con una pequeña modificación en los datos y examinemos si cumple con la 5NF :

Al descomponer esta tabla se reducen las redundancias, lo que da como resultado las dos tablas siguientes:

La consulta que une estas tablas devolvería los siguientes datos:

La operación JOIN devuelve tres filas más de las que debería; al agregar otra tabla para aclarar la relación, se obtienen tres tablas separadas:

¿Qué devolverá ahora la operación JOIN? En realidad, no es posible unir estas tres tablas. Esto significa que no fue posible descomponer la tabla Franquiciado – Libro – Ubicación sin pérdida de datos, por lo tanto, la tabla ya cumple con la 5NF .

Descargo de responsabilidad : los datos utilizados demuestran el principio, pero no siempre se cumplen. En este caso, lo mejor sería descomponer los datos de la siguiente manera, con una clave sustituta que llamaremos "ID de tienda":

La operación JOIN ahora devolverá el resultado esperado:

CJ Date ha argumentado que solo una base de datos en 5NF está verdaderamente "normalizada". ^{[ 13 ]}

Echemos un vistazo a la tabla Book de los ejemplos anteriores y veamos si satisface la forma normal de clave de dominio :

Lógicamente, el grosor se determina por el número de páginas. Esto significa que depende de las páginas , que no son una clave. Por ejemplo, un libro de hasta 350 páginas se considera "delgado" y uno de más de 350 páginas se considera "grueso".

Esta convención es técnicamente una restricción, pero no es ni una restricción de dominio ni una restricción de clave; por lo tanto, no podemos confiar en las restricciones de dominio ni en las restricciones de clave para mantener la integridad de los datos.

En otras palabras, nada nos impide poner, por ejemplo, "Grueso" para un libro con solo 50 páginas, y esto hace que la tabla viole la DKNF .

Para solucionar esto, se crea una tabla que contiene una enumeración que define el grosor , y esa columna se elimina de la tabla original:

De esa forma, se ha eliminado la violación de la integridad del dominio y la tabla está en DKNF .

La normalización no evita todos los casos de resultados imposibles, contradictorios o impredecibles. En este ejemplo, usar páginas mínimas y máximas de 1/350 y 200/999.999.999.999 daría lugar a resultados impredecibles. Por lo tanto, sería mejor especificar y usar solo páginas mínimas.

Una definición simple e intuitiva de la sexta forma normal es que "una tabla está en 6NF cuando la fila contiene la clave primaria y, como máximo, otro atributo".. ^{[ 14 ]}

Eso significa, por ejemplo, la tabla Publisher diseñada al crear la 1NF :

es necesario descomponerlo aún más en dos tablas:

La principal desventaja de la sexta forma normal (6NF) es la proliferación de tablas necesarias para representar la información de una sola entidad. Si una tabla en quinta forma normal (5NF) tiene una columna de clave primaria y N atributos, representar la misma información en 6NF requerirá N tablas; las actualizaciones de múltiples campos en un único registro conceptual requerirán actualizaciones en varias tablas; y las inserciones y eliminaciones requerirán operaciones en varias tablas. Por este motivo, en bases de datos destinadas al procesamiento de transacciones en línea (OLTP), no se recomienda utilizar la 6NF.

Sin embargo, en los almacenes de datos , que no permiten actualizaciones interactivas y están especializados en consultas rápidas sobre grandes volúmenes de datos, ciertos sistemas de gestión de bases de datos (DBMS) utilizan una representación interna en sexta forma normal (6NF), conocida como almacenamiento columnar . En situaciones donde el número de valores únicos de una columna es mucho menor que el número de filas de la tabla, el almacenamiento columnar permite un ahorro significativo de espacio mediante la compresión de datos. El almacenamiento columnar también permite la ejecución rápida de consultas de rango (por ejemplo, mostrar todos los registros donde una columna específica se encuentre entre X e Y, o sea menor que X).

En todos estos casos, sin embargo, el diseñador de la base de datos no tiene que realizar la normalización 6NF manualmente creando tablas separadas. Algunos sistemas de gestión de bases de datos (DBMS) especializados en almacenamiento de datos, como Sybase IQ , utilizan almacenamiento columnar por defecto, pero el diseñador sigue viendo solo una única tabla multicolumna. Otros DBMS, como Microsoft SQL Server 2012 y versiones posteriores, permiten especificar un "índice de almacén columnar" para una tabla en particular. ^{[ 15 ]}