Консалтинг и автоматизация в области управления
эффективностью банковского бизнеса

Журнал ВРМ World

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

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

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

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

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

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

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




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

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

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


  Поле Имен Местоположение
ФАЙЛ 1 Mark Di Lorenzo MA93
  Denis E. Mario CT15
  Tom & Mary Roberts IL21
ФАЙЛ 2 Dilorenzo, Mark 6793
  Mario, Denise 0215
  Roberts, Thomas & Mary 8721
ФАЙЛ 3 Marc Dilorenzo ESQ Boston
  Mrs Dennis Mario Hartford
  Mr & Mrs Thomas Roberts Chicago

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


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


ПОЛЕ ИМЕНИ 1 ПОЛЕ ИМЕНИ 2 УЛИЦА
POWELL, KIMBERLY   PO BOX 2345 C/O RAY WHITE
EVANGELICAL METHOD 1ST CHURCH C/O CHELSEY BARTLETT
ENSMINGER, J DAVID D/B/A J D & E INC C/O MRS. ENS 2999 S UNIVERSAL BLVD



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


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


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

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


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


 ПОЛЕ ИМЕНИ УЛИЦА ГОРОД/ШТАТ
Файл 1 GRIFFITH, CARRIE EILEEN 3834 SOUTH V ST FT SMITH, AR
Файл 2 GRIFFITH, CARRIE 3835 (sic) SO V STREET FORT SMITH, AR
Файл 3 GRIFITH (sic), EILEEN 3834 S V STREET FORTSMITH, AA (sic)

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


ИМЯ
WHITE HEN PANTRY 1-9401-1 & 1-9201-1
NABIL ELFAKIFH
WHITE HEN PANTRY
WHEN INC
W A V INC.
WHITE HEN PANTRY, INC
WHP 0-8301-2
АДРЕС
SEE SCHEDULE
DBA WHITE HEN PANTRY 1-8202-8 & 1-7302-5
DBA WHIOTE HEN PANTRY
DBA WHITE HEN PANTRY
DBA WHITE HEN PANTRY
STORE 90-7914-8
WHITE HEN PANTRY 0-8301-2

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




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

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

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

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


ЛИЧНОЕ ИМЯ АДРЕС НОМЕР ТЕЛЕФОНА
ALDEN BAKER 220 OLD CO RD EXT 2-0192
CORMER B&B LOAN # 0122 PO BOX 7075 796=2348
PETEY ELLIS AUTO / 88 CHEV. 25 BOYLSTON ST REVERE MA 555-34563
TICE FARM AS SOLE TRUSTEE ACROSS FROM HIGH SCHOOL FAX 345-2934
PRINCIPAL MUTUAL (#298719) 711 HIGH ST TO 640-7322, 6 RINGS
FRAN & WALLY TIPPIO ET AL 123 MAIN S/O S. LAUN 011.52.16.178430

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


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


ПОЛЕ ИМЕНИ 1
WHITE, CLEO & ASSOCIATES

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


УЛИЦА УЛИЦА ПРОДОЛЖ. 1
555 N MAIN AT CORNER OF 71B AN D LAKE RD
555 N MAIN AT CORNER OF MAIN AND LAKE

ФРАЗЫ ОТНОШЕНИЯ
ITS SUCCESSORS & ASSIGNS OR BENEFICIARY ATIMA AS RECEIVER FOR
ITS SUCC &/OR ASSIGNS ATIMA AS REC FOR
IT> SUCCESSORS & ASSIGNS ATTN
ITS SUCCESSORS & OR ITS ASSIGNS ATTN:
ITS SUCCESSORS & ASSIGNS A T I M A C/O
HIS SUCCESSORS OR ASSIGNS %
&/OR ITS ASSIGNS OR INTERESTS A DIVISION OF
ITS SUCCESSORS &/OR ASSIGNS AS THEIR INTEREST MAY APPEAR 
ITS SUCCESSORS OR ASSIGNS AS THEIR INTEREST MAY APPEAR 
THEIR RESPECTIVE SUCCESSORS &/OR ASSIGNS  
&/OR ITS ASSIGNS ATIMA