Veri martında / depoda saat dilimlerini işleme

Bir veri martının / deposunun yapı taşlarını tasarlamaya başlıyoruz ve tüm zaman dilimlerini destekleyebilmemiz gerekiyor (müşterilerimiz dünyanın her yerinden). Çevrimiçi (ve kitaplarda) tartışma okumaktan, ortak bir çözüm, ayrı bir tarih ve saat boyutunun yanı sıra olgu tablolarında bir zaman damgasına sahip olmak gibi görünüyor.

Ancak, yanıtlamakta zorlandığım soru, tarih ve saat boyutlarının dinamik saat dilimi gereksinimlerimi göz önünde bulundurarak benim için gerçekten ne işe yaradığıdır? Bir zaman boyutu biraz daha mantıklı ama tarih boyutuyla zor zamanlar geçiriyorum. Bir tarih boyutu için genel bir tasarım yaklaşımı genellikle gün adı, haftanın günü, ay adı vb. Özellikleri içerir. 31 Aralık 2013 Salı günü UTC'de Çarşamba günü saat 11:00 , 1 Ocak 2014 UTC + 2'den sonraki tüm saat dilimlerinde.

Yani her sorgu (ve rapor) tüm bu zaman dilimi dönüşümleri yapmak zorunda kalacak, o zaman sahip ve muhtemelen asla kullanmayacağım (bu gibi) bu özellikleri depolamak ne anlamı var? Bazı insanlar her saat dilimi için gerçek satırları olmasını önerir, ancak bu bana saçma geliyor. Her ay milyonlarca kayıt depolayabilmemiz gerekir.

Diğerleri, bir şey yapmakla birlikte, müşteri uygulamalarımın ve raporlarımın bir tarihten kolayca anlayabilmesi gereken bir şeyi başarmak için ekstra karmaşıklık ve ekstra eklemeler gibi görünüyor (raporlama öncelikle web tabanlı olacak) tarihlerin dönüştürülmesinde, görüntülenmesinde ve biçimlendirilmesinde yardımcı olacak sayısız kütüphane vardır).

Düşünebildiğim tek şey, tarih ve saate göre gruplamanın kolaylığı ve muhtemelen performansı, ancak bir uygulamanın datepart'a göre gruplandırmanın ne kadar kötü olduğudur (MS SQL kullanıyoruz, ancak milyonlarca satırı sorgulayacağız) veya düşünmeliyiz sadece saat, gün, ay ve yıl sayısından fazla olmayan son derece basit tarih ve saat boyutları, Pazartesi gibi çoğu değişmez zaman dilimleri devreye girdiğinde fazla bir şey ifade etmez mi?

Birinci olarak...

Datime/TimeBir Dateboyuta ve bir Timeboyuta ayırmak kesinlikle gidilecek yoldur.

Birden çok saat dilimini yönetmek için DateKeyve öğelerini çoğaltmanız gerekir , TimeKeyböylece aşağıdakiler elde edilir:

• LocalDateKey
• LocalTimeKey
• UtcDateKey
• UtcTimeKey

Diyorsun...

Tüm bu sorun yaşıyorum, UTC 31 Aralık 2013 Salı 23:00 2013 UTC + 2 sonrası tüm zaman dilimleri 1 Ocak 2014 Çarşamba olduğunu.

Yukarıda listelediğim 4 sütuna sahip olarak, olgu tablosunu Tablo Takma Adlarını Kullanarak Tarih ve / veya Saat boyutuna katılabileceksiniz (Kimball terminolojisinde bu takma boyut tabloları "Rol Oynatma Boyutları" olarak bilinir), aşağıdaki gibi bir şey olurdu:

/*
    Assumes the following:
        - [DateLongName] has the format of this example "Tuesday, December 31, 2013"
        - [TimeShortName] has the format of this example "11:00 PM"
        - Both [DateLongName] & [TimeShortName] are strings
*/
select
    -- Returns a string matching this example  "11:00 PM Tuesday, December 31, 2013"
    localTime.TimeShortName + ' ' + localDate.DateLongName
    ,utcTime.TimeShortName + ' ' + utcDate.DateLongName
    ,f.*
