Игра в уверенность

В своей статье «Without Metadata, Content Is Just Bits» («Информация без метаданных — всего лишь набор битов») от 27 ноября 2000 года Стюарт Олсоп (Stewart Alsop), ведущий колонки в журнале Fortune, пишет, что «метаданные (информация об информации) представляют собой самую сложную проблему, с которой сталкиваются технологические отрасли промышленности, пытаясь создать повсеместно распространенные сетевые структуры. Ничто не работает без метаданных — будь то полная интеграция информации в мобильном телефоне, загрузка музыки в цифровом формате для прослушивания дома или онлайновое взаимодействие с брокерской компанией. По мере постепенного переноса взаимодействия между компаниями в Сеть растет важность доступа к метаданным для всех участников — они позволяют компаниям отслеживать сделки и анализировать их успешность. Метаданные — основа учета в Цифровом веке».

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

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

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

Один из способов определить, насколько окупаются затраты на ваши метаданные, — это задать себе следующие вопросы.

1. Полны ли ваши данные?
2. Точны ли они? Возвращают ли одни и те же запросы одинаковые результаты, если они имеют дело с различными наборами данных?
3. Вовремя ли вы получаете нужные данные?
4. Поддерживают ли данные ваши конкретные бизнес-операции?
5. Актуальны ли ваши метаданные?

Если хотя бы на один вопрос вы отвечаете «Не знаю», то ваши метаданные нуждаются в обновлении — это повысит окупаемость затраченных средств.

Обычные и обогащенные метаданные

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

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

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

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

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

Бизнес-правила

Как обычно, первое и наиболее важное условие — обеспечить участие пользователей на самых ранних этапах проекта. Например, недавно при работе над проектом хранилища данных моя группа создала объединенную команду разработки ПО, в которую вошли пользователи и аналитики, ответственные за сбор требований, а также один разработчик, чтобы «уравновесить» их. Этой команде поручили установить бизнес-правила и определения для каждого элемента данных в хранилище данных. Разрабатываемое приложение предназначалось для сбора данных из трех систем: демографической системы, содержащей сведения обо всех потенциальных клиентах; системе поддержки продаж, хранящей информацию об имеющихся клиентах, и системе поставки с данными о предоставленных услугах. Демографическая система представляла собой общегосударственную базу данных, система поддержки продаж использовалась в региональном отделении, а система поставок объединяла сведения из более 200 отделений, разбросанных по всей стране.

Бизнес-правила регулировали следующее:

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

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

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

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

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

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

В этих бизнес-правилах также описывались все процедуры обработки, которые отличались для разных календарных лет (табл. 1). Время от времени бизнес-процессы менялись; например, сведения об услугах, предоставленных до 1995 года, хранились в особом виде.

Таблица 1. Примеры бизнес-правил

Мы разместили эти бизнес-правила в той же базе данных, в которой расположено хранилище данных; пользователи имели доступ к данным и метаданным посредством единого интерфейса.

Обработка статистических данных

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

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

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

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

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

Таблица 2. Пример статистических сведений об обработке данных

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

Использование метаданных

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

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

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

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

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

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

Описанное здесь приложение работы с метаданными можно встроить в инструментальные средства пользовательского интерфейса. В описанном выше проекте мы создали интерфейс с OLAP-системой Business Objects, доступный пользователям по правому щелчку мыши. В другом проекте приложение поддержки обогащенных метаданных было доступно через Web-интерфейс.

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

Карен Казимер-Шокли (Karen Kazimer-Shockley) — старший консультант в компании Systems Management Engineering Inc., расположенной в г. Рестон, штат Вирджиния. За более чем 25 лет практики в сфере ИТ ей довелось работать с мэйнфреймами, мини-ЭВМ, клиент-серверными приложениями и ПО, базирующимся на Web. С ней можно связаться по e-mail: k.kazimer-shockley@att.net.