Блог → Разбираем использование МСУБД на простом примере

Итак, с чего же начать конструирование МСУБД? Первым делом надо четко определить: что нам нужно? Какие именно аналитические показатели требуются, и от каких факторов они зависят? Эта информация и будет определять структуру МБД и содержащиеся в ней данные. Возьмём классический пример: продажи по регионам. Допустим, мы продаем некие товары - в различных регионах, в течение некоторого времени. Это и будут наши аналитические факторы, а показателем сделаем объёмы продаж. Заметьте, что уже на этом этапе данные в МБД будут до некоторой степени агрегированы (сгруппированы). Так, например, в реляционной БД могут храниться данные о каждой конкретной продаже. В МБД же такая детализированность нужна крайне редко - скорее всего, туда будут загружаться суммарные данные (скажем, по дням). Попав в МБД, данные - по мере необходимости, могут подвергаться дальнейшей агрегации (например, по месяцам). Более подробно об этом будет сказано ниже, пока же вернемся к нашим баранам (в смысле, продажам).

Для начала возьмем двумерный случай - объёмы продаж по товарам и времени. В реляционной модели эта информация представляется примерно так:



А вот как это выглядит в многомерном представлении:



Даже на таком простом примере сразу видны некоторые особенности многомерной модели. С одной стороны, в глаза бросается некоторая избыточность данных: мы храним сразу все возможные значения показателей, подставляя Null там, где данные отсутствуют. Тех, кто подумал, что такое представление неэффективно, спешу заверить - это не совсем так. Небольшое число разрозненных данных, с обилием пустых значений, нет смысла анализировать. Обычно для анализа используют подборки данных, в которых пустых значений не более 5%, на таком материале многомерное представление себя оправдывает.

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

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



В терминологии МБД подобные множества значений аналитических факторов называются измерениями (dimensions). На физическом уровне измерение представляет собой всего лишь именованный массив переменной длины. Значения измерений могут быть любого типа, который поддерживает данная МСУБД: числа, даты, строки символов и т.д. Измерения мы определили, теперь настал черёд переменных (variables). Переменной называют множество значений показателя, т.е. собственно данные, наполняющие N-мерный куб. Несмотря на ряд существенных отличий, можно сказать, что измерения являются аналогом табличной структуры в реляционных БД, а переменные - аналогом таблиц.

Приятная особенность МСУБД - возможность создавать различные переменные, комбинируя уже имеющиеся измерения. Например, имея четыре измерения [1,2,3,4] можно создать две переменные: [1,2,3] и [2,3,4]. Можно также создавать несколько переменных на одном и том же множестве измерений - поскольку переменная и соответствующие ей измерения не так сильно связаны, как таблица и её структура: это два самостоятельных вида хранимых объектов МСУБД. На всякий случай замечу, что иногда переменные именуют "показателями", а термин "переменная" применяют в более широком смысле, называя так совокупность понятий, обозначающих типы объектов МБД (даже авторы серьезных книжек по OLAP порой сознаются в некоторой неопределенности в терминах).

Как я уже упоминал выше, агрегация данных - это по сути группировка их по какому-либо фактору и соответствующее суммирование показателей. Например, мы имеем множество торговых точек и филиалов, и знаем, каким образом они группируются по регионам. Как нам получить суммарные показатели по регионам? Легко! Для этого есть специальный тип объекта - отношение (relation). Отношения определяют связь вида "один ко многим" между значениями одного или двух измерений. Если отношение определяется для одного измерения - его называют иерархическим, а множество связанных (на одном измерении) отношений - иерархией. Такая иерархия представляет собой всем известную структуру: дерево. Определяя отношения, мы можем построить дерево так, что на каждом его уровне будем получать определенный уровень агрегации. Надо только правильно определить отношения и дать пользователю возможность выбирать желаемый уровень агрегации - все остальные действия в МСУБД происходят автоматически.

Формула - еще один объект МБД, очень похожий на представления в реляционных БД. Математически формулу можно представить как N-мерную функцию значений соответствующих измерений. Как и в реляционных БД, вычисление значений формулы может быть реализовано на каком-либо процедурном языке (например, на Express Basic в Oracle Express). При вычислениях могут использоваться значения измерений, переменных и других формул.

Разумеется, существуют и другие хранимые объекты - программы, модели данных, наборы значений. Но тут, увы, всё слишком зависит от конкретной реализации, так что - читайте документацию. RTFM.