Марги Росс (Margy Ross) — Президент Kimball Group.
Соблюдайте следующие правила чтобы гарантировать гранулированность данных, а так же гибкость и доступность информационного ресурса в будущем. Нарушайте правила, и бросайте смятённых пользователей на глухие неприступные стены вашего хранилища данных.
Студенты, посещающие лекции Kimball Group по многомерному моделированию, попросили у меня список «заповедей Kimball» для многомерного моделирования. Воздержимся от использования религиозной терминологии. Поэтому, нижеследующее, добытое методом проб и ошибок, назовём не слишком строгими рекомендациями и правилами «как-ничего-не-сломать».
Правило № 1: Загружайте в многомерные структуры подробные атомарные данные.
С учётом непредсказуемости запросов бизнес-пользователей, для обеспечения всевозможной фильтрации и группировки, многомерные модели должны быть заполнены самыми подробными сведениями какими только возможно. Это тот фундамент, на котором всё будет держаться. Пользователям, как правило, нужно видеть больше одной записи разом. И Вы не можете знать всё то множество произвольных, практически непредсказуемых, вариантов развёртывания/свёртывания элементов отчёта. Если доступны только обобщенные данные, то уже сейчас можно предположить случаи, когда пользователи упрутся в кусок кирпичной стены, при попытке закопаться в детали поглубже. Конечно, для увеличения производительности частых запросов к агрегированным данным, атомарная детализация может быть дополнена сводными многомерными моделями. Но бизнес-пользователи не могут жить только с суммированными данными. Чтобы свободно отвечать на постоянно меняющиеся вопросы, им необходимо как можно больше подробностей, вплоть до кровавых.
Правило № 2: Стройте многомерную модель вокруг бизнес-процессов.
Бизнес-процессы это различные деятельности, осуществляемые в организации и представляют из себя ряд измеряемых событий. Примеры: получение заказов или выставление счетов клиенту. Обычно, бизнес-процессы фиксируют или порождают уникальные, связанные с каждым событием, показатели эффективности. Такие показатели интерпретируются как факты, расфасованные в отдельные (для каждого бизнес-процесса) таблицы атомарных фактов. В дополнение к таблицам фактов отдельного процесса, иногда создаются сводные таблицы фактов, объединяющие данные множества бизнес-процессов в одну таблицу фактов, но с общим уровнем детализации. Повторюсь, сводные таблицы фактов дополняют детализированные таблицы бизнес-процессов, но никак не заменяют их.
Правило № 3: Убедитесь, что каждая таблица фактов связана с таблицей размерностей времени.
Измеряемые события, описанные в Правиле № 2, всегда имеют разнообразные отметки дат, связанные с ними. Например, срез ежемесячного баланса или денежного перевода, зафиксированный до сотых долей секунды. Каждая таблица фактов должна иметь, по крайней мере, один внешний ключ к связанной таблице с размерностями времени. Эта таблица должна быть с гранулярностью в один день, с атрибутами календаря и какими-либо нестандартными характеристиками, которые описывают дату измеряемого события. В качестве примеров: финансовый месяц и указатель корпоративных праздников. Бывает, что в таблице фактов представлены несколько внешних дат-ключей.
Правило № 4: Убедитесь, что все факты в отдельной таблице фактов, одинаковой гранулярности или уровня детализации.
Все таблицы фактов можно классифицировать по трём основным видам гранулярности: транзакционные, периодические срезы, или срезы с накоплением. Независимо от типа гранулярности, каждое измерение в таблице фактов должно быть в точности на одном и том же уровне детализации. Комбинирование фактов из одной таблицы, но представляющих различные уровни детализации, обязательно вызовет путаницу у бизнес-пользователей. А инструменты бизнес-аналитики станут подвержены завышениям, дублированию и другим ошибкам в результатах расчётов.
Правило № 5: В таблицах фактов избавляйтесь от отношений многие-ко-многим.
Поскольку таблицы фактов хранят результаты событий бизнес-процессов, то зачастую они строятся на отношении «многие-ко-многим (M:M) между внешними ключами, так, например, множество продуктов продаются во многих магазинах много дней. Эти поля внешних ключей никогда не должны иметь неопределенных значений (Null). Иногда размерности могут содержать множество значений для единственного события-показателя. Например, множество диагнозов, связанных с посещением организации здравоохранения или множество клиентов, связанных с банковским счетом. В таких случаях, неразумно решать проблему размерностей со множеством значений непосредственно в таблице фактов, поскольку это нарушит нормальную гранулярность измеряемого события. Поэтому, соединение с таблицей фактов, отношением многие-ко-многим, происходит через промежуточную таблицу (Bridge) с двойным ключом.
Правило № 6: Избавляйтесь от отношений многие-к-одному между таблицами размерностей.
Иерархические с фиксированной глубиной отношения многие-к-одному (М:1) между атрибутами, как правило, денормализуются или сворачиваются в плоскую таблицу размерностей. Если Вы провели большую часть карьеры, проектируя модели с сущностными связями для традиционных систем с обработкой транзакций, то сопротивляйтесь инстинктивному стремлению к нормализации отношений М:1 или дроблению на более мелкие подразмерности вида „снежинка“ (прим.пер.: стремитесь к схеме „звезда“). Денормализация размерностей — это и есть игра под названием „многомерное моделирование“.
Множество отношений М:1, представленых в одной таблице размерностей, является общепринятой практикой. Также, в таблице размерностей встречаются отношения один-к-одному, такие как уникальное описание продукта, связанное с кодом продукта. Иногда, в случае очень подробных таблиц размерностей с миллионами строк и часто меняющимися атрибутами свёртки, разрешается иметь отношения многие-к-одному в таблице фактов. Однако, подходить к такому использованию таблицы фактов необходимо очень и очень осторожно, тщательно всё взвесив и обдумав.
Правило № 7: Храните в таблицах размерностей заголовки для отчётов и области значений для фильтров.
Коды и, что более важно, сопутствующие расшифровки и описания, использованные для формирования меток и фильтрующих запросов, должны быть собраны в таблицы размерностей. Не храните поля с непонятными кодами или громоздкие описательные поля непосредственно в таблице фактов. Но, мало просто запихнуть код в таблицу размерностей. Не надейтесь, что они автоматически будут корректно поддерживаться в инструменте BI, а пользователям не будут нужны поясняющие расшифровки. Если это заголовок строки/столбца или фильтр из выпадающего меню, то они должны храниться как атрибут размерности.
Т.к. в Правиле № 5 мы заявили, что внешние ключи таблицы фактов никогда не могут содержать неопределеных значений, то разумно избегать неопределенных значений и в полях атрибутов в таблице размерностей. Заменяйте значение Null в атрибуте на какое-то значение по умолчанию, например, NA или любое другое по вашему вкусу. Вы, как распорядитель(прим.пер.: здесь обыгрывается ситуация с неким слугой или дворецким, а не простым суровым админом) по источнику данных, насколько это возможно, предотвращаете замешательство пользователей.
Правило № 8: Убедитесь, что таблицы размерностей используют суррогатный ключ.
Невыразительные, заданные последовательно суррогатные ключи (за исключением размерности с датами, где приняты более выразительные хронологические ключи (прим.пер.: хотя, по-идее, хронология — это тоже последовательность)) предоставляют ряд эксплуатационных преимуществ. Такие ключи получаются меньшего размера, а это, в свою очередь, уменьшает таблицы фактов и индексы, но повышает производительность. Суррогатные ключи абсолютно необходимы, если Вы сопровождаете изменения атрибута размерности, добавлением новой записи в размерность, при каждом профильном изменении. Даже если Ваши бизнес-пользователи, изначально не планировали визуализировать изменения отслеживаемого атрибута, используя суррогаты вам будет проще внести поправки, если ветер подует в другую сторону. Суррогаты также позволяют привести множество действующих ключей к общему профилю (прим. пер.: имеется ввиду, к некому стандартному виду), а также смягчат последствия неожиданной эксплуатационной деятельности, такой как утилизация устаревших номеров продукта или приобретение другой компании, со своей собственной схемой кодирования.
Правило № 9: Создавайте согласованные размерности для интеграции данных в масштабах предприятия.
Согласованные размерности (также известные, как общие/common, главные/master, стандартные/standard или ссылочные/reference) имеют важное значение для корпоративных хранилищ данных. Однажды загруженные в ETL-систему, а затем повторно использумые во множестве таблиц фактов, согласованные размерности снабжают непротиворечивыми описательными атрибутами все многомерные модели и дают возможность исследовать(drill) и интегрировать между собой данные из множества различных бизнес-процессов. Шинная матрица хранилища данных предприятия (Enterprise Data Warehouse Bus Matrix) является ключевым архитектурным шаблоном для представления основных бизнес-процессов предприятия и связанных с ними размерностей. Повторное использование согласованных размерностей, в конечном итоге, сокращает время выхода на рынок за счет устранения избыточного проектирования и усилий в области разработки; однако, согласованные размерности требуют соблюдения некоторых обязательств (commitment), а также инвестиций в должность распорядителя данных (прим.пер.: это не администратор в привычном понимании, и вообще, может быть даже, не технический специалист, но человек, хорошо знакомый с предметной областью, например, бизнес-аналитик) и систему управления (data stewardship and governance), даже если вам не нужно договариваться со всеми и каждым по каждому атрибуту размерности для достижения полной согласованности.
Правило № 10: Непрерывно соотносите требования с действительностью, чтобы предоставить бизнес-пользователями подходящий DW/BI-инструмент, помогающий им принимать решения.
Разработчики многомерных моделей должны постоянно балансировать между требованиями бизнес-пользователей и, заложенными в фундамент, реалиями имеющегося источника данных. Только в этом случае, производимый проект, будет успешно реализован и, что более важно, имеет реальный шанс пойти в дело и приносить пользу. Соблюдение баланса „требования-против-действительности“ — это сущность жизни для DW/BI-профессионалов, на чём бы Вы не были сосредоточены: многомерных моделях, стратегиях проекта, технических/ETL/BI архитектурах или планах развертывания/обслуживания.
Заключение.
Если Вы регулярно читали наши статьи Intelligent Enterprise, Toolkit books или ежемесячно Design Tips, то эти правила не должны быть для Вас в новинку. Сейчас мы собрали наши правила в единый свод, к которому можно обратиться, когда соберётесь проектировать или перепроверять ваши модели.