Начальный и конечный период в каждом факте в хранилище данных

Question

Меня попросили добавить новую таблицу в наше хранилище данных.В настоящее время мы разделяем наши факты на месячные, квартальные и годовые таблицы с временными измерениями для каждого.Каждая запись факта имеет одно временное значение.Данные генерируются в исходной системе по начальному и конечному периоду, а конечная дата становится значением измерения времени записи факта.Поток фактов в таблицу фактов за месяц, квартал или год рассказывает, как понимать даты в записях и как их использовать.

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

У меня нет данныхСкладской эксперт.Я понимаю, что единичное измерение времени на факт - это принцип.Мой вопрос: каковы последствия нарушения этого принципа?Другими словами, каковы аргументы против этого?С какими проблемами я могу столкнуться в будущем?Мне кажется, что наличие начального и конечного периодов для каждого факта лучше представляет данные, но я признаю, что я не знаю достаточно, чтобы полностью оценить последствия этого выбора дизайна.Может ли кто-нибудь предоставить какое-нибудь предположение?

Редактировать: Я ценю эти ответы.Они, по крайней мере, говорят мне, что это не такая плохая практика, как мне поверили.Я уточню одну вещь о датах: они представляют не период действия, а период агрегации.Таким образом, запись факта может представлять среднее значение фунтов, использованных для определенного ингредиента, рассчитанное для произвольного периода месяцев.Не знаю, имеет ли это какое-то значение, но это так.

Answer 1

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

1. ОЧЕНЬ распространено иметь несколько временных измерений на факт.Кто-то дал вам неверную информацию, когда сказал, что нарушил общепринятую практику.В качестве примера для факта «заказа» обычно указывается дата заказа, дата отгрузки, дата поставки, период и т. Д.

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

Answer 2

Преимущество записи дат начала и окончания состоит в том, что вы можете легче представлять неоднородные периоды времени.Это означает, что вы можете легче объединять, объединять и сравнивать данные, записанные с различной степенью детализации.Из вашего описания, кажется, нет ничего принципиально «неправильного» в том, что вы предлагаете.Я реализовывал подобные вещи раньше.

Я считаю, что лучшая модель для периодов времени в таблице - это использование полуоткрытых интервалов.Т.е. интервалом является период, представленный StartDate> = x

Answer 3

Хорошо. Так я выполняю (буду) одни и те же требования. Я моделирую корректировки в своей таблице фактов с новым полем даты, в котором записана дата события.

Например, сверху

EventDateKey Сумма RecordType

20110327 700,0 Источник

20110329 -500,0 Регулировка DW

Таким образом, если вам нужно агрегировать (суммировать сумму), ваши данные могут использовать EventDateKey и работать с любым периодом в том же измерении Date. Это сложно, потому что вы моделируете корректировку в своей таблице фактов, но она дает всю гибкость, которую вы ищете, не теряя при этом объем информации.

Answer 4

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

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

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

неправильный подход будет состоять в том, чтобы смешивать зерна в одной таблице.Рассмотрим следующее

FromDateKey ToDateKey   Amount
20110327     20110402   700.0
20110329     20110330   200.0     

Любой sum(), который будет включать обе строки, будет дважды считать вторую запись, которая уже включена в первую.

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