¿Cómo puedo argumentar de manera convincente contra la duplicación de columnas de la base de datos?


47

Comencé a trabajar en una nueva organización y uno de los patrones que he estado viendo en la base de datos es duplicar campos para facilitar la escritura de consultas para los analistas de negocios. Estamos usando Django y su ORM.

En un caso, mantenemos un objeto MedicalRecordNumber con una cadena única que identifica a un paciente en un determinado contexto. Tenemos objetos de registro que rastrean a los pacientes y tienen números de registro médico asociados , pero en lugar de usar una relación de clave externa, duplican la cadena para evitar escribir una unión ( no por razones de rendimiento). Este patrón es común en toda la base de datos.

Para mí, la importancia de que un modelo de datos esté limpio es solo para poder pensarlo bien. La complejidad innecesaria es una pérdida de mi tiempo limitado de procesamiento cognitivo. Es un problema sistemático. No sentirse cómodo escribiendo uniones es un problema de habilidades rectificables. No necesariamente quiero abogar por volver y cambiar el esquema, pero me encantaría poder articular de manera convincente los problemas con este tipo de duplicación.


2
¿Qué significa "no sentirse cómodo escribiendo une"? ¿Cómo explican eso?
scriptin

99
¿Estas personas trabajan para usted? ¿Eres su supervisor? La mayoría de sus justificaciones se pueden encontrar aquí: en.wikipedia.org/wiki/Database_normalization . Sí, necesitan mejorar en el uso de combinaciones.
Robert Harvey

1
¿Ha buscado la literatura sobre por qué es deseable la normalización?
Nathan Tuggy

17
¿No agregar vistas que hacen la unión internamente hace que escribir consultas sea igual de fácil? Podrías sugerirlos como alternativa.
CodesInChaos

1
¿Comunicaste esto (cortésmente) con tus compañeros y personas mayores? ¿Cuáles son sus justificaciones, qué consideraciones están haciendo? Hay muchas razones posibles por las cuales esta podría ser una buena idea (aunque usted diga "el rendimiento no es la razón", ¿qué evidencia tiene para respaldar eso?). Antes de acusarlos de ser demasiado vagos y / o rígidos, ¿ha considerado (y preguntado) las razones que tienen para tener el diseño como está? ¿Quizás hay muchas más lecturas que escrituras (análisis pesado DB)? ¿Seguimiento de cambios? ¿Información histórica? Pregúnteles a todos: alguien podría saber la verdadera razón
Luaan

Respuestas:


128

Su base de datos operativa debe estar altamente normalizada, para reducir anomalías .

Su base de datos analíticos (almacén) debe estar altamente desnormalizada, para facilitar el análisis.

Si no tiene una base de datos analítica separada, debe hacer algunas vistas altamente materializadas [materializadas].

Si le dice a sus analistas / gerentes de negocios senior que hagan muchas uniones para un análisis simple, bueno, podría ser despedido.

Agile Data Warehouse Design es un buen libro

Vea mis consejos rápidos de almacenamiento de datos sucios aquí


99
Este es el camino correcto.
Nit

66
+1 Esto es exactamente para lo que están destinadas las Vistas: permitir una vista desnormalizada en una base de datos normalizada.
Nzall

44
Absolutamente correcto, pero creo que "reducir las anomalías" debería enfatizarse más, ya que esa es la respuesta principal a la pregunta. La anomalía más común (¿solo?) Que verá con la duplicación / desnormalización de datos es que las columnas se llenarán de alguna manera con datos contradictorios al mismo tiempo, dejándolo sin forma de saber cuáles se supone que son los datos reales y no forma de determinar qué salió mal. Esto último puede mitigarse con un seguimiento masivo de los cambios, pero esto no será barato ni rápido para resolver el problema. Más rentable para evitar el problema por completo.
jpmc26

2
Otro ángulo a considerar es que, incluso suponiendo que los desarrolladores sean capaces de mantener los datos correctos (dudosos), se convierte en una gran pérdida de recursos para garantizar que cada campo duplicado se actualice cuando sea necesario para mantener la coherencia.
Nate CK

1
@Panzercrisis La única forma en que una transacción es "implícita" es si tiene una confirmación automática ejecutándose al final de su consulta. Este no suele ser el caso para una base de datos de producción. En una aplicación, las transacciones deben iniciarse automáticamente y una confirmación debe emitirse por separado de la consulta. Esta es una pequeña inversión inicial en la aplicación, pero simplifica los cambios de código que implican agregar llamadas a la base de datos y reduce cuánto debe pensar un desarrollador (mejora la velocidad de desarrollo, reduce los errores de desarrollo). Ese tipo de diseño también encaja bien con cosas como la agrupación de conexiones.
jpmc26

57

Entiendo por qué alguien quiere evitar escribir una unión para cada selección.

Pero puede crear una vez una vista con la unión y usarla en lugar de su tabla no normalizada.

Por lo tanto, combina la ventaja de la normalización con la comodidad de una selección fácil.


12
Las vistas son tus amigos. Úsalos generosamente. Y para el rendimiento, incluso podría usar vistas Materializadas si su RDBMS las admite.
VH-NZZ

13

Las respuestas que ya se han votado más o menos cubren "cómo evitar la duplicación" (usando vistas) pero no el por qué. Básicamente muestran que la duplicación de columnas es la solución incorrecta al problema de facilitar la escritura de consultas. Pero la pregunta "¿por qué no duplicar ninguna columna aleatoria solo por el gusto de hacerlo?" sigue en pie.

