Измерение времени и даты в хранилище данных - PullRequest
14 голосов
/ 24 марта 2010

Я строю хранилище данных. У каждого факта есть timestamp. Мне нужно создавать отчеты по дням, месяцам, кварталам, но и по часам. Глядя на примеры, я вижу, что даты обычно сохраняются в таблицах измерений. alt starexample http://etl -tools.info / images / dw_star_schema.jpg

Но я думаю, что это бессмысленно для времени. Таблица измерений будет расти и расти. С другой стороны, JOIN с таблицей измерения даты более эффективен, чем использование функций даты / времени в SQL.

Каково ваше мнение / решения?

(я использую Infobright)

Ответы [ 4 ]

30 голосов
/ 24 марта 2010

Кимбалл рекомендует иметь отдельные измерения времени и даты:

дизайн-наконечник-51-новейшего мышления-на-времени размерности столы

В предыдущих книгах по набору инструментов мы Рекомендуется строить такое измерение с компонентом минут или секунд времени как смещение от полуночи каждый день, но мы пришли к пониманию что полученный конечный пользователь приложения стали слишком сложными, особенно при попытке вычислить время охватывает. Кроме того, в отличие от календарного дня измерение, очень мало описательные атрибуты для конкретная минута или секунда в течение день. Если предприятие хорошо определенные атрибуты для временных интервалов в течение дня, например смены имен или рекламные слоты, дополнительный измерение времени суток может быть добавлено к дизайн, где это измерение определяется как количество минут (или четные секунды) за полночь. Таким образом, это измерение времени дня будет иметь 1440 записей, если зерна были минуты или 86 400 записей, если зерно было секунд.

7 голосов
/ 25 марта 2010

Я думаю, это зависит от ваших требований к отчетности. Если вам нужно что-то вроде

WHERE "Hour" = 10

означая каждый день с 10:00:00 до 10:59:59, тогда я бы использовал измерение времени, потому что оно быстрее, чем

WHERE date_part('hour', TimeStamp) = 10  

потому что функция date_part () будет оцениваться для каждой строки. Вы все равно должны хранить метку времени в таблице фактов для агрегирования по границам дней, например:

WHERE TimeStamp between '2010-03-22 23:30' and '2010-03-23 11:15' 

, что становится неудобно при использовании полей измерений.

Обычно измерение времени имеет минутное разрешение, поэтому 1440 строк.

4 голосов
/ 24 марта 2010

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

3 голосов
/ 22 сентября 2011

Я бы порекомендовал иметь отдельное измерение для даты и времени. Измерение даты будет иметь 1 запись для каждой даты как часть идентифицированного допустимого диапазона дат. Например: с 01.01.1980 по 12/31/2025.

И отдельное измерение для времени, имеющее 86400 записей, причем каждая секунда имеет запись, идентифицированную ключом времени.

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

...