Крупнейшие компании России внедряют хранилища с середины 90х годов. Предыдущие проекты нельзя назвать неуспешными, так как они решали текущие задачи, в частности, обеспечить руководство компании достоверной непротиворечивой информацией хотя бы по некоторым направлениям деятельности. Однако рост компаний, изменение законодательства и возросшие требования к стратегическому анализу и планированию требуют дальнейшего развития стратегий построения хранилища данных.

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

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

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

Источниками данных для будущего хранилища являются транзакционные базы данных (OLTP), унаследованные системы, файловые хранилища, интранет-сайты, разрозненные локальные аналитические приложения. Прежде всего, необходимо определить, где находятся требуемые данные. Поскольку, как правило, эти данные хранятся в различных форматах, необходимо их привести к единому виду, для чего применяются довольно сложные системы извлечения, преобразования и загрузки (Extract, Transformation, Load -ETL) в хранилище данных.

Эта работа не может быть выполнена без сопутствующего анализа метаданных и НСИ. Более того, практика внедрения хранилищ данных показала ¹, что метаданные, созданные и импортированные из различных источников, фактически управляют всем процессом сбора данных.

Ведение НСИ

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

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

Ведение метаданных

Прототипом системы управления метаданными являлись системы словарей-справочников данных, которые были предназначены для логической централизации сведений об информационных ресурсах предприятия и должны были выполнять функции инструмента управления информационными ресурсами предприятия ².

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

Многие источники содержат в себе элементы метаданных, но практически никогда не несут их полный набор. Результатом является рассогласование в отчетах, предоставляемых разными системами - источниками. Например, в одном отчете объем продукции может исчисляться в рублях, в другом - в штуках, в третьем - в суммарном весовом исчислении. То есть, одно и то же поле "Объем продукции" может содержать в разных отчетах самые разные данные.

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

Связь между данными, НСИ и метаданными

Структура хранилища данных включает три основных уровня информации: детальные, сводные и архивные данные, а также сопровождающие их метаданные ³. В настоящее время стало ясно, что этот список должен быть дополнен нормативно-справочной информацией. Связь между данными, НСИ и метаданными можно наглядно представить в виде треугольника (рис. 1).

Рис. 1. Треугольник взаимных связей между данными, метаданными и НСИ.
 

 

Как видно из рисунка, все взаимосвязи распадаются на три пары:

• данные - метаданные
• данные - НСИ
• метаданные - НСИ

Рассмотрим каждую пару более подробно.

Данные и метаданные

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

Если у вас в руках уже есть необходимая книга, вам не нужна каталожная карточка к книге. Большинство домашних библиотек не имеет каталогов потому, что хозяин хорошо знает свою библиотеку и является ее создателем и пользователем. И библиотекарем, если кто-нибудь посторонний попросит книгу из его библиотеки. Но большая общественная библиотека обойтись без каталога не сможет.

В корпоративных информационных системах все не так просто и очевидно. Несмотря на то, что первые публикации о необходимости создания систем словарей-справочников появились в середине 80-х годов, корпоративные ресурсы все еще проектируются, разрабатываются и эксплуатируются обособленно, без создания единого смыслового пространства. Подобная ситуация в библиотечном деле означала бы, что читатель одной библиотеки даже не смог бы узнать, есть ли необходимая ему книга в другой библиотеке. В 1995г. была опубликована статья ⁴, в которой было указано, что для успешной интеграции данных необходимо организовать и поддерживать поток метаданных. На языке пользователей библиотек это открытие звучит приблизительно так: "Библиотеки должны обмениваться информацией о книгах в едином формате". Сейчас стало ясно, что это требование нуждается в уточнении, так как метаданные порождаются на всех этапах создания и эксплуатации информационных систем.

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

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

Метаданные времени эксплуатации - это операционные метаданные, которые включают в себя статистику использования вычислительных ресурсов, активность пользователей и статистику работы приложений (например, частоту исполнения, количество записей, покомпонентный анализ).

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

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

Данные и НСИ

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

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

Несмотря на то, что коды ОКПО, ИНН, ISBN являются уникальными и в реляционных базах могут быть первичными ключами, на практике зачастую создаются дополнительные локальные кодификаторы.

Метаданные и НСИ

Существуют различные определения и классификации НСИ по источникам, по способу ведения, по классифицируемым данным. Для целей данной работы можно считать, что нормативно-справочная информация включает в себя словари, справочники, классификаторы, кодификаторы, нормативы и идентификаторы.

