Блог

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

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

Например, между ‘2009-06-29’ и ‘2011-06-29’ прошло 2 года, однако нам нужно знать, что этот диапазон состоит из одного полного года (2010), одиннадцати месяцев (январь-май / 10 и июль-декабрь / 09) и 58 дней (1-29 / 09 июня и 1-29 / 11 июня).

Из этого результата мы можем извлечь уже обобщенные записи из 70 детализированных периодов, объединить и представить итоговое значение.

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

1. Заполните массив «datesToParse» начальным диапазоном дат.
2. Определите, существует ли один или несколько полных лет между датами.
   • Для каждого года между датами удаляйте этот период из диапазона дат и разделяйте «период до» и «период после» года на два новых диапазона дат.
   • Поместите два новых диапазона дат в стек «datesToParse».
   • Повторять
3. Когда все возможные годы будут удалены из массива «datesToParse», повторите процесс для месяцев, недель и дней.

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

Есть ли лучший способ сделать это? Похоже, что эта проблема решалась много раз раньше.

Я не понимаю, почему вы хотите реализовать такое сложное решение, обычная реализация заключается в том, чтобы иметь только одну таблицу фактов с данными на самом низком уровне детализации (ежедневно в вашем случае) и просто СУММИРОВАТЬ () показатели в ваших запросах по мере необходимости.

Это очень просто реализовать и поддерживать, а запросы очень легко писать (или генерировать из вашего инструмента создания отчетов). У вас это не работает? Какой объем данных у вас есть? Реализовали ли вы дату как измерение (надеюсь, да) или как значение в таблице фактов? Используете ли вы инструмент создания отчетов (SSRS, Cognos, Business Objects) или создаете свои собственные запросы?

Если вы думаете о проблемах с производительностью, то для DWH довольно часто происходит подобное развитие:

1. Реализовать единую таблицу фактов (как описано выше)
2. Добавьте много данных
3. Обнаруживайте проблемы с производительностью по мере увеличения объема данных
4. Улучшение индексации
5. Реализовать разбиение таблицы на разделы
6. Реализовать OLAP

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