3

Je suis nouveau en modélisation dimensionnelle Je crois que vous pouvez m'aider dans les doutes suivants.Tableaux des clés naturelles et des faits

Dans le système de production, j'ai une table de transaction, une table des ventes par exemple. L'identifiant unique est une clé primaire appelée SaleId. Exemple:

enter image description here

Mon doute est lors de la modélisation de la table de fait si le SaleID être inclus dans la table de faits comme NaturalKey?

enter image description here

doit également la table de fait une clé artificielle?

N'hésitez pas à m'envoyer un lien comme référence. Merci d'avance

Répondre

3

Techniquement parlant, ce n'est probablement pas une clé naturelle - il semble que le système soit généré. Cependant, il est parfois très utile de stocker un identifiant généré par le système dans un fait pour l'utiliser comme dimension dégénérée. Habituellement, ce sont des cas où les utilisateurs professionnels voient cet ID généré par le système (numéros de commande, numéros de facture, numéros de bons de commande, etc.) ou s'il n'y a pas d'autre moyen utile d'identifier certaines lignes pouvant être regroupées .

Si les utilisateurs de vos solutions de BI sont susceptibles de vouloir accéder à l'information et de la regarder par la vente, alors le SaleID pourrait bien être un bon candidat pour ce traitement. Pensez-vous qu'il existe un autre moyen d'atteindre ce niveau? Un client peut-il être associé à deux ventes distinctes le même jour? Si oui, vos utilisateurs voudraient-ils les considérer comme deux ventes distinctes? Vous pourriez avoir besoin de leur parler pour savoir ce qui leur sera utile. Si, pour une raison ou une autre, vous ne pouvez pas obtenir une réponse claire, je dirais qu'il faut la garder - il y a peu de mal, et vous pouvez toujours l'enlever plus tard si elle n'est pas utilisée.

est ici de prendre du groupe Kimball sur dégénérés Dimensions, au cas où vous êtes à tout pas clair sur la façon dont ils travaillent:

http://www.kimballgroup.com/2003/06/design-tip-46-another-look-at-degenerate-dimensions/


En ce qui concerne les clés de substitution de la table des faits - je les utilise toujours . Comme le souligne Kimball Design Tip #81, ils sont parfois utiles, et c'est le genre de chose que je préfère mettre au début et ne pas utiliser que de réaliser plus tard qu'il aurait été utile d'avoir. Point 2 - où vous pouvez faire des mises à jour en insérant de nouvelles lignes et en supprimant les anciennes - cela s'applique certainement au travail que j'ai fait.

+1

J'ai supprimé ma réponse, puisque la vôtre fournit beaucoup plus d'informations. Je l'ai légèrement modifié pour supprimer les références au mien et j'espère que cela ne vous dérange pas. –

+1

@MarekGrzenkowicz La modification est très bien, merci de me le faire savoir! Je voulais juste donner du crédit là où il était dû puisque vous aviez dépassé certains points valables. –

4

L'exigence d'une clé primaire dans une table de faits dépend du type de la table de faits. Les faits transactionnels qui ne sont jamais mis à jour n'en ont pas besoin. Les instantanés périodiques n'en ont probablement pas besoin, sauf si la période en cours est une mesure à jour. L'accumulation d'instantanés en a définitivement besoin.