Проект хранилища данных: объединенное измерение даты и времени в сравнении с отдельными измерениями и часовыми поясами дня и времени

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

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

Поскольку я очень неопытен в этой области, я надеюсь, что кто-то там знает компромиссы между двумя подходами, то есть производительность и управление всеми различными ключами часового пояса. Возможно, есть и другие подходы, я видел, как некоторые люди говорили о наличии отдельной строки в таблице фактов для часового пояса, но это кажется проблемой, если ваши таблицы фактов состоят из миллионов строк, то вам нужно увеличить их в четыре раза, чтобы добавить часовые пояса. ,

Если мы сделаем 15-минутное зерно, у нас будет 131 400 (24 * 15 * 365) строк в год в нашей таблице измерений даты и времени, которая не звучит слишком ужасно для производительности, но мы не будем знать наверняка, пока мы не протестируем некоторые прототип запросов. Другая проблема, связанная с наличием отдельных ключей часовых поясов в таблице фактов, заключается в том, что запрос должен присоединить таблицу измерений к другому столбцу на основе желаемого часового пояса, возможно, это то, что SSAS позаботится о вас, я не уверен ,

спасибо за любые мысли, -Matt

Разделяя дату и время, вы сможете легко составлять статистику по времени. например: если вы хотите выполнить запрос, чтобы определить, какой период времени наиболее занят. Это очень легко сделать, используя отдельное измерение времени.

Кроме того, у вас должен быть только один ключ времени. Выберите время по Гринвичу / Восточному поясному времени - затем используйте это в таблице фактов. Если вам нужно запускать отчеты, основанные на другом часовом поясе, просто преобразуйте их в свое приложение или запрос.

Просто следите за тем, как мы решили реализовать наш 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 для США Центральной поясному времени), но это будет разрушаться , если некоторые даты / времени для записи фактов в летнее время , а некоторые нет.

Если события для записи факта могут происходить в разных часовых поясах, например, при отправке или полете, вам нужно поле часового пояса для каждой даты, и вы получите до пяти байт на дату.