Table de fait avec de multiples faits

Question

J'ai une dimension (SiteItem) a deux faits importants:

perUserClicks 
perBrowserClicks

Cependant, dans cette dimension, j'ai des groupes de valeurs basées sur une colonne d'attributs (appelons-les AboveFoldItems groupes, LeftNavItems, OnTheFlyItems, etc.) ont chacun plus de faits qui sont spécifiques à ce groupe:

AboveFoldItems: eyeTime, loadTime
LeftNavItems: mouseOverTime
OnTheFlyItems: doesn't have any extra, but may in the future

est le schéma de la table fait suivant ok?

DateKey   
SessionKey
SiteItemKey
perUserClicks 
perBrowserClicks
eyeTime
loadTime
mouseOverTime

Il semble un peu inutile car certaines colonnes se rapportent à des clés de dimension (les faits non pertinents sont laissés NULL). Mais ... cela semble que ce serait un problème commun, donc il devrait y avoir une solution commune pour cela, non?

Answer 1

Je suis généralement en accord avec la réponse de Damir à ce sujet, mais parce que la table de faits est très étroite dans votre cas particulier, il y a encore du mérite au advocation d'Aaron pour garder les valeurs NULL.

Nous avons plusieurs schémas en étoile dans des domaines particuliers avec plusieurs tables de faits qui partagent la plupart (sinon la totalité) des dimensions (et conformez interne). Les dimensions de portée limitée ne sont pas considérés comme « conformes » à travers l'entreprise, mais ils sont ce que nous appelons les dimensions « internes partagées ».

En général, si les données sont chargées simultanément de sorte que la dimension n'a pas changé, vous pouvez joindre les deux tables de fait sur les touches, mais en général, bien sûr, vous ne pouvez pas joindre deux schémas en étoile différents sur les touches de dimension si ils sont mères porteuses dans les dimensions traditionnelles changent lentement. En général, vous devez rejoindre étoiles distinctes sur les touches naturelles ou « clés d'affaires » dans la dimension et non sur les mères porteuses (sauf généralement dans le cas particulier de la dimension de la date où elle est immuable et ne dispose que d'une clé naturelle).

Notez que lorsque vous rejoignez les deux étoiles, vous devez utiliser LEFT JOIN, dans ce cas, vous produirez NULLs que vous aurez toujours sans doute de prendre en compte - si vous obtenez en fait revenir au modèle d'origine vous avez eu avec NULLs! ; -)

L'avantage de la table supplémentaire fait est plus évident lorsque vos tables sont grandes avec un petit jeu de clés et la répartition verticale des données produit des économies d'espace ainsi qu'un modèle logique propre - cela est particulièrement vrai lorsque les touches sont seulement vraiment partagé jusqu'à un certain point - ayant une clé ou clé NULL fictive est certainement pas une bonne idée -. cela indique généralement un problème de modélisation dimensionnelle

Cependant, comme le dit Aaron, si vous le poussez à l'extrême, vous pouvez avoir une seule colonne de fait dans chaque table de fait avec les touches partagées, ce qui signifie que les frais généraux clés rapetisse le coût de fait et vous avez vraiment finir dans un EAV déguisées modèle.

Je regarderais aussi de voir si vous êtes dans la situation de « trop Kimball quelques dimensions ». On dirait que vous devez avoir de bons attributs dimensionnels localisés dans le SessionKey et SiteItemKey - mais sans voir l'intégralité du modèle et les exigences, il est difficile de dire, mais je pense que vous auriez des données démographiques des utilisateurs dans un faible cardinalité ou même dimension flocon de neige sans pleine dimension session ou du site.

Answer 2

Il n'y a pas vraiment une solution élégante, soit vous avez des colonnes nullable ou vous utilisez une solution de EAV. J'ai posté sur EAV avant (et a suscité beaucoup de commentaires qui pourraient être la peine de lire):

• Ce qui est si mal à EAV, de toute façon?

Je suis un fan de ce modèle dans certains scénarios, mais si vos dimensions / attributs ne changent pas souvent, il peut être beaucoup de travail supplémentaire pour rien. Les valeurs NULL dans une colonne ne font pas vraiment des déchets aussi longtemps que le code environnant peut traiter de manière appropriée.

Answer 3

Vous pouvez avoir plus d'une table de fait: factperUserClicks, factperBroWserClicks, factEyeTime, etc ...

Chacun de ces aurait DateKey, SessionKey, SiteItemKey. Cette clés de façon que la dimension qui « font sens » apparaissent avec chaque fait.

Idéalement, il devrait y avoir aucun NULLS dans le DW - si vous les gardez dans la même table de fait, en utilisant des zéros peut être plus approprié

.

En ce qui concerne économiser l'espace disque, je ne vois pas une solution idéale - mais, dans un DW est censé commerce espace pour la vitesse et (requête) simplicité de toute façon

.