Datawarehouse-Design: Kombinierte Datums- und Uhrzeitdimension im Vergleich zu getrennten Tag- und Zeitdimensionen und Zeitzonen

Wir beginnen gerade mit dem Entwurf für ein neues Data Warehouse und versuchen zu entwerfen, wie unsere Datums- und Zeitdimensionen funktionieren. Wir müssen in der Lage sein, mehrere Zeitzonen zu unterstützen (wahrscheinlich mindestens GMT, IST, PST und EST). Wir dachten anfangs, dass wir eine breite kombinierte Datums- / Zeitdimension bis zu einer Granularität von vielleicht 15 Minuten haben würden. Auf diese Weise haben wir einen Schlüssel in unseren Faktentabellen und alle unterschiedlichen Datums- und Zeitdaten für alle unterstützten Zeitzonen befinden sich in einer Dimensionstabelle. (dh Datumsschlüssel, GMT-Datum, GMT-Zeit, IST-Datum, IST-Zeit usw.)

Kimball schlägt vor, eine von der Tageszeitdimension getrennte Tagesdimension zu verwenden, um zu verhindern, dass die Tabelle zu groß wird (Data Warehouse-Toolkit, S. 249). Dies klingt jedoch in Ordnung. Dies würde bedeuten, dass wir für jede Zeitzone zwei Schlüssel in unseren Faktentabellen haben Wir müssen unterstützen (eine für das Datum und eine für die Tageszeit).

Da ich in diesem Bereich sehr unerfahren bin, hoffe ich, dass jemand da draußen die Kompromisse zwischen den beiden Ansätzen kennt, dh die Leistung im Vergleich zur Verwaltung aller verschiedenen Zeitzonenschlüssel. Vielleicht gibt es auch andere Ansätze. Ich habe einige Leute gesehen, die davon gesprochen haben, eine separate Zeile in der Faktentabelle pro Zeitzone zu haben, aber das scheint ein Problem zu sein, wenn Faktentabellen Millionen von Zeilen sind, müssen Sie sie vervierfachen, um Zeitzonen hinzuzufügen .

Wenn wir das 15-Minuten-Korn machen, haben wir 131.400 (24 * 15 * 365) Zeilen pro Jahr in unserer Datums- / Zeitdimensionstabelle, was für die Leistung nicht allzu schrecklich klingt, aber wir werden es nicht sicher wissen, bis wir einige testen Prototyp-Abfragen. Das andere Problem mit separaten Zeitzonenschlüsseln in der Faktentabelle ist, dass die Abfrage die Dimensionstabelle basierend auf der gewünschten Zeitzone mit einer anderen Spalte verknüpfen muss. Vielleicht ist dies etwas, das SSAS für Sie erledigt, da bin ich mir nicht sicher .

Danke für alle Gedanken, -Matt

Wenn Sie Datum und Uhrzeit getrennt haben, können Sie Aggregate sehr einfach nach Zeit erstellen. Zum Beispiel: Wenn Sie eine Abfrage ausführen möchten, um herauszufinden, welcher Zeitraum des Tages am meisten beschäftigt ist. Dies ist sehr einfach unter Verwendung einer separaten Zeitdimension durchzuführen.

Außerdem sollten Sie nur einen Zeitschlüssel haben. Entscheiden Sie sich für eine GMT / EST-Zeit und verwenden Sie diese in der Faktentabelle. Wenn Sie Berichte basierend auf der anderen Zeitzone ausführen müssen, konvertieren Sie sie einfach in Ihre Anwendung oder Abfrage.

Nur eine Fortsetzung unserer Entscheidung, unser DataWarehouse so zu implementieren, dass es mehrere Zeitzonen unterstützt und so effizient wie möglich ist: Wir haben eine Tabelle mit Zeitzonen (ID, Name usw.) sowie eine "Zeitzone" erstellt Brücke "Tabelle, die so aussieht:

time_zone_bridge
---------------
date_key_utc
time_key_utc
timezone_id
date_key_local
time_key_local

