Puis-je avoir des codes de non-mesure mélangés avec des mesures dans mon tableau de faits?

Question

Nous faisons une accumulation complexe de données. Notre client nous envoie des éléments comportant deux dimensions (le temps et une unité commerciale). Le temps est principalement année-mois. La dimension de l'unité commerciale ne comporte que quelques attributs: un nom et quelques catégories auxquelles les BU peuvent appartenir à des fins de reporting et d'analyse.

Les éléments qu’ils nous envoient incluent des informations sur l’état actuel (dates et codes). Celles-ci semblent être comme des faits. Ils envoient également des informations qui caractérisent la relation avec l'unité business (principalement des codes supplémentaires). Encore une fois, ils sont spécifiques à l’unité et à la période.

Enfin, ils nous envoient des informations clairement additives. Il inclut les devises et les comptes qui ont des unités appropriées.

Devrais-je combiner ces informations qualitatives dans une seule table de faits avec les faits additifs? Ou devrais-je séparer les éléments qualitatifs (qui ne peuvent être utilisés qu'avec des comptes) des éléments quantitatifs (qui peuvent être utilisés avec sum)?

Answer 1

Ne placez les éléments dans la table de faits que s'ils sont dégénérés (ce qui pose un problème de cardinalité / unicité dans votre dimension où il prend la dimension d'une relation 1-1 à la table de faits). Kimball recommande d'éviter la tentation de mettre n'importe quoi sauf des dimensions dégénérées dans les faits (numéro de commande unique, par exemple).

Vous pouvez toujours les inclure dans ce que Kimball appelle un "courrier indésirable". dimension. Tous ces codes peuvent simplement être regroupés dans une dimension indésirable. La plupart des dates sont classées dans la table de faits en tant que clés dans votre dimension de date dans un rôle particulier (généralement avec une clé int naturelle de la forme AAAAMMJJ - une des seules fois où nous n'utilisons pas de clé de substitution sans signification non-identité)

J'aime regarder naïvement l’étoile comme l’ensemble des faits, puis les colonnes dans lesquelles les dimensions sont simplement déterminées par la commodité. On ne doit pas nécessairement les considérer comme correspondant à une entité commerciale particulière. Rappelez-vous que l’étoile n’est pas une base de données OLTP normalisée de type DRE.

Answer 2

Si les données sont à la fois directement liées au fait additif et ne sont pas quelque chose que vous voulez regrouper / trier / rechercher, alors le placer dans la table de faits est correct.

Sachez toutefois que les données non additives de la table de faits empêchent les cumuls ou deviennent une opération avec perte.

Answer 3

Brad Wilson décrit avec précision le risque de les ajouter à votre tableau de faits. Dans le passé, j’avais ajouté des attributs de courrier indésirable à ma table de faits uniquement pour exiger un refactoring plus tard.

  

Les articles qu’ils nous envoient en incluent   informations sur l'état actuel (dates et   codes). Celles-ci semblent être comme des faits. Ils   envoyer aussi des informations qui   caractérise la relation avec   la business unit (majoritairement additionnelle   codes). Encore une fois, ceux-ci sont uniques à la   unité commerciale et période.

À quoi servent les dates? De prime abord, je recommanderais de définir ces dimensions et de les décrire avec précision.

Quelle est la volatilité des codes supplémentaires entrés? Si le grain de votre table de faits est la date et la BU, pourquoi ne peuvent-ils pas être inclus dans la dimension de la BU et traités comme des attributs évoluant lentement?

Sans plus de détails, je ne peux pas faire de recommandation ferme, mais ce seraient les premières questions que je me poserais.