За последние 6 лет мне доводилось видеть несколько OLAP-проектов, в которых имели место быть различные ошибки: длинные строковые ключи измерений, отсутствие секционирования приличных объемов фактов, игнорирование дизайна агрегаций, преобладание измерений с единственным атрибутом. Все это, особенно последнее, свидетельствует о непонимании сути многомерной модели. Рассмотрим подробнее вопрос об оптимальном проектировании измерений, а конкретнее, о ценности естественных иерархий.
Если почти каждое измерение проекта состоит из одного атрибута, то их с вероятностью 99% можно объединить. Если в одном измерении много атрибутов и нет иерархий, то, скорее всего, их можно и нужно выявить и построить. Эти два приведенных упущения говорят о ленивом разработчике либо о незнании им особенностей бизнеса. Профилирование данных, интервьюирование Бизнеса помогают выстроить пригодные натуральные иерархии в измерениях. Ральф Кимбалл неслучайно делает упор на Dimensional Modeling. Какой смысл закачивать в кубы огромные массивы данных, если криво сделаны измерения / присутствуют проблемы в измерениях ?!
Вспомним преимущества натуральных естественных иерархий в измерениях:
- Наглядное изложение о взаимосвязях, зависимостях сущностей Бизнеса; некоторые зависимости не всегда очевидны (особливо для новых сотрудников), а проясняются по мере детального, длительного, кропотливого изучения бизнес-процессов;
- Новые дополнительные атрибуты, интересные для аналитики; Лаконичная компоновка атрибутов - навигация от общего к частному;
- Повышение производительности запросов к кубу: в частности, атрибуты, участвующие в естественных иерархиях, материализуются на диске в хранилищах иерархий во время процессинга измерений и автоматически считаются кандидатами / включаются в агрегаты данных; Соотношения количества элементов между уровнями иерархии в несколько раз, десятки раз положительно сказывается на скорости операции Drill Down, многомерных вычислениях;
- Высокие требования к качеству данных: заданные связи между атрибутами не позволят элементу данных одновременно иметь нескольких родительских элементов в рамках одной и той же иерархии; Иерархии позволяют оперативно и отчетливо увидеть грязь, шумы в данных: автоматическая сортировка в алфавитном порядке поднимает вверх на каждом уровне пустые значения, опечатки, фейковые значения, а собственно уровни иерархии способствуют обнаружению логических аномалий, нестыковок в данных, поскольку разбивают большие последовательности на подмножества;
- Некоторая защита от безумной пользовательской нагрузки на сервер при попытке вытащить атрибуты больших измерений на ось строк / столбцов сводной таблицы: показываются не сразу все элементы, а последовательные порции при выполнении Drill Down;
- Сокращение физического пространства куба за счет удаления измерений с единственным атрибутом; Измерения - это логический контейнер для атрибутов; Измерения призваны отвечать на непосредственно связанные с бизнес-событиями вопросы Что, Где, Когда, Кому, Откуда;
- Облегчение написания MDX-выражений (функции Children, Parent, Descendants, FirstChild, LastChild и др.);
- Упрощение установки прав доступа пользователей на уровне данных атрибутов измерений;
От архитектурных положений перейдем к практическим примерам с картинками. Итак, поехали!
В измерении "Даты" есть что добавить и улучшить, в частности интегрировать календарь рабочих дней. Измерения дат и времени - одни из тех немногих, которые единожды сделал и забыл:
В измерении "Даты" очень важно правильно определить связи и свойства атрибутов, чтобы корректно работали функции Time Intelligence:
В больших многомиллионных измерениях "Клиенты" / "Договоры" / "Заказы" / "Счета" и т.п. можно создать иерархию по первым символам, по первым N символам (зависит от распределения данных), фамилиям / маске данных. На рисунке ниже приведен такой пример. Цифры красным цветом означают ориентировочное количество элементов на соответствующем уровне иерархии. Этот прием удобен для Drill Down навигации, поскольку поиск по элементам (как по вхождению строки, так и точному совпадению) может быть невыполним.
Ниже предъявлен пример обогащения атрибутного состава с последующим образованием иерархий в измерении "Страны":
Числовые значения могут выступать одновременно как мерами, так и атрибутами измерений. Аналоговые (~ бесконечно многие) величины можно дискретизировать в диапазоны и увязать с таблицей фактов. Образец справочника (Microsoft Master Data Services) именованных диапазонов числовых значений прикреплен в конце данной статьи.
Еще один пример весьма пользительного обогащения измерения "Валюты":
Объединяя официальные государственные справочники (ФИАС / КЛАДР) и статистические данные получаем новое качество географического измерения и возможностей аналитики:
Типичная иллюстрация объединения нескольких измерений в одно, отвечающего на вопрос Где. Торговые точки - это представительства юридического лица и точки присутствия брендов (торговых сетей), не говоря уже о геолокации.
Вплетение географических и других официальных справочников, чёткие связи между атрибутами позволяют легко оперировать точками развитой розничной сети:
Сведение логинов пользователей всех систем (Active Directory, Front, Middle, Back, HR, Mobile и др.) в единое измерение - не только мечта IT-директора, но и нужный ресурс для самих пользователей:
Создание иерархий измерений - творческий процесс, результаты которого ценят пользователи многомерных моделей.