¿Por qué muchos diseños ignoran la normalización en RDBMS?

23

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?

Yosi Dahari
fuente
77
porque DBs normalizados necesitan una gran cantidad de combinaciones en incluso la mayoría de las preguntas triviales
monstruo de trinquete
1
esas uniones aún tendrán que suceder incluso ocultas por las vistas
fanático del trinquete el
29
Muchos programadores no conocen los conceptos básicos del modelo relacional.
mike30
10
"Normalizar hasta que duela, desnormalizar hasta que funcione". codinghorror.com/blog/2008/07/… tiene algunas buenas respuestas.
Matthew Steeples
3
Lo ignoran porque no tienen que responder a DBA, analistas de BI o auditores de seguridad.
Aaronaught

Respuestas:

19

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:

  1. ¿Por qué no se normalizan algunas bases de datos en la naturaleza?
  2. ¿Por qué / cuándo se debe desnormalizar una base de datos normalizada ?
  3. ¿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.

Aaronaught
fuente
1
Deberías copiar y pegar esto en un artículo de blog ... esto es ORO.
Marcel Popescu
15

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:

  1. Minimiza la cantidad de datos redundantes.
  2. Maximiza la medida en que los mecanismos de integridad integrados de la base de datos (restricciones de clave externa, restricciones de unicidad) pueden aprovecharse para garantizar la integridad de los datos.
  3. Reduce el número de columnas por fila aumentando la eficiencia de IO en algunos casos. Las filas anchas tardan más en recuperarse.

Dicho esto, hay muchas razones válidas para desnormalizar:

  1. El rendimiento, particularmente para análisis, puede verse afectado por la normalización. Para el análisis contra bases de datos relacionales, los modelos dimensionales desnormalizados son el enfoque estándar.
  2. El beneficio de hacer cumplir la integridad de los datos dentro de la base de datos está empezando a disminuir. A medida que el desarrollo se centra cada vez más en el nivel medio orientado a objetos que a menudo aplica las reglas de negocio, la dependencia de las restricciones relacionales en la base de datos es menos importante.
  3. Como otros han mencionado, la normalización complicará las consultas requeridas para recuperar datos relevantes.

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" .

DemetriKots
fuente
77
Hola Yosi, entiendo tu punto. La normalización es fundamental para comprender realmente la teoría de las bases de datos relacionales y tiene una aplicación real en la práctica, por lo que no es sorprendente que sea un gran tema en los cursos. Los buenos ingenieros deberían entenderlo y entender cuándo debería aplicarse. Lo que no parece estar cubierto en el trabajo del curso es que la desnormalización selectiva puede generar muchos beneficios y algunos problemas realmente no se prestan a modelos normalizados.
DemetriKots
1
¿Qué pasa con la consistencia de los datos? Por ejemplo, si tiene el nombre de la tienda en cada detalle de ventas, puede tener diferentes descripciones contradictorias, mientras que si los datos están normalizados, el nombre de la tienda aparece solo uno (en la tabla de la tienda) y no hay lugar para inconsistencias.
Tulains Córdova
1
Estoy de acuerdo. Creo que la normalización se sobreutiliza a veces por los DBA a los que se les ha enseñado que este es el mejor diseño. Siempre he sugerido que los DBA pueden normalizar las tablas en el ETL todo lo que quieran, pero cuando se trata de las tablas a las que hace referencia la interfaz de usuario, necesito tablas que sean fáciles de consultar sin uniones excesivas. Me he encontrado con tablas que estaban demasiado normalizadas, por lo que apenas podía solucionar los problemas de los usuarios sin gastar HORAS en la resolución de problemas.
L_7337
1
Por el contrario, el análisis es increíblemente difícil si no puede comenzar desde un modelo normalizado. Solo tenía que hacer este ejercicio, y fue un infierno. Los desarrolladores de aplicaciones nunca deben suponer que un esquema desnormalizado será adecuado para las necesidades analíticas. Y en cuanto al punto # 3 contra la normalización, es un problema que se resuelve casi trivialmente con vistas materializadas / indexadas.
Aaronaught
1
Y el n. ° 2 suena razonable, pero pone en tensión la credulidad en la práctica: no recuerdo haber visto una sola instancia en mis más de 10 años en los que la aplicación hizo cumplir las restricciones. Con mayor frecuencia, los desarrolladores equiparan incorrectamente las reglas de negocios con la integridad de los datos o usan el hecho de que los ORM teóricamente pueden imponer restricciones relacionales como una excusa para no hacerlo en ningún lugar. Tal vez solo estoy siendo cínico, pero toda mi experiencia profesional me ha enseñado que declaraciones como "la aplicación exigirá la integridad de los datos" son enormes señales de advertencia.
Aaronaught
11
  1. Muchos desarrolladores no saben ni se preocupan por la normalización, ni por el modelado de datos o la base de datos.
  2. Para algunos trabajos realmente no es importante.
  3. A veces hay una muy buena razón para desnormalizar, por ejemplo, para hacer que una carga de trabajo difícil en particular funcione bien.
  4. Los conceptos de bases de datos relacionales están recientemente menos de moda que en los años 1990 y 2000. Los desarrolladores tienden a ser influenciados por la moda, incluso si afirman ser muy racionales. No tiene sentido discutir sobre el gusto.

La normalización también es, históricamente, un territorio para el argumento religioso cercano, por lo que dudo en decir mucho más.

joshp
fuente
Agregaría a esto que a veces el relacional no es realmente el diseño correcto para una base de datos; por ejemplo, un directorio LDAP es jerárquico, algunos otros tipos pueden ser mejor atendidos por un diseño plano.
Maximus Minimus
1
En cuanto al punto # 4, diría que las bases de datos relacionales están menos de moda y están comenzando a cambiarse por variedades nosql, y eso es realmente una gran cosa la mayor parte del tiempo. Pero no veo muchos motores y agitadores que combinen modelos de datos no relacionales utilizando un RDBMS. Eso es estúpido.
Aaronaught
@joshp - Gracias, buen resumen. el punto # 3 es el que personalmente me interesa más. ¿Por qué otros factores "superan" la necesidad de normalización?
Yosi Dahari
@JimmyShelter Estoy de acuerdo. Dejando de lado la moda, las relaciones no siempre son la mejor opción.
joshp
44
@Yosi: la razón por la que algunos factores pueden superar la normalización es que la normalización es una técnica para evitar problemas comunes de consistencia de datos cuando se insertan, actualizan y eliminan datos. Si los datos se escriben una vez y luego se leen después de eso, las C, U y D de CRUD ya no importan. En tal caso, los beneficios de la normalización básicamente no tienen sentido, por lo que otras presiones competitivas pueden tener prioridad, como el rendimiento de lectura o la simplicidad de la consulta.
Joel Brown
9

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.

Ninguna posibilidad
fuente
¿Puede sugerir documentos / artículos de calidad de diseño de base de datos (no solo esquema, sino también procedimientos)?
Tilak
"tener muchas columnas en una sola tabla no va en contra de la normalización" -Claro. Mi intención era #entailments. En la pregunta que mencioné #columnas solo por simplicidad, supuse que el lector comprenderá la correlación y con eso lo que quise decir
Yosi Dahari
@Tilak, no estoy seguro de si hay una referencia específica para obtener las mejores pautas, pero puede recopilar su lista de modelos de datos y literatura de diseño de bases de datos. Lo siento si esto no responde a tu pregunta. Creo que este podría ser un buen tema para un libro.
No,