La normalización es una técnica de diseño de base de datos, que se utiliza para diseñar una tabla de base de datos relacional hasta una forma normal superior. El proceso es progresivo y no se puede lograr un nivel más alto de normalización de la base de datos a menos que se hayan satisfecho los niveles anteriores.
Eso significa que, tener datos en forma no normalizada (la menos normalizada) y con el objetivo de lograr la más alta nivel de normalización, el primer paso sería asegurar el cumplimiento de la primera forma normal, el segundo paso sería asegurar que se satisfaga 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 existen para resolver rara vez aparecen en la práctica.
Tenga en cuenta que los datos en el siguiente ejemplo fueron diseñado intencionalmente para contradecir la mayoría de las formas normales. En la vida real, es muy posible poder omitir algunos de los pasos de normalización porque la tabla no contiene nada que contradiga la forma normal dada. También ocurre comúnmente que corregir una violación de una forma normal también corrige una violación de una forma normal superior en el proceso. Además, se ha elegido una tabla para la normalización en cada paso, lo que significa que al final de este proceso de ejemplo, es posible que todavía haya algunas tablas que no satisfagan la forma normal más alta.
Initial dataEdit
Cree una tabla de base de datos con la siguiente estructura:
| Título | Autor | Autor Nacionalidad | Formato | Precio | Asunto | Páginas | Espesor | Editor | País del editor | Tipo de publicación | ID de género | Nombre de género |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Diseño y optimización de base de datos MySQL inicial | Chad Russell | Americano | Tapa dura | 49,99 | MySQL,
Base de datos, Diseño |
520 | Grueso | Apress | EE. UU. | Libro electrónico | 1 | Tutorial |
En este ejemplo, asumimos que cada libro tiene un solo autor.
Satisfacer 1NFEdit
Para satisfacer 1NF, los valores en cada columna de una tabla deben ser atómicos. En la tabla inicial, Asunto contiene un conjunto de valores de asunto, lo que significa que no cumple.
Una forma de lograr el 1NF sería separar las duplicidades en varias columnas usando grupos repetidos Asunto:
| Título | Formato | Autor | Autor Nacionalidad | Precio | Asunto 1 | Asunto 2 | Asunto 3 | Páginas | Espesor | Editor | País del editor | ID de género | Nombre de género |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Diseño y optimización de bases de datos MySQL iniciales | Tapa dura | Chad Russell | Americano | 49,99 | MySQL | Base de datos | Diseño | 520 | Grueso | Apress | EE. UU. | 1 | Tutorial |
Aunque ahora la tabla cumple formalmente con la 1NF (es atómica), el problema con esta solución es obvio – si un libro tiene más de tres temas, no se puede agregar a la base de datos sin alterar su estructura.
Para resolver el problema de una manera más elegante, es necesario identificar las entidades representadas en la tabla y separarlas en sus propias tablas respectivas. En este caso, daría como resultado tablas de libro, tema y editor:
| Título | Formato | Autor | Autor Nacionalidad | Precio | Páginas | Espesor | ID de género | Nombre de género | ID de editor |
|---|---|---|---|---|---|---|---|---|---|
| MySQL inicial Diseño y optimización de bases de datos | Tapa dura | Chad Russell | Americano | 49.99 | 520 | Grueso | 1 | Tutorial | 1 |
|
|
Simplemente separar los datos iniciales en varias tablas rompería la conexión entre los datos. Eso significa que es necesario determinar las relaciones entre las tablas recién introducidas. Tenga en cuenta que la columna de ID de editor en la tabla del libro es una clave externa que da cuenta de una relación de varios a uno entre un libro y un editor.
Un libro puede adaptarse a muchos temas, así como un tema puede corresponden a muchos libros. Eso significa que también se debe definir una relación de muchos a muchos, que se logra mediante la creación de una tabla de vínculos:
|
En lugar de una tabla en forma no normalizada, ahora hay 4 tablas que cumplen con 1NF.
Satisfacer 2NFEdit
La tabla Libro tiene una clave candidata (que por lo tanto es la clave primaria), la clave compuesta {Título, Formato}. Considere el siguiente fragmento de tabla:
| Título | Formato | Autor | Autor Nacionalidad | Precio | Páginas | Espesor | ID de género | Nombre de género | ID de editor |
|---|---|---|---|---|---|---|---|---|---|
| Diseño y optimización de base de datos MySQL inicial | Tapa dura | Chad Russell | Americano | 49,99 | 520 | Grueso | 1 | Tutorial | 1 |
| Principio del diseño y optimización de bases de datos MySQL | E-book | Chad Russell | Americano | 22,34 | 520 | Grueso | 1 | Tutorial | 1 |
| El modelo relacional para la gestión de bases de datos: Versión 2 | Libro electrónico | EFCodd | Británico | 13,88 | 538 | Grueso | 2 | Ciencia popular | 2 |
| El modelo relacional para la base de datos Ma nagement: Versión 2 | Tapa blanda | EFCodd | Británico | 39.99 | 538 | Grueso | 2 | Ciencia popular | 2 |
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 duplicidades, cada atributo de clave no candidata debe depender de la clave candidata completa, no solo de parte de ella.
Para normalizar esta tabla, haga que {Título} sea una clave candidata (simple) (la clave principal) para que cada atributo de clave no candidata dependa de la clave candidata completa, y elimine Price en una tabla separada para que su dependencia del formato se pueda conservar:
|
|
Ahora, la tabla de libros cumple con 2NF.
Satisfacer 3NFEdit
La tabla de libros todavía tiene una dependencia funcional transitiva ({Author Nationality} depende de {Author}, que depende de {Title }). Existe una infracción similar para el género ({Genre Name} depende de {Genre ID}, que depende de {Title}). Por tanto, la tabla Book no está en 3NF. Para hacerlo en 3NF, usemos la siguiente estructura de tabla, eliminando así las dependencias funcionales transitivas colocando {Author Nationality} y {Genre Name} en sus propias tablas respectivas:
| Título | Autor | Páginas | Espesor | Genre ID | Publisher ID |
|---|---|---|---|---|---|
| Diseño de base de datos MySQL inicial y Optimización | Chad Russell | 520 | Grueso | 1 | 1 |
| El modelo relacional para la administración de bases de datos: Versión 2 | EFCodd | 538 | Grueso | 2 | 2 |
|
| Autor | Autor Nacionalidad |
|---|---|
| Chad Russell | Americano |
| EFCodd | Británico |
| Gen re ID | Nombre del género |
|---|---|
| 1 | Tutorial |
| 2 | Ciencia popular |
Satisfaciendo EKNFEdit
La forma normal de clave elemental (EKNF) cae estrictamente entre 3NF y BCNF y no se discute mucho en la literatura. Su objetivo es «capturar las cualidades sobresalientes de 3NF y BCNF» mientras se evitan 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.
Satisfacer 4NFEdit
Suponga que la base de datos es propiedad de una franquicia minorista de libros que tiene varias franquicias que poseen tiendas en diferentes ubicaciones.Y, por lo tanto, el minorista decidió agregar una tabla que contiene datos sobre la disponibilidad de los libros en diferentes ubicaciones:
| ID del franquiciado | Título | Ubicación |
|---|---|---|
| 1 | Diseño y optimización de bases de datos MySQL iniciales | California |
| 1 | Optimización y diseño de bases de datos MySQL iniciales | Florida |
| 1 | Principio del diseño y optimización de bases de datos MySQL | Texas |
| 1 | El modelo relacional para la gestión de bases de datos: versión 2 | California |
| 1 | El modelo relacional para la administración de bases de datos: versión 2 | Florida |
| 1 | El modelo relacional para la administración de bases de datos: versión 2 | Texas |
| 2 | Principio del diseño y optimización de bases de datos MySQL | California |
| 2 | Principios del diseño y optimización de bases de datos MySQL | Florida |
| 2 | Diseño y optimización de bases de datos MySQL iniciales | Texas |
| 2 | El modelo relacional para la administración de bases de datos: versión 2 | California |
| 2 | El modelo relacional para la administración de bases de datos: Versión 2 | Florida |
| 2 | El modelo relacional para la administración de bases de datos: Versión 2 | Texas |
| 3 | Principios del diseño y optimización de bases de datos MySQL | Texas |
Como esta estructura de tabla consiste en una clave primaria compuesta, no contiene ningún atributo que no sea de clave y ya está en BCNF (y por lo tanto también satisface todas las formas normales anteriores). Sin embargo, si asumimos que todos los libros disponibles se ofrecen en cada área, podríamos notar que 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:
|
|
||||||||||||
| ID de franquicia | Ubicación | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | California | ||||||||||||
| 1 | Florida | ||||||||||||
| 1 | Texas | ||||||||||||
| 2 | California | ||||||||||||
| 2 | Florida | ||||||||||||
| 2 | Texas | ||||||||||||
| 3 | Texas |
Ahora, cada registro se identifica de manera inequívoca con una superclave, por lo tanto, 4NF se satisface.
Satisfacer ETNFEdit
Supongamos que los franquiciados también pueden pedir libros de diferentes proveedores. Deje que la relación también esté sujeta a la siguiente restricción:
- Si un determinado proveedor proporciona un determinado título
- y el título se proporciona al franquiciado
- y el franquiciado está siendo suministrado por el proveedor,
- luego el proveedor proporciona el título al franquiciado.
| ID de proveedor | Título | ID de franquicia |
|---|---|---|
| 1 | Diseño y optimización de base de datos MySQL inicial | 1 |
| 2 | El modelo relacional para la gestión de bases de datos: Versión 2 | 2 |
| 3 | Aprendiendo SQL | 3 |
Esta tabla está en 4NF, pero el ID del proveedor es igual a la combinación de sus proyecciones: {{ID del proveedor, libro}, {libro, ID del franquiciado}, {ID del franquiciado, proveedor IDENTIFICACIÓN}}.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 se puede descomponer aún más:
|
|
|
La descomposición produce cumplimiento con ETNF.
Satisfacer 5NFEdit
Para detectar una tabla que no cumple con 5NF, Por lo general, es necesario examinar los datos a fondo. Suponga que la tabla del ejemplo 4NF con una pequeña modificación en los datos y examinemos si satisface 5NF:
| ID del franquiciado | Título | Ubicación |
|---|---|---|
| 1 | Principios del diseño y optimización de bases de datos MySQL | California |
| 1 | Aprendiendo SQL | California |
| 1 | El modelo relacional para la administración de bases de datos: versión 2 | Texas |
| 2 | El modelo relacional para la administración de bases de datos: versión 2 | California |
Si descomponemos esta tabla, reducimos las redundancias y obtenemos las siguientes dos tablas:
|
|
¿Qué sucede si intentamos unirnos a estas tablas? La consulta devolvería los siguientes datos:
| Franquiciado ID | Título | Ubicación |
|---|---|---|
| 1 | Diseño de base de datos MySQL inicial y Optimización | California |
| 1 | Aprendizaje de SQL | California |
| 1 | El modelo relacional para la gestión de bases de datos: versión 2 | California |
| 1 | El modelo relacional para la administración de bases de datos: Versión 2 | Texas |
| 1 | Aprendizaje de SQL | Texas |
| 1 | Principio del diseño y optimización de bases de datos MySQL | Texas |
| 2 | El modelo relacional para la administración de bases de datos: versión 2 | California |
Aparentemente, JOIN devuelve tres filas más de las que debería. Intentemos añadir otro. Hay otra tabla para aclarar la relación.Terminamos con tres tablas separadas:
|
|
|
¿Qué devolverá el JOIN ahora? En realidad, no es posible unir estas tres tablas. Eso significa que no fue posible descomponer el Franquiciado – Ubicación del libro sin pérdida de datos, por lo que la tabla ya satisface 5NF.
CJ Date ha argumentado que solo una base de datos en 5NF está verdaderamente «normalizada».
Satisfacer DKNFEdit
Echemos un vistazo a la tabla de libros de ejemplos anteriores y veamos si satisface la forma normal de clave de dominio:
| Título | Páginas | Espesor | Genre ID | Publisher ID | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Diseño y optimización de bases de datos MySQL iniciales | 520 | Grueso | 1 | 1 | ||||||||||||||||||||||||||
| El modelo relacional para la gestión de bases de datos: versión 2 | 538 | Grueso | 2 | 2 | ||||||||||||||||||||||||||
| Aprendiendo SQL | 338 | Slim | 1 | 3 | ||||||||||||||||||||||||||
| Libro de recetas SQL | 636 | Grueso | 1 | 3 |
|
|
De esa manera, la violación de la integridad del dominio se ha eliminado y la tabla está en DKNF.
Satisfacer 6NFEdit
Una definición simple e intuitiva de la sexta forma normal es que «una tabla está en 6NF cuando la fila contiene la clave principal y, como máximo, otro atributo».
Eso significa, por ejemplo, la tabla Publisher diseñada al crear el 1NF
| Publisher_ID | Nombre | País |
|---|---|---|
| 1 | Apress | EE. UU. |
debe ser más descompuesto en dos tablas:
|
|
El inconveniente obvio de 6NF es la proliferación de tablas necesarias para representar la información en una sola entidad. Si una tabla en 5NF tiene una columna de clave primaria y N atributos, la representación de la misma información en 6NF requerirá N tablas; las actualizaciones de varios campos a un solo registro conceptual requerirán actualizaciones de varias tablas; y las inserciones y eliminaciones requerirán operaciones de manera similar en varias tablas. Por esta razón, en bases de datos destinadas a satisfacer las necesidades de procesamiento de transacciones en línea, no se debe usar 6NF.
Sin embargo, en almacenes de datos, que no permiten actualizaciones interactivas y que están especializados para consultas rápidas en grandes volúmenes de datos. , ciertos DBMS utilizan una representación interna 6NF, 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 un ahorro significativo 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).
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 DBMS que están especializados para el almacenamiento, como Sybase IQ, utilizan el almacenamiento en columnas de forma predeterminada, pero el diseñador sigue viendo solo una tabla de varias columnas. Otros DBMS, como Microsoft SQL Server 2012 y versiones posteriores, le permiten especificar un «índice de almacén de columnas» para una tabla en particular.
