По следам этого поста.

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

Указанную проблему можно решить двумя способами:

Спланировать на этапе проектирования всевозможное количество статических (уже готовых) отчетных шаблонов и заполнять их данными по требованию пользователей.
Разработать динамическую модель построения отчетов «на лету» с использованием технологий анализа OLAP (OnLine Analytical Processing), далее ОЛАП.

Очевидно, первый способ на практике очень сложен, потому как вероятность допустить ошибку на этапе проектирования шаблонов весьма высока. К минусам второго способа стоит отнести ограниченное множество измерений, по которым можно производить анализ. Полагая, что задачей анализа является минимизация недоступных для отчетности наборов данных при максимуме удовлетворенных потребностей пользователей, решением проблемы будет являться комбинация из двух предложенных способов. При этом, учитывая, что ожидания от системы у заказчика существует априори, то статическими шаблонами покрывается большинство требований пользователей. Механизмы ОЛАП‑а, в свою очередь, позволят создавать динамические отчеты для более «изысканных» условий анализа, описывать динамику наполнения Системы и показывать направления векторов изменений в данных.

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

Online Transaction Processing (OLTP)
Online Analytical Processing (OLAP)

Первый подход подразумевает «стандартный» дизайн базы данных, когда исполняются несколько правил нормализации вида «допустимое абстрагирование – сущность — таблица». В этом виде проектируется база данных Системы. Он идеален для хранения данных в виду своей эффективной избыточности, когда набор связанных между собой данных находится в БД при минимуме дублирующихся полей, и, как следствие, занимает минимум места при всех прочих равных. Этот подход является обратным ко второму (OLAP), императивом которого является максимально допустимая денормализация данных и связей между ними.

Технология анализа данных ОЛАП базируется на создании т.н. многомерных ОЛАП‑кубов, которые являются ни чем иным кроме как функцией от многих переменных (или измерений), дискретное множество значений которой (т.н. факты) описывают какое-то качественное состояние системы. Указав некоторые из измерений этой функции (т.е. куба) в качестве входящих параметров, можно получить набор данных, пригодных для использования в динамическом шаблоне отчета. Очевидно, что для того, чтобы оперативно получить такой набор данных, следует априори знать конечное множество значений для каждого измерения. Тем самым избыточность связей и дублирующихся данных при дизайне OLAP не является недостатком ввиду достигаемых целей:

Минимизация вычислений значения для требуемого измерения
Минимизация вычислений значения состояния системы (факта)

Общепонятным примером таких измерений могут служить:

Время в качестве измерения
Атрибуты сущностей в качестве измерения
Количества сущностей в качестве значения куба

Дизайн БД OLTP разработан таким образом, чтобы минимизировать избыточное количество значений для любого из допустимых измерений, а, стало быть, не подходит в качестве источника данных для куба. Для того чтобы измерения были в достаточной мере полными, оригинальную базу данных Системы следует преобразовать в т.н. хранилище данных – специализированную БД OLAP, которая удовлетворяет условиям поставленной задачи. Она будет служить источником данных, используемых в отчетах.

Из всего вышесказанного следует, что при решении поставленной проблемы анализа данных справедливы следующие утверждения:

С использованием специального преобразования следует наполнять данными БД‑хранилище из основной БД
Для отчетов (как статических, так и динамических) будет использоваться БД‑хранилище, а для АРМ-ов системы и всей остальной оснастки – основная БД Системы
Ресурсы, потребляемые системой при построении отчетов и остальной работе с БД, будут распределены параллельно, тем самым разделяясь на два независимых процесса исполнения и не мешая друг другу

В указанном подходе существуют два минуса:

Требуется создать преобразование данных, перегоняющее значения из основной БД в хранилище
Поскольку преобразование теоретически ресурсоемко, оно может исполняться через некоторые промежутки времени.

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

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

Практическое решение

Для наиболее эффективного использование кубом денормализованных данных, структура хранилища должна удовлетворять следующим условиям:

БД состоит из таблиц измерений и фактов
Факт – это вычисленное значение многомерной функции (куба), которое является качественной характеристикой системы
Факты сами могут являться измерениями и наоборот
Таблицы должны быть связаны так, чтобы существовал хотя бы один алгоритмический способ получить факт по заданным измерениям.

Практически этим четырем условиям будет характерна топология таблиц БД «снежинка»:

Рис 1: пример практической реализации БД-хранилища «снежинка»
Здесь Value – это значения измерений, фактов.

На практике денормализующее преобразование задается в хранимых процедурах и исполняется в JOB-like процессах БД с указанными промежутками времени.

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

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

Примером промышленного решения поставленной задачи анализа и построения отчетов являются продукты Microsoft Analysis Services и Microsoft Reporting Services.

Подход к Online Analysis Processing