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 enseñe 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 ) | |||||||||||
Sin grupos repetidos | |||||||||||
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 | MySQL, Base de datos, Diseño | 520 | Grueso | Presionar | EE.UU | Libro electronico | 1 | Tutorial |
Suponemos en este ejemplo que cada libro tiene un solo autor.
Satisfactorio 1NF
Para satisfacer 1NF, los valores en cada columna de una tabla deben ser atómicos. 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 usando grupos repetidos Asunto :
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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, 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 : [11]
Título | Formato | Autor | Nacionalidad del autor | Precio | Paginas | Grosor | ID de género | Nombre del género | ID de editor |
---|---|---|---|---|---|---|---|---|---|
Inicio del diseño y optimización de bases de datos MySQL | De tapa dura | Chad Russell | americano | 49,99 | 520 | Grueso | 1 | Tutorial | 1 |
|
|
La simple separación de los datos iniciales en varias tablas rompería la conexión entre los datos. Eso significa que se deben determinar las relaciones entre las tablas recién introducidas. Observe que la columna ID de editor en la tabla del libro es una clave externa que realiza una relación de muchos a uno entre un libro y un editor.
Un libro puede adaptarse a muchos temas, así como un tema puede corresponder a muchos libros. Eso significa que también se debe definir una relación de muchos a muchos , lograda mediante la creación de una tabla de vínculos : [11]
|
En lugar de una tabla en forma no normalizada , ahora hay 4 tablas que cumplen con la 1NF.
Satisfactorio 2NF
La 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:
Título | Formato | Autor | Nacionalidad del autor | Precio | Paginas | Grosor | ID de género | Nombre del género | ID de editor |
---|---|---|---|---|---|---|---|---|---|
Inicio del diseño y optimización de bases de datos MySQL | De tapa dura | Chad Russell | americano | 49,99 | 520 | Grueso | 1 | Tutorial | 1 |
Inicio del diseño y optimización de bases de datos MySQL | Libro electronico | 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 electronico | EFCodd | británico | 13,88 | 538 | Grueso | 2 | Ciencia popular | 2 |
El modelo relacional para la gestión de bases de datos: versión 2 | Libro de bolsillo | 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, 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 3NF
La 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:
Título | Autor | Paginas | Grosor | ID de género | ID de editor |
---|---|---|---|---|---|
Inicio del diseño y optimización de bases de datos MySQL | Chad Russell | 520 | Grueso | 1 | 1 |
El modelo relacional para la gestión de bases de datos: versión 2 | EFCodd | 538 | Grueso | 2 | 2 |
|
Autor | Nacionalidad del autor |
---|---|
Chad Russell | americano |
EFCodd | británico |
ID de género | Nombre del género |
---|---|
1 | Tutorial |
2 | Ciencia popular |
Satisfaciendo a EKNF
La 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 4NF
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 de franquiciado | Título | Localización |
---|---|---|
1 | Inicio del diseño y optimización de bases de datos MySQL | California |
1 | Inicio del diseño y optimización de bases de datos MySQL | Florida |
1 | Inicio 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 gestión de bases de datos: versión 2 | Florida |
1 | El modelo relacional para la gestión de bases de datos: versión 2 | Texas |
2 | Inicio del diseño y optimización de bases de datos MySQL | California |
2 | Inicio del diseño y optimización de bases de datos MySQL | Florida |
2 | Inicio del diseño y optimización de bases de datos MySQL | Texas |
2 | El modelo relacional para la gestión de bases de datos: versión 2 | California |
2 | El modelo relacional para la gestión de bases de datos: versión 2 | Florida |
2 | El modelo relacional para la gestión de bases de datos: versión 2 | Texas |
3 | Inicio del diseño y optimización de bases de datos MySQL | 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, 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 satisfactorio
Suponga 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:
- Si un determinado proveedor proporciona un determinado título
- y el título se entrega al franquiciado
- y el franquiciado está siendo suministrado por el proveedor,
- luego, el proveedor proporciona el título al franquiciado . [dieciséis]
Identificación del proveedor | Título | ID de franquiciado |
---|---|---|
1 | Inicio del diseño y optimización de bases de datos MySQL | 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 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 5NF
Para 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 :
ID de franquiciado | Título | Localización |
---|---|---|
1 | Inicio del diseño y optimización de bases de datos MySQL | California |
1 | Aprendiendo SQL | California |
1 | El modelo relacional para la gestión de bases de datos: versión 2 | Texas |
2 | El modelo relacional para la gestión de bases de datos: versión 2 | California |
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:
ID de franquiciado | Título | Localización |
---|---|---|
1 | Inicio del diseño y optimización de bases de datos MySQL | California |
1 | Aprendiendo SQL | California |
1 | El modelo relacional para la gestión de bases de datos: versión 2 | California |
1 | El modelo relacional para la gestión de bases de datos: versión 2 | Texas |
1 | Aprendiendo SQL | Texas |
1 | Inicio del diseño y optimización de bases de datos MySQL | Texas |
2 | El modelo relacional para la gestión de bases de datos: versión 2 | California |
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 DKNF
Echemos un vistazo a la tabla de libros de ejemplos anteriores y veamos si satisface la forma normal de clave de dominio :
Título | Paginas | Grosor | ID de género | ID de editor |
---|---|---|---|---|
Inicio del diseño y optimización de bases de datos MySQL | 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 | Delgado | 1 | 3 |
Libro de recetas SQL | 636 | Grueso | 1 | 3 |
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 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 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 6NF
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 mucho, otro atributo" . [18]
Eso significa, por ejemplo, la tabla Publisher diseñada al crear el 1NF
Publisher_ID | Nombre | País |
---|---|---|
1 | Presionar | EE.UU |
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
- Desnormalización
- Refactorización de base de datos
- Descomposición de unión sin pérdida
notas y referencias
- ^ "La adopción de un modelo relacional de datos ... permite el desarrollo de un sub-lenguaje de datos universal basado en un cálculo de predicados aplicado. Un cálculo de predicados de primer orden es suficiente si la colección de relaciones está en la primera forma normal. Tal el lenguaje proporcionaría una vara de medir el poder lingüístico para todos los demás lenguajes de datos propuestos, y sería en sí mismo un fuerte candidato para incrustarse (con la modificación sintáctica apropiada) en una variedad de lenguajes anfitriones (programación, orientada a comandos o problemas) ". Codd, "Un modelo relacional de datos para grandes bancos de datos compartidos" Archivado el 12 de junio de 2007, en Wayback Machine , p. 381
- ^ Codd, EF Capítulo 23, "Serios defectos en SQL", en El modelo relacional para la gestión de bases de datos: Versión 2 . Addison-Wesley (1990), págs. 371–389
- ^ Codd, EF "Mayor normalización del modelo relacional de la base de datos", p. 34
- ^ Codd, EF (junio de 1970). "Un modelo relacional de datos para grandes bancos de datos compartidos" . Comunicaciones de la ACM . 13 (6): 377–387. doi : 10.1145 / 362384.362685 . S2CID 207549016 . Archivado desde el original el 12 de junio de 2007 . Consultado el 25 de agosto de 2005 .
- ^ Codd, EF "Mayor normalización del modelo relacional de la base de datos". (Presentado en Courant Computer Science Symposia Series 6, "Data Base Systems", Ciudad de Nueva York, 24-25 de mayo de 1971.) Informe de investigación de IBM RJ909 (31 de agosto de 1971). Publicado nuevamente en Randall J. Rustin (ed.), Data Base Systems: Courant Computer Science Symposia Series 6 . Prentice-Hall, 1972.
- ^ Codd, EF "Investigaciones recientes en sistemas de bases de datos relacionales". IBM Research Report RJ1385 (23 de abril de 1974). Republicado en Proc. Congreso de 1974 (Estocolmo, Suecia, 1974), Nueva York: Holanda Septentrional (1974).
- ^ Fecha, CJ (1999). Introducción a los sistemas de bases de datos . Addison-Wesley. pag. 290.
- ^ a b c d e f g h yo Bhattacharyya, malayo (febrero de 2020). "Sistemas de gestión de bases de datos, normalización de bases de datos" (PDF) . Instituto de Estadística de la India . Consultado el 22 de junio de 2020 .
- ^ Darwen, Hugh; Date, CJ; Fagin, Ronald (2012). "Una forma normal para prevenir tuplas redundantes en bases de datos relacionales" (PDF) . Actas de la 15ª Conferencia Internacional sobre Teoría de Bases de Datos . Conferencia conjunta EDBT / ICDT 2012 . Serie de actas de conferencias internacionales de ACM. Asociación de Maquinaria Informática . pag. 114. doi : 10.1145 / 2274576.2274589 . ISBN 978-1-4503-0791-8. OCLC 802369023 . Consultado el 22 de mayo de 2018 .
- ^ Kumar, Kunal; Azad, SK (octubre de 2017). Patrón de diseño de normalización de base de datos . 2017 4a Conferencia Internacional de la Sección de IEEE Uttar Pradesh sobre Electricidad, Computación y Electrónica (UPCON) . IEEE. doi : 10.1109 / upcon.2017.8251067 . ISBN 9781538630044. S2CID 24491594 .
- ^ a b c d "Normalización de la base de datos en MySQL: Cuatro sencillos y rápidos pasos" . ComputerWeekly.com . Archivado desde el original el 30 de agosto de 2017 . Consultado el 23 de marzo de 2021 .
- ^ "Normalización de la base de datos: quinta forma normal y más allá" . KnowledgeBase de MariaDB . Consultado el 23 de enero de 2019 .
- ^ El fragmento de la tabla en sí tiene varias claves candidatas (clave simple {Precio} y claves compuestas de Formato junto con cualquier columna excepto Precio o Grosor ), pero asumimos que en la tabla completa solo {Título, Formato} será único.
- ^ "Formas normales adicionales - Diseño de bases de datos y teoría relacional - página 151" . what-when-how.com . Consultado el 22 de enero de 2019 .
- ^ a b "Normalizace databáze" , Wikipedie (en checo), 7 de noviembre de 2018 , consultado el 22 de enero de 2019
- ^ a b Date, CJ (21 de diciembre de 2015). El nuevo diccionario de bases de datos relacionales: términos, conceptos y ejemplos . "O'Reilly Media, Inc.". pag. 138. ISBN 9781491951699.
- ^ Date, CJ (21 de diciembre de 2015). El nuevo diccionario de bases de datos relacionales: términos, conceptos y ejemplos . "O'Reilly Media, Inc.". pag. 163. ISBN 9781491951699.
- ^ "normalización - Me gustaría entender 6NF con un ejemplo" . Desbordamiento de pila . Consultado el 23 de enero de 2019 .
- ^ Corporación Microsoft. Índices de almacén de columnas: descripción general. https://docs.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-overview . Consultado el 23 de marzo de 2020.
Otras lecturas
- Date, CJ (1999), Introducción a los sistemas de bases de datos (8ª ed.). Addison-Wesley Longman. ISBN 0-321-19784-4 .
- Kent, W. (1983) Una guía simple de cinco formas normales en la teoría de bases de datos relacionales , Communications of the ACM, vol. 26, págs. 120-125
- H.-J. Schek, P. Pistor Estructuras de datos para un sistema integrado de recuperación de información y gestión de bases de datos
enlaces externos
- Kent, William (febrero de 1983). "Una guía sencilla de cinco formas normales en la teoría de bases de datos relacionales" . Comunicaciones de la ACM . 26 (2): 120-125. doi : 10.1145 / 358024.358054 . S2CID 9195704 .
- Conceptos básicos de normalización de bases de datos por Mike Chapple (About.com)
- Introducción a la normalización de la base de datos , parte 2
- Introducción a la normalización de bases de datos por Mike Hillyer.
- Un tutorial sobre las primeras 3 formas normales de Fred Coulson
- Descripción de los conceptos básicos de normalización de bases de datos por Microsoft
- Normalización en DBMS por Chaitanya (beginnersbook.com)
- Una guía paso a paso para la normalización de bases de datos
- ETNF: forma normal de tupla esencial