La normalización de la base de datos es el proceso de estructurar una base de datos , generalmente una base de datos relacional , de acuerdo con una serie de los llamados formularios normales para reducir la redundancia de datos y mejorar la integridad de los datos . Fue propuesto por primera vez por 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 apliquen correctamente mediante 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).
Objetivos
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 "sub-lenguaje de datos universal" basado en la lógica de primer orden . [1] ( SQL es un ejemplo de un sub-lenguaje de datos de este tipo, aunque Codd consideró que tenía graves defectos. [2] )
Los objetivos de normalización más allá de 1NF (primera forma normal) fueron establecidos por Codd de la siguiente manera:
- Para 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 la base de datos" [3]
Cuando se intenta modificar (actualizar, insertar o eliminar) una relación, pueden surgir los siguientes efectos secundarios indeseables en las relaciones que no se han normalizado lo suficiente:
- Actualizar anomalía. La misma información se puede expresar en varias filas; por lo tanto, las actualizaciones de la relación pueden resultar en inconsistencias lógicas. Por ejemplo, cada registro en una relación "Habilidades de los empleados" puede contener un ID de empleado, Dirección de empleado y Habilidad; por lo tanto, es posible que sea necesario aplicar un cambio de dirección para un empleado en particular a varios registros (uno para cada habilidad). Si la actualización es sólo parcialmente exitosa, la dirección del empleado se actualiza en algunos registros pero no en otros, entonces la relación se deja en un estado inconsistente. Específicamente, la relación proporciona respuestas contradictorias a la pregunta de cuál es la dirección de este empleado en particular. Este fenómeno se conoce como anomalía de actualización.
- Anomalía de inserción. Hay circunstancias en las que ciertos hechos no pueden registrarse en absoluto. Por ejemplo, cada registro en una relación "Profesorado y sus cursos" puede contener un ID de profesor, Nombre de profesor, Fecha de contratación de profesor y Código de curso. Por lo tanto, podemos registrar los detalles de cualquier miembro de la facultad que imparta al menos un curso, pero no podemos registrar a un miembro de la facultad recién contratado que aún no haya sido asignado para impartir ningún curso, excepto estableciendo el Código del curso en nulo . Este fenómeno se conoce como anomalía de inserción.
- Anomalía de eliminación. En determinadas circunstancias, la eliminación de datos que representan ciertos hechos requiere la eliminación de datos que representan hechos completamente diferentes. La relación "Facultad y sus Cursos" descrita en el ejemplo anterior adolece de este tipo de anomalía, pues si un miembro de la facultad deja temporalmente de estar asignado a algún curso, debemos borrar el último de los registros en los que figura ese profesor, efectivamente también eliminando al miembro de la facultad, a menos que establezcamos el Código del curso en nulo. Este fenómeno se conoce como anomalía de deleción.
Minimice el rediseño al ampliar la estructura de la base de datos
Una base de datos completamente normalizada permite que su estructura se extienda para adaptarse 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.
Ejemplo
Consultar y manipular los datos dentro de una estructura de datos que no está normalizada, como la siguiente representación no 1NF de las transacciones de tarjetas de crédito de los clientes, implica más complejidad de la realmente necesaria:
Cliente | Cust. IDENTIFICACIÓN | Actas | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Abrahán | 1 |
| ||||||||||||
Isaac | 2 |
| ||||||||||||
Jacob | 3 |
|
A cada cliente le corresponde un 'grupo repetitivo' de transacciones. La evaluación automatizada de cualquier consulta relacionada con las transacciones de los clientes, por lo tanto, implicaría en general dos etapas:
- Desembalar uno o más grupos de transacciones de clientes que permitan examinar las transacciones individuales de un grupo, y
- Derivar un resultado de consulta basado en los resultados de la primera etapa
Por ejemplo, para averiguar la suma monetaria de todas las transacciones que ocurrieron en octubre de 2003 para todos los clientes, el sistema tendría que saber que primero debe descomprimir el grupo de Transacciones de cada cliente, luego sumar los Montos de todas las transacciones así obtenidas. donde la Fecha de la transacción cae en octubre de 2003.
Una de las ideas importantes de Codd fue que se puede reducir la complejidad estructural. La complejidad estructural reducida brinda a los usuarios, aplicaciones y DBMS más poder y flexibilidad para formular y evaluar las consultas. Un equivalente más normalizado de la estructura anterior podría verse así:
Cliente | Cust. IDENTIFICACIÓN |
---|---|
Abrahán | 1 |
Isaac | 2 |
Jacob | 3 |
Cust. IDENTIFICACIÓN | Tr. IDENTIFICACIÓN | Fecha | Monto |
---|---|---|---|
1 | 12890 | 14 de octubre de 2003 | −87 |
1 | 12904 | 15 de octubre de 2003 | −50 |
2 | 12898 | 14 de octubre de 2003 | −21 |
3 | 12907 | 15 de octubre de 2003 | −18 |
3 | 14920 | 20 de noviembre de 2003 | −70 |
3 | 15003 | 27 de noviembre de 2003 | −60 |
En la estructura modificada, la clave principal es {Cust. ID} en la primera relación, {Cust. ID, Tr. ID} en la segunda relación.
Ahora cada fila representa una transacción de tarjeta de crédito individual, y el DBMS puede obtener la respuesta de interés, simplemente encontrando todas las filas con una Fecha que cae en octubre y sumando sus Cantidades. La estructura de datos coloca todos los valores en pie de igualdad, exponiendo a cada uno directamente al DBMS, por lo que cada uno puede potencialmente participar directamente en las consultas; mientras que en la situación anterior algunos valores estaban incrustados en estructuras de nivel inferior que debían manejarse de manera especial. En consecuencia, el diseño normalizado se presta al procesamiento de consultas de propósito general, mientras que el diseño no normalizado no lo hace. La versión normalizada también permite al usuario cambiar el nombre del cliente en un solo lugar y protege contra errores que surgen si el nombre del cliente está mal escrito en algunos registros (ver "anomalía de actualización" más arriba).
Formas normales
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 (de la menos normalizada a la más normalizada) son:
- UNF: forma no normalizada
- 1NF: Primera forma normal
- 2NF: Segunda forma normal
- 3NF: Tercera forma normal
- EKNF: forma normal de tecla elemental
- BCNF: forma normal de Boyce-Codd
- 4NF: Cuarta forma normal
- ETNF: forma normal de tupla esencial
- 5NF: Quinta forma normal
- DKNF: forma normal de clave de dominio
- 6NF: Sexta forma normal
UNF (1970) | 1NF (1970) | 2NF (1971) | 3NF (1971) | EKNF (1982) | BCNF (1974) | 4NF (1977) | ETNF (2012) | 5NF (1979) | DKNF (1981) | 6NF (2003) | |
---|---|---|---|---|---|---|---|---|---|---|---|
Clave principal (sin tuplas duplicadas ) | |||||||||||
Columnas atómicas (las celdas tienen un solo valor) [8] | |||||||||||
Cada dependencia funcional no trivial no comienza con un subconjunto adecuado de una clave candidata o termina con un atributo principal (no hay dependencias funcionales parciales de atributos no principales en claves candidatas) [8] | |||||||||||
Cada dependencia funcional no trivial comienza con una superclave o termina con un atributo principal (no hay dependencias funcionales transitivas de atributos no principales en claves candidatas) [8] | |||||||||||
Cada dependencia funcional no trivial comienza con una superclave o termina con un atributo primo elemental [8] | N / A | ||||||||||
Cada dependencia funcional no trivial comienza con una superclave [8] | N / A | ||||||||||
Toda dependencia multivalor no trivial comienza con una superclave [8] | N / A | ||||||||||
Cada dependencia de unión tiene un componente de superclave [9] | N / A | ||||||||||
Cada dependencia de unión tiene solo componentes de superclave [8] | N / A | ||||||||||
Cada restricción es una consecuencia de las restricciones de dominio y las restricciones clave [8] | |||||||||||
Cada dependencia de unión es trivial [8] |
Ejemplo de normalización paso a paso
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. [10] 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. [11]
Eso significa que, teniendo 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 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. [12]
Tenga en cuenta que 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 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.
Datos iniciales
Deje que exista una tabla de base de datos con la siguiente estructura: [11]
Título | Autor | Nacionalidad del autor | Formato | Precio | Sujeto | Paginas | Grosor | Editor | País del editor | Tipo de publicación | ID de género | Nombre del género | |||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Inicio del diseño y optimización de bases de datos MySQL | Chad Russell | americano | De tapa dura | 49,99 |
| 520 | Grueso | Presionar | EE.UU | Libro electronico | 1 | Tutorial |
Suponemos en este ejemplo 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 exclusiva una fila. Dos libros pueden tener el mismo título, pero un número ISBN identifica un libro de forma única, por lo que podemos usarlo como clave principal:
ISBN # | Título | Autor | Nacionalidad del autor | Formato | Precio | Sujeto | Paginas | Grosor | Editor | País del editor | Tipo de publicación | ID de género | Nombre del género | |||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1590593324 | Inicio del diseño y optimización de bases de datos MySQL | Chad Russell | americano | De tapa dura | 49,99 |
| 520 | Grueso | Presionar | EE.UU | Libro electronico | 1 | Tutorial |
Satisfactorio 1NF
Para satisfacer la primera forma normal , cada columna de una tabla debe tener un solo valor. Las columnas contienen conjuntos de valores o no se permiten registros anidados.
En la tabla inicial, Subject contiene un conjunto de valores de sujeto, lo que significa que no cumple.
Una forma de lograr el 1NF sería separar las duplicidades en múltiples columnas distintas Asunto 1 , Asunto 2, etc.
ISBN # | Título | Formato | Autor | Nacionalidad del autor | Precio | Asunto 1 | Asunto 2 | Asunto 3 | Paginas | Grosor | Editor | País del editor | ID de género | Nombre del género |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1590593324 | Inicio del diseño y optimización de bases de datos MySQL | De tapa dura | Chad Russell | americano | 49,99 | MySQL | Base de datos | Diseño | 520 | Grueso | Presionar | 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, que en lugar de extraer los sujetos en una separada Asunto tabla: [11]
ISBN # | Título | Formato | Autor | Nacionalidad del autor | Precio | Paginas | Grosor | Editor | País del editor | ID de género | Nombre del género |
---|---|---|---|---|---|---|---|---|---|---|---|
1590593324 | Inicio del diseño y optimización de bases de datos MySQL | De tapa dura | Chad Russell | americano | 49,99 | 520 | Grueso | Presionar | EE.UU | 1 | Tutorial |
Agregamos una columna de clave externa a la tabla Asunto que se refiere a la clave principal de la fila de donde extrajimos el tema. 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 cumplen con la 1NF. Satisfactorio 2NFLa tabla Libro tiene una clave candidata (que, por lo tanto, es la clave principal ), la clave compuesta {Título, Formato} . [13] Considere el siguiente fragmento de 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 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 {Título} 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 Price en una tabla separada para que su dependencia del formato pueda ser Preservado:
Ahora, la mesa Book se ajusta a 2NF . Satisfactorio 3NFLa tabla Libro todavía tiene una dependencia funcional transitiva ({Autor Nacionalidad} depende de {Autor}, que depende de {Título}). Existe una violación similar para el género ({Genre Name} depende de {Genre ID}, que depende de {Title}). Por lo 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:
Satisfaciendo a EKNFLa forma normal de clave elemental (EKNF) se encuentra 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 tolerante" y BCNF es "propenso a la complejidad computacional"). Dado que rara vez se menciona en la literatura, no se incluye en este ejemplo. [14] Satisfactorio 4NFSuponga 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:
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, 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:
Ahora, cada registro se identifica de forma inequívoca mediante una superclave , por lo que se satisface 4NF . [15] ETNF satisfactorioSuponga que los franquiciados también pueden solicitar libros de diferentes proveedores. Deje que la relación también esté sujeta a la siguiente restricción:
Esta tabla está en 4NF , pero el ID de proveedor es igual a la combinación de sus proyecciones: {{ID de proveedor, libro}, {libro, ID de franquiciado}, {ID de franquiciado, ID de 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 se puede descomponer aún más: [16]
La descomposición produce el cumplimiento de ETNF . Satisfactorio 5NFPara detectar una tabla que no satisface el 5NF , generalmente es necesario examinar los datos a fondo. Supongamos que la tabla del ejemplo 4NF con una pequeña modificación en los datos y examinemos si satisface 5NF :
Si descomponemos esta tabla, reducimos las redundancias y obtenemos las siguientes dos tablas:
¿Qué pasa si intentamos unirnos a estas mesas? La consulta devolvería los siguientes datos:
Aparentemente, JOIN devuelve tres filas más de las que debería; intentemos agregar 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 cumple con 5NF . [15] CJ Date ha argumentado que solo una base de datos en 5NF está verdaderamente "normalizada". [17] Satisfaciendo a DKNFEchemos un vistazo a la tabla de libros de ejemplos anteriores y veamos si satisface la forma normal de clave de dominio :
Lógicamente, el grosor está determinado por el número de páginas. Eso significa que depende de Pages, que no es una clave. Establezcamos una convención de ejemplo 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 las restricciones de dominio y las restricciones clave para mantener la integridad de los datos. En otras palabras, nada nos impide poner, por ejemplo, "Grueso" para un libro de solo 50 páginas, y esto hace que la tabla viole DKNF . Para resolver esto, podemos crear una tabla que contenga una enumeración que defina el Espesor y eliminar esa columna de la tabla original:
De esa forma, se ha eliminado la violación de la integridad del dominio y la tabla está en DKNF . Satisfactorio 6NFUna 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 mucho, otro atributo" . [18] 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 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 para un solo registro conceptual requerirán actualizaciones de 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 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, muestra 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 única 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. [19] Ver también
notas y referencias
Otras lecturas
enlaces externos
|