from
    FactTableName  AS f

    -- Local Date and Local Time joins          
    inner join dbo.Date  AS localDate
        on localDate.DateKey = f.LocalDateKey

    inner join dbo.Time  AS localTime
        on localTime.TimeKey = f.LocalTimeKey 

    -- Utc Date and Utc Time joins    
    inner join dbo.Date  AS utcDate
        on utcDate.DateKey = f.UtcDateKey

    inner join dbo.Time  AS utcTime
        on utcTime.TimeKey = f.UtcTimeKey 

Kapanışta ...

Eğer bir OLTP veritabanı bir veri ambarı oluşturma ve değiliz gibi, yerel ve Utc kez nesil sizin ETL yapılmalıdır , DEĞİL ayrı üzere UTC saat yerelleflmesinden (aşağıdaki nedenlerle herhangi bir istemci tarafı uygulamalarında rapor okuyucunun bakış açısı):

• Hesaplamanın herhangi bir sorguda bulunması, üzerlerine ekstra bir performans yükü getirir ve sahip olduğunuz raporlar için söz konusu sorguyu kaç kez çalıştırmanız gerektiğiyle çarpılır (milyonlarca satırı okurken önemlidir)
• Her sorguda (özellikle gün ışığından yararlanma zamanını dikkate aldığınızda) hesaplamanın doğru bir şekilde sürdürülmesini sağlamanın ek yükü
• Sütunda, sorguları aramalar yerine dizin taramaları yapmaya zorlayan bir hesaplama yapacağınız için (her veri sayfasının okunması gerektiğinden genellikle daha pahalıdır), sütunun bir parçası olduğu dizinlerin aralık taramasını önleyin; Bu olarak bilinen non- sargable .
  • Yorumlar nedeniyle düzenle: Bu, dönüşümü gerçek sorguya indirdiğinizde geçerlidir .
• Ek UTC tarih ve saatlerine sahip olma kavramını kullanarak, bu kavramı almanızı ve bunu çağırarak genişletmenizi engelleyen hiçbir şey yoktur StandardisedDateKeyveya CorporateHQDateKeybir UTC tarih tablosu yerine, anlaşmaya varılan diğer bazı standartlara göre standartlaştırırsınız.
• İki ayrı sütun türüne (Yerel ve UTC) sahip olmak, coğrafi mesafe boyunca yan yana karşılaştırmaya olanak tanır. Düşün -> Avustralya'daki biri hem Yerel hem de UTC ile zaman damgalı bir kayda girer, New York'taki biri Yerel (Avustralya) tarih ve saati ve UTC tarih ve saatinin New York temsiliyle raporu okur , böylece bir şeyin Avustralyalı mevkidaşları gün ortasında yaptılar (Avustralya saati) gecenin ortasında (New York saati) oldu. Zamanın bu karşılaştırması çok uluslu işletmelerde vazgeçilmezdir.

Bu cevabın kısalığı için şimdiden özür dilerim ve iş başında olmadığımda ayrıntılandırmayı planlıyorum.

Verilerinizin kolayca toplanmasına izin verdikleri için tarih ve saat tablolarına sahip olmanın kesinlikle avantajları vardır. Çoğu durumda, bu doğadaki şeyleri ay veya iş günlerine göre sıralamanın en basit yolu. Ancak bu, zaman damgasının kullanışlılığının yerini almaz. Sizin durumunuzda bir UTC zaman damgası. Bu zaman damgasına sahip olduğunuzda, tek yapmanız gereken bunu rapor veya sunum katmanındaki yerel saate dönüştürmektir. Aralık taramalarını önlemek için, istek aralığınızı UTC saatine de dönüştürdüğünüzden emin olun.

Başka sorularınız veya yorumlarınız varsa çekinmeyin.