Veri Ambarı Tasarımı: Birleşik Tarih ve Boyut ile Ayrı Gün ve Saat boyutları ve zaman dilimleri karşılaştırması

Yeni bir veri ambarı için tasarıma yeni başlıyoruz ve tarih ve saat boyutlarımızın nasıl çalışacağını tasarlamaya çalışıyoruz. Birden fazla zaman dilimini (muhtemelen en azından GMT, IST, PST ve EST) destekleyebilmemiz gerekir. Başlangıçta, 15 dakikalık ayrıntı düzeyine kadar geniş bir birleşik tarih saat boyutuna sahip olacağımızı düşünüyorduk. (örn. Tarih Anahtarı, GMT Tarihi, GMT Saati, IST Tarihi, IST Saati, vb ...)

Kimball, tablonun çok büyük büyümesini (veri ambarı araç takımı s. 240) önlemek için gün zaman boyutundan ayrı bir gün boyutuna sahip olmayı önerir, ancak bu kulağa hoş geliyor, ancak her bir zaman dilimi için olgu tablolarımızda iki anahtarımız olduğu anlamına gelir. desteklememiz gerekiyor (biri tarih için, diğeri günün saati için).

Bu alanda çok tecrübesiz olduğumdan, birinin iki yaklaşım arasındaki dengeyi, yani performansa karşı tüm farklı zaman dilimi anahtarlarının yönetimini bildiğini umuyorum. Belki başka yaklaşımlar da var, bazı insanların saat dilimi başına olgu tablosunda ayrı bir satırdan bahsettiğini gördüm, ancak eğer gerçek tablolar milyonlarca satırsa bu bir sorun gibi görünüyor, o zaman zaman dilimleri eklemek için dört katına çıkarmanız gerekiyor .

15 dakikalık bir tane yaparsak, tarih saat boyut tablonuzda yılda 131.400 (24 * 15 * 365) satırımız olacak, bu da performans için çok korkunç görünmüyor, ancak bazılarını test edene kadar kesin olarak bilemeyiz prototip sorguları. Olgu tablosunda ayrı saat dilimi anahtarlarına sahip olmanın diğer kaygısı, sorgunun istenen zaman dilimine göre farklı bir sütuna boyut tablosuna katılması gerektiğidir, belki de bu SSAS'ın sizin için hallettiği bir şeydir, emin değilim .

herhangi bir düşünce için teşekkürler, -Matt

Tarih ve saatin ayrı olması, zaman içinde toplu işlemleri kolayca yapmanızı sağlar. örneğin: günün hangi saat diliminde en meşgul olduğunu bulmak için bir sorgu çalıştırmak istiyorsanız. Bu, ayrı bir zaman boyutu kullanılarak çok kolay bir şekilde gerçekleştirilir.

Ayrıca, sadece bir saatiniz olmalıdır. GMT / EST zamanına karar verin - sonra bunu olgu tablosunda kullanın. Raporları diğer saat dilimine göre çalıştırmanız gerekiyorsa, bunu uygulamanızda veya sorgunuzda dönüştürmeniz yeterlidir.

Birden fazla Zaman Dilimini desteklemek ve mümkün olduğunca verimli olmak için DataWarehouse'umuzu nasıl uygulamaya karar verdiğimize ilişkin bir takip: Zaman dilimlerinin bir tablosunu (id, ad vb.) Ve "Zaman Dilimi" ni oluşturmayı seçtik köprü "tablosu şöyle görünür:

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

Bu şekilde normal tarih ve saat boyut tablolarımızı küçük tutabiliriz, tüm gerçeklerimiz UTC tarih / saat anahtarlarına bağlanır, o zaman farklı bir saat dilimine göre raporlamamız / gruplamamız gerekirse, sadece saat dilimi köprü tablosuna katılmamız gerekir ve yerel tarih / saat tuşlarını tarih ve saat boyut tablolarına geri bağlayın. Doğrudan SqlServer'dan TZ şeyler yapmaktan çok daha az karmaşık olduğundan, saat dilimi köprü tabloyu SSIS'den çağrılan C # kodunu kullanarak dolduruyoruz.

Kombine bir DateTimeboyut kullanan bir depo fikrinin reddedildiğini gördüm, ancak bunun nedeninin çok açık bir nedenini görmedim. Biraz basitleştirmek gerekirse, şu anda oluşturduğum bilgi tablosu:

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
)

DateTimeAlanlar DateTime masaya katılmak:

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)),
...
)

Bu yarım saatlik bir çözünürlüktedir, bu nedenle günde 48 kayıt, 20 yılda 350.400 - oldukça yönetilebilir.

Etkinlik tarihi / saatleri saklandığında UTC'ye çevrilir, ancak LocalTimeZoneSKalan ve köprü tablosu ile yerel saati almak için kolayca katılabiliriz:

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

Bugün oluşturulan işlemleri almak için UTC saati:

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

Bugün, işlem için yerel saatle oluşturulan işlemleri almak için:

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'

TimeZoneSKBir REALofset ile değiştirerek işleri basitleştirmek cazip gelebilir (örneğin, ABD Merkezi Yaz Saati için -5.0), ancak bir gerçek kaydı için bazı tarih / saatler Yaz Saati Uygulamasındaysa ve bazıları değilse bu durum bozulacaktır.

Bir olgu kaydı olayları, bir gönderi veya uçuş gibi farklı saat dilimlerinde gerçekleşebilirse, her tarih için bir saat dilimi alanına ihtiyacınız vardır ve tarih başına beş bayta kadarsınız demektir.