Auf diese Weise können wir unsere normalen Datums- und Zeitdimensionstabellen klein halten. Alle unsere Fakten sind mit den UTC-Datums- / Zeitschlüsseln verknüpft. Wenn wir nach einer anderen Zeitzone berichten / gruppieren müssen, müssen wir uns nur über die Zeitzonenbrückentabelle verbinden und verknüpfen Sie die lokalen Datums- / Zeitschlüssel mit den Datums- und Zeitdimensionstabellen. Wir füllen unsere Zeitzonenbrückentabelle mit C # -Code, der von SSIS aufgerufen wird, da dies viel weniger kompliziert war als das direkte Ausführen von TZ-Inhalten von SqlServer.

Ich habe die Idee eines Lagers mit einer kombinierten DateTimeDimension abgelehnt gesehen, aber ich habe keinen wirklich klaren Grund dafür gesehen. Hier ist die Faktentabelle, die ich gerade erstelle:

Transactions
(
...
CreatedDateTimeSK         INT NOT NULL,  -- Four bytes per date...
AuthorizedDateTimeSK      INT NOT NULL,
BatchSubmittedDateTimeSK  INT NOT NULL,
BatchApprovedDateTimeSK   INT NOT NULL,
SettlementDateTimeSK      INT NOT NULL,
LocalTimeZoneSK           TINYINT NOT NULL  -- ...plus one byte for the time zone
)

Die DateTimeFelder werden mit einer DateTime-Tabelle verknüpft:

DateTimes
(
DateTimeSK   INT NOT NULL PRIMARY KEY,
SQLDate      DATE NOT NULL,
SQLDateTime  DATETIME2(0) NOT NULL,
Year         SMALLINT NOT NULL,
Month        TINYINT NOT NULL,
Day          TINYINT NOT NULL,
Hour         TINYINT NOT NULL,
Minute       TINYINT NOT NULL CHECK (Minute IN (0, 30)),
...
)

Dies entspricht einer Auflösung von einer halben Stunde. Es gibt also 48 Datensätze pro Tag, 350.400 in 20 Jahren - ziemlich überschaubar.

Datum / Uhrzeit des Ereignisses werden beim Speichern in UTC übersetzt, aber mit dem LocalTimeZoneSKFeld und einer Brückentabelle können wir uns leicht verbinden, um die Ortszeit zu erhalten:

TimeZoneBridge
(
DateTimeSK       INT NOT NULL,
TimeZoneSK       TINYINT NOT NULL,
PRIMARY KEY (DateTimeSK, TimeZoneSK),
LocalDateTimeSK  INT NOT NULL
)

Um Transaktionen heute zu erstellen, UTC-Zeit:

SELECT COUNT(*)
FROM Transactions AS T
  INNER JOIN DateTimes AS CD ON T.CreatedDateTimeSK = CD.DateTimeSK
WHERE CD.SQLDate = '2014-08-22'

So erstellen Sie Transaktionen heute in Ortszeit für die Transaktion:

SELECT COUNT(*)
FROM Transactions AS T
  INNER JOIN TimeZoneBridge AS TZB ON T.CreatedDateTimeSK = TZB.DateTimeSK AND T.TimeZoneSK = TZB.TimeZoneSK
  INNER JOIN DateTimes AS CD ON TZB.LocalDateTimeSK = CD.DateTimeSK
WHERE CD.SQLDate = '2014-08-22'

Sie könnten versucht sein, die Dinge zu vereinfachen, indem Sie die TimeZoneSKdurch einen REALVersatz ersetzen (z. B. -5,0 für die zentrale Sommerzeit in den USA). Dies wird jedoch nicht möglich sein, wenn sich Datum / Uhrzeit für einen Faktendatensatz in der Sommerzeit befinden und andere nicht.

Wenn die Ereignisse für einen Faktendatensatz in verschiedenen Zeitzonen auftreten können, z. B. in einer Sendung oder einem Flug, benötigen Sie für jedes Datum ein Zeitzonenfeld und bis zu fünf Byte pro Datum.