Пошаговое внедрение средств управления метаданными IBM Information Server

Всего 10 лет назад рынок предлагал для создания хранилищ данных (ХД) только серверы, СУБД и ограниченный набор инструментов. Разработчикам ХД приходилось самостоятельно разрабатывать средства извлечения и загрузки данных (ETL), средства управления метаданными и нормативно-справочной информацией (НСИ) и многое другое. В настоящее время многие компании предлагают интегрированные средства создания ХД, однако эти инструментальные наборы столь обширны, что иной раз их внедрение представляет собой непростую задачу. Данная статья предлагает пошаговый сценарий внедрения средств управления метаданными IBM Information Server в проектах по созданию ХД на примере типичной нефтедобывающей компании.

Сабир Асадуллаев, исполнительный архитектор SWG IBM EE/A, IBM

Сабир Асадуллаев более 25 лет работает в информационных технологиях. Является специалистом в области проектирования хранилищ данных и ведения корпоративных метаданных. Руководил ИТ проектами в нефтегазовой отрасли, в банковской сфере, на транспорте, в науке и других областях в Европе и в Северной Америке. Обладает опытом организации коллективной разработки программного обеспечения и создания офиса управления проектами (PMO). Работая в IBM c 2006г, подготовил ряд ключевых архитектурных решений для крупнейших клиентов IBM. Окончил физический факультет МГУ (1979), кандидат физ-мат. наук (1986), сертифицированный руководитель проектов (2001), лучший архитектор CEMAAS IBM (2006), сертифицированный архитектор корпоративных решений IBM (2008), исполнительный архитектор (2010). Автор более 30 публикаций в ИТ, астрономии и биологии.



21.09.2009

Описание сценария

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

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

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

В соответствии с выявленными проблемами были сформулированы следующие бизнес – цели:

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

Текущая логическая топология

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

Информационные системы дочерних организаций реализованы на различных платформах и находятся вне рассмотрения данной работы. Отраслевые информационные системы основаны, в основном, на SAP R/3. Отраслевые хранилища данных разработаны на платформе SAP BW. Информационные системы центрального офиса (ЦО) разработаны с применением технологий Oracle. Витрины данных в настоящее время работают поверх информационных систем центрального офиса и используют SAP BW. В качестве платформы для корпоративного хранилища данных принята DB2.

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

В центре Рис. 1 расположена централизованная часть ИТ инфраструктуры Компании. Она включает в себя несколько отраслевых хранилищ данных на платформе SAP/BW и информационные системы центрального офиса на базе СУБД Oracle. Исторически сложилось так, эти две группы используют различные средства и методы сбора данных, поэтому данные, хранимые в этих системах, несогласованны друг с другом. В результате отчеты, создаваемые OLAP-системами не обеспечивают единого понимания атрибутов (показателей) отчетов.

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


Архитектура системы управления метаданными

Существуют три основных архитектурных шаблона для системы управления метаданными: двухточечный шаблон, двухточечный с единой метамоделью и «звезда» 1 .

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

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

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

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

Рис. 1. Текущая логическая топология
Рис. 1. Текущая логическая топология

Архитектура среды управления метаданными

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

Источники метаданных – это все информационные системы – источники данных, которые включены в корпоративную систему управления метаданными.

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

Средства управления метаданными обеспечивают определение прав, ответственности и управляемости.

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


Архитектура репозитория метаданных

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

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

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

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

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

Таблица 1. Сравнение архитектур репозиториев метаданных

Архитектура

Централизованная

Распределенная

Децентрализованная

Метамодель

Единственная, единая и единообразная

Единственная, единая и единообразная

Множественные, разнообразные, несовместимые модели

Глобальный репозиторий

Полный набор метаданных

Подмножество глобальных метаданных

Ссылки на метаданные в локальных репозиториях

Локальный репозиторий

Нет локальных репозиторив

Метаданные локальных систем

Собственные метамодели, метаданные и их организация

Управление метаданными

Консолидированное

Обработка централизованная, доступ локальный

Обработка и доступ в локальном репозитории

Доставка метаданных

Корпоративная

Корпоративная

Фрагментированная

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


Целевая логическая топология

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

  1. Планируется создание корпоративного хранилища данных и использование IBM Information Server в качестве средства извлечения, преобразования и загрузки данных (ETL). Эта задача находится вне рамок текущей работы.
  2. Второе, наиболее важное изменение – это централизованное управление метаданными, которое позволить установить в Компании единый бизнес-язык для всех систем, эксплуатируемых в центральном офисе. Поэтому на клиентской стороне требуется только программа-клиент метаданных.
Рис. 2. Текущая логическая топология
Рис. 2. Текущая логическая топология

