Comment puis-je argumenter de manière convaincante contre la duplication de colonnes de base de données?

47

J'ai commencé à travailler dans une nouvelle organisation et l'un des modèles observés dans la base de données consiste à dupliquer des champs afin de faciliter la rédaction des requêtes pour les analystes métier. Nous utilisons Django et son ORM.

Dans un cas, nous conservons un objet MedicalRecordNumber avec une chaîne unique identifiant un patient dans un certain contexte. Nous avons des objets d' inscription qui suivent les patients et ont des numéros médicaux associés , mais plutôt que d'utiliser une relation de clé étrangère, ils dupliquent la chaîne afin d'éviter d'écrire une jointure ( pas pour des raisons de performances). Ce modèle est commun dans toute la base de données.

Pour moi, l’importance de la propreté d’un modèle de données tient au fait que j’y réfléchis bien. La complexité inutile est un gaspillage de mon temps de traitement cognitif limité. C'est un problème systématique. Ne pas être à l'aise pour écrire des jointures est un problème de compétences rectifiable. Je ne veux pas forcément préconiser de revenir en arrière et de changer le schéma, mais j'aimerais pouvoir expliquer de manière convaincante les problèmes liés à ce type de duplication.

canisrufus
la source
2
Que signifie "ne pas être à l'aise pour écrire des jointures"? Comment expliquent-ils cela?
scriptin
9
Est-ce que ces gens travaillent pour vous? Êtes-vous leur superviseur? La plupart de vos justifications peuvent être trouvées ici: en.wikipedia.org/wiki/Database_normalization . Oui, ils doivent mieux utiliser les jointures.
Robert Harvey
1
Avez-vous consulté la littérature sur les raisons pour lesquelles la normalisation est souhaitable?
Nathan Tuggy
17
L'ajout de vues faisant la jointure en interne ne faciliterait-il pas l'écriture des requêtes? Vous pouvez les suggérer comme alternative.
CodesInChaos
1
L'avez-vous communiqué (poliment) avec vos pairs et vos aînés? Quelles sont leurs justifications, quelles considérations font-ils? Cela peut être une bonne idée pour de nombreuses raisons (même si vous dites que "la performance n’est pas la raison", quelles preuves avez-vous pour le prouver?). Avant de les accuser d'être trop paresseux et / ou rigide, avez-vous examiné (et demandé) les raisons pour lesquelles ils ont conçu le design tel qu'il est? Peut-être y a-t-il beaucoup plus de lectures que d'écritures (analytics heavy DB)? Changer le suivi? Données historiques? Demandez à tout le monde - quelqu'un pourrait connaître la vraie raison.
Luaan

Réponses:

128

Votre base de données opérationnelle doit être hautement normalisée afin de réduire les anomalies .

Votre base de données analytique (entrepôt) doit être hautement dénormalisée afin de faciliter l'analyse.

Si vous ne disposez pas d'une base de données analytique séparée, vous devez créer des vues [matérialisées] hautement dénormalisées.

Si vous demandez à vos analystes / gestionnaires d’entreprise senior de faire beaucoup de jointures pour une analyse simple, vous risquez de vous faire virer.

Agile Data Warehouse Design est un bon livre

Voir mes astuces quick n 'dirty data warehouse ici

