database - machine - Overnormalización
normalization forms in dbms (11)
Mucha gente está hablando de rendimiento. Creo que una cuestión clave es la flexibilidad. En general, cuanto más normalizada sea su base de datos, más flexible será.
Actualmente usamos una base de datos "sobre normalizada" porque, en nuestro entorno operativo, los requisitos del cliente cambian mensualmente. Al "sobrenormalizar" podemos adoptar nuestro software en consecuencia, sin cambiar la estructura de la base de datos.
¿Cuándo se describiría el diseño de una base de datos como sobrenormalizado? ¿Es esta caracterización una absoluta? ¿O depende de la forma en que se usa en la aplicación? Gracias.
Cuando el costo de rendimiento excede el beneficio para el propósito previsto de la aplicación.
En el sentido general, creo que está sobrenormalizado cuando hace tantas UNIDAS para recuperar datos que están causando notables penalizaciones de rendimiento y puntos muertos en su base de datos, incluso después de haber desactivado los índices. Obviamente, para grandes aplicaciones y sitios como MySpace o eBay, la des-normalización es un requisito de escalabilidad.
Como desarrollador de varias pequeñas empresas, les digo que, en mi experiencia, siempre ha sido más fácil pasar de normalizado -> desnormalizado que al revés, y de hecho al revés (para evitar la duplicación de datos ahora que el negocio los requisitos han cambiado un año más tarde) es mucho más difícil.
Cuando leo afirmaciones generales como "debes poner la dirección en la mesa de tus clientes en lugar de una tabla de direcciones separada para evitar la unión", me estremezco, porque solo sabes que dentro de un año alguien te va a pedir que hagas algo con direcciones que no previó totalmente, como mantener un seguimiento de auditoría o almacenar múltiples por cliente. Si su base de datos le permite crear una vista indexada, puede eludir ese problema hasta que llegue al punto en que su conjunto de datos sea tan grande que no pueda existir o ser servido por un único servidor o conjunto de servidores en un 1- escribir, leer mucho ambiente. Para la mayoría de nosotros, no creo que ese escenario ocurra muy a menudo.
Cuando tengo dudas, busco la tercera forma normal con algunas excepciones (por ejemplo, tener un campo que contenga una lista CSV de cadenas separadas porque sé que nunca miraré los datos desde el otro ángulo). Cuando deba consolidarme, primero veré mis puntos de vista o índices. Espero que esto ayude.
Mi opinión sobre esto:
Siempre normaliza todo lo que puedas hacer. Normalmente me vuelvo loco por la normalización y trato de diseñar algo que pueda manejar todas las futuras extensiones imaginables. Con lo que termino es con un diseño de base de datos que es extremadamente flexible ... e imposible de implementar.
Entonces comienza el verdadero trabajo: Desnormalización. Aquí resuelve lo que sabe que sería problemático implementar y / o ralentizaría las consultas debido a demasiadas uniones.
De esta forma, sabrá qué escarifica para que el diseño sea utilizable.
Editar: Documentaciones! Olvidé mencionar que documentar la des-normalización es muy importante. Cuando se hace cargo de un proyecto, es extremadamente útil saber la razón detrás de las elecciones.
La normalización es absoluta. Una base de datos sigue formularios normales o no. Hay media docena de formas normales. En su mayoría, tienen nombres como del Primero al Quinto. Además, hay una forma normal de Boyce-Codd.
La normalización existe precisamente para un propósito: evitar "anomalías de actualización".
La normalización no es subjetiva. No es un juicio. Cada tabla y relación entre tablas sigue o no una forma normal.
En consecuencia, no puede estar "sobrenormalizado" o "subnormalizado".
Habiendo dicho eso, la normalización tiene un costo de rendimiento. Algunas personas optan por desnormalizarse de diversas maneras para mejorar el rendimiento. La desnormalización sensible más común es romper 3NF e incluir datos derivados.
Un error común es romper 2NF y tener copias duplicadas de una dependencia funcional entre una clave y un valor no clave. Esto requiere actualizaciones adicionales o, lo que es peor, activadores para mantener las copias en paralelo.
La desnormalización de una base de datos transaccional debería ser una situación caso por caso.
Un almacén de datos, además, raramente sigue alguna de las reglas de normalización transaccional porque (esencialmente) nunca se actualiza.
La "sobrenormalización" podría significar que una base de datos es demasiado lenta debido a una gran cantidad de uniones. Esto también puede significar que la base de datos ha superado el hardware. O que las aplicaciones no han sido diseñadas para escalar.
El problema más común aquí es que las personas intentan usar una base de datos transaccional para informar mientras se realizan las transacciones. El bloqueo de las transacciones interfiere con los informes.
"Subnormalización", sin embargo, significa que hay infracciones de NF y se está realizando un procesamiento innecesario para manejar los datos replicados y corregir las anomalías de actualización.
Siempre es una cuestión del dominio de la aplicación. Por lo general, es una cuestión de corrección, pero ocasionalmente una cuestión de rendimiento.
Hay un caso en el que puedo pensar en un caso prima facie de sobrenormalización: supongamos que tiene un orden + orden de pedido, y el artículo de pedido hace referencia a ID de producto, y deja el precio al producto.precio. Como eso introduce el acoplamiento temporal, se ha normalizado incorrectamente porque la sobrenormalización afecta a las órdenes ya enviadas, a menos que los precios nunca cambien. Ciertamente puede argumentar que esto es simplemente un error de modelado (como en los comentarios), pero también veo la subnormalización como un error de modelado en la mayoría de los casos.
La otra categoría está relacionada con el rendimiento. En principio, creo que en general hay mejores soluciones para el rendimiento que desnormalizar datos, como vistas materializadas, pero si su aplicación sufre las consecuencias en el rendimiento de muchas combinaciones, puede valer la pena evaluar si la desnormalización puede ayudarlo. Creo que estos casos a menudo se enfatizan demasiado, porque a veces las personas tratan de desnormalizar antes de que describan adecuadamente su aplicación.
Las personas a menudo se olvidan de las alternativas, como mantener una forma canónica de la base de datos y utilizar el almacenamiento u otras estrategias para leer con frecuencia, pero con poca frecuencia los datos cambiados.
En mi experiencia, nunca he visto una base de datos normalizada que contenga direcciones postales, ya que generalmente es aceptable almacenar la dirección como una cadena. Idealmente, habría tablas para países, condados / estados, ciudades, distritos y calles. No he encontrado a nadie que necesite informar sobre el nivel de la calle, por lo que no ha sido necesario. Las direcciones solo se deben usar para el contacto postal, por lo que se tratan como una sola entidad.
Si el rendimiento se ve afectado por demasiadas uniones, la creación de tablas desnormalizadas para generar informes puede acelerar las cosas. Al copiar los datos en nuevas tablas, es posible ejecutar informes sin uniones.
Normalice sus bases de datos OLTP y desnormalice sus bases de datos OLAP. Cada uno tiene una misión que dicta su esquema. Al igual que las bases de datos de transacciones normalizadas, existen almacenes de datos por una razón. Un sistema completo necesita ambos.
La tercera forma normal ( 3NF ) se considera el nivel óptimo de normalización para muchas aplicaciones de bases de datos racionales. Este es un estado en el cual, como Bill Kent resumió una vez , cada "campo no clave [en cada tabla dentro de un sistema de administración de bases de datos relacionales en particular, o RDBMS] debe proporcionar un hecho sobre la clave, la clave completa y nada más que la clave." 3NF es un término introducido por EF Codd , inventor del modelo relacional para la gestión de bases de datos. En general, los datos de los que depende una aplicación de software, especialmente una aplicación utilizada para un Sistema de procesamiento de transacciones en línea (OLTP), tendrán un buen rendimiento en 3NF. Esta forma normal, por definición, reduce el tamaño de la base de datos solicitando una repetición mínima de los datos de fila / columna, y maximiza la eficiencia de la consulta y la facilidad de mantenimiento de la aplicación. 3NF logra eso al requerir que las tablas de una base de datos (es decir, su esquema) se dividan en tablas separadas relacionadas por claves primarias / externas, básicamente hasta que la regla de Kent sea verdadera (bueno, lo he dicho así para facilitar la lectura pero la definición real de 3NF es mucho más detallada que eso). Por el contrario, la sobrenormalización implica aumentar el número de combinaciones requeridas en una consulta entre tablas relacionadas. Esto se produce como resultado de desglosar el esquema de la base de datos en un nivel mucho más detallado que 3NF. Sin embargo, aunque la normalización después del 3er grado a menudo puede considerarse una sobrenormalización, la connotación negativa del término "sobrenormalización" a veces puede ser injustificada. Overnormalization puede ser deseable en algunas aplicaciones que por diseño requieren 4NF (y más allá) debido a la complejidad y versatilidad del software de la aplicación. Un ejemplo de esto es un programa de base de datos comercial altamente personalizable y extensible para algunas industrias en el que se vende a usuarios finales que requieren una API abierta. Pero también puede ser deseable lo contrario, es decir, la desnormalización, especialmente cuando se diseña una base de datos de Procesamiento analítico en línea (OLAP) utilizada estrictamente para resumir datos de una base de datos OLTP solo para consultar / informar, como datos almacén. En este caso, los datos deben necesariamente residir en un formato altamente desnormalizado (es decir, 1NF o 2NF). A menudo, bajo estas limitaciones, cuando hay una gran demanda de consultas e informes eficientes, encontramos que los programadores de bases de datos y aplicaciones llaman a una base de datos, "sobrenormalizada". Pero como dijo alguna vez Tony Davis de Redgate, teniendo en cuenta el software de base de datos y los sistemas de almacenamiento mucho más avanzados y eficientes, "el rendimiento alcanzado por múltiples combinaciones en una consulta es insignificante. Si su base de datos es lenta, no es porque está ''sobrenormalizado''! " Entonces, en conclusión, esta caracterización - sobrenormalización - no es absoluta, y depende de la forma en que se usa en la aplicación. En palabras de Kent , " las reglas de normalización están diseñadas para evitar anomalías de actualización e inconsistencias de datos ... [pero] no hay obligación de normalizar completamente todos los registros cuando se tienen en cuenta los requisitos de rendimiento real ... El diseño normalizado mejora la integridad de los datos, al minimizar la redundancia y la inconsistencia, pero a un posible costo de rendimiento para ciertas aplicaciones de recuperación ... [Por lo tanto,] la deseabilidad de la normalización debe evaluarse, en términos de su impacto en el rendimiento de las aplicaciones de recuperación " .