Материал опубликован с разрешения компании
Автор оригинала: Ральф Кимбал (все
статьи)ы
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается .
Наиболее частый вопрос, который мне задают в аудитории или по электронной
почте, это вопрос о том, как обрабатывать множественные временные
отметки в таблице фактов. Несмотря на то что правильный и немедленный
ответ звучит как "сделайте каждую временную отметку
измерением Время", стоит внимательно описать этот подход, поскольку
он хорошо иллюстрирует целый набор современных приёмов проектирования
хранилищ данных, которые я выделю БОЛЬШИМИ БУКВАМИ.
Во-первых, выберите БАЗОВУЮ СТЕПЕНЬ ДЕТАЛИЗАЦИИ вашей таблицы фактов.
Любая таблица фактов, которую я когда-либо проектировал, была либо
на уровне транзакции (transaction grain), периодического снимка
(periodic snapshot grain) или аккумулирующего снимка (accumulating
snapshot grain). В вы сможете познакомиться с другими базовыми степенями
детализации. Когда вы поймёте базовую степень детализации, вы сможете
оценить, каков смысл и уместность множественных временных
отметок по отношению к этой степени детализации. Множественные временные
отметки наиболее часто встречаются на уровне аккумулирующего снимка
данных, когда запись в таблице фактов описывает, например, полную
историю строки заказа. Множественные временные отметки могут представлять
1. Оригинальную дату размещения заказа
2. Желаемую дату доставки товара
3. Реальную дату отгрузки
4. Реальную дату доставки
5. Дату возврата
Во-вторых, для приведённого выше примера со строкой заказа создайте
пять РОЛЕЙ для одного измерения Время. Ознакомьтесь со статьёй по
адресу ,
в которой обсуждаются роли. Это означает пять полей в таблице фактов,
каждое из которых является хорошим внешним ключом, связанным с измерением.
Единое измерение Время "предоставляется" таблице фактов
через пять представлений, которые семантически изолируют каждый
экземпляр измерения Время друг от друга, так как они должны быть
изолированы.
В-третьих, убедитесь в том, что внешние ключи в таблице фактов
представляют собой правильные СУРРОГАТНЫЕ КЛЮЧИ. Другими словами,
они должны иметь не тип даты/времени SQL, а быть бессмысленными
целыми числами. Сопротивляйтесь любому искушению вложить какой-либо
смысл или порядок сортировки в эти ключи! Для более близкого знакомства
с проблемой суррогатных ключей ознакомьтесь со статьями "Суррогатные
ключи. Контролируйте идентификаторы строк формированием суррогатных
ключей в хранилищах данных" и "Суррогатные
ключи. Конвейерная обработка суррогатных ключей". Если
вы внимательно присмотритесь к нашему примеру со строкой заказа,
то вы согласитесь с тем, что некоторые из временных отметок
должны иметь значения "неизвестно" или "событие ещё
не произошло". Это одна из классических причин использования
суррогатных ключей.
Если ваши временные отметки имеют точность на уровне минут
или секунд, то вы должны отделить календарный день от времени суток
и разнести их по разным измерениям. Мы обсудим варианты проектирования
подобных временных отметок в будущих выпусках советов разработчику.
Если вы нашли в сети интересные ссылки на ресурсы
по технологиям хранилищ данных, OLAP, CRM или data mining, и хотите
поделиться ими с другими, присылайте
их. Я с удовольствием размещу их на этом сайте.
RSS