Neil McGuigan
la source
9
C'est la bonne façon de faire.
Nit
6
+1 C’est exactement ce à quoi sont destinées les vues: autoriser une vue dénormalisée sur une base de données normalisée.
Nzall
4
Absolument correct, mais je pense qu'il faut insister davantage sur "réduire les anomalies", car c'est la réponse principale à la question. L’anomalie la plus courante (seule?) Que vous verrez avec la duplication / dénormalisation des données est que les colonnes seront en quelque sorte peuplées avec des données contradictoires en même temps, vous laissant ainsi le moyen de savoir ce que les données réelles sont supposées être et non. manière de déterminer ce qui a mal tourné. Ce dernier peut être atténué par un suivi massif des modifications, mais ce ne sera ni bon marché ni rapide à résoudre pour trouver le problème. Plus rentable pour éviter complètement le problème.
jpmc26
2
Un autre angle à prendre en compte est que, même en supposant que les développeurs soient capables de conserver des données correctes (douteux), leurs ressources sont considérablement sollicitées pour garantir que chaque champ dupliqué est mis à jour lorsque cela est nécessaire pour maintenir la cohérence.
Nate CK
1
@Panzercrisis La transaction est "implicite" uniquement si une validation automatique est en cours d'exécution à la fin de votre requête. Cela ne devrait généralement pas être le cas pour une base de données de production. Dans une application, les transactions doivent être lancées automatiquement et une validation doit être émise séparément de la requête. Il s’agit d’un petit investissement initial dans l’application, mais cela simplifie les modifications de code qui impliquent l’ajout d’appels à une base de données et réduit le temps qu’un développeur doit prendre en compte (améliore la vitesse de développement, réduit les erreurs de développement). Ce type de conception s’intègre également bien à des choses comme la mise en commun des connexions.
jpmc26
57

Je comprends pourquoi quelqu'un veut éviter d'écrire une jointure pour chaque sélection.

Mais vous pouvez créer une fois une vue avec la jointure et l'utiliser à la place de votre table non normalisée.

Vous combinez ainsi l’avantage de la normalisation avec la commodité d’une sélection facile.

noué
la source
12
Les vues sont vos amis. Utilisez-les généreusement. Et pour améliorer les performances, vous pouvez même utiliser des vues matérialisées si votre SGBDR les prend en charge.
VH-NZZ le
13

Les réponses qui ont déjà été votées couvrent à peu près le "comment éviter la duplication" (en utilisant des vues) mais pas le pourquoi. En gros, ils montrent que la duplication de colonnes n’est pas la bonne solution pour faciliter l’écriture de requêtes. Mais la question "pourquoi ne pas dupliquer une colonne aléatoire juste pour le plaisir?" encore debout.

La réponse est "à cause de la loi de Murphy". La loi de Murphy stipule que:

Si quelque chose peut mal tourner, ça va aller.

Dans ce cas, le contenu de chaque champ de ligne d'une colonne dupliquée est supposé être identique au contenu de chaque champ de ligne correspondant de la colonne d'origine. Ce qui peut mal se passer, c’est que le contenu de certains champs de ligne peut différer de celui des champs originaux, ce qui fait des ravages. Vous pourriez penser que vous avez pris toutes les précautions imaginables pour vous assurer qu'elles ne seront pas différentes, mais la loi de Murphy stipule que, dans la mesure où elles peuvent différer, elles seront différentes. Et le chaos va s'ensuivre.

Pour illustrer cela, considérez simplement le fait que les colonnes dupliquées ne sont pas remplies par magie; quelqu'un doit réellement écrire du code qui stocke des valeurs à chaque fois que des lignes sont créées dans la table d'origine, et quelqu'un doit écrire du code qui les met à jour régulièrement chaque fois que les originaux sont modifiés. Mis à part le fait que cela ajoute une charge excessive au code qui entre des données dans la base de données (et qui, par définition, est bien plus crucial que tout code qui interroge simplement la base de données), quelqu'un, quelque part, dans certaines circonstances, pourrait oublier effectuer cette duplication. Ensuite, les valeurs seront différentes. Ils peuvent également se rappeler d’effectuer la duplication, mais pas dans le cadre d’une transaction, de sorte qu’elle puisse être omise dans certaines conditions de défaillance rares. Mais je n’ai pas vraiment besoin de perdre mon temps à écrire ces exemples,si ça peut aller mal, ça ira.

Mike Nakis
la source
12

Le penser en termes de compromis plutôt que de bons / mauvais sera plus productif. Ils échangent les avantages de la normalisation (en particulier la cohérence) contre ceux de l’utilisation des requêtes.

À un extrême, la base de données deviendrait inutile si les données devenaient sérieusement incohérentes. À l'opposé, la base de données serait inutile s'il était trop difficile pour les personnes qui doivent l'interroger tous les jours pour obtenir des résultats fiables.

Que pouvez-vous faire pour réduire les risques et les coûts?

  • Construisez un outil de vérification de la cohérence et exécutez-le régulièrement.
  • Acheminez les accès en écriture via un logiciel mettant à jour les données répliquées de manière cohérente.
  • Ajoutez des vues ou créez des outils de requête qui effectuent les jointures automatiquement afin que les utilisateurs puissent penser en termes d’informations plutôt qu’en internes.
Jerry101
la source
6

Je pense que le principal argument en faveur de la normalisation des données pour les analystes métier est qu’elle favorise l’intégrité des données. Si vos données de clé sont stockées dans un seul emplacement (une colonne, une table), il est beaucoup moins probable que les données soient corrompues par des mises à jour incorrectes. Je pense qu'ils se soucieraient probablement de l’importance de l’intégrité des données. C’est donc un bon moyen de les convaincre de mettre à jour leurs méthodes d’interaction avec la base de données.

Une méthode d'interrogation légèrement plus difficile va probablement être préférable à une corruption potentielle des données.

Oleksi
la source
6
Ses collaborateurs soutiendront qu'ils sont assez bons pour s'assurer que toutes les données sont correctement mises à jour (une prémisse que je conteste, s'ils ne sont pas à l'aise avec les jointures). Peut-être un meilleur argument est-il que vous perdez la plupart des avantages d'ACID fournis par les SGBDR, si vous évitez la normalisation.
Robert Harvey
4
Probablement, mais tout est une question de risque. Sont-ils disposés à accepter le risque de corruption de la base de données car cela facilite les requêtes?
Oleksi
1
En défendant ici l'avocat du diable, un contre-argument évident serait que, si quelqu'un va de toute façon foirer une mise à jour et corrompre des données, c'est un problème avec ou sans normalisation - et, au moins, une certaine redondance dans la base de données la rend plus probable. que quelqu'un remarquera la corruption et pourra même le réparer plus tard. (Bien entendu, la dénormalisation ad hoc n'est pas le schéma de détection d'erreur le plus fiable, mais le principe de vérification des erreurs par redondance est bon: c'est ainsi que fonctionne la comptabilité en partie double .)
Ilmari Karonen Le
En d'autres termes, l'intégrité des données ne se limite pas à l'intégrité relationnelle. Avec une base de données entièrement normalisée, vous pouvez toujours conserver une intégrité relationnelle parfaite, même si quelqu'un gâche une mise à jour, mais cela ne réduit en rien les données mises à jour de manière incorrecte.
Ilmari Karonen
0

Pour ajouter à ce que les autres gars ont suggéré ci-dessus. C'est un problème de gouvernance des données. Vous devez travailler avec les parties prenantes concernées: architectes de données et gestionnaires de données pour élaborer des principes, des règles et des conventions de dénomination des données.

Soyez patient et travaillez méthodiquement. Le changement ne se fera pas du jour au lendemain.

hlosukwakha
la source
0

Quitter.

Honnêtement, vous pouvez passer des mois à débattre de la normalisation, de la cohérence et de la lutte contre les bugs fous causés par la paresse pure, puis cesser de fumer.

Ou vous pouvez simplement gagner du temps, éviter la frustration et arrêter maintenant.

Les bons programmeurs sont des gens très paresseux. Ils comprennent les besoins des clients et de la direction. Mais surtout, ils comprennent que résoudre correctement les problèmes, en utilisant des solutions bien conçues et bien mises en œuvre, leur évite personnellement d' énormes quantités de travail, d'efforts et, surtout, d'agonie et de stress.

Vous feriez bien mieux de travailler dans un endroit qui comprend et valorise une bonne ingénierie.

Bonne chance.


Après coup: ils ont peut-être besoin d'outils BI / OLAP ... http://en.wikipedia.org/wiki/Online_analytical_processing

AK_
la source