Время/время

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

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

одномерное измерение с 175 тыс. строк в нем.
измерение времени снежинки с 7300 строк в календарном измерении и 175 тыс. строк во временном измерении
чтобы таблица фактов имела внешние ключи для даты события и времени события.

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

Ответ 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)

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

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