измерение даты / времени

Question

Я проектирую хранилище данных, и у меня возникли проблемы со временем.Зерно, в котором я нуждаюсь, является почасовым (для расчета совокупного количества событий в час), и я также должен приспособить шаблон смены, который не удобно помещается в течение 24-часового периода (на самом деле, возможно, что «синее» смещение не охватит одновремя дня в течение нескольких дней).

Имея это в виду, я рассматриваю один из 3 подходов

1. одно измерение времени с 175К строк в нем.
2. измерение времени снежинки с 7300 строками в измерении календаря и 175k строками в измерении времени
3. отдельных измерений, так что таблица фактов имеет внешние ключи для даты события и времени события.

Я склоняюсь к подходу 3, поскольку он позволяет ссылаться на небольшое календарное измерение в соединениях по отдельности, но я был бы признателен за любые мысли.

Answer 1

Да, производственные смены сложны и со временем меняются, часто одна смена начинается днем ​​раньше и т. Д.

Имейте в виду, что здесь два календаря . Одним из них является стандартный календарь , а другим - производственный календарь - сдвиг относится к производственному календарю . Как правило, день в производственном календаре может длиться больше (или меньше), чем 24 часа.

Например:

деталь, выпущенная в понедельник, 2011-02-07 23:45 может выглядеть как

TimeOfProduction = '2011-02-07 23:45'
DateKey = 20110207
TimeKey = 2345
ProductionDateKey = 20110208 (the first shift of the next day started at 22:00)
ProductionTimeKey = 145 (1 hour and 45 minutes of the current production date)     
ShiftKey = 1
ShiftTimeKey = 145 (1 hour and 45 minutes of the current shift)

Итак, мое предложение:

1. Обычный Date Dimension (по одной строке на дату)
2. Обычный Time Dimension (одна строка в минуту в течение 24 часов = 1440 строк + см. Примечание ниже)
3. Shift Dimension - типоразмер 2 с rw_ValidFrom, (rw_ValidTo) , rw_IsCurrent
4. Ролевая игра DateKey в ProductionDateKey
5. Ролевая игра TimeKey в ProductionTimeKey и ShiftTimeKey.
6. Держите TimeOfProduction (datetime) в таблице фактов тоже.
7. Во время процесса ETL примените логику текущего сдвига, чтобы прикрепить ProductionDateKey, ProductionTimeKey, ShiftKey, ShiftTimeKey к каждой строке таблицы factPart.

Обратите внимание , что вам может понадобиться добавить дополнительные строки в Time Dimension, если рабочий день может длиться более 24 часов. Обычно это возможно, если используется местное время и существует переход на летнее время.

Итак, звезда может выглядеть примерно так

Answer 2

Мои £ 0,02 за то, что оно стоит:

Предполагая, что нет никаких дополнительных проблем, связанных с рассмотрением смены (вопрос @Andriy M):

Я бы предпочел сделать скидку2, если нет особого преимущества (производительность, упрощение класса запросов и т. Д.), Вы можете увидеть его принятие.Вы не описываете какую-либо такую ​​выгоду, поэтому кажется, что вы добавляете сложность ради нее самой.

Моим личным предпочтением будет вариант 1 - концептуально самый простой, самый прямой и (IMO) лучшийподходит для хранилищ данных.

Вариант 3 имеет упомянутые вами преимущества, но у меня есть неприятное подозрение, что он охватывает две альтернативы: в обоих измерениях календаря, как вы его описали, но выбор для измерения времени составляет 175 тыс. Строк или 24В настоящее время я не могу привести аргументы в пользу какой-либо из этих альтернатив, только интуитивное ощущение, что есть два таких варианта.Если проблема сдвига здесь актуальна, это может повлиять на выбор между этими альтернативами (если они являются подлинными альтернативами).

Если вы хотите продолжить вариант 2, альтернативы, изложенные для варианта 3, также актуальны.

Answer 3

Я бы выбрал вариант 3. - Отдельные размеры. Преимущества:

• Простота - две сравнительно небольшие таблицы - с измерением времени, загружаемым только один раз, поскольку фиксированное количество минут в дне.

• Повторное использование - два отдельных измерения с большей вероятностью будут использоваться совместно с другими таблицами фактов, которые могут иметь только измерение Дата или Время

• Простое разбиение благодаря наличию отдельного атрибута для измерения даты в таблице фактов

• Расширяемость - подумайте об атрибутах, которые вы можете добавить к измерениям даты и времени по мере роста ваших потребностей в отчетности. Для измерения Дата это может быть (чтобы не извлекать эту информацию каждый раз из даты): год, квартал, месяц, день, неделя, метка даты (например, «12 сентября 2011 года»), название месяца, название дня недели, различные показатели (праздник индикатор, конец квартала, конец месяца и т. д.). Для измерения времени (которое может - для точности - содержать каждую секунду дня) это может быть: часы, минуты, секунды, метка части дня (например, «утро», «вечер»), индикатор рабочего времени (секунды из 8: От 00:00 до 17:00:00) и т. Д. Но наличие всего этого в одном измерении означало бы большую избыточность.

Сдвиги, которые не выровнены с началом / концом дня, кажутся мне хорошим кандидатом на отдельную отметку времени начала и конца записи басни фактов для каждой смены. , id_date_end, id_time_end. Затем вы можете выполнить переход от таблицы фактов событий к таблице смен, чтобы получить агрегированные результаты для каждой смены.

Редактировать: Или модель перемещается просто как другое измерение - это зависит от того, является ли для вас изменение важным бизнес-процессом, который вы хотите отслеживать независимо от его атрибутов (но на данный момент я могу ' Не думайте о каких-либо других атрибутах, кроме Date & Time ... Location, возможно?) или, если это просто контекст события (и, следовательно, должен быть просто измерением).