Cuándo desnormalizar un diseño de base de datos

Este equipo redactor ha estado mucho tiempo buscando la solución a tu búsqueda, te brindamos la respuesta de modo que nuestro deseo es resultarte de mucha apoyo.

Solución:

Su colega senior es un desarrollador, no un modelador de datos. Es mejor empezar desde cero, sin ellos. La normalización es complicada solo para aquellos que no leerán libros. Es bastante justo que te haga pensar, pero algunas cuestiones son absurdas.

Tus números:

1. Debe apreciar las diferencias entre los datos reales en línea y los datos históricos; luego la diferencia entre necesidades meramente históricas y de archivo. Todos ellos son correctos para los requisitos comerciales específicos y incorrectos para todos los demás, no existe el bien y el mal universales.

   • ¿Por qué no hay una copia en papel de la factura? En la mayoría de los países, eso sería un requisito legal y fiscal, ¿cuál es exactamente la dificultad de sacar la factura anterior?
   • donde la base de datos tiene el requisito de almacenar las facturas cerradas, entonces claro, tan pronto como se cierre la factura, necesita un método para capturar esa información.
   • ProductPrice (en realidad, yo lo llamaría ProductDate) es una buena idea, pero puede que no sea necesaria. Pero tiene razón, necesita evaluar la vigencia de los datos, en el contexto completo de toda la base de datos.
   • No veo cómo ayudaría copiar el precio del producto en la tabla de facturas (¿no hay muchas líneas de pedido?)
   • en bases de datos modernas, donde el Copiar de la factura se debe regurgitar, la factura cerrada se almacena adicionalmente en una forma diferente, por ejemplo, XML. Un cliente guarda los PDF como BLOB. Así que no hay que perder el tiempo con el precio del producto hace cinco años. Pero los datos básicos de la factura están en línea y actualizados, incluso para facturas cerradas; simplemente no puede volver a calcular la factura antigua utilizando los precios actuales.
   • algunas personas usan una tabla archive_invoice, pero eso tiene problemas porque ahora cada segmento de código o herramienta de informe de usuario tiene que buscar en dos lugares (tenga en cuenta que en estos días algunos usuarios entienden las bases de datos mejor que la mayoría de los desarrolladores)
   • De todos modos, eso es todo discusión, para su comprensión.
     • La base de datos sirve para fines actuales y de archivo a partir de un único conjunto de tablas (sin tablas de “archivo”
     • Una vez que se crea una factura, es un documento legal y no se puede modificar ni eliminar (se puede revertir o abonar parcialmente con una nueva factura, con valores negativos). Estan marcados IsIssued/IsPaid/Etc
     • Products no se pueden eliminar, se pueden marcar IsObsolete
     • Hay tablas separadas para InvoiceHeader y InvoiceItem
     • InvoiceItem tiene FK para ambos InvoiceHeader y Product
     • por muchas razones (no solo las que mencionas), la fila InvoiceItem contiene la NumUnits; ProductPrice; TaxAmount; ExtendedPrice. Claro, esto parece una “desnormalización” pero no lo es, porque los precios, las tasas de impuestos, etc., están sujetos a cambios. Pero lo que es más importante, el requisito legal es que podamos reproducir la factura anterior a pedido.
     • (donde se puede reproducir a partir de archivos en papel, esto no es necesario)
     • los InvoiceTotalAmount es una columna derivada, solo SUM() de los InvoiceItems

2. Eso es una tontería. Los sistemas contables y los contables no “funcionan” así.

   • Si es un verdadero sistema de contabilidad, entonces tendrá asientos de diario o “entrada doble”; eso es lo que debe usar una cuenta calificada (por ley).

   • Entrada doble no significa entrada duplicada; significa que cada transacción financiera (una cantidad) tendrá una cuenta fuente y una cuenta objetivo a la que se aplicará; por lo que no hay “desnormalización” ni duplicación. En una base de datos bancaria, debido a que las transacciones financieras se realizan en cuentas individuales, esto se representa comúnmente como dos transacciones financieras separadas (filas) dentro de una transacción Db. Las restricciones de bases de datos comerciales ordinarias se utilizan para garantizar que haya dos “lados” en cada transacción financiera.

   • Asegurarse de que las facturas no se puedan eliminar es un tema aparte, que tiene que ver con la seguridad, etc., si alguien está paranoico acerca de las cosas que se eliminan de su base de datos, y su base de datos no fue asegurada por una persona calificada, entonces tienen más y diferentes problemas que no tienen nada que ver con esta pregunta. Obtenga una auditoría de seguridad y haga lo que le digan.

   • Wikipedia no es una fuente confiable de información sobre normalización.

   • Una base de datos normalizada es siempre mucho más rápida que una base de datos no normalizada. Por lo tanto, es muy importante comprender qué es la normalización y la desnormalización y qué no es. El proceso se ve enormemente obstaculizado cuando la gente tiene “definiciones” fluidas y de aficionados, sólo conduce a confusión y “discusiones” que hacen perder el tiempo. Cuando tenga definiciones fijas, puede evitar todo eso y simplemente continuar con el trabajo.

   • Las tablas de resumen son bastante normales, para ahorrar tiempo y potencia de procesamiento, para volver a calcular la información que no cambia, por ejemplo: totales hasta la fecha para cada año, pero este año; Totales de MTD para cada mes de este año, pero no de este mes. “Recalcular siempre” los datos es un poco tonto cuando (a) la información es muy grande y (b) no cambia. Calcular solo para el mes actual

     • En los sistemas bancarios (millones de operaciones por día), en EndOfDay, también calculamos y almacenamos el total diario. Estos se sobrescriben durante los últimos cinco días, porque los Auditores están realizando cambios y se permiten Entradas de diario contra transacciones financieras de los últimos 5 días.
     • Los sistemas no bancarios generalmente no necesitan totales diarios.

   • Las tablas de resumen no son una “desnormalización” (excepto a los ojos de aquellos que acaban de aprender sobre la “normalización” de su “fuente” mágica de fluidos en constante cambio; o como no practicantes, que aplican reglas simples en blanco o negro a todo). Una vez más, la definición no se está discutiendo aquí; es simplemente no se aplica a las tablas de resumen.

   • Las tablas de resumen no afectan la integridad de los datos (asumiendo, por supuesto, que los datos de los que se obtuvieron fueran integrales).

   • Las tablas de resumen son una adición a la base de datos, que no es necesario que tengan las mismas restricciones que la base de datos. Básicamente, existen tablas de informes o tablas de almacenamiento de datos, a diferencia de las tablas de bases de datos.

   • No hay anomalías de actualización (que es una definición estricta) relacionadas con las tablas de resumen. No puede cambiar ni eliminar una factura del año pasado. Las anomalías de actualización se aplican a datos actuales desnormalizados o no normalizados verdaderos.

1) Este es un archivo. Todo lo que contiene nunca debe actualizarse. Seguiría la sugerencia del senior y haría que la tabla de facturas fuera autónoma. ¿Quizás usar un blob para la propia factura que contenga lenguaje de marcado?

