Дизайн сховища даних: комбінований розмір дати та порівняно з окремими розмірами дня та часу та часові пояси

Ми тільки починаємо розробку нового сховища даних і намагаємось розробити, як працюватимуть наші параметри дати та часу. Нам потрібно мати можливість підтримувати декілька часових поясів (можливо, принаймні GMT, IST, PST та EST). Ми спочатку думали, що у нас буде один широкий комбінований часовий вимір до, можливо, 15-ти хвилинної деталізації, таким чином, у нас є один ключ у наших таблицях фактів, а всі різні часові дані дати для всіх підтримуваних часових поясів знаходяться в одній таблиці вимірів. (тобто ключ дати, дата GMT, час GMT, дата IST, час IST тощо)

Kimball пропонує мати окремий розмір дня від розміру часу, щоб запобігти зростанню таблиці занадто великим (набір інструментів сховища даних стор. 240), але це чудово звучить, але це означає, що у наших таблицях фактів для кожного часового поясу є дві клавіші нам потрібно підтримати (один на дату і один на час доби).

Оскільки я дуже недосвідчений в цій галузі, я сподіваюся, що хтось там знає компроміси між двома підходами, тобто ефективність та управління всіма ключами часового поясу. Можливо, є й інші підходи. Я бачив, як деякі люди говорять про наявність окремого рядка в таблиці фактів за часовим поясом, але це здається проблемою, якщо фактичні таблиці - це мільйони рядків, то вам потрібно в чотири рази їх додати часові пояси. .

Якщо ми зробимо 15-хвилинне зерно, у нашій таблиці виміру часу на дату буде 131,400 (24 * 15 * 365) рядків на рік, що не звучить занадто жахливо для продуктивності, але ми не будемо точно знати, поки не перевіримо деякі запити прототипу. Інша проблема, пов'язана з наявністю окремих таблиць часового поясу в таблиці фактів, полягає в тому, що запит повинен приєднати таблицю вимірів до іншого стовпця на основі потрібного часового поясу. Можливо, це те, про що піклується SSAS, я не впевнений .

дякую за будь-які думки, -Мат

Якщо розділити дату та час, ви зможете робити агрегати за часом набагато легше. наприклад: якщо ви хочете запустити запит, щоб визначити, який часовий період дня найбільш зайнятий. Це набагато легко виконати, використовуючи окремий часовий вимір.

Крім того, ви повинні мати лише один тайм-ключ. Вирішіть чи GMT / EST час - тоді використовуйте це у таблиці фактів. Якщо вам потрібно запускати звіти за іншим часовим поясом, просто перетворіть їх у свою програму чи запит.

Лише далі про те, як ми вирішили впровадити наш DataWarehouse для підтримки декількох часових зон та бути максимально ефективними: ми вирішили створити таблицю часових поясів (ідентифікатор, ім’я тощо), а також "часову зону. таблиця міст ", яка виглядає приблизно так:

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

Таким чином ми можемо зберегти наші нормальні таблиці розмірів дати та часу невеликими, всі наші факти посилаються на клавіші дати / часу UTC, тоді, якщо нам потрібно повідомити / групувати за іншим часовим поясом, нам просто потрібно приєднатися через таблицю мосту часового поясу і зв’язати локальні клавіші дати / часу назад до таблиць виміру дати та часу. Ми заповнюємо таблицю мосту часового поясу за допомогою коду C #, викликаного від SSIS, оскільки це було набагато складніше, ніж робити TZ речі безпосередньо з SqlServer.

Я бачив, що ідея складу з комбінованим DateTimeрозміром відхилена, але я не бачив дійсно зрозумілої причини. Трохи спрощуючи, ось таблиця фактів, яку я зараз будую:

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
)

В DateTimeполе приєднатися до таблиці 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)),
...
)

Це з роздільною здатністю півгодини, тому в день є 48 записів, 350 400 за 20 років - цілком керовані.

Дата / час події перекладається на UTC, коли вони зберігаються, але за допомогою LocalTimeZoneSKполя та таблиці містків ми можемо легко приєднатися до місцевого часу:

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

Щоб отримати транзакції, створені сьогодні, час UTC:

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

Щоб отримати транзакції, створені сьогодні, у місцевий час для проведення транзакції:

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'

Ви можете захотіти , щоб спростити речі, замінивши TimeZoneSKз REALзміщенням (наприклад, -5,0 для США Центральної поясним часом), але це буде руйнуватися , якщо деякі дати / часу для запису фактів в літню пору , а деякі ні.

Якщо події для запису фактів можуть відбуватися в різних часових поясах, наприклад, відправлення або рейс, тоді вам потрібно поле часового поясу для кожної дати, і ви маєте до п'яти байтів на дату.