Zeit- und Datumsdimension im Data Warehouse

Question

Ich baue ein Data Warehouse. Jede Tatsache hat es ist es timestamp. Ich muss tagsüber, Monat, Quartal, aber auch nach Stunden Berichte erstellen. Wenn ich mir die Beispiele anschaue, sehe ich, dass Daten in Dimensionstabellen in der Regel gespeichert werden.
_{(Quelle: ETL-TOOLS.info)}

Aber ich denke, dass es keinen Sinn für die Zeit macht. Der Dimensionstisch würde wachsen und wachsen. Auf der anderen Seite ist die Tabelle der Datumsdimension effizienter als die Verwendung von Datums-/Zeitfunktionen in SQL.

Was sind Ihre Meinungen/Lösungen?

(Ich benutze InfoBright)

Answer 1

Ich vermute, dass es von Ihrer Berichtsanforderung abhängt. Wenn Sie so etwas wie brauchen

WHERE "Hour" = 10

Das heißt jeden Tag zwischen 10:00:00 und 10:59:59, dann würde ich die Zeitdimension verwenden, weil sie schneller als

WHERE date_part('hour', TimeStamp) = 10  

Weil die Funktion date_part () für jede Zeile ausgewertet wird. Sie sollten den Zeitstempel noch im Faktentisch behalten, um über Grenzen von Tagen zu aggregieren, wie in:

WHERE TimeStamp between '2010-03-22 23:30' and '2010-03-23 11:15' 

Was bei der Verwendung von Dimensionsfeldern unangenehm wird.

Normalerweise hat die Zeitdimension eine winzige Auflösung, also 1440 Zeilen.

Answer 2

Kimball empfiehlt, separate Zeit- und Datumsabmessungen zu haben:

Design-TIP-51-LATEST-DENINGING-ON-TEMENTION-TABELLEN

In früheren Toolkit -Büchern haben wir empfohlen, eine solche Dimension mit der Minuten oder Sekundenkomponente der Zeit als Offset ab Mitternacht eines jeden Tages zu erstellen, aber wir haben festgestellt Zeitspanne. Im Gegensatz zur Kalendertagsdimension gibt es innerhalb eines Tages nur sehr wenige beschreibende Attribute für die spezifische oder zweite Sekunde. Wenn das Enterprise innerhalb eines Tages gut definierte Attribute für Zeitscheiben hat, z. B. Schichtnamen oder Werbezeitschlitzen Sogar Sekunden) nach Mitternacht. Daher hätte diese Zeitabmessung entweder 1440 Rekorde, wenn das Getreide Minuten oder 86.400 Rekorde wären, wenn das Getreide Sekunden lang wäre.

Answer 3

Die Zeit sollte eine Dimension für Data Warehouses sein, da Sie häufig darüber aggregieren möchten. Sie könnten die verwenden Schneeflockenschema Um den Overhead zu reduzieren. Wie ich in meinem Kommentar betonte, scheinen Stunden im Allgemeinen eine ungewöhnlich hohe Auflösung zu sein. Wenn Sie darauf bestehen, kann die Stunde des Tages eine separate Dimension hilfreich sein, aber ich kann Ihnen nicht sagen, ob dies ein gutes Design ist.

Answer 4

Ich würde empfehlen, eine separate Dimension für Datum und Uhrzeit zu haben. Die Datumsdimension hätte 1 Datensatz für jeden Datum als Teil des identifizierten gültigen Datenbereichs. Zum Beispiel: 01.01.1980 bis 03.12.2025.

Und eine separate Dimension für die Zeit mit 86400 Datensätzen, wobei jede Sekunde einen Datensatz mit dem Zeitschlüssel identifiziert hat.

In den Tatsachenaufzeichnungen, bei denen Sie Datum und Uhrzeit benötigen, fügen Sie beide Schlüsseln mit Verweise auf diese entsprechenden Dimensionen hinzu.