Matriz en fase
(leer más)
Normalización de bases de datos o normalización de bases de datos (ver diferencias ortográficas) es el proceso de estructurar una base de datos relacional de acuerdo con una serie de las llamadas formas normales para reducir redundancia de datos y mejorar la integridad de los datos. Fue propuesto por primera vez por el científico informático británico Edgar F. Codd como parte de su modelo relacional.
La normalización implica organizar las columnas (atributos) y las tablas (relaciones) de una base de datos para garantizar que sus dependencias se cumplan correctamente mediante las restricciones de integridad de la base de datos. Se logra aplicando algunas reglas formales mediante un proceso de síntesis (creación de un nuevo diseño de base de datos) o descomposición (mejora del diseño de una base de datos existente).
Un objetivo básico de la primera forma normal definida por Codd en 1970 era permitir que los datos se consultaran y manipularan utilizando un "sublenguaje de datos universal" basado en la lógica de primer orden. Un ejemplo de tal lenguaje es SQL, aunque es uno que Codd consideró como seriamente defectuoso. Las bases de datos a menudo se normalizan mediante parámetros heurísticos de entrada adaptativos, lo que se logra fácilmente con una fracción de la asignación de procesamiento utilizada por métodos como la interpolación de subclases.
Codd estableció los objetivos de la normalización más allá de 1FN (primera forma normal):
- Liberar la colección de relaciones de dependencias de inserción, actualización y eliminación indeseables.
- Para 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.
- Para hacer el modelo relacional más informativo a los usuarios.
- Para hacer que la recopilación de relaciones sea neutral a las estadísticas de consulta, donde estas estadísticas puedan cambiar a medida que pasa el tiempo.
—E.F. Codd, "Más Normalización del Modelo Relacional Base de Datos"
Cuando se intenta modificar (actualizar, insertar o eliminar) una relación, pueden surgir los siguientes efectos secundarios indeseables en relaciones que no se han normalizado lo suficiente:
Una base de datos completamente normalizada permite que su estructura se amplíe para acomodar 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. Codd pasó a definir la segunda forma normal (2NF) y la tercera forma normal (3NF) en 1971, y Codd y Raymond F. Boyce definió la forma normal de Boyce-Codd (BCNF) en 1974.
De manera informal, una relación de base de datos relacional a menudo se describe como "normalizada" si cumple con la tercera forma normal. La mayoría de las relaciones 3FN 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:
Constraint (descripción informativa en paréntesis) | UNF (1970) | 1NF (1970) | 2NF (1971) | 3NF (1971) | EKNF (1982) | BCNF (1974) | 4NF (1977) | ETNF (2012) | 5NF (1979) | DKNF (1981) | 6NF (2003) |
---|---|---|---|---|---|---|---|---|---|---|---|
filas únicas (sin registros duplicados) | |||||||||||
Columnas de escalar (los columnas no pueden contener relaciones o valores compuestos) | |||||||||||
Cada atributo no-prime tiene una dependencia funcional completa de una clave candidata (atributos dependen de la completo clave primaria) | |||||||||||
Cada dependencia funcional no-trivial comienza con un superkey o termina con un atributo primario (atributos dependen) sólo sobre la clave primaria) | |||||||||||
Cada dependencia funcional no-trivial comienza con un superkey o termina con un atributo primario elemental (una forma más estricta de 3NF) | — | ||||||||||
Cada dependencia funcional no-trivial comienza con un superkey (una forma más estricta de 3NF) | — | ||||||||||
Cada dependencia multivalorada no-trivial comienza con un superkey | — | ||||||||||
Cada dependencia de la unión tiene un componente de superkey | — | ||||||||||
Cada dependencia de la unión tiene sólo componentes superkey | — | ||||||||||
Cada limitación es consecuencia de limitaciones de dominio y limitaciones clave | |||||||||||
Cada dependencia es trivial |
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 mayor nivel de normalización de la base de datos a menos que se hayan satisfecho los niveles anteriores.
Eso significa que, al tener datos en forma no normalizada (la menos normalizada) y con el objetivo de lograr el nivel más alto de normalización, el primer paso sería garantizar el cumplimiento de la primera forma normal, el segundo paso sería garantizar la segunda forma normal se satisface, 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.
Los datos del siguiente ejemplo se diseñaron 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 suele ocurrir que corregir una violación de una forma normal también corrige una violación de una forma normal superior en el proceso. También se eligió una tabla para la normalización en cada paso, lo que significa que al final de este proceso de ejemplo, es posible que aún haya algunas tablas que no satisfagan la forma normal más alta.
Deje que exista una tabla de base de datos con la siguiente estructura:
Título | Autor | Autor Nationality | Formato | Precio | Asunto | Páginas | Espesor | Publisher | Publisher Country | Tipo de publicación | Genre ID | Nombre genérico | |||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Inicio de MySQL Diseño y optimización de bases de datos | Chad Russell | American | Cubierta dura | 49.99 |
| 520 | Ladrón | Apress | USA | E-book | 1 | Tutorial |
Para este ejemplo, se supone que cada libro tiene un solo autor.
Como requisito previo para ajustarse al modelo relacional, una tabla debe tener una clave principal, que identifica de forma única una fila. Dos libros pueden tener el mismo título, pero un ISBN identifica un libro de forma única, por lo que puede usarse como clave principal:
ISBN | Título | Autor | Autor Nationality | Formato | Precio | Asunto | Páginas | Espesor | Publisher | Publisher Country | Tipo de publicación | Genre ID | Nombre genérico | |||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1590593324 | Inicio de MySQL Diseño y optimización de bases de datos | Chad Russell | American | Cubierta dura | 49.99 |
| 520 | Ladrón | Apress | USA | E-book | 1 | Tutorial |
Para satisfacer la Primera forma normal, cada columna de una tabla debe tener un solo valor. No se permiten columnas que contengan conjuntos de valores o registros anidados.
En la tabla inicial, Asunto contiene un conjunto de valores de asunto, lo que significa que no cumple.
Para resolver el problema, los temas se extraen en una tabla Asunto separada:
ISBN | Título | Formato | Autor | Autor Nationality | Precio | Páginas | Espesor | Publisher | País editor | Genre ID | Nombre genérico |
---|---|---|---|---|---|---|---|---|---|---|---|
1590593324 | Inicio de MySQL Diseño y optimización de bases de datos | Cubierta dura | Chad Russell | American | 49.99 | 520 | Ladrón | Apress | USA | 1 | Tutorial |
ISBN | Nombre del sujeto |
---|---|
1590593324 | MySQL |
1590593324 | Base de datos |
1590593324 | Diseño |
Se agrega una columna de clave externa a la tabla Asunto, que hace referencia a la clave principal de la fila de la que se extrajo el asunto. Por lo tanto, se representa la misma información pero sin el uso de dominios no simples.
En lugar de una tabla en forma no normalizada, ahora hay dos tablas que se ajustan a la 1NF.
Si una tabla tiene una clave principal de una sola columna, automáticamente satisface 2NF, pero si una tabla tiene una clave compuesta o de varias columnas, es posible que no satisfaga 2NF.
La siguiente tabla Libro tiene una clave compuesta de {Título, Formato} (indicado por el subrayado), por lo que es posible que no satisfaga 2FN. 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:
Título | Formato | Autor | Autor Nationality | Precio | Páginas | Espesor | Genre ID | Nombre genérico | ID de editor |
---|---|---|---|---|---|---|---|---|---|
Inicio de MySQL Diseño y optimización de bases de datos | Cubierta dura | Chad Russell | American | 49.99 | 520 | Ladrón | 1 | Tutorial | 1 |
Inicio de MySQL Diseño y optimización de bases de datos | E-book | Chad Russell | American | 22.34 | 520 | Ladrón | 1 | Tutorial | 1 |
El modelo de relación para la gestión de bases de datos: Versión 2 | E-book | E.F.Codd | Británica | 13.88 | 538 | Ladrón | 2 | Ciencias populares | 2 |
El modelo de relación para la gestión de bases de datos: Versión 2 | Paperback | E.F.Codd | Británica | 39.99 | 538 | Ladrón | 2 | Ciencias populares | 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, convierta a {Title} en una clave candidata (simple) (la clave principal) para que cada atributo que no sea clave candidata dependa de la clave candidata completa y elimine Precio en una tabla separada para que su dependencia de Formato se pueda conservar:
|
| |||||||||||||||||||||||||||||||||||||||
|
Ahora, la tabla Libro se ajusta a 2NF.
La tabla Libro todavía tiene una dependencia funcional transitiva ({Nacionalidad del autor} depende de {Autor}, que depende de {Título}). Existe una infracción similar para el género ({Genre Name} depende de {Genre ID}, que depende de {Title}). Por lo tanto, la tabla Libro no está en 3FN. Para hacerlo en 3NF, usemos la siguiente estructura de tabla, eliminando así las dependencias funcionales transitivas al colocar {Nacionalidad del autor} y {Nombre del género} en sus propias tablas respectivas:
Título | Autor | Páginas | Espesor | Genre ID | ID de editor |
---|---|---|---|---|---|
Inicio de MySQL Diseño y optimización de bases de datos | Chad Russell | 520 | Ladrón | 1 | 1 |
El modelo de relación para la gestión de bases de datos: Versión 2 | E.F.Codd | 538 | Ladrón | 2 | 2 |
|
Autor | Autor Nationality |
---|---|
Chad Russell | American |
E.F.Codd | Británica |
Genre ID | Nombre genérico |
---|---|
1 | Tutorial |
2 | Ciencias populares |
La forma normal clave elemental (EKNF) cae estrictamente entre 3NF y BCNF y no se discute mucho en la literatura. Su objetivo es "capturar las cualidades sobresalientes tanto de 3NF como de FNBC" mientras se evitan los problemas de ambos (es decir, que 3NF es "demasiado tolerante" y FNBC es "propenso a la complejidad computacional"). Dado que rara vez se menciona en la literatura, no se incluye en este ejemplo.
Suponga 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 lo tanto, el minorista decidió agregar una tabla que contiene datos sobre la disponibilidad de los libros en diferentes ubicaciones:
ID de Franchisee | Título | Ubicación |
---|---|---|
1 | Inicio de MySQL Diseño y optimización de bases de datos | California |
1 | Inicio de MySQL Diseño y optimización de bases de datos | Florida |
1 | Inicio de MySQL Diseño y optimización de bases de datos | Texas |
1 | El modelo de relación para la gestión de bases de datos: Versión 2 | California |
1 | El modelo de relación para la gestión de bases de datos: Versión 2 | Florida |
1 | El modelo de relación para la gestión de bases de datos: Versión 2 | Texas |
2 | Inicio de MySQL Diseño y optimización de bases de datos | California |
2 | Inicio de MySQL Diseño y optimización de bases de datos | Florida |
2 | Inicio de MySQL Diseño y optimización de bases de datos | Texas |
2 | El modelo de relación para la gestión de bases de datos: Versión 2 | California |
2 | El modelo de relación para la gestión de bases de datos: Versión 2 | Florida |
2 | El modelo de relación para la gestión de bases de datos: Versión 2 | Texas |
3 | Inicio de MySQL Diseño y optimización de bases de datos | Texas |
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á ligado sin ambigüedades a una determinada Ubicación y, por lo tanto, la tabla no satisface la 4NF.
Eso significa que, para satisfacer la cuarta forma normal, esta tabla también debe descomponerse:
|
|
Ahora, cada registro se identifica de forma inequívoca 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:
ID de proveedor | Título | ID de Franchisee |
---|---|---|
1 | Inicio de MySQL Diseño y optimización de bases de datos | 1 |
2 | El modelo de relación para la gestión de bases de datos: Versión 2 | 2 |
3 | Aprender SQL | 3 |
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 combinació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 el cumplimiento de ETNF.
Para detectar una tabla que no cumple con el 5NF, generalmente es necesario examinar los datos a fondo. Supongamos la tabla del ejemplo 4NF con una pequeña modificación en los datos y examinemos si satisface 5NF:
ID de Franchisee | Título | Ubicación |
---|---|---|
1 | Inicio de MySQL Diseño y optimización de bases de datos | California |
1 | Aprender SQL | California |
1 | El modelo de relación para la gestión de bases de datos: Versión 2 | Texas |
2 | El modelo de relación para la gestión de bases de datos: Versión 2 | California |
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:
ID de Franchisee | Título | Ubicación |
---|---|---|
1 | Inicio de MySQL Diseño y optimización de bases de datos | California |
1 | Aprender SQL | California |
1 | El modelo de relación para la gestión de bases de datos: Versión 2 | California |
1 | El modelo de relación para la gestión de bases de datos: Versión 2 | Texas |
1 | Aprender SQL | Texas |
1 | Inicio de MySQL Diseño y optimización de bases de datos | Texas |
2 | El modelo de relación para la gestión de bases de datos: Versión 2 | California |
El JOIN devuelve tres filas más de lo 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 tablas. 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.
C.J. Date ha argumentado que solo una base de datos en 5NF está realmente 'normalizada'.
Echemos un vistazo a la tabla Libro de los ejemplos anteriores y veamos si satisface la forma normal de clave de dominio:
Título | Páginas | Espesor | Genre ID | ID de editor |
---|---|---|---|---|
Inicio de MySQL Diseño y optimización de bases de datos | 520 | Ladrón | 1 | 1 |
El modelo de relación para la gestión de bases de datos: Versión 2 | 538 | Ladrón | 2 | 2 |
Aprender SQL | 338 | Slim | 1 | 3 |
SQL Cookbook | 636 | Ladrón | 1 | 3 |
Lógicamente, el Grosor viene determinado por el número de páginas. Eso significa que depende de Páginas que no es una clave. Establezcamos una convención de ejemplo diciendo 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 depender de 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 con solo 50 páginas, y esto hace que la tabla viole 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, la violación de la integridad del dominio ha sido eliminada y la tabla está en DKNF.
Una definición simple e intuitiva de la sexta forma normal es que "una tabla está en 6FN cuando la fila contiene la clave principal y, como máximo, otro atributo".
Eso significa, por ejemplo, la tabla Editor diseñada al crear el 1NF
ID de editor | Nombre | País |
---|---|---|
1 | Apress | USA |
debe descomponerse aún más en dos tablas:
|
|
La desventaja obvia 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, representar la misma información en 6NF requerirá N tablas; las actualizaciones de varios campos en un solo registro conceptual requerirán actualizaciones en varias tablas; y las inserciones y eliminaciones también requerirán operaciones en varias tablas. Por esta razón, en las bases de datos destinadas a satisfacer las necesidades de procesamiento de transacciones en línea, no se debe utilizar 6NF.
Sin embargo, en los 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 donde la cantidad de valores únicos de una columna es mucho menor que la cantidad de filas en la tabla, el almacenamiento orientado a columnas permite ahorros significativos en espacio a través de 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 de 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 aún ve 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 mesa en particular.
(leer más)
(leer más)
Las preguntas básicas abordadas por la teoría de la computabilidad... (leer más)