2) Servicios de informes, una tabla de almacén que se actualiza mediante activación, algo que se crea mediante un script cada vez que … todo esto estaría bien, creo. De hecho, es ideal normalizarlo, pero no siempre es rápido. Tengo una base de datos de atención médica de buen tamaño que administro que está completamente normalizada … y luego tiene una serie de tablas desnormalizadas con ecuaciones acumuladas y campos comúnmente extraídos. Casi todo se ejecuta desde ese conjunto desnormalizado: es más rápido agregarlos con un disparador cuando se cargan los archivos que tener que seguir extrayendo de varias tablas cada vez que quiero ver un informe de 100,000 registros.

Plantea puntos válidos, sin embargo, no está completamente claro sobre la normalización y lo que significa, por ejemplo en

1) La afirmación de que mantener las facturas como estaban desnormaliza los datos es completa y totalmente errónea. Tomemos el precio, por ejemplo: si tiene un requisito comercial que establece que debe mantener un historial de precios, mantener solo el precio actual es incorrecto y rompe los requisitos. Y no tiene nada que ver con la normalización, simplemente no está bien diseñado. La desnormalización se trata de introducir posibilidades de ambigüedad en su modelo (y otros artefactos) y, en este caso, simplemente no está modelando correctamente su espacio problemático.
No hay nada de malo en modelar su base de datos para admitir datos temporales (o versionar y / o separar las áreas de la base de datos en archivo / temporal y el conjunto de trabajo).

No es posible mirar la normalización sin mirar la semántica (en términos de requisitos).

Además, si su desarrollador senior no puede ver la diferencia, supongo que no obtuvo su antigüedad en el desarrollo de RDBMS;)

2) La segunda parte es, de hecho, la desnormalización. Sin embargo, si alguna vez se encuentra con un analista senior de DB que predica seriamente la normalización, le oirá decir que es perfectamente aceptable desnormalizar siempre que lo haga conscientemente y se asegure de que beneficia las deficiencias de sobrepeso y que las anomalías no lo muerdan. También te dirán que normalices el modelo lógico y que en el modelo físico se te permita desviarte del ideal para diversos fines (rendimiento, mantenimiento, etc …). En mi libro, el objetivo principal de la normalización es que no tenga anomalías ocultas (consulte este artículo sobre 5NF, por ejemplo)

El almacenamiento en caché de resultados intermedios está permitido incluso en bases de datos normalizadas e incluso por los mayores evangelistas de la normalización: puede hacerlo en la capa de aplicación (como algún tipo de caché) o puede hacerlo a nivel de base de datos o puede tener un almacén de datos para tales propósitos. Todas estas son opciones válidas y no tienen nada que ver con la normalización del modelo lógico.

Además, en cuanto a su contador, debería poder convencerlo de que lo que está reclamando es no una buena prueba y desarrollar un conjunto de pruebas (tal vez junto con él) que automatizarán las pruebas del sistema sin la intervención de los usuarios y le darán una mayor confianza de que su sistema está libre de errores.

Por otro lado, conozco sistemas que requieren que los usuarios ingresen información duplicada, como ingresar el número de líneas en la factura antes o después de ingresar las líneas reales, para asegurarse de que la entrada esté completa. Estos datos están ‘duplicados’ y no tiene que almacenarlos si tiene un procedimiento que validará la entrada. Si ese procedimiento viene más tarde, se permite almacenar los datos ‘desnormalizados’; nuevamente, la semántica lo justifica y puede ver el modelo como normalizado. (es beneficioso entender este concepto)

EDITAR:
El término “desnormalizado” en (2) no es correcto si observa la definición formal de formas normales y si considera un diseño desnormalizado si rompe alguna de las formas normales (para algunas personas esto es obvio y no hay otra forma sobre eso).

Aún así, es posible que desee acostumbrarse a la idea de que mucha gente y no necesariamente textos inútiles usarán el término normalización para cualquier esfuerzo que intente reducir la redundancia en la base de datos (solo como ejemplo, encontrará artículos científicos, por lo que no digo que deban ser correctos, solo como una advertencia de que es común, que llaman a los atributos derivados una forma de desnormalización, ver aquí).

Si desea referirse a algunas autoridades más coherentes y reconocidas (nuevamente, no reconocidas por todos), tal vez las palabras de CJDate puedan hacer una clara distinción:

Gran parte de la teoría del diseño tiene que ver con reducir la redundancia; la normalización reduce la redundancia dentro de relvars, la ortogonalidad la reduce entre relvars.

citado desde la base de datos en profundidad: teoría relacional para profesionales

y en la página siguiente

Así como la falta de normalización total implica redundancia y puede conducir a ciertas anomalías, también puede ocurrir la falta de adherencia a la ortogonalidad.

Por lo tanto, el término adecuado para la redundancia entre relvars es ortogonalidad (básicamente, todas las formas normales hablan de un relvar único, por lo que si observa estrictamente la normalización, nunca sugeriría ninguna mejora debido a las dependencias entre dos relvars diferentes).

De todos modos, uno de los otros conceptos importantes cuando se considera el diseño de bases de datos es también la diferencia entre los modelos de base de datos lógicos y físicos. Muchas cosas que son útiles a nivel físico, como tablas con subtotales o índices, no tienen cabida en el modelo lógico, donde intenta establecer e investigar las relaciones entre los conceptos que está intentando modelar. Y es por eso que puedes decir que están permitidos y no arruinan el diseño.

Las líneas a veces pueden ser un poco borrosas sobre qué es el modelo lógico y qué es el modelo físico. Un ejemplo especialmente bueno es una tabla con subtotales. Para considerarlo parte de la implementación física e ignorarlo en el nivel lógico, debe:

• asegurarse de que los usuarios (y las aplicaciones) no puedan actualizar la tabla de subtotales directamente de una manera que no sea consistente con su predicado (en otras palabras, tienen un error en el procedimiento de subtotal)
• asegurarse de que los usuarios (y las aplicaciones) no puedan actualizar la tabla de la que dependen sin actualizar el subtotal (en otras palabras, que alguna aplicación no eliminará una fila de la tabla de detalles sin actualizar el total)

Si rompe alguna de las reglas anteriores, terminará con base de datos inconsistente que proporcionará hechos inconsistentes. (En tal caso, si desea diseñar formalmente un procedimiento para solucionar o examinar los problemas causados, no lo consideraría solo una tabla adicional, existiría en el nivel lógico; donde no debería estar).

Además, la normalización siempre depende de la semántica y las reglas de negocio que está intentando modelar. Por ejemplo, DBAPerformance da un ejemplo en el que almacenar el TaxAmount en la tabla de transacciones no hay un diseño desnormalizado, pero no menciona que depende del tipo de sistema que intente modelar (¿es obvio?); por ejemplo, si la transacción tiene otro atributo llamado TaxRate por lo general, se desnormalizará porque existe una dependencia funcional de un conjunto de atributos no clave (TaxAmount = Amount * TaxRate => FD: Amount, TaxRate -> TaxAmount), y uno de estos debe eliminarse o garantizarse que sea coherente.

Obviamente, podría decir, pero, si el sistema que está construyendo es para una empresa de auditoría, es posible que no tenga dependencia funcional; es posible que estén auditando a alguien que esté usando cálculos manuales o que tenga un software defectuoso o que deba tener la capacidad de registrar datos incompletos. y el cálculo puede ser incorrecto originalmente y, como empresa de auditoría, debe registrar el hecho tal como sucedió.

Por lo tanto, la semántica (predicados) que están determinados por los requisitos influirá si se rompe alguna de las formas normales, al influir en las dependencias funcionales (en otras palabras, establecer correctamente las dependencias funcionales es una parte bastante importante del modelado cuando se lucha por una base de datos normalizada).

Si te gusta el tema, tienes la opción de dejar una división acerca de qué le añadirías a este ensayo.

---

---

Utiliza Nuestro Buscador