La normalización de la base de datos es el proceso de estructurar una base de datos relacional de acuerdo con una serie de las llamadas formas normales para reducir la redundancia de datos y mejorar la integridad de los datos . Fue propuesto por primera vez por el informático británico Edgar F. Codd como parte de su modelo relacional .
La normalización implica organizar las columnas (atributos) y tablas (relaciones) de una base de datos para garantizar que sus dependencias se cumplan adecuadamente según las restricciones de integridad de la base de datos. Se logra aplicando algunas reglas formales, ya sea mediante un proceso de síntesis (creando un nuevo diseño de base de datos) o descomposición (mejorando un diseño de base de datos existente).
Un objetivo básico de la primera forma normal definida por Codd en 1970 era permitir que los datos fueran consultados y manipulados utilizando un "sublenguaje de datos universal" basado en la lógica de primer orden . [1] Un ejemplo de tal lenguaje es SQL , aunque Codd lo consideró seriamente defectuoso. [2]
Codd estableció los objetivos de la normalización más allá de 1NF (primera forma normal) como:
- Liberar la colección de relaciones de dependencias de inserción, actualización y eliminación no deseadas.
- Reducir la necesidad de reestructurar la recopilación de relaciones, a medida que se introducen nuevos tipos de datos, y así aumentar la vida útil de los programas de aplicación.
- Hacer que el modelo relacional sea más informativo para los usuarios.
- Hacer que la recopilación de relaciones sea neutral a las estadísticas de la consulta, donde estas estadísticas pueden cambiar con el paso del tiempo.
— EF Codd, "Mayor normalización del modelo relacional de base de datos" [3]
Cuando se intenta modificar (actualizar, insertar o eliminar) una relación, pueden surgir los siguientes efectos secundarios indeseables en relaciones que no han sido suficientemente normalizadas:
Una base de datos completamente normalizada permite ampliar su estructura para dar cabida a nuevos tipos de datos sin cambiar demasiado la estructura existente. Como resultado, las aplicaciones que interactúan con la base de datos se ven mínimamente afectadas.
Las relaciones normalizadas y la relación entre una relación normalizada y otra reflejan conceptos del mundo real y sus interrelaciones.
Codd introdujo el concepto de normalización y lo que ahora se conoce como la primera forma normal (1NF) en 1970. [4] Codd pasó a definir la segunda forma normal (2NF) y la tercera forma normal (3NF) en 1971, [5] y Codd y Raymond F. Boyce definieron la forma normal de Boyce-Codd (BCNF) en 1974. [6]
De manera informal, una relación de base de datos relacional a menudo se describe como "normalizada" si cumple con la tercera forma normal. [7] La mayoría de las relaciones 3NF están libres de anomalías de inserción, actualización y eliminación.
Las formas normales (desde la menos normalizada hasta la más normalizada) son:
La normalización es una técnica de diseño de bases de datos que se utiliza para diseñar una tabla de base de datos relacional hasta una forma normal superior. [9] El proceso es progresivo y no se puede lograr un mayor nivel de normalización de la base de datos a menos que se hayan satisfecho los niveles anteriores. [10]
Eso significa que, teniendo datos en forma no normalizada (la menos normalizada) y apuntando a lograr el mayor nivel de normalización, el primer paso sería garantizar el cumplimiento de la primera forma normal , el segundo paso sería garantizar que se cumpla la segunda forma normal . y así sucesivamente en el orden mencionado anteriormente, hasta que los datos se ajusten a la sexta forma normal .
Sin embargo, vale la pena señalar que las formas normales más allá de 4NF son principalmente de interés académico, ya que los problemas que deben resolver rara vez aparecen en la práctica. [11]
Los datos del siguiente ejemplo fueron diseñados intencionalmente para contradecir la mayoría de las formas normales. En la práctica, a menudo es posible omitir algunos de los pasos de normalización porque los datos ya están normalizados hasta cierto punto. La reparación de una violación de una forma normal también suele solucionar una violación de una forma normal superior. En el ejemplo, se ha elegido una tabla para la normalización en cada paso, lo que significa que al final algunas tablas podrían no estar suficientemente normalizadas.
Deje que exista una tabla de base de datos con la siguiente estructura: [10]
Para este ejemplo se supone que cada libro tiene un solo autor.
Una tabla que se ajusta al modelo relacional tiene una clave principal que identifica de forma única una fila. En nuestro ejemplo, la clave principal es una clave compuesta de {Título, Formato} (indicado por el subrayado):
En la primera forma normal, cada campo contiene un único valor. Un campo no puede contener un conjunto de valores o un registro anidado.
El asunto contiene un conjunto de valores del sujeto, lo que significa que no los cumple.
Para resolver el problema, los temas se extraen en una tabla de Asuntos separada : [10]
En lugar de una tabla en forma no normalizada , ahora hay dos tablas conforme a la 1NF.
Recuerde que la siguiente tabla Libro tiene una clave compuesta de {Título, Formato} , que no satisfará 2NF si algún subconjunto de esa clave es un determinante. En este punto de nuestro diseño, la clave no está finalizada como clave principal , por lo que se denomina clave candidata . Considere la siguiente tabla:
Todos los atributos que no forman parte de la clave candidata dependen del Título , pero solo el Precio también depende del Formato . Para cumplir con 2NF y eliminar duplicados, cada atributo de clave que no sea candidata debe depender de la clave candidata completa, no solo de una parte.
Para normalizar esta tabla, haga de {Título} una clave candidata (simple) (la clave principal) para que cada atributo que no sea de clave candidata dependa de toda la clave candidata, y elimine Precio en una tabla separada para que su dependencia del Formato pueda ser preservado:
Ahora, tanto la tabla de Libros como la de Precios se ajustan a 2NF .
La tabla Libro todavía tiene una dependencia funcional transitiva ({Autor Nacionalidad} depende de {Autor}, que depende de {Título}). Existen infracciones similares para el editor ({País del editor} depende de {Publisher}, que depende de {Título}) y para el género ({Nombre del género} depende de {ID de género}, que depende de {Título}). Por lo tanto, la tabla Libro no está en 3NF. Para resolver esto, podemos colocar {Nacionalidad del autor}, {País del editor} y {Nombre del género} en sus respectivas tablas, eliminando así las dependencias funcionales transitivas:
La forma normal de clave elemental (EKNF) se encuentra estrictamente entre 3NF y BCNF y no se analiza mucho en la literatura. Su objetivo es "captar las cualidades destacadas tanto de 3NF como de BCNF" evitando al mismo tiempo los problemas de ambos (es decir, que 3NF es "demasiado indulgente" y BCNF es "propenso 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 es propiedad de una franquicia minorista de libros que tiene varios franquiciados que poseen tiendas en diferentes ubicaciones. Y por eso el minorista decidió agregar una tabla que contiene datos sobre la disponibilidad de los libros en diferentes 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 ofrezcan en cada área, el Título no está vinculado inequívocamente a una Ubicación determinada y, por lo tanto, la tabla no satisface 4NF .
Eso significa que, para satisfacer la cuarta forma normal , esta tabla también debe descomponerse:
Ahora, cada registro se identifica inequívocamente mediante una superclave , por lo que se cumple 4NF .
Supongamos que los franquiciados también pueden pedir libros a diferentes proveedores. Sea la relación también sujeta a la siguiente restricción:
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 el ETNF y puede descomponerse aún más: [12]
La descomposición produce el cumplimiento de ETNF.
Para detectar una tabla que no cumple con el 5NF , generalmente es necesario examinar los datos minuciosamente. Supongamos la tabla del ejemplo 4NF con una pequeña modificación en los datos y examinemos si satisface 5NF :
Descomponer esta tabla reduce las redundancias, lo que da como resultado las dos tablas siguientes:
La consulta que une estas tablas devolvería los siguientes datos:
JOIN devuelve tres filas más de las que debería; agregar otra tabla para aclarar la relación da como resultado tres tablas separadas:
¿Qué devolverá JOIN ahora? En realidad, no es posible unir estas tres mesas. Eso significa que no fue posible descomponer el Franquiciado - Libro - Ubicación sin pérdida de datos, por lo tanto, la tabla ya satisface 5NF .
CJ Date ha argumentado que sólo una base de datos en 5NF está verdaderamente "normalizada". [13]
Echemos un vistazo a la tabla Libro de ejemplos anteriores y veamos si satisface la forma normal de clave de dominio :
Lógicamente, el Grosor viene determinado por el número de páginas. Eso significa que depende de Pages , que no es una clave. Pongamos un ejemplo de convención que diga que un libro de hasta 350 páginas se considera "delgado" y un libro de más de 350 páginas se considera "grueso".
Esta convención es técnicamente una restricción, pero no es una restricción de dominio ni una restricción clave; por lo tanto, no podemos confiar en restricciones de dominio y restricciones clave para mantener la integridad de los datos.
En otras palabras, nada nos impide poner, por ejemplo, "Grueso" para un libro de sólo 50 páginas, y esto hace que la tabla infrinja el DKNF .
Para resolver 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 manera, se elimina la violación de la integridad del dominio y la tabla está en DKNF .
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 el 1NF:
debe descomponerse aún más en dos tablas:
El inconveniente obvio de 6NF es la proliferación de tablas necesarias para representar la información de una sola entidad. Si una tabla en 5NF tiene una columna de clave principal y N atributos, representar la misma información en 6NF requerirá N tablas; las actualizaciones de varios campos de un único registro conceptual requerirán actualizaciones de varias tablas; y las inserciones y eliminaciones requerirán de manera similar operaciones en varias tablas. Por este motivo, en bases de datos destinadas a satisfacer las necesidades de procesamiento de transacciones en línea (OLTP), no se debe utilizar 6NF.
Sin embargo, en los almacenes de datos , que no permiten actualizaciones interactivas y que están especializados en consultas rápidas sobre grandes volúmenes de datos, ciertos DBMS utilizan una representación 6NF interna, conocida como almacén de datos en columnas . En situaciones en las que el número de valores únicos de una columna es mucho menor que el número de filas de la tabla, el almacenamiento orientado a columnas permite ahorros significativos de espacio mediante la compresión de datos. El almacenamiento en columnas también permite la ejecución rápida de consultas de rango (por ejemplo, mostrar todos los registros donde una columna en particular está entre X e Y, o menos que X).
Sin embargo, en todos estos casos, el diseñador de la base de datos no tiene que realizar la normalización 6NF manualmente creando tablas separadas. Algunos DBMS especializados en almacenamiento, como Sybase IQ , utilizan almacenamiento en columnas de forma predeterminada, pero el diseñador todavía ve solo una tabla de varias columnas. Otros DBMS, como Microsoft SQL Server 2012 y posteriores, le permiten especificar un "índice de almacén de columnas" para una tabla en particular. [15]