Две фазы расширенного жизненного цикла метаданных

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

Жизненный цикл с точки зрения пошагового внедрения удобно разделить на две фазы:

  1. Фаза «Проектирование метаданных»: анализ и понимание, разработка, преобразование, публикация.
  2. Фаза «Производство метаданных»: потребление, владение, управление качеством, управление метаданными, отчетность и аудит.

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


Фаза «Проектирование метаданных»

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

  • Бизнес-аналитик осуществляет картирование потоков данных и готовит исходную классификацию.
  • Эксперт предметной области должен разработать бизнес классификацию.
  • Аналитик данных выполняет анализ систем.

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

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

Коллективное создание и управление  бизнес – словарем, поддержку бизнес контекста для ИТ активов, разработка потоков извлечения, трансформации и доставки данных обеспечивается на этапе Разработка.

  • ИТ разработчик создает логику обработки,  преобразования и перемещения.

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

  • ИТ разработчик готовит задания на преобразования и перемещение данных, которые исполняются системой.

Унифицированный механизм размещения метаданных и оповещения об обновлениях вступает в работу на этапе Публикация.

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

Фаза «Производство метаданных»

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

  • Бизнес – пользователи получают возможность использования метаданных

Права доступа к метаданным определяются на этапе Владение.

  • Стюард метаданных определяет права использования метаданных

Задачи выверки разнородных данных в рамках интеграционных процессов, повышения качества информационных активов, мониторинга качества входных данных и позволяет устранять проблемы со структурами данных и их пригодностью до того, как они повлияют на проект, решаются на этапе Управление качеством метаданных.

  • Руководитель проекта проводит   анализ воздействия изменений
  • Бизнес-аналитик выявляет противоречия в метаданных
  • Эксперт предметной области обновляет бизнес классификацию
  • Аналитик данных устраняет противоречия между метаданными и классификацией
  • ИТ разработчик управляет ресурсами данных
  • Стюард метаданных поддерживает единое понимания смысла метаданных
  • Бизнес – пользователи в свое работе неизбежно выявляют рассогласование метаданных

Управление доступом к шаблонам, отчетам и результатам; управление метаданными,  навигацией и запросами по метамодели; определение прав, ответственности и управляемостиисполняются на этапе Управление метаданными.

  • Руководитель проекта должен назначить стюардов и распределить ответственность между членами команды.

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

  • Стюард метаданных осуществляет проведение аудита и подготовку отчетов

Результаты аудита могут быть использованы для анализа и понимания на следующем витке жизненного цикла.


Роли и взаимодействия на фазе проектирования метаданных

С помощью редактора картирования, входящего в состав FastTrack, бизнес-аналитик создает спецификации картирования (сопоставления, отображения) потоков от источников к потребителям информации (Рис.4). Каждое картирование может содержать несколько источников и несколько потребителей. Спецификации картирования используются для документирования бизнес - требований.

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

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

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

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

Аналитики данных и архитекторы могут вызывать Rational Data Architect для проектированы баз данных, в том числе, федеративных, которые могут взаимодействовать с DataStage и другими компонентами Information Server. Rational Data Architect анализ данных на основе исследования и анализа метаданных. Аналитики данных могут выявлять, моделировать, визуализировать и связывать разнородные активы данных, и могут создавать физические модели с нуля, из логических моделей с помощью преобразования, или с помощью обратного проектирования эксплуатируемых баз данных.

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

FastTrack интегрирован в IBM Information Server так, что спецификации, метаданные и задания становятся доступны всем участникам проекта, которые используют Information Server, Information Analyzer, DataStage Server и Business Glossary.

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

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

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

Рис. 4. Роли и взаимодействия на фазе жизненного цикла «Проектирование метаданных»
Рис. 4. Роли и взаимодействия на фазе жизненного цикла «Проектирование метаданных»

ИТ - разработчик привлекает Information Services Director как основу для размещения интеграционных задач в качестве согласованных и многократно используемых сервисов. Затем ИТ - разработчик может использовать сервис - ориентированные задания управления метаданными для интеграции корпоративных приложений, для управления бизнес – процессами, вместе с корпоративной интеграционной шиной и серверами приложений.

Бизнес-пользователи нуждаются в доступе к метаданным «только на чтение», и их потребности покрываются двумя инструментами: Business Glossary Browser и Business Glossary Anywhere.


Роли и взаимодействия на фазе производства метаданных

ИТ - специалисты, ответственные за управление изменениями, например, руководитель проекта, с помощью Metadata Workbench может анализировать воздействие изменений на информационную среду (Рис.5).

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

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

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

Аналитик данных устраняет противоречия между глоссарием и таблицами и столбцами баз данных с помощью Business Glossary и Rational Data Architect

Metadata Workbench предоставляет ИТ – разработчикам средства просмотра, анализа и обогащения метаданных. Таким образом, ИТ – разработчики могут использовать средства проектирования, встроенные в Metadata Workbench для управления и понимания информационных активов, созданных и доступных посредством IBM Information Server

Бизнес - пользователи, ответственные за соблюдение законодательных требований (таких, как акт Сарбейн-Оксли или Базель-II), имеют возможность отслеживать происхождение данных с помощью соответствующих инструментов Metadata Workbench.

Стюарды могут использовать Information Analyzer для поддержки единого понимания смысла данных всеми пользователями и участниками проекта.

Стюарды могут привлекать Metadata Workbench для управления метаданными, хранящимися в IBM Information Server.

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

Рис. 5. Роли и взаимодействия на фазе жизненного цикла «Производство метаданных»
Рис. 5. Роли и взаимодействия на фазе жизненного цикла «Производство метаданных»

Путь внедрения – 1. Проектирование.

Итак, мы имеем два пути внедрения метаданных:

  • Первый путь: Проектирование метаданных,
  • Второй путь: Производство.

Эти два маршрута начинаются в одной исходной точке. На Рис. 6 представлен путь внедрения метаданных, который связан, в основном, с первой частью жизненного цикла метаданных – «Проектирование». Имеются в виду этапы Анализ и проектирования, Моделирование, Разработка, Преобразование, Публикация и Потребление.

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

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

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

В качестве четвертого шага мы можем добавить Business Glossary для создания бизнес - классификации.

С тем, чтобы разработать логические и физические модели на пятом шаге может быть добавлен Rational Data Architect. Шестой шаг – это расширенное использование установленного ранее Information Analyzer для создания правил выверки данных.

На седьмом шаге мы планируем расширенное использование FastTrack для программирования сквозной обработки информации от источников до систем назначения. На седьмом шаге можно установить QualityStage и DataStage для разработки и выполнения процедур преобразования данных.

Для размещения интеграционных заданий как сервисов на девятом шаге следует добавить Information Services Director. На последнем, десятом шаге, необходимо дать пользователям права доступа к метаданным, и для этого следует добавить Business Glossary Browser and Business Glossary Anywhere.

См. рисунок 6 в более крупном масштабе.

Рис. 6. Путь внедрения метаданных на этапах жизненного цикла «Проектирование метаданных»
Рис. 6. Путь внедрения метаданных на этапах жизненного цикла «Проектирование метаданных»

Путь внедрения – 2. Производство.

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

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

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

Следующий шаг «Расширенное использование Business Glossary» должен быть выполнен как можно раньше для того, чтобы назначить стюардов, ответственных за метаданные. Для выполнения анализа воздействия изменений необходимо добавить Metadata Workbench.

Расширенное использование продуктов FastTrack и QualityStage позволяет выявить противоречия между словарем и столбцами баз данных. Расширенное использование Rational Data Architect поможет устранить выявленные противоречия между глоссарием и столбцами баз данных. Применение программного пакета Metadata Workbench способствует пониманию и управлению информационными активами.

С помощью Business Glossary пользователи могут обновлять бизнес – классификацию в соответствии с новыми требованиями. Для подготовки отчетов о выявленных рассогласованиях метаданных и других недостатков, желательно использовать Metadata Workbench.

Information Analyzer следует использовать для поддержки единого понимания смысла метаданных. Для поддержки метаданных и подготовки отчетов о состоянии метаданных могут быть использованы и Metadata Workbench и Web Console.

См. рисунок 7 в более крупном масштабе.

Рис. 7. Путь внедрения метаданных на этапах жизненного цикла «Производство метаданных»
Рис. 7. Путь внедрения метаданных на этапах жизненного цикла «Производство метаданных»

Заключение.

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

Пошаговое внедрение средств управления метаданными IBM Information Server снижает сроки и трудоемкость реализации проекта, позволяет бизнес – пользователем раньше воспользоваться преимущества управления метаданными, и повышает вероятность успешного внедрения среды управления метаданными.

Эта работа выполнена в рамках инициативы plusOne. Автор выражает благодарность Anshu Kak за приглашение в проект plusOne и поддержку.


Литература.

1 Poole J., Chang D., Tolbert D, Mellor D. Common Warehouse Metamodel: An Introduction to the Standard for Data Warehouse Integration, Wiley, 2003.

2 Marco D., Jennings M. Universal Meta Data Models, Wiley, 2004.

3 Асадуллаев C. “Управление метаданными средствами IBM Information Server”, 2008

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=430008
ArticleTitle=Пошаговое внедрение средств управления метаданными IBM Information Server
publish-date=09212009