Наиболее частый вопрос, который мне задают в аудитории или по электронной почте, это вопрос о том, как обрабатывать множественные временные отметки (timestamp) в таблице фактов. Несмотря на то что правильный и немедленный ответ звучит как “сделайте каждую временную отметку измерением Время”, стоит внимательно описать этот подход, поскольку он хорошо иллюстрирует целый набор современных приёмов проектирования хранилищ данных (DWH), которые я выделю БОЛЬШИМИ БУКВАМИ.

Во-первых, выберите БАЗОВУЮ СТЕПЕНЬ ДЕТАЛИЗАЦИИ вашей таблицы фактов. Любая таблица фактов, которую я когда-либо проектировал, была либо на уровне транзакции (transaction grain), периодического снимка (periodic snapshot grain) или аккумулирующего снимка (accumulating snapshot grain). В этой статье вы сможете познакомиться с другими базовыми степенями детализации. Когда вы поймёте базовую степень детализации, вы сможете оценить, каков смысл и уместность множественных временных отметок по отношению к этой степени детализации. Множественные временные отметки наиболее часто встречаются на уровне аккумулирующего снимка данных, когда запись в таблице фактов описывает, например, полную историю строки заказа. Множественные временные отметки могут представлять:

  1. Оригинальную дату размещения заказа
  2. Желаемую дату доставки товара
  3. Реальную дату отгрузки
  4. Реальную дату доставки
  5. Дату возврата

Во-вторых, для приведённого выше примера со строкой заказа создайте пять РОЛЕЙ для одного измерения Время. Ознакомьтесь со статьёй, в которой обсуждаются роли. Это означает пять полей в таблице фактов, каждое из которых является хорошим внешним ключом (foreign key), связанным с измерением. Единое измерение Время “предоставляется” таблице фактов через пять представлений (view), которые семантически изолируют каждый экземпляр измерения Время друг от друга, так как они должны быть изолированы.

В-третьих, убедитесь в том, что внешние ключи в таблице фактов представляют собой правильные СУРРОГАТНЫЕ КЛЮЧИ (surrogate key). Другими словами, они должны иметь не тип даты/времени SQL, а быть бессмысленными целыми числами. Сопротивляйтесь любому искушению вложить какой-либо смысл или порядок сортировки в эти ключи! Для более близкого знакомства с проблемой суррогатных ключей ознакомьтесь со статьями “Суррогатные ключи. Контролируйте идентификаторы строк формированием суррогатных ключей в хранилищах данных” и “Суррогатные ключи. Конвейерная обработка суррогатных ключей“. Если вы внимательно присмотритесь к нашему примеру со строкой заказа, то вы согласитесь с тем, что некоторые из временных отметок должны иметь значения “неизвестно” или “событие ещё не произошло”. Это одна из классических причин использования суррогатных ключей.

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

Материал опубликован с разрешения компании Ralph Kimball Associates
Автор оригинала: Ральф Кимбалл (Kimball)
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также: