Comment empêcher les enregistrements orphelins dans les tables de détail de la base de données normalisée?

Question

Je dois maintenir une ancienne base de données qui n'est pas correctement normalisée. Par exemple, il y a une table de projet qui a grandi (ou peut-être explosé) pour avoir 5 colonnes de dates différentes ou plus, pour différentes étapes du projet allant de la commande à la date de livraison. Il existe également plusieurs tables contenant chacune des colonnes pour les adresses civiques, les adresses électroniques ou les liens Web.

Je voudrais normaliser la structure, créer des tableaux d'adresses, des dates planifiées, etc., ainsi que les tableaux nécessaires pour permettre les relations 1: N (adresse par client, date d'échéance par projet, etc.).

Pour le moment, je ne sais absolument pas comment gérer les modifications apportées aux données dans les tableaux détaillés. Considérons par exemple le changement d'adresse de livraison d'un client. Il est hors de question de modifier les données de la table d’adresses, car plusieurs enregistrements (éventuellement dans plusieurs tables) pourraient référencer cet enregistrement. L'ajout d'un nouvel enregistrement d'adresse peut laisser l'ancien enregistrement orphelin si aucune autre ligne n'a de relation avec une clé étrangère.

J'ai réfléchi aux moyens suivants pour gérer cela:

• Ajoutez un nouvel enregistrement détaillé et vérifiez dans un déclencheur de mise à jour de la table principale si l'ancien enregistrement détaillé doit être supprimé. Cela nécessiterait une connaissance de toutes les tables ayant des relations avec la table de détail, dans chacune d'elles ou dans un sproc. Je n'aime pas cette perte de séparation. Cela impliquerait également plus de tables dans la transaction active.

• Laissez le déclencheur essayer de supprimer l'ancien enregistrement détaillé et de détecter les erreurs éventuelles. Cela ne va pas.

• Vivez avec l'enregistrement orphelin et demandez à une tâche de maintenance périodique de nettoyer toutes les tables détaillées.

Quelle est la méthode préférée pour gérer les modifications de données dans les tables de détail liées à plusieurs tables maîtres? Des conseils pour en savoir plus?

Answer 1

Une partie du problème peut provenir de la conception de schéma originale: les clés étrangères indiquent la mauvaise direction, les adresses, numéros de téléphone, etc., sont gérées de manière maîtresse et non comme des détails. Cela peut être pratique lorsque vous souhaitez que toutes les utilisations d'une adresse donnée soient mises à jour à la fois, mais d'après mon expérience, cela entraîne toujours trop de cas exceptionnels difficiles. déménagement du domicile ou du bureau afin de mettre à jour l’enregistrement existant. Si vous essayez de masquer ce détail à l'utilisateur sur l'écran CRUD, vous vous retrouvez dans une situation où il ne fait tout simplement pas ce que vous voulez.

Si cette méthode est utilisée uniquement pour réduire les valeurs en double, il s'agit en réalité d'une dénormalisation de la base de données: la simple existence de la ligne d'adresse n'a pas de sens. La seule différence est que contrairement à la plupart des dénormalisations, il tente de gagner en efficacité spatiale au lieu de la vitesse. Créer une table de liens à ce stade ne fait que compliquer le problème.

Si vous souhaitez, par exemple, plusieurs adresses par contact, faites-en une table de détail avec une clé étrangère pointant vers le contact parent et ne vous inquiétez pas des valeurs d'adresse dupliquées, car ce ne sont que des valeurs. . Dans le cas contraire, faites de Address une entité réelle: ajoutez un titre ou un champ de description et un écran CRUD afin qu’il puisse se présenter seul en tant qu’entité.

Answer 2

Vivez avec l'enregistrement orphelin et demandez à une tâche de maintenance périodique de nettoyer toutes les tables détaillées.

Answer 3

Je pense que vous êtes en train de brouiller les cas de suppression et de mise à jour.

Si vous avez les clients a et b, et que les deux utilisent la même adresse, les enregistrements d'une table relationnelle (tels que ClientAddresses, par exemple, seront mémorisés) plus complexe que cela)

Je pense que si deux clients partagent une adresse identique et qu'elle est incorrecte pour le client a, elle le serait également pour le client b (erreur de saisie de données), mais si vous êtes sûr de ne pas vouloir que le client change faites à l'adresse de base, supprimez l'enregistrement d'association (supprimer de ClientAddresses) et ajoutez une nouvelle adresse. Lorsque vous effectuez la suppression de la table relationnelle (probablement d'une procédure stockée), vérifiez s'il existe d'autres enregistrements faisant référence à l'enregistrement d'adresse en cours de dissociation, sinon supprimés de la table de base.