Sans connaître toute la structure de vos tables je suis limité dans mes conseils. Cependant, non, votre base de données ne tracera pas votre disparition si vous supprimez une colonne dans les circonstances suivantes (en aucun cas exhaustives):
- Vous utilisez toujours une clé de base de données pour mapper vos dimensions.
- Vos nouveaux indices sur ce nouveau tableau de dimension couvrent correctement les indices lorsqu'ils devraient l'être.
- Vous gérez ce nombre d'indices pour ne pas surcharger les insertions / mises à jour
Votre nouveau design a des tableaux à deux dimensions et un tableau de faits
- C'est pourquoi il est passé de m: 1 à m: n avec un tableau de "références croisées". Nous appelons cela une autre dimension.
La conception a effectivement mis en œuvre la normalisation pour y parvenir
- En supprimant une dépendance, votre équipe sera mieux équipée pour récupérer des faits qui peuvent transformer le traitement de vos données de manière plus significative.
Remarque sur les dimensions et les faits
- Dimensions pour le contexte descriptif
Les dimensions fournissent le contexte «qui, quoi, où, quand, pourquoi et comment» entourant un événement de processus métier. Les tableaux de dimensions contiennent les attributs descriptifs utilisés par les applications BI pour filtrer et grouper les faits. En gardant à l'esprit le grain d'une table de faits, toutes les dimensions possibles peuvent être identifiées.
Dans la mesure du possible, une dimension doit être à valeur unique lorsqu'elle est associée à une ligne de faits donnée . Les tables de dimensions sont parfois appelées «l'âme» de l'entrepôt de données car elles contiennent les points d'entrée et les étiquettes descriptives qui permettent au système DW / BI d'être exploité pour l'analyse commerciale. Une quantité disproportionnée d'efforts est investie dans la gouvernance des données et le développement des tableaux de dimensions car ils sont les moteurs de l'expérience BI de l'utilisateur.
Les faits sont les mesures qui résultent d'un événement de processus métier et sont presque toujours numériques. Une seule ligne de table de faits a une relation un à un avec un événement de mesure comme décrit par le grain de la table de faits . Ainsi, un tableau de faits correspond à un événement physique observable et non aux exigences d'un rapport particulier . Dans une table de faits , seuls les faits correspondant au grain déclaré sont autorisés . Par exemple, dans une transaction de vente au détail, la quantité d'un produit vendu et son prix étendu sont de bons faits, alors que le salaire du gérant de magasin est refusé.
Techniques de modélisation dimensionnelle de Kimball
Ma suggestion est que l'équipe de conception devrait savoir que l'application des règles dans la base de données est la meilleure, sauf si cela nuit aux performances. Je ne connais pas la taille ou la quantification de vos déclarations DDL pour répondre pleinement à cela, cependant.
Mais soyez assuré que cela devrait être un changement positif pour votre système, car maintenant SQL Server n'aura plus à parcourir toutes ces données supplémentaires pour récupérer ce qui compte vraiment.
Je ne peux pas parler pour votre base de données mais je vous détesterais pour ça :-)
La colonne héritée contiendra des données redondantes après la modification. Cela pourrait entraîner des données contradictoires si l'ancienne colonne et la nouvelle table xréf ne sont pas conservées de manière cohérente. Considérez que les développeurs qui ne connaissent pas la dette technique pourraient logiquement corrompre la base de données.
J'ai du mal à penser à une raison pour laquelle il ne faut pas supprimer la colonne et la relation héritées. Cela garantira également que tout le code dépendant a été correctement modifié.
la source