Desain Datawarehouse: Gabungan dimensi Waktu Tanggal vs. Dimensi dan zona waktu Hari dan Waktu terpisah

Kami baru memulai desain untuk gudang data baru dan kami mencoba merancang bagaimana dimensi tanggal dan waktu kami akan bekerja. Kami harus dapat mendukung beberapa zona waktu (mungkin setidaknya GMT, IST, PST, dan EST). Kami awalnya berpikir bahwa kami akan memiliki satu dimensi waktu tanggal gabungan yang luas hingga mungkin 15 menit, dengan begitu kami memiliki satu kunci dalam tabel fakta kami dan semua data waktu tanggal yang berbeda untuk semua zona waktu yang didukung berada dalam tabel satu dimensi. (yaitu Kunci Tanggal, Tanggal GMT, Waktu GMT, Tanggal IST, Waktu IST, dll ...)

Kimball menyarankan untuk memiliki dimensi hari yang terpisah dari dimensi hari untuk mencegah tabel tumbuh terlalu besar (Toolkit data warehouse hal. 240) yang kedengarannya baik namun itu berarti kita memiliki dua kunci dalam tabel fakta untuk setiap zona waktu kita perlu mendukung (satu untuk tanggal dan satu untuk waktu hari).

Karena saya sangat tidak berpengalaman dalam bidang ini, saya berharap seseorang di luar sana tahu pertukaran antara kedua pendekatan, yaitu kinerja vs. pengelolaan semua kunci zona waktu yang berbeda. Mungkin ada pendekatan lain juga, saya telah melihat beberapa orang berbicara tentang memiliki baris terpisah di tabel fakta per zona waktu, tapi itu sepertinya masalah jika tabel fakta Anda adalah jutaan baris maka Anda perlu melipatgandakannya untuk menambah zona waktu .

Jika kita melakukan butiran 15 menit, kita akan memiliki baris 131.400 (24 * 15 * 365) per tahun dalam tabel dimensi waktu tanggal kita yang kedengarannya tidak terlalu mengerikan untuk kinerja tetapi kita tidak akan tahu pasti sampai kita menguji beberapa pertanyaan prototipe. Kekhawatiran lain dengan memiliki kunci zona waktu yang terpisah di tabel fakta adalah bahwa kueri harus bergabung dengan tabel dimensi ke kolom berbeda berdasarkan zona waktu yang diinginkan, mungkin ini adalah sesuatu yang SSAS urus untuk Anda, saya tidak yakin .

terima kasih atas pemikiran, -Matt

Dengan memisahkan tanggal dan waktu, Anda dapat melakukan agregat berdasarkan waktu dengan lebih mudah. untuk eg: jika Anda ingin menjalankan kueri untuk menemukan periode waktu apa yang paling sibuk. Ini lebih mudah dilakukan menggunakan dimensi waktu yang terpisah.

Juga, Anda hanya perlu memiliki satu timekey. Tentukan waktu GMT / EST - lalu gunakan ini di tabel fakta. Jika Anda perlu menjalankan laporan berdasarkan zona waktu lain, cukup konversikan dalam aplikasi atau kueri Anda.

Hanya tindak lanjut tentang bagaimana kami memutuskan untuk mengimplementasikan DataWarehouse kami untuk mendukung beberapa Zona Waktu dan menjadi seefisien mungkin: Kami memilih untuk membuat tabel zona waktu (id, nama, dll ...) serta "Zona Waktu" tabel "jembatan yang terlihat seperti ini:

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

Dengan cara ini kita dapat menjaga tabel dimensi tanggal dan waktu normal kita kecil, semua fakta kita terhubung ke kunci tanggal / waktu UTC, maka jika kita perlu melaporkan / mengelompokkan berdasarkan zona waktu yang berbeda kita hanya perlu bergabung melalui tabel jembatan zona waktu dan tautkan kunci tanggal / waktu lokal kembali ke tabel dimensi tanggal dan waktu. Kami mengisi tabel jembatan zona waktu kami menggunakan kode C # yang dipanggil dari SSIS karena ini jauh lebih mudah daripada melakukan hal-hal TZ dari SqlServer secara langsung.

Saya telah melihat gagasan tentang gudang menggunakan DateTimedimensi gabungan ditolak, tetapi saya belum melihat alasan yang sangat jelas mengapa. Sederhananya sedikit, inilah tabel fakta yang saya bangun sekarang:

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
)

DateTimeBidang - bidang bergabung dengan tabel DateTime:

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

Ini adalah resolusi setengah jam, jadi ada 48 catatan per hari, 350.400 dalam 20 tahun - cukup mudah dikelola.

Tanggal / waktu acara diterjemahkan ke UTC saat disimpan, tetapi dengan LocalTimeZoneSKbidang dan tabel jembatan kita dapat dengan mudah bergabung untuk mendapatkan waktu setempat:

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

Untuk mendapatkan transaksi yang dibuat hari ini, waktu UTC:

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

Untuk mendapatkan transaksi yang dibuat hari ini, pada waktu setempat untuk transaksi:

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'

Anda mungkin tergoda untuk menyederhanakan hal-hal dengan mengganti TimeZoneSKdengan REALoffset (mis., -5,0 untuk Waktu Siang Tengah AS), tetapi ini akan rusak jika beberapa tanggal / waktu untuk catatan fakta dalam Waktu Hemat Siang hari dan ada yang tidak.

Jika peristiwa untuk catatan fakta dapat terjadi di zona waktu yang berbeda, seperti pengiriman atau penerbangan, maka Anda memerlukan bidang zona waktu untuk setiap tanggal, dan Anda hingga lima byte per tanggal.