Пять основных "загрязнителей" унаследованных данных, порождающих проблемы при перемещении данных в Хранилище

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

Пять препятствий на пути перемещения данных

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

1. Недостаток унаследованных стандартов: Множество форматов в разрозненных файлах с данными.
2. Неявность данных: Унаследованная информация "плавает"в полях свободного формата и скрыта от пользователей.
3. Близорукость наследования: Обилие идентификаторов блокирует создание объединенного представления.
4. Кошмары отклонений: Усложнение приведения данных в соответствие и их объединения.
5. Сюрпризы в отдельных полях унаследованных данных: Значения данных, не согласующиеся с описаниями полей и бизнес-правилами.

• Отсутствуют общие клиентские ключи записей и файлов.
• В одном поле содержится множество имен.
• В двух полях содержится одно имя.
• В одном и том же поле содержатся и имя и адрес.
• Перемешаны личное имя и наименование компании.
• Различные адреса для одного и того же клиента.
• Hазличные имена и написания имен для одного и того же клиента.
• "Помехи" в областях имени и адреса.
• Несоответствующее использование специальных символов.

Если ваши унаследованные данные содержат такие проблемы, как следует переносить информацию в реляционную среду?

Избегая переноса данных "вслепую"

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

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

Пять серьезных проблем с унаследованными данными...

1. Недостаток унаследованных стандартов: Множество форматов в разрозненных файлах с данными.

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

Что касается поля "Имя" - являются ли DENISE MARIO в Файле 2 и DENIS E MARIO в Файле 1 одним и тем же лицом, или "e" в имени Denise просто сместилось вследствие ошибки, изменив таким образом пол? (И как быть в случае, если Denise Mario время от времени предпочитает использовать свое девичье имя - Denise Mathews? Это безусловно осложнит идентификацию вами клиентов. Однако эта проблема соответствия и объединения более подробно рассмотрена в разделе "Кошмар отклонений…").

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

Этот пример отражает регистрационную метку для трастового счета. Чтобы определить, что собой представляет клиент, необходимо извлечь значение информации, скрытое в других полях. К таким "спрятанным сокровищам" относятся такие значения, как: FBO ("В пользу…"),TTE ("Доверенное лицо"), UTA ("Счет, находящийся в доверительном управлении"), c/o ("На попечении…") и DTD ("Датированный…").

"Плавающие области" усложняют выявление и извлечение отношений из текста свободного формата. Например, значение данных, появляющееся в поле Адрес в Строке 1 в одной из записей, в следующей может встретиться в Строке 2 и может быть поделено между Строками 2 и 3 в еще одной записи. Для построения точных консолидированных представлений о ключевых бизнес-объектах и их связи через аккаунты необходимо эффективно перестраивать ссылки на связанные значения до того, как информация будет перекодироваться в ваши реляционные таблицы.

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

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

3. Близорукость наследования: Обилие идентификаторов блокирует создание объединенного представления.
Компания Acme Co. имеет телефоны по трем различным адресам. Однако унаследованные данные содержат три аккаунта под тремя различными номерами. Как ваше предприятие сможет идентифицировать клиента, если номера аккаунтов сужают ваше представление о предмете? Аналогично компании может потребоваться установить отношения бизнес-объекта (например, клиента) с различными направлениями бизнеса. Или может возникнуть необходимость в консолидированном представлении дочерних компаний конкретной фирмы, скажем - United Technologies. Для выявления ее дочерних компаний - Otis Elevator, Pratt & Whitney, Hamilton Standard и Carrier - следует использовать настраиваемую машину соответствия, способную анализировать любые атрибуты записей в поисках соответствующих и родственных объектов.

4. Кошмары отклонений: Усложнение приведения данных в соответствие и их объединения.
Бизнес-объекты могут быть представлены самыми разнообразными способами. Один из клиентов компании Vality Technology привел более сотни различных отклонений в данных своего клиента, корпорации Digital Equipment. Выявление отклонений в миллионе записей и множестве полей - достаточно трудоемкая задача.

Тем не менее, ваша реакция на важные запросы может оказаться неверной при отсутствии целостности объекта. Следует либо связать между собой все "примеры", либо соединить их все в единое представление, определяемое одним единственным набором атрибутов. Если целостность объекта не соблюдается, Digital Equipment Corp. не будет включена в запрос по продажам и потребителям.

В приведенном ниже примере несогласованное использование имен затрудняет объединение. Отклонения в значениях Имен и Адресов только усугубляют проблему.

Отклонения в бизнес-наименованиях: Обычные средства очистки данных, поисковые таблицы и словари имен и адресов бесполезны в деле выявления и объединения отклонений. Например, компания White Hen Pantry сочла невозможным использовать разрозненные данные, которые обычно "распылены" в поле Адреса.

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

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

• Коммерческие наименования смешаны с личными именами.
• Иностранные имена смешаны с местными.
• Различные отношения (например, "На попечении…"), распыленные по адресным полям.
• Поля имен, содержащие непредусмотренные отношения и адресную информацию.
• Указания (например, " на развилке взять влево") в адресных полях.
• Посторонние помехи (например, 8-разрядная строка в 10-значном цифровом поле SSN).
• Адреса, в которых утрачены междугородные коды, введены лишние цифры и проч.
• Урезанная информация.
• Описания компонент, требующие их номеров.
• Использование пробелов, специальных символов и разграничителей полей в несоответствующих местах. Например, иногда поле второго имени содержит адрес. В ряде случаев слова прерываются в конце строки и продолжаются на следующей.
• Присутствие значений "На попечении…" в полях, предназначенных для хранения имени и адреса, и отсутствие достоверных предположений об их местонахождении в последующих записях.
• Имена в адресных полях. Утраченные значения.
• Аббревиатуры.

Еще больше сюрпризов...

Поля личных имен, содержащие бизнес-наименования: Поля улиц и телефонов, содержащие другие проблемные записи:

Является ли "Alden Baker" наименованием предприятия или это личное имя клиента? Неоднозначность толкования затрудняет разделение личных имен и бизнес-наименований.

Бизнес-наименование "Cleo C. White & Associates" ошибочно указано с порядком слов, характерным для личных имен:

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

Автор: По материалам зарубежных сайтов