Я строю хранилище данных. Каждый факт имеет свою timestamp. Мне нужно создавать отчеты по дням, месяцам, кварталам, но и по часам. Глядя на примеры, я вижу, что даты обычно сохраняются в таблицах измерений. 
(источник: etl-tools.info)
Но я думаю, что это бессмысленно для времени. Таблица измерений будет расти и расти. С другой стороны, JOIN с таблицей измерения даты более эффективен, чем использование функций даты/времени в SQL.
Каковы ваши мнения/решения?
(Я использую Infobright)
Я предполагаю, что это зависит от ваших требований к отчетности. Если вам нужно что-то вроде
WHERE "Hour" = 10
означает каждый день между 10:00:00 и 10:59:59, тогда я буду использовать измерение времени, потому что оно быстрее, чем
WHERE date_part('hour', TimeStamp) = 10
потому что функция date_part() будет оцениваться для каждой строки. Вы должны по-прежнему удерживать TimeStamp в таблице фактов, чтобы заполнить границы дней, например:
WHERE TimeStamp between '2010-03-22 23:30' and '2010-03-23 11:15'
который становится неудобным при использовании размерных полей.
Обычно размер времени имеет минутное разрешение, поэтому 1440 строк.
Кимбалл рекомендует иметь раздельные размеры времени и даты:
design-tip-51-latest-thinking-on-time-dimension-tables
В предыдущих книгах Инструментария мы имеем рекомендуется создать такой размер с компонентом минут или секунд времени в качестве смещения с полуночи каждый день, но мы осознали что конечный пользователь приложения стали слишком сложными, особенно при попытке вычислить время охватывает. Кроме того, в отличие от календарного дня измерения, очень мало описательные атрибуты для определенной минуты или секунды в пределах день. Если предприятие хорошо определенные атрибуты для временных фрагментов в течение дня, например, имена смены или рекламные временные интервалы, дополнительный измерение времени дня может быть добавлено к дизайн, в котором этот размер определяется как количество минут (или даже секунды) за полночь. Таким образом, это измерение времени суток было бы 1440 записей, если зерно было минут или 86 400 записей, если зерно было секунд.
Время должно быть измерением на хранилищах данных, так как вы часто захотите объединить его. Вы можете использовать snowflake-Schema, чтобы уменьшить накладные расходы. В целом, как я отметил в своем комментарии, часы кажутся необычно высоким разрешением. Если вы настаиваете на них, делая час дня отдельным аспектом может помочь, но я не могу сказать вам, если это хороший дизайн.
Я бы рекомендовал иметь отдельное измерение для даты и времени. Date Dimension будет иметь 1 запись для каждой даты как часть определенного допустимого диапазона дат. Например: 01/01/1980 - 12/31/2025.
И отдельное измерение для времени, имеющего 86400 записей с каждой секундой, имеющих запись, идентифицированную клавишей времени.
В записях фактов, где u нужна дата и время, добавьте обе клавиши, имеющие ссылки на эти соответствующие размеры.