Pude ver muchos diseños que la normalización no era la primera consideración en la fase de toma de decisiones.
En muchos casos, esos diseños incluían más de 30 columnas, y el enfoque principal era "poner todo en el mismo lugar"
Según lo que recuerdo, la normalización es una de las primeras cosas más importantes, entonces, ¿por qué a veces se cae tan fácilmente?
Editar:
¿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?
design
sql
database-design
relational-database
rdbms
Yosi Dahari
fuente
fuente
Respuestas:
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:
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:
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.
fuente
La suposición incorporada en la pregunta y en algunas de las respuestas es que la normalización es un buen diseño de base de datos. De hecho, este no suele ser el caso. La normalización es una forma de lograr un conjunto particular de objetivos de diseño y un requisito si depende en gran medida de la base de datos para hacer cumplir las "reglas comerciales" sobre las relaciones entre los elementos de datos.
La normalización le brinda algunos beneficios clave:
Dicho esto, hay muchas razones válidas para desnormalizar:
No está claro que la normalización sea un signo de buen diseño. En algunos casos, la normalización es un artefacto de un momento en el que el espacio de almacenamiento era escaso y cuando gran parte de la responsabilidad de codificar las reglas comerciales residía en la base de datos (piense en las aplicaciones cliente-servidor de 2 niveles con la mayoría, si no toda, la lógica comercial en procedimientos almacenados). Es muy posible que muchos proyectos se desvíen de la normalización en función de buenas decisiones arquitectónicas en lugar de una mala comprensión de los principios de diseño de bases de datos.
El artículo de Jeff Atwood al que se hace referencia en los comentarios anteriores proporciona una buena discusión detallada: "Quizás normalizar no es normal" .
fuente
La normalización también es, históricamente, un territorio para el argumento religioso cercano, por lo que dudo en decir mucho más.
fuente
En proyectos grandes, y especialmente en los mainframes, este no es el caso. De hecho, si busca sitios de trabajo, verá varios puestos para modeladores de datos. Además, tener muchas columnas en una sola tabla no va en contra de la normalización. Sin embargo, su observación es válida para algunos proyectos.
El diseño de la base de datos es una de las habilidades necesarias para construir sistemas de calidad. Dicho esto, algunos desarrolladores no saben lo suficiente sobre el diseño de bases de datos y aún así se les asigna la tarea de modelado de datos y diseño de bases de datos. Algunos proyectos incluso se saltan el modelado de datos. El enfoque en muchos proyectos se centra principalmente en la codificación y el diseño front-end.
Otro factor para el diseño deficiente de la base de datos es el hecho de que la Normalización no es un tema trivial, especialmente cuando se trata de 4th NF, 5th NF, etc. La mayoría de los libros que he visto no pueden explicar bien esas formas. Suele haber malos ejemplos y demasiada teoría. Esto hace que el tema sea menos popular de lo que debería.
Los errores en el diseño de la base de datos son difíciles de encontrar a menos que los busque o los encuentre durante las pruebas. Al no tener un estándar para la calidad del diseño de la base de datos, es más probable que ocurran errores.
Agregue a eso el hecho de que algunos proyectos no siguen una metodología de desarrollo rigurosa (una que promueva el diseño de la base de datos), como resultado, las responsabilidades se mezclan y las tareas se pierden entre el analista de negocios, los desarrolladores y los DBA. Los desarrolladores hablan en OO y UML donde los DBA hablan en DD y algunos en ERD y probablemente muchos no obtienen UML u OO. En resumen, la falta de conocimiento, la falta de buenos recursos claros, la falta de un lenguaje unificado para describir los datos y la falta de metodología son los culpables.
fuente