Faktentabelle mit mehreren Fakten

Question

Ich habe eine Dimension (SiteItem) hat zwei wichtige Fakten:

perUserClicks 
perBrowserClicks 

jedoch in dieser Dimension, ich habe Gruppen von Werten auf der Grundlage einer Attributspalte (lassen Sie sich die Gruppen AboveFoldItems nennen, LeftNavItems, OnTheFlyItems, etc.) haben jeweils mehr Fakten, die spezifisch für diese Gruppe:

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

Ist die folgende Tatsache Tabellenschema ok?

DateKey 
SessionKey 
SiteItemKey 
perUserClicks 
perBrowserClicks 
eyeTime 
loadTime 
mouseOverTime 

Es scheint ein wenig verschwenderisch, da nur einige Spalten zu einigen Dimensionsschlüssel beziehen (die irrelevanten Tatsachen bleiben NULL). Aber ... das scheint ein häufiges Problem zu sein, also sollte es eine gemeinsame Lösung dafür geben, oder?

Answer 1

Ich stimme generell mit Damirs Antwort überein, aber da die Faktentabelle in Ihrem speziellen Fall sehr eng ist, gibt es immer noch einen Verdienst für Aarons Befürwortung, die NULL zu behalten.

Wir haben mehrere Sternschemata in bestimmten Themenbereichen mit mehreren Faktentabellen, die die meisten (wenn nicht alle) der Dimensionen (konform und intern) teilen. Die Dimensionen mit begrenzter Reichweite werden im gesamten Unternehmen nicht als "konform" angesehen, sondern als "gemeinsame interne" Dimensionen.

Jetzt, wenn die Daten gleichzeitig geladen werden, so dass die Dimension nicht geändert wurde, können Sie beide Faktentabellen auf den Schlüsseln verknüpfen, aber im Allgemeinen können Sie natürlich nicht zwei verschiedene Sternschemas für die Dimensionsschlüssel verknüpfen wenn sie Surrogate in traditionellen sich langsam verändernden Dimensionen sind. Im Allgemeinen müssen Sie separate Sterne auf den natürlichen Schlüsseln oder "Geschäftsschlüsseln" innerhalb der Dimension und nicht auf Surrogaten zusammenführen (außer normalerweise im Spezialfall der Datumsdimension, wo sie sich nicht ändert und nur einen natürlichen Schlüssel hat).

Beachten Sie, dass wenn Sie die beiden Sterne verbinden, Sie einen LINKEN JOIN verwenden müssen. In diesem Fall werden Sie NULLEN produzieren, die Sie wahrscheinlich noch berücksichtigen müssen - damit Sie tatsächlich zum Original zurückkehren Modell, das du mit NULL hatte!;-)

Der Vorteil der zusätzlichen Faktentabelle ist offensichtlicher, wenn Ihre Tabellen mit einer kleineren Menge von Schlüsseln breit sind und die vertikale Partitionierung der Daten Platzersparnisse sowie ein saubereres logisches Modell erzeugt - das ist besonders zutreffend Wenn die Schlüssel nur wirklich bis zu einem Punkt geteilt werden - mit einem Dummy-Schlüssel oder NULL-Schlüssel ist definitiv keine gute Idee - dies verweist in der Regel auf ein dimensionales Modellierungsproblem. Wie Aaron sagt, wenn Sie es auf die Spitze treiben, können Sie eine einzelne Faktenspalte in jeder Faktentabelle mit gemeinsamen Schlüsseln haben, was bedeutet, dass der Schlüsseloverhead die Faktenkosten in den Schatten stellt und Sie wirklich in einem verkleideten Zustand enden EAV-Modell.

Ich würde auch sehen, ob Sie in Kimballs Situation von "zu wenigen Dimensionen" sind. Scheint so, als müssten Sie gute dimensionale Attribute in SessionKey und SiteItemKey haben - aber ohne Ihr gesamtes Modell und Ihre Anforderungen zu sehen, ist es schwer zu sagen, aber ich würde denken, dass Sie einige demografische Daten in einer niedrigen Kardinalität oder sogar Snowflake Dimension ohne haben vollständige Sitzungs- oder Site-Dimension

Answer 2

Es gibt wirklich keine elegante Lösung, Sie haben entweder Nullable-Spalten oder Sie verwenden eine EAV-Lösung. Ich stellte über EAV vor (und eine Menge Kommentar erzeugt, die lesenswert sein könnten):

http://sqlblog.com/blogs/aaron_bertrand/archive/2009/11/19/what-is-so-bad-about-eav-anyway.aspx

Ich bin ein Fan von diesem Modell in einigen Szenarien, aber wenn Ihre Abmessungen/Attribute, nicht häufig ändern es kann viel zusätzliche Arbeit für nichts sein. NULL-Werte in einer Spalte machen nicht wirklich Verschwendung, solange der umgebende Code mit ihnen angemessen umgehen kann.

Answer 3

Sie könnten mehr als eine Faktentabelle haben: factperUserClicks, factperBroWserClicks, factEyeTime, etc ...

Jede dieser DateKey, SessionKey, SiteItemKey hätte. Auf diese Weise erscheinen nur Dimensionsschlüssel, die "Sinn ergeben" mit jeder Tatsache.

Im Idealfall sollte es keine NULL in der DW geben - wenn Sie sie in der gleichen Faktentabelle behalten, ist die Verwendung von Nullen möglicherweise besser geeignet.

Soweit ich Speicherplatz sparen kann, sehe ich keine ideale Lösung - aber in einer DW soll man sowieso Platz für Geschwindigkeit und (Abfrage-) Einfachheit tauschen.