La respuesta es "Debido a la Ley de Murphy". La ley de Murphy establece que:

Si algo puede salir mal, lo hará.

En este caso, se supone que el contenido de cada campo de fila de una columna duplicada es idéntico al contenido de cada campo de fila correspondiente de la columna original. Lo que puede salir mal es que el contenido de algunos campos de fila puede diferir de los originales, causando estragos. Se podría pensar que usted ha tomado todas las precauciones imaginables para asegurarse de que no van a ser diferentes, pero la ley de Murphy señala que debido a que pueden ser diferentes, van a ser diferentes. Y se producirán estragos .

Como ejemplo de cómo puede suceder esto, simplemente considere el hecho de que las columnas duplicadas no se llenan de magia; alguien debe escribir un código que almacene valores en ellos cada vez que se crean filas en la tabla original, y alguien debe escribir un código que los actualice siempre que se modifiquen los originales. Dejando a un lado el hecho de que esto está agregando una carga indebida al código que ingresa datos en la base de datos (y que, por definición, es mucho más crucial que cualquier código que simplemente consulta la base de datos), alguien, en algún lugar, en ciertas circunstancias, podría olvidar para llevar a cabo esta duplicación. Entonces, los valores serán diferentes. O pueden recordar llevar a cabo la duplicación, pero no dentro de una transacción, por lo que, bajo ciertas condiciones de fallas raras, puede omitirse. Pero en realidad no necesitaba perder el tiempo escribiendo estos ejemplos,si puede salir mal, lo hará.


12

Pensarlo en términos de compensaciones en lugar de buenas / malas será más productivo. Están intercambiando las ventajas de la normalización (especialmente la coherencia) por ventajas en la usabilidad de consultas.

En un extremo, la base de datos se volvería inútil si los datos se volvieran severamente inconsistentes. En el otro extremo, la base de datos sería inútil si es demasiado difícil para las personas que necesitan consultarla todos los días para obtener resultados con los que puedan contar.

¿Qué puede hacer para reducir los riesgos y los costos?

  • Cree una herramienta de verificación de coherencia y ejecútela regularmente.
  • Dirija el acceso de escritura a través de un software que actualiza los datos replicados de manera consistente.
  • Agregue vistas o cree herramientas de consulta que hagan las uniones automáticamente para que los empresarios puedan pensar en términos de la información en lugar de los elementos internos de la base de datos.

6

Creo que el argumento más sólido para la normalización de datos para los analistas de negocios es que promueve la integridad de los datos. Si sus datos clave se almacenan en un solo lugar (una columna, en una tabla), es mucho menos probable que los datos se corrompan por actualizaciones incorrectas. Creo que probablemente les importaría la importancia de la integridad de los datos, por lo que esta podría ser una buena manera de convencerlos de actualizar sus formas de interactuar con la base de datos.

Es probable que un método de consulta un poco más difícil sea preferible a la posible corrupción de datos.


66
Su gente argumentará que son lo suficientemente buenos como para asegurarse de que todos los datos se actualicen correctamente (una premisa que discuto, si no se sienten cómodos con las uniones). Quizás un mejor argumento es que pierde la mayoría de los beneficios de ACID que proporcionan los RDBMS, si evita la normalización.
Robert Harvey

44
Probablemente, pero todo es una cuestión de riesgo. ¿Están dispuestos a aceptar el riesgo de corromper la base de datos porque facilita la consulta?
Oleksi

1
Jugando el abogado del diablo aquí, un argumento en contra obvio sería que, si alguien arruina una actualización y corrompe los datos de todos modos, eso es un problema con o sin normalización, y, al menos, tener algo de redundancia en la base de datos lo hace más probable que alguien notará la corrupción e incluso podrá solucionarla más tarde. (Por supuesto, la desnormalización ad hoc no es el esquema de detección de errores más confiable, pero el principio de verificación de errores a través de la redundancia es sólido: así es como funciona la contabilidad de doble entrada .)
Ilmari Karonen

O, para decirlo en otros términos, hay más en la integridad de los datos que solo la integridad relacional. Con una base de datos completamente normalizada, aún puede mantener una integridad relacional perfecta incluso si alguien estropea una actualización, pero eso no hace que los datos actualizados incorrectamente sean menos basura.
Ilmari Karonen

0

Para agregar a lo que los otros chicos han sugerido anteriormente. Este es un problema de gobernanza de datos. Debe trabajar con las partes interesadas relevantes: arquitectos de datos y administradores de datos para desarrollar principios de datos, políticas y convenciones de denominación.

Sea paciente y trabaje metódicamente. El cambio no sucederá de la noche a la mañana.


0

Dejar.

Honestamente, puede pasar meses discutiendo sobre la normalización, la coherencia y la lucha contra los errores locos causados ​​por la pereza, y luego dejar de fumar.

O simplemente puede ahorrar tiempo, frustración y renunciar ahora.

Los buenos programadores son personas muy vagas. Entienden las necesidades de los clientes y la administración. Pero lo más importante es que entienden que resolver bien los problemas, usar soluciones bien diseñadas y bien implementadas les ahorra personalmente ENORMES cantidades de trabajo, esfuerzo y, lo más importante, agonía y estrés.

Por lo tanto, sería mucho mejor trabajar en un lugar que comprenda y valore la buena ingeniería.

Buena suerte.


Pensamiento posterior: Quizás lo que necesitan son herramientas de BI / OLAP ... http://en.wikipedia.org/wiki/Online_analytical_processing

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.