La tercera forma normal ( 3NF ) es un enfoque de diseño de esquema de base de datos para bases de datos relacionales que utiliza principios de normalización para reducir la duplicación de datos, evitar anomalías en los datos , garantizar la integridad referencial y simplificar la gestión de datos. Fue definido en 1971 por Edgar F. Codd , un informático inglés que inventó el modelo relacional para la gestión de bases de datos .
Se dice que una relación de base de datos (por ejemplo, una tabla de base de datos ) cumple con los estándares de la tercera forma normal si todos los atributos (por ejemplo , columnas de la base de datos ) dependen funcionalmente únicamente de la clave primaria . Codd definió esto como una relación en la segunda forma normal donde todos los atributos no primos dependen solo de las claves candidatas y no tienen una dependencia transitiva de otra clave. [1]
Un ejemplo hipotético de incumplimiento de la tercera forma normal sería una base de datos de un hospital que tuviera una tabla de pacientes que incluyera una columna para el número de teléfono de su médico. El número de teléfono depende del médico, en lugar del paciente, por lo que sería mejor almacenarlo en una tabla de médicos. El resultado negativo de tal diseño es que el número de un médico se duplicará en la base de datos si tiene varios pacientes, lo que aumentará tanto la posibilidad de error de entrada como el costo y riesgo de actualizar ese número si cambia (en comparación con un tercer número normal). modelo de datos compatible con el formulario que solo almacena el número de un médico una vez en la mesa de un médico).
Codd luego se dio cuenta de que 3NF no eliminó todas las anomalías de datos indeseables y desarrolló una versión más fuerte para abordar esto en 1974, conocida como forma normal de Boyce-Codd .
Definición de tercera forma normal
La tercera forma normal (3NF) es una forma normal utilizada en la normalización de bases de datos . 3NF fue definido originalmente por E. F. Codd en 1971. [2]
La definición de Codd establece que una tabla está en 3NF si y solo si se cumplen las dos condiciones siguientes:
- La relación R (tabla) está en segunda forma normal (2NF).
- Cada atributo no primo de R no depende transitivamente de cada clave de R.
Un atributo no primo de R es un atributo que no pertenece a ninguna clave candidata de R. [3] Una dependencia transitiva es una dependencia funcional en la que X → Z ( X determina Z ) indirectamente, en virtud de X → Y y Y → Z (donde no es el caso que Y → X ). [4]
Una definición de 3NF que es equivalente a la de Codd, pero expresada de manera diferente, fue dada por Carlo Zaniolo en 1982. Esta definición establece que una tabla está en 3NF si y solo si para cada una de sus dependencias funcionales X → A , al menos una de las siguientes las condiciones se cumplen: [5] [6] [ necesita cotización para verificar ]
- X contiene A (es decir, A es un subconjunto de X , lo que significa que X → A es una dependencia funcional trivial),
- X es una superclave ,
- cada elemento de A \ X , el conjunto de diferencias entre A y X, es un atributo principal (es decir, cada atributo en A \ X está contenido en alguna clave candidata ).
La definición de Zaniolo da un sentido claro de la diferencia entre 3NF y la forma normal más estricta de Boyce-Codd (BCNF). BCNF simplemente elimina la tercera alternativa ("Cada elemento de A \ X , el conjunto de diferencias entre A y X , es un atributo principal").
"Nada más que la llave"
Bill Kent dio una aproximación a la definición de Codd de 3NF, paralela al compromiso tradicional de dar evidencia verdadera en un tribunal de justicia: "[cada] [atributo] que no sea clave debe proporcionar un hecho sobre la clave, la clave completa, y nada más que la llave ". [7] Una variación común complementa esta definición con el juramento "así que ayúdame Codd ". [8]
Exigir la existencia de "la clave" asegura que la mesa esté en 1NF ; exigir que los atributos que no sean de clave dependan de "la clave completa" asegura 2NF ; además, exigir que los atributos que no son clave dependan de "nada más que la clave" garantiza 3NF. Si bien esta frase es un mnemónico útil, el hecho de que solo mencione una clave significa que define algunas condiciones necesarias pero no suficientes para satisfacer las formas normales 2 y 3. Tanto 2NF como 3NF se preocupan por igual con todas las claves candidatas de una tabla y no con una sola clave.
Chris Date se refiere al resumen de Kent como "una caracterización intuitivamente atractiva" de 3NF y señala que con una ligera adaptación puede servir como una definición de la forma normal Boyce-Codd, un poco más fuerte : "Cada atributo debe representar un hecho sobre la clave, el conjunto clave, y nada más que la clave ". [9] La versión 3NF de la definición es más débil que la variación BCNF de Date, ya que la primera solo se ocupa de garantizar que los atributos que no son claves dependen de las claves. Los atributos principales (que son claves o partes de claves) no deben ser funcionalmente dependientes en absoluto; cada uno de ellos representa un hecho sobre la clave en el sentido de proporcionar parte o toda la clave en sí. (Esta regla se aplica solo a los atributos funcionalmente dependientes, ya que aplicarla a todos los atributos prohibiría implícitamente las claves candidatas compuestas, ya que cada parte de dicha clave violaría la cláusula de "clave completa").
Un ejemplo de una tabla 2NF que no cumple con los requisitos de 3NF es:
Torneo | Año | Ganador | Fecha de nacimiento del ganador |
---|---|---|---|
Indiana Invitational | 1998 | Al Fredrickson | 21 de julio de 1975 |
Abierto de Cleveland | 1999 | Bob Albertson | 28 de septiembre de 1968 |
Maestros de Des Moines | 1999 | Al Fredrickson | 21 de julio de 1975 |
Indiana Invitational | 1999 | Chip Masterson | 14 de marzo de 1977 |
Debido a que cada fila de la tabla debe indicarnos quién ganó un Torneo en particular en un Año en particular, la clave compuesta {Torneo, Año} es un conjunto mínimo de atributos garantizados para identificar de forma única una fila. Es decir, {Torneo, Año} es una clave candidata para la mesa.
El incumplimiento de 3NF se produce porque el atributo no principal (fecha de nacimiento del ganador) depende transitivamente de la clave del candidato {Torneo, año} a través del atributo no principal Ganador. El hecho de que la fecha de nacimiento de Winner dependa funcionalmente de Winner hace que la tabla sea vulnerable a inconsistencias lógicas, ya que no hay nada que impida que se muestre a la misma persona con diferentes fechas de nacimiento en diferentes registros.
Para expresar los mismos hechos sin violar 3NF, es necesario dividir la tabla en dos:
|
|
Las anomalías de actualización no pueden ocurrir en estas tablas porque, a diferencia de antes, el ganador ahora es una clave candidata en la segunda tabla, lo que permite solo un valor para la fecha de nacimiento para cada ganador.
Cálculo
Una relación siempre se puede descomponer en tercera forma normal, es decir, la relación R se reescribe en proyecciones R 1 , ..., R n cuya unión es igual a la relación original. Además, esta descomposición no pierde ninguna dependencia funcional , en el sentido de que toda dependencia funcional de R puede derivarse de las dependencias funcionales que se mantienen en las proyecciones R 1 , ..., R n . Además, tal descomposición se puede calcular en tiempo polinomial . [10]
Derivación de condiciones de Zaniolo
La definición de 3NF ofrecida por Carlo Zaniolo en 1982, y dada anteriormente, se prueba de la siguiente manera: Sea X → A un FD no trivial (es decir, uno donde X no contiene A) y sea A un atributo no clave. También sea Y una clave de R. Entonces Y → X.
Normalización más allá de 3NF
La mayoría de las tablas 3NF están libres de anomalías de actualización, inserción y eliminación. Ciertos tipos de tablas 3NF, que rara vez se encuentran en la práctica, se ven afectados por tales anomalías; estas son tablas que no alcanzan la forma normal de Boyce-Codd (BCNF) o, si cumplen con BCNF, no alcanzan las formas normales superiores 4NF o 5NF .
Consideraciones para su uso en entornos de informes
Si bien 3NF era ideal para el procesamiento de máquinas, la naturaleza segmentada del modelo de datos puede ser difícil de consumir por un usuario humano. El análisis a través de consultas, informes y paneles de control a menudo se facilitaba mediante un tipo diferente de modelo de datos que proporcionaba análisis precalculados, como líneas de tendencia, cálculos del período hasta la fecha (mes hasta la fecha, trimestre hasta la fecha, año- hasta la fecha), cálculos acumulativos, estadísticas básicas (promedio, desviación estándar, promedios móviles) y comparaciones de períodos anteriores (hace un año, hace un mes, hace una semana), por ejemplo, modelado dimensional y más allá del modelado dimensional, aplanamiento de estrellas a través de Hadoop y ciencia de datos . [11] [12]
Ver también
- Sistema de valor-atributo
Referencias
- ^ Codd, EF "Mayor normalización del modelo relacional de la base de datos", p. 34.
- ^ Codd, E. F. "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, pág. 43.
- ^ Codd, pág. 45–46.
- ^ Zaniolo, Carlo. "Una nueva forma normal para el diseño de esquemas de bases de datos relacionales". ACM Transactions on Database Systems 7 (3), septiembre de 1982.
- ^ Abraham Silberschatz, Henry F. Korth, S. Sudarshan, Conceptos del sistema de base de datos (5ª edición), p. 276–277.
- ^ Kent, William. "Una guía simple para las cinco formas normales en la teoría de las bases de datos relacionales" , Communications of the ACM 26 (2), febrero de 1983, págs. 120-125.
- ^ El autor de un libro de 1989 sobre administración de bases de datos le da crédito a uno de sus estudiantes por haber creado el apéndice "Así que ayúdame Codd". Diehr, George. Gestión de bases de datos (Scott, Foresman, 1989), pág. 331.
- ^ Fecha, C. J. Introducción a los sistemas de bases de datos (7ª ed.) (Addison Wesley, 2000), p. 379.
- ^ Serge Abiteboul , Richard B. Hull, Victor Vianu : Fundamentos de bases de datos. Addison-Wesley, 1995. http://webdam.inria.fr/Alice/ ISBN 0201537710 . Teorema 11.2.14.
- ^ "Comparaciones entre técnicas de modelado de Data Warehouse - Roelant Vos" . roelantvos.com . Consultado el 5 de marzo de 2018 .
- ^ "Lecciones de modelado de datos de Hadoop | EMC" . Blog de InFocus | Servicios de Dell EMC . 23 de septiembre de 2014 . Consultado el 5 de marzo de 2018 .
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-126
enlaces externos
- Consejos de Litt: normalización
- Conceptos básicos de normalización de bases de datos por Mike Chapple (About.com)
- 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
- Tercera forma normal con ejemplos simples de exploreDatabase