Совет №51
Последние размышления о таблицах измерения Время
Материал опубликован с разрешения компании
Автор оригинала: Ральф Кимбал (все
статьи)
Перевод на русский язык: Антон Задорожный
Оригинальный документ располагается здесь.
Практически каждая таблица фактов имеет один или более внешних
ключей, связанных с измерением Время. Показатели определены в точные
моменты времени и большинство показателей со временем повторяются.
Наиболее общим и полезным измерением Время является календарь с
уровнем гранулярности в один день. Это измерение имеет удивительно
много атрибутов. Только некоторые из этих атрибутов (такие как имя
месяца и год) могут быть получены непосредственно из SQL-выражения
типа date-time. Праздники, рабочие дни, фискальные периоды, номера
недель, индикатор последнего дня месяца и другие навигационные атрибуты
должны быть встроены в календарное измерение и вся навигация по
датам должна быть реализована в приложениях при помощи атрибутов
измерения. Календарное измерение имеет несколько весьма необычных
свойств. Это – одно из немногих измерений, которое полностью определено
в начале проекта по хранилищу данных. У него также нет источника
в общепринятом смысле. Лучший способ создать календарное измерение
– это потратить полдня с электронной таблицей и построить его вручную.
Десять лет по дням это меньше 4000 строк.
Каждое календарное измерение нуждается в атрибуте типа Дата и в
атрибуте Полная Дата. Эти два поля составляют естественный ключ
таблицы измерения. Атрибут типа Дата почти всегда имеет значение
«дата», но также должна существовать, по крайней мере, одна запись,
отражающая специальную ситуацию, когда дата неприменима, испорчена
или пока не введена. Этот внешний ключ, ссылающийся на таблицу фактов,
в этих случаях должен указывать на значение «не дата» в календарной
таблице дат! Вам требуется, по крайней мере, одна такая специальная
запись, но вы можете счесть нужным разделить несколько таких необычных
ситуаций. Для неприменимой даты Тип Дата принимает значение «неприменимо»
или «NA». Атрибут Полная Дата является полным реляционным значением
даты и принимает пустое значение в специальных случаях описанных
выше. Помните, что внешний ключ в таблице фактов не может быть пустым,
так как это нарушает требование ссылочной целостности.
В идеальном случае, первичный ключ календарной даты должен быть
бессмысленным суррогатным ключом, но многие команды разработчиков
ETL не могут противостоять желанию сделать этот ключ читаемой последовательностью,
как например 20040718 будет значить 18 июля 2007-го года. Как бы
то ни было, как с любым интеллектуальным ключом, несколько специальных
записей заставит разработчика совершать трюки. Например, интеллектуальный
ключ для несуществующей даты может быть каким-нибудь бессмысленным
значением вроде 99999999, и приложения, что пытаются интерпретировать
значение ключа напрямую, без использования таблицы измерения, должны
всегда тестироваться с этим значением, так как оно не является действительной
датой.
В некоторых таблицах фактов время фиксируется на уровне детальнее
календарной даты, вплоть до минут или даже секунд. Не всегда построить
измерение время с каждой минутой и секундой каждого представленного
дня. В году более 31 миллиона секунд! Мы хотим сохранить мощное
календарное измерение и одновременно поддерживать точечные запросы
к минутам или секундам. Мы можем также пожелать рассчитывать очень
точные интервалы путем сравнения точного времени в двух записях
таблицы фактов. По этим причинам мы рекомендуем добавить в таблицу
фактов как внешний ключ календарного измерения, так и полную даты
и время в формате SQL timestamp. Компонент точного времени «день»
остается как внешний ключ – ссылка на наше знакомое календарное
измерение. Мы также встроили полную дату и время SQL timestamp непосредственно
в таблицу фактов для всех запросов, требующих большой точности.
Смотрите на это как на особый вид факта, не измерение. В таком интересном
случае бесполезно создавать измерение с компонентами в виде минут
или секунд точной временной отметки, так как при использовании отдельных
измерений «день» и «время дня» расчет временных интервалов по записям
таблиц фактов становится слишком беспорядочным. В предыдущих книгах
мы рекомендовали создавать такое измерение с минутами или секундами
в виде смещения от полуночи каждого дня, но теперь нам стало понятно,
что получающиеся приложения становятся слишком сложными, особенно
при попытке рассчитать промежутки времени. Также, в отличие от календарного
измерения, получается некоторое количество описательных атрибутов
для определенной минуты или секунды внутри дня.
Если на предприятии существуют хорошо определенные атрибуты для
интервалов внутри дня, например, смены или рекламные паузы, в схему
может быть добавлено дополнительное измерение «время дня», определенное
как минуты (или даже секунды) прошедшие с полуночи. Таким образом,
это измерение может иметь или 1440 записей для минут или 86400 записей
для секунд. Наличие такого измерения «время дня» не отменяет необходимость
в точной дате и времени SQL timestamp, описанной выше.
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS