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

3. ИНСТРУМЕНТЫ

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

3.1 Инструменты управления репозиторием метаданных

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

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

4. МЕТОДЫ

4.1 Отслеживание происхождения и анализ влияния

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

«как реализовано»» (As Implemented Lineage), и она может отличаться от «происхождения «как спроектировано»» (As Designed Lineage), определяемого спецификациями мэппинга данных, за фиксированными в проектной документации.

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

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

Рисунок 89 содержит простейший пример описания происхождения элемента данных. Расшиф ровывается оно следующим образом: элемент бизнес-данных «Итого сумма заказа», физически реа лизованный как столбец zz_total, зависит от трех других элементов данных, а именно: «Цена за шт.» (столбец yy_unit_cost физической модели), «Налог штата» (yy_tax) и «Заказано (шт.)» (yy_qty).

Заказано (шт.) yy_qty

Рисунок 89. Пример схематического представления происхождения элемента данных

При всей кажущейся доходчивости графических схем отображения происхождения элемен тов данных (наподобие той, что представлена на рис. 89) они бывают понятны далеко не всем биз нес-пользователям, особенно если учесть, что на практике их структура оказывается значительно сложнее, чем в приведенном простом примере. Более высокоуровневые схемы (например, после довательности обработки данных системами — System Lineage) позволяют составлять обобщен ное представление о движении данных на уровне систем или приложений. Многие средства ви зуализации поддерживают функции масштабирования (+/–), позволяющие переходить с уровня просмотра происхождения отдельного элемента на уровень потоков данных между системами, что существенно упрощает понимание происхождения элементов данных в общем контексте ар хитектуры систем. Рисунок 90 содержит пример наглядного представления последовательности обработки данных системами и/или приложениями.

Хранилище

данных

Рисунок 90. Пример схемы потоков данных на уровне систем

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

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

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

Технические аспекты. Начните с систем-источников и выявите всех первичных потребите лей, а затем всех последующих потребителей первого изучаемого набора данных, затем вто рого, третьего и так далее, пока не выявите все системы, которые их обрабатывают или ис пользуют. Пользователи из числа технологов могут почерпнуть много полезного из стратегии раскрытия системного закулисья и получить ответы на различные вопросы об интересующих их данных. Такой подход позволит и техническим, и бизнес-пользователям самостоятельно исследовать происхождение различных элементов данных в масштабах предприятия, получая ответы на вопросы типа «Откуда берется номер карты социального страхования?», и генери ровать отчеты о последствиях гипотетических изменений, например: «Системы, требующие перенастройки в случае изменения разрядности данных в столбце N». Такая стратегия, од нако, при всей ее практической полезности может оказаться весьма сложной в реализации и управлении.

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

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