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

В своей статье Two Powerful Ideas («Два мощных правила», Intelligent Enterprise No 8’2002, с. 20) я описал два основных правила проектирования хранилища данных. Первое касалось разделения систем — в логическом, физическом и управленческом плане — на область промежуточных данных и область представления данных. А во втором правиле речь шла о создании «звезд» и кубов в области представления. Рассматривая проблему с технической точки зрения, я описал множество преимуществ этих правил. В конце статьи я высказал мысль о том, что симметричные «звезды» и кубы, будучи сконструированы в области представления, обеспечат нам набор предсказуемых точек общности для объединения данных всего предприятия.

Требуется унификация?

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

Но на многих предприятиях присутствует сильное желание внедрить единую разметку данных, поступающих из разнородных источников. Если эта система должна определять структуру хранилища данных, на предприятии должны выполняться два условия:

  • большинство топ-менеджеров должны решительно поддерживать общий формат данных;
  • один из топ-менеджеров, по роду деятельности связанный с пользователями (например, вице-президент по маркетингу), должен стать «мотором» инициативы по созданию общей структуры данных.

Архитектор хранилища данных, обладай он хоть тройной энергией и силой убеждения, не сможет единолично создать и провести в жизнь систему общего формата данных на предприятии. Руководство и «агент пользователей» из состава топ-менеджмента должны периодически прокладывать проекту путь в политических дебрях компании, заботясь о том, чтобы все участники выполняли требования по реализации единой системы данных.

Витрина данных — не прерогатива одного подразделения

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

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

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

Унифицированные измерения и факты

Теоретически инициатива по созданию единого формата данных на всем предприятии не зависит от выбранного метода моделирования данных. Но на практике для создания общей схемы данных требуется размерное моделирование, а вот ER-моделирование (entity/relationship — сущность-отношение) не обеспечивает никакой поддержки или стимула для решения этой задачи. Большая ER-модель противоречивых данных, собранных со всего предприятия, так и остается большой моделью несистематизированной информации. Странно, но размерное моделирование иногда обвиняют в сложности, потому что оно вынуждает создавать унифицированные измерения. Да, задача унификации структуры данных на всем предприятии сложна, но она никак не связана с моделью хранения, определяемой выбранным способом моделирования!

При размерном моделировании мир данных делится на два основных типа: измерения и описания контекста этих измерений. Чисто числовые измерения хранятся в таблицах фактов, а описания контекста (обычно текстовые) хранятся в таблицах измерений. В следующей статье этой серии мы разберем технические особенности таблиц фактов и измерений, а пока нам достаточно знать, что все размерные проекты однотипны и даже скучны. Например, если понятие «продукт» существует в различных местах большого предприятия, структура соответствующего ему измерения во всех таких местах, скорее всего, будет аналогичной даже до наведения единообразия в формате данных.

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

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

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

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

Архитектура магистральной шины хранилища данных

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

В архитектуре шины хранилища данных очень простые приложения способны получать из разных источников данных результаты с одинаковыми заголовками строк в наборах ответов, а затем объединять эти наборы по одинаковым заголовкам при помощи процедуры «горизонтального прохода по данным» (drilling across), или «многоходового SQL». Заголовки строк гарантированно относятся к одной области, так как они получены из одной таблицы измерений! Этот, казалось бы, очевидный и тривиальный результат — очень мощная возможность. Согласованность заголовков строк позволяет «разделять и побеждать» общую проблему хранилища данных, обеспечивая создание:

  • распределенных систем;
  • поэтапно развиваемых, адаптивных проектов;
  • высокоэффективных запросов;
  • высокорентабельных аппаратных решений.

Только ли для сильно распределенных систем?

Вы можете спросить, годится ли архитектура шины лишь для сильно распределенных систем. Подход на основе архитектуры шины с ее унифицированными измерениями и фактами никак не связан с задачей централизации! В основе архитектуры шины лежит всего лишь использование единой структуры данных в разнородных источниках данных. В проекте сильно централизованного хранилища данных, которое разрабатывается единой проектной группой и устанавливается на одной физической системе, приходится решать те же проблемы создания и использования «главного набора» общих типов данных. В сущности, даже в очень централизованном хранилище данных разные источники данных представляются как отдельные физические таблицы. Даже в среде, созданной по ER-модели, измерения и описания контекста этих измерений размещаются в разных таблицах. Для выполнения запросов, затрагивающих все эти таблицы, даже в централизованной, созданной по ER-модели среде придется бороться все с теми же проблемами.

«Сухой остаток» преимуществ

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

Архитектура шины также поддерживает автономный режим разработки, при котором слабосвязанные группы, проектирующие витрины данных, совместно создают общую распределенную систему. Таким образом, архитектура магистральной шины — это некий шаблон, позволяющий разным организациям эффективно обмениваться данными, даже если у них есть свои ИТ-отделы, а технологии различаются. На самом деле OLAP и ROLAP могут прекрасно сосуществовать в среде, созданной в архитектуре магистральной шины, ведь им достаточно быть совместимыми в плане заголовков строк при выводе результатов запроса.

Ральф Кимбалл (Ralph Kimball) — соавтор Star Workstation в компании Xerox и учредитель компании Red Brick Systems. Автор трех бестселлеров о технологиях информационных хранилищ, в том числе The Data Warehouse Toolkit (Wiley, 2002). Преподает архитектуру распределенных информационных хранилищ в Kimball University, выполняет оценку проектов крупных информационных хранилищ. Связаться с ним можно через Web-сайт http://www.rkimball.com.