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

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.

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

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.

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.

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.

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.

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.

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