Классификатор, например, банковский идентификационный код БИК, ведется централизованно внешней организацией (Банком России) и содержит правила формирования кода. Кроме того, классификатор может определять правила использования кода. Так, повторное использование банковских идентификационных кодов участников расчётов разрешается по истечении календарного года после даты их исключения из Справочника БИК РФ, но не ранее выхода на сводный баланс Банка России по расчётам с применением авизо за указанный календарный год. Код БИК не содержит контрольного числа.

В Общероссийском классификаторе управленческой документации (ОКУД) принята иерархическая трехступенчатая классификация: класс форм (первые две цифры), подкласс форм (вторые две цифры), регистрационный номер (следующие три цифры), контрольное число (последняя цифра). Классификатор может содержать правила расчета контрольного числа или алгоритмы проверки кода (ОКПО, ОКУД).

Метаданные в классификаторах - это правила расчета контрольного числа, описание иерархической классификации и правила использования идентификационных кодов.

Идентификатор (ИНН, ISBN) ведется децентрализованно уполномоченными организациями. В отличие от случая классификатора, коды идентификатора обязательно подчиняются правилам расчета контрольного числа. Правила составления идентификатора разрабатываются централизованно и поддерживаются требованиями стандартов или иных распорядительных документов. Основное отличие от классификатора заключается в том, что идентификатор как полный список либо недоступен, либо в нем нет необходимости на этапе проектирования системы. Рабочий список пополняется индивидуальными кодами в процессе эксплуатации системы.

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

Справочник (например, телефонный) ведется сторонней организацией. Нумерация кодов (номеров телефонов) не подчиняется каким-либо правилам.

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

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

Несмотря на внешнее отсутствие правил, кодировка осуществляется в соответствии с замыслом проектировщика и зачастую содержит правила (метаданные) в неявном виде. Например, для проведения расчетов через Новый год в справочник может быть введен повторно месяц январь под 13-м номером.

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

Метаданные для нормативов определяют область их применения, сроки действия и ограничения.

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

Таким образом, НСИ всегда содержит бизнес - метаданные и технические метаданные.

Основная часть технических и бизнес - метаданных создается на этапе "Понимание" жизненного цикла управления метаданными ⁵. Проектные метаданные возникают на этапе разработки и, в меньшей степени, на этапе эксплуатации (например, назначение ответственных за метаданные). Операционные метаданные создаются и накапливаются в процессе эксплуатации системы.

Таблица 1. Виды НСИ

	Примеры	Ведение	Алгоритм проверки	Правила кодирования
Кодификатор	Код месяца	Локальное	Нет	Возможны
Справочник	Телефонные номера	Централизованное	Нет	Возможны
Классификатор	БИК, ОКУД	Централизованное	Нет / Есть	Есть
Идентификатор	ИНН, ISBN	Децентрализованное	Есть	Есть
Норматив	Ставка налогообложения	Регулирующие органы	Нет	Числовое значение
Словарь	Термины	Бизнес-пользователи	Нет	Возможны

Состав корпоративного хранилища данных

Корпоративное хранилище данных (КХД) преобразует данные, метаданные и НСИ из разнородных источников и предоставляет их пользователям аналитических систем как единую версию правды. Под источниками данных обычно понимают транзакционные базы данных, унаследованные системы, файлы различных форматов, а также иные источники, данные из которых должны быть предоставлены пользователям.

В состав КХД входят:

1. средства ETL извлечения, преобразования и загрузки данных в центральное хранилище данных;
2. центральное хранилище данных (ЦХД), предназначенное и оптимизированное для надежного и защищенного хранения данных;
3. витрины данных, обеспечивающие эффективный доступ пользователей к данным, которые хранятся в структурах, оптимальных для решения конкретных задач пользователей.

Центральное хранилище включает в себя, прежде всего, три репозитория:

1. репозиторий нормативно - справочной информации (НСИ);
2. репозиторий данных;
3. репозиторий метаданных.

В рассмотренную схему не входят оперативный склад данных, зоны промежуточного хранения (staging area), средства доставки данных и доступа к ним, приложения и другие компоненты КХД, несущественные для данного уровня детализации.

Рис.2. Состав корпоративного хранилища данных.
 

 

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

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

Пример реализации существующих подходов

В качестве иллюстрации существующих подходов к интеграции данных можно привести статью ⁶ о внедрении системы НСИ в банке. Банк затратил более шести месяцев на реинжиниринг процессов планирования и прогнозирования для управления эффективностью деятельности. Успех внедрения инициативы управления НСИ вице-президент банка объясняет тем, что команда сосредоточилась на решении локальной задачи, избегая "большого взрыва", под которым понимается создание корпоративного хранилища данных. По его мнению, создание корпоративных мастер данных является долгой, сложной и рискованной работой.

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

Внимательное прочтение статьи приводит к следующим выводам. Прежде всего, этот проект не предусматривал интеграцию корпоративных данных и охватывал только реинжиниринг процессов планирования и прогнозирования. Созданный репозиторий данных, по-видимому, является узко тематической витриной, и не способен поддерживать распространенные аналитические методы, например, технологию детализированного (drill-down) анализа.

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

Таким образом, проектная команда внедрила системы ведения метаданными и НСИ для одной специфической области деятельности. Команда сознательно избегала решений уровня предприятия - не было внедрено ни корпоративное хранилище данных, ни системы ведения метаданными или НСИ компании.

Утверждения о практической невозможности внедрения корпоративного хранилища данных опровергаются проектами, ведущимися сотрудниками IBM на регулярной основе.

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

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

Практическая реализация тройной стратегии

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

Известным решением является анализ данных и метаданных в рамках проекта интеграции данных, но без создания систем ведения метаданных и НСИ. Внедрение этих систем обычно рассматриваются как отдельные проекты и исполняются после внедрения хранилища данных (рис.3).

Рис.3. Вариант существующей последовательности действий.
 

 

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

Проекты по интеграции данных, метаданных и НСИ, выполненные последовательно в любом порядке, не могут обеспечить пользователям требуемое качество информации.

Чтобы решить эту задачу при построении хранилища данных, три взаимосвязанных проекта интеграции данных, метаданных и НСИ должны выполняться одновременно (рис.4).

1. Интеграция корпоративных метаданных устанавливает единое понимание смысла данных и метаданных.
2. Интеграция НСИ исключает конфликты в кодировке данных и метаданных.
3. Интеграция данных предоставляет конечным пользователям единую версию правды на основе согласованных метаданных и НСИ

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

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

Рис.4. Предлагаемая последовательность действий.
 

 

На практике существует множество способов, методов и подходов, обеспечивающих успех параллельного скоординированного исполнения трех крупных проектов интеграции данных, метаданных и НСИ.

1. Три проекта желательно (но не обязательно) объединить в единую программу.
2. Необходимо придерживаться одного из всемирных или национальных стандартов в области управления проектами (напр., Guide to Project Management Body of Knowledge или PRINCE2).
3. Следует выбрать соответствующий жизненный цикл разработки (каскадная модель, спиральная, инкрементальная и так далее).
4. Выбрать подходящее окружение (среду)
   • Для хранилища данных (возможно, источники данных, ETL / ELT, репозитории данных, зоны промежуточного хранения, операционные склады данных, прикладные витрины данных, тематические и региональные витрины данных, аналитические средства, генераторы отчетов и другие приложения)
   • Для метаданных (напр., Управляемая среда метаданных с 6 уровнями: уровни источников, интеграции, репозиториев, управления, витрин метаданных и доставки)
   • Для НСИ (как вариант, зона восходящих потоков НСИ, ядро управления НСИ, зона нисходящих потоков НСИ)
5. Выбрать пригодную архитектуру
   • Для хранилища данных (существует около 20 вариантов архитектур хранилищ данных)
   • Для метаданных (централизованная, децентрализованная, распределенная))
   • Для НСИ (реестр, репозиторий или веерная архитектура)
6. Выбрать уместный жизненный цикл
   • Для данных (вариант цикла: понимание, извлечение, преобразование, загрузка, консолидация, архивирование, доставка)
   • Для метаданных (вариант цикла: разработка, публикация, владение, потребление, управление метаданными)
   • Для НСИ (вариант цикла: отождествление, создание, обзор, публикация, обновление, выведение из использования)
7. Выбрать ключевые характеристики
   • Для хранилища данных (зависят от функциональных и нефункциональных требований)
   • Для метаданных (определить типы метаданных и их характеристики)
   • Для НСИ (вариант характеристик: доступ к данным, отождествление ключей, управление записями, управление иерархиями, модель данных, управление данными, технологические операции и безопасность, интероперабльность)

Следует определить набор ролей и специалистов в трех проектах и выбрать рабочие инструменты для каждой роли в команде.

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

Заключение

В настоящее время IBM является единственной компанией, которая предлагает почти полный набор продуктов для осуществления предлагаемой идеи. К ним относятся средства извлечения данных из разнородных источников, средства ведения глоссария метаданных, инструменты проектирования структур данных, средства извлечения и ведения НСИ, современные методологии проектирования среды бизнес - разведки (BI), индустриальные модели данных, а также ПО промежуточного слоя, позволяющее связать компоненты в единую среду информационного обслуживания пользователей.

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

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

• Подробнее о продуктах IBM Rational Software
• Обратиться в "Интерфейс" за дополнительной информацией/по вопросу приобретения продуктов