Lo interesante de este hilo de preguntas y respuestas es que en realidad hay 3 preguntas. Todos respondieron una diferente, y casi nadie respondió la primera:
- ¿Por qué no se normalizan algunas bases de datos en la naturaleza?
- ¿Por qué / cuándo se debe desnormalizar una base de datos normalizada ?
- ¿En qué situaciones es perjudicial o innecesario normalizar en primer lugar?
Los lectores de alertas notarán que estas son preguntas muy diferentes, y trataré de responder cada una de ellas por separado mientras evito demasiados detalles. Por "demasiado", quiero decir que no creo que este sea el contexto apropiado para llevar a cabo un debate extendido sobre los méritos de varios argumentos a favor o en contra de la normalización; Simplemente voy a explicar cuáles son esos argumentos, tal vez enumere algunas advertencias y guarde la filosofía para preguntas más específicas, si alguna vez surgen.
Además, en esta respuesta, supongo que "normalización" implica "BCNF, 3NF, o al menos 2NF" , ya que ese es el nivel de normalización que los diseñadores generalmente buscan alcanzar. Es más raro ver diseños 4NF o 5NF; Aunque ciertamente no son objetivos imposibles, se preocupan por la semántica de las relaciones en lugar de solo su representación , lo que requiere un conocimiento considerablemente mayor sobre el dominio.
Entonces, hacia adelante y hacia arriba:
1. ¿Por qué no se normalizan algunas bases de datos en la naturaleza?
La respuesta a esto podría ser "porque no deberían serlo", pero hacer esa suposición de inmediato es un trabajo de detective bastante pobre. No progresaríamos mucho como sociedad si siempre actuamos bajo el supuesto de que lo que sea, debería ser.
Las razones reales por las que las bases de datos no se normalizan en primer lugar son más complicadas. Aquí están los 5 mejores que he encontrado:
Los desarrolladores que lo diseñaron no sabían o no entendían cómo normalizar. Una fuerte evidencia de esto viene en la forma de muchas otras malas opciones de diseño que lo acompañan, como usar columnas varchar para todo o tener un desorden de nombres de columnas y tablas sin sentido . Y les aseguro que he visto bases de datos "reales" que son tan malas como las de los artículos de TDWTF.
A los desarrolladores que lo diseñaron no les importó o estaban activamente en contra de la normalización por principio . Tenga en cuenta que aquí no estoy hablando de casos en los que se tomó una decisión deliberada de no normalizar en función del análisis contextual, sino de equipos o empresas donde la normalización se entiende más o menos, pero simplemente se ignora o se evita por costumbre. De nuevo, sorprendentemente común.
El software se realizó / se realizó como un proyecto Brownfield . Muchos puristas ignoran este negocio perfectamente legítimo en lugar de la razón técnica para no normalizar. A veces, en realidad, no puede diseñar una nueva base de datos desde cero, debe atornillarse a un esquema heredado existente e intentar normalizarse en ese punto implicaría demasiado dolor. 3NF no se inventó hasta 1971, y algunos sistemas, especialmente los sistemas financieros / contables, tienen sus raíces incluso más atrás.
La base de datos se normalizó originalmente , pero una acumulación de pequeños cambios durante un largo período de tiempo y / o un equipo ampliamente distribuido introdujo formas sutiles de duplicación y otras violaciones de cualquier forma normal que se haya implementado originalmente. En otras palabras, la pérdida de la normalización fue accidental y se dedicó muy poco tiempo a la refactorización.
Se tomó una decisión comercial deliberada de no perder tiempo en el análisis comercial o el diseño de la base de datos y simplemente "hacerlo". Esto es a menudo una economía falsa y, en última instancia, se convierte en una forma creciente de deuda técnica , pero a veces es una decisión racional, al menos en función de la información que se conocía en ese momento; por ejemplo, la base de datos puede haber sido diseñada como un prototipo pero terminó ser promovido al uso de producción debido a limitaciones de tiempo o cambios en el entorno empresarial.
2. ¿Por qué / cuándo se debe desnormalizar una base de datos normalizada?
Esta discusión a menudo surge cuando una base de datos está normalizada para comenzar. O el rendimiento es deficiente o hay mucha duplicación en las consultas (uniones), y el equipo siente, correcta o incorrectamente, que han ido tan lejos como pueden con el diseño actual. Es importante tener en cuenta que la normalización mejora el rendimiento la mayor parte del tiempo, y hay varias opciones para eliminar el exceso de uniones cuando la normalización parece estar trabajando en su contra, muchas de las cuales son menos invasivas y riesgosas que simplemente cambiar a un modelo desnormalizado:
Cree vistas indizadas que encapsulan las áreas problemáticas más comunes. Los DBMS modernos son capaces de hacerlos insertables o actualizables (p. Ej INSTEAD OF., Activadores de SQL Server ). Esto tiene un pequeño costo para las declaraciones DML en las tablas / índices subyacentes, pero generalmente es la primera opción que debe probar porque es casi imposible arruinarlo y no cuesta casi nada mantenerlo. Por supuesto, no todas las consultas pueden convertirse en una vista indizada; las consultas agregadas son las más problemáticas. Lo que nos lleva al siguiente elemento ...
Cree tablas agregadas desnormalizadas que los activadores actualicen automáticamente. Estas tablas existen además de las tablas normalizadas y forman una especie de modelo CQRS . Otro modelo CQRS, más popular en estos días, es usar pub / sub para actualizar los modelos de consulta, lo que brinda el beneficio de la asincronía, aunque eso puede no ser adecuado en casos muy raros donde los datos no pueden estar obsoletos.
A veces, las vistas indexadas no son posibles, las tasas de transacción y los volúmenes de datos son demasiado altos para admitir desencadenantes con un rendimiento aceptable, y las consultas siempre deben devolver datos en tiempo real. Estas situaciones son raras, me arriesgaría a suponer que podrían aplicarse a cosas como el comercio de alta frecuencia o las bases de datos de inteligencia / aplicación de la ley, pero pueden existir. En estos casos, realmente no tiene más opción que desnormalizar las tablas originales.
3. ¿En qué situaciones es dañino o innecesario normalizar en primer lugar?
De hecho, hay varios buenos ejemplos aquí:
Si la base de datos se usa solo para informes / análisis. Normalmente, esto implica que hay una base de datos normalizada adicional que se utiliza para OLTP, que se sincroniza periódicamente con la base de datos de análisis a través de ETL o mensajes.
Al aplicar un modelo normalizado se requeriría un análisis innecesariamente complejo de los datos entrantes. Un ejemplo de esto podría ser un sistema que necesita almacenar números de teléfono que se recopilan de varios sistemas externos o bases de datos. Usted podría desnormalizar el código de código de llamada y el área, pero tendría que dar cuenta de todos los diferentes formatos posibles, números de teléfono, números personalizados no válidos (1-800-GET-cosas), por no hablar de diferentes lugares. Por lo general, es más problemático de lo que vale, y los números de teléfono generalmente se colocan en un solo campo a menos que tenga una necesidad comercial específica para el código de área por sí solo.
Cuando la base de datos relacional está principalmente allí para proporcionar soporte transaccional para una base de datos adicional no relacional. Por ejemplo, puede estar utilizando la base de datos relacional como una cola de mensajes, o para rastrear el estado de una transacción o saga, cuando los datos primarios se almacenan en Redis o MongoDB o lo que sea. En otras palabras, los datos son "datos de control". Por lo general, no tiene sentido normalizar datos que en realidad no son datos comerciales .
Arquitecturas orientadas a servicios que comparten una base de datos física. Esto es un poco de una extraña, pero en un cierto SOA, que va de vez en cuando necesita tener datos duplicados físicamente porque los servicios no se les permite directamente la consulta de datos de cada uno. Si ocurren a compartir la misma base de datos física, tendrá los datos parecen no ser normalizados - pero en general, los datos de propiedad de cada servicio individual está siendo normalizado a menos que uno de los otros factores atenuantes está en su lugar. Por ejemplo, un servicio de facturación puede ser el propietario de la entidad de facturación, pero el servicio de contabilidad necesita recibir y almacenar la fecha y el importe de la factura para incluirla en los ingresos de ese año.
Estoy seguro de que hay más razones que no he enumerado; Lo que quiero decir, en esencia, es que son bastante específicos y serán bastante obvios cuando surjan en la práctica. Se supone que las bases de datos OLAP usan esquemas en estrella, se supone que las SOA tienen alguna duplicación, etc. Si está trabajando con un modelo de arquitectura conocido que simplemente no funciona con la normalización, entonces no se normaliza; en términos generales, el modelo de arquitectura tiene prioridad sobre el modelo de datos.
Y para responder la última pregunta:
¿Es cierto que los buenos arquitectos y expertos eligen un diseño desnormalizado mientras que los desarrolladores no experimentados eligen lo contrario? ¿Cuáles son los argumentos en contra de comenzar su diseño con la normalización en mente?
No, eso es BS completa y absoluta Es también B que los expertos siempre eligen un normalizado de diseño. Los expertos no solo siguen un mantra. Investigan, analizan, discuten, aclaran e iteran, y luego eligen cualquier enfoque que tenga más sentido para su situación particular.
La base de datos 3NF o BCNF suele ser un buen punto de partida para el análisis porque se ha probado y probado con éxito en decenas de miles de proyectos en todo el mundo, pero, de nuevo, también lo ha hecho C. Eso no significa que usemos C automáticamente en cada nuevo proyecto. Las situaciones del mundo real pueden requerir algunas modificaciones al modelo o el uso de un modelo completamente diferente. No lo sabes hasta que estés en esa situación.