Объединенное (федеративное) ХД

В наше время уже нет необходимости доказывать, как важно для многофилиальных корпораций наличие согласованной управленческой информации, необходимой для четкого понимания того, как функционирует бизнес. К сожалению, сегодня очень немногим компаниям удалось достичь высокого уровня информационного обеспечения. Во многих организациях сложилась практика реализации многочисленных ХД. Хотя, по определению, существует только одно ХД, а все остальные объекты являются его подмножеством или постепенно развиваемыми витринами данных, не все организации придерживаются этого правила. Таким образом, во многих компаниях существует два, три, десяток и даже более систем ХД. Обычной подход к улучшению информированности о бизнес-операциях - проведение стандартизации "сверху вниз" как структуры отчетности, так и модели данных. Однако с практической точки зрения стандартизация бизнес-структур оказывается для большинства организаций исключительно нецелесообразной - требуется слишком много средств, времени. Кроме того, данный подход может быть просто нереализуем, поскольку в любом бизнесе присутствует чрезвычайно мало простых и однообразных областей, которые не потребовали бы учета местной специфики. Если, например, можно стандартизировать коды валют по всей корпорации, введение полностью стандартизированной линейки продуктов редко оправданно, а в некоторых случаях - даже нежелательно. Поэтому даже если стандартизацию и удалось бы полностью реализовать на практике, необходимость обеспечения согласованности лишала бы филиалы компании возможности приспосабливаться к условиям местного бизнеса и происходящим на нем изменениям. Такая ситуация чревата возникновениями противоречий между центральным офисом и местными отделениями - центральная система неспособна отвечать потребностям пользователей, а сотрудники филиалов не стремятся тщательно проверять качество данных, и поэтому возникает опасность, что данные, отправляемые в головной офис, могут оказаться ошибочными. Выше описанные проблемы могут быть решены на основе подхода, в основе которого лежит создание Федеративного ХД. В соответствии с данным подходом, с помощью иерархии связанных ХД можно обмениваться данными, бизнес моделями и структурами отчетности, благодаря чему можно, с одной стороны, осуществлять общий контроль и предусмотреть определенную степень стандартизации, а, с другой - позволить региональным отделениям сохранить автономность и учесть местную специфику. Система объединенных ХД характеризуется совместным использованием общих информационных точек, устраняя, таким образом, избыточность и гарантируя достоверность информации по всей организации (см. рисунок).

Федеративное ХД состоит из ряда экземпляров ХД, которые функционируют на полуавтономной основе и, как правило, организационно или географически разнесены, однако могут рассматриваться и управляться как одно большое ХД. Поскольку построение федеративного ХД можно осуществлять постепенно - "шаг за шагом", при его создании разумно воспользоваться методом "начинай с малого, планируй в глобальном аспекте". Такой подход существенно снижает риск неудачи при глобальном развертывании системы, поскольку каждое локальное ХД меньше по масштабу, незамедлительно отвечает местным требованиям и может управляться сотрудниками регионального бизнес-подразделения. Каждый из экземпляров ФХД хранит копию базовой бизнес-модели и общие основные данные (common master data), причем каждое ХД более высокого уровня содержит итоговые транзакционные данные более низкого уровня. Общие основные данные - например, схема организационной структуры компании - отправляется «вниз», т.е. из корпоративного (глобального) ХД, а суммарные данные о транзакциях отправляются "верх", т.е. из локального ХД. Таким образом "федерация" ХД может предоставить местным отделениям необходимую гибкость, а также обеспечить общий контроль и согласованность; при этом каждое ХД функционирует независимо от всех других остальных. Данный подход выгоден не только с точки зрения ежедневных операций, но и при процессе внедрения - при построении "федерации" ХД, которые позволяют вносить изменения, предприятия могут начать с одного единственного проекта, а затем построить корпоративную систему, добавляя новые ХД в соответствии с приоритетами бизнеса. Таким образом, возможность настройки используемых ХД с учетом изменений, снимает необходимость заранее устанавливать окончательную архитектуру, другими словами рискованный монолитный проект может быть разбит на многочисленные, менее крупные и рискованные, но более доходные проекты. Достоинства системы объединенных ХД

общая семантика и бизнес-правила.
один набор процессов извлечения и бизнес-правил.
децентрализованные ресурсы и управление.
параллельная разработка.

Недостатки такого архитектурного решения

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

Требования к техническому и программному обеспечению

Аналитические системы всегда предъявляли существенно более высокие, чем традиционные СОД, требования к аппаратному обеспечению и программному обеспечению. И, приступая к построению аналитической системы, следует понимать, что её реализация практически невозможна без разрешения таких вопросов как:

неоднородность программной среды
распределенность
защиты данных от несанкционированного доступа
построения и ведения многоуровневых справочников метаданных
эффективное хранение и обработка очень больших объемов данных

Основополагающим отличием ХД от традиционных СОД является то, что они практически никогда не создаются на пустом месте. И практически всегда, конечное решение будет разнородным (с точки зрения производителей программных средств, принципов построения, операционных систем). Основой ХД являются не внутренние, как в большинстве традиционных СОД, а внешние источники данных. Внешние источники данных - основа ХД - хранилища данных

различного рода ИС,
электронные архивы,
общедоступные и коммерческие электронные каталоги,
справочники,
статистические сборники.

Как правило, сегодня в любой организации реально функционирует множество несвязанных или слабо связанных СОД. В большинстве случаев, они создавались в различное время, различными коллективами разработчиков и реализованы на основе различных программных и аппаратных средств. Таким образом, уже сама основа, на которой будет строиться ХД, чаще всего уже является крайне неоднородной. Добавьте сюда средства выгрузки, транспортировки, реализации целевой БД ХД. Очевидно, что в таких условиях, даже говорить об однородности программных средств чрезвычайно сложно. Поэтому задача построения ХД - это задача построения единой согласовано функционирующей информационной системы, на основе неоднородных программных средств и решений. И уже сам выбор средств реализации ХД становится чрезвычайно сложной задачей. Здесь должно учитываться множество факторов, включая, взаимную совместимость различных программных компонент, легкость их освоения и использования, эффективность функционирования, стабильность и даже формы, уровень и потенциальную перспективность взаимоотношений различных фирм производителей Типичная архитектура ХД представлена на рисунке

Менеджер загрузки (load manager) выполняет операции, связанные с извлечением и загрузкой данных в ХД. Менеджер хранилища (warehouse manager) выполняет операции, связанные с управлением информацией, помещенной в ХД:

анализ непротиворечивости данных;
создание индексов и представлений для базовых таблиц;
денормализация данных (при необходимости);
обобщение данных (при необходимости);
резервное хранение и архивирование

Менеджер запросов (query manager) выполняет операции, связанные с управлением пользовательскими запросами.