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

Журнал ВРМ World

Очистка данных: проблемы и актуальные подходы

1. Введение

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




Рисунок 1. Шаги построения Хранилища данных: ETL-процесс

Хранилища данных требуют и одновременно обеспечивают всестороннюю поддержку очистки данных. Они загружают и постоянно обновляют огромные объемы данных из различных источников, поэтому вероятность попадания в них "грязных данных" весьма высока. Более того, Хранилища данных используются для принятия решений, следовательно, чтобы некорректные данные не привели к некорректным выводам, просто жизненно необходимо проводить корректировки таких данных. Например, дублирующаяся или утраченная информация может стать причиной некорректной или неадекватной статистики ("мусор на входе - мусор на выходе "). Ввиду большого спектра возможных несоответствий в данных и большого объема данных их очистка считается одной из самых крупных проблем в технологии Хранилищ данных. В процессе так называемого ETL (извлечения, преобразования, загрузки - extraction, transformation, loading), показанного на Рис. 1, дальнейшее преобразование данных связано с трансляцией схемы/данных и интеграцией, а также с фильтрацией и агрегацией данных, предназначенных для Хранилища данных. Как показано на Рис. 1, вся очистка данных обычно выполняется в отдельной области подготовки данных до загрузки преобразованных данных в Хранилище. Существует множество средств с различной функциональностью, предназначенных для поддержки подобных задач, однако часто достаточно большой объем работы по очистке и преобразованию приходится выполнять вручную или низкоуровневыми программами, трудными для написания и использования.

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

Метод очистки данных должен удовлетворять ряду критериев. Во-первых, он должен выявлять и удалять все основные ошибки и несоответствия, как в отдельных источниках данных, так и при интеграции нескольких источников. Метод должен поддерживаться определенными инструментами, чтобы сократить объемы ручной проверки и программирования, и быть гибким в плане работы с дополнительными источниками. Далее, очистка данных не должна производиться в отрыве от связанных со схемой преобразования данных, выполняемых на основе сложных метаданных. Функции маппирования для очистки и других преобразований данных должны быть определены декларативным образом и подходить для использования в других источниках данных и в обработке запросов. Инфраструктура технологического процесса должна особенно поддерживаться для Хранилищ данных, обеспечивая эффективное и надежное выполнение всех этапов преобразования данных для множества источников и больших наборов данных. Поскольку большая часть исследований касалась трансляции и интеграции схемы, исследовательское сообщество уделяло совсем мало внимания очистке данных. Ряд исследовательских групп занимаются общими проблемами, так или иначе связанными, в том числе, и с очисткой данных - например, специфическими подходами к data mining и преобразованию данных на основании сопоставления схемы. В последнее время ряд исследований коснулись более сложного единого подхода к очистке данных, касающегося ряда аспектов преобразования, специфических операторов и их реализации. В данной статье предлагается обзор проблем в области очистки данных и их решение. Следующий раздел посвящен классификации проблем, раздел 3 рассматривает основные подходы к очистке, использованные в современных средствах и исследовательской литературе. Раздел 4 представляет собой обзор коммерческих средств очистки данных, в том числе и инструментов ETL. Раздел 5 подводит итог изложенному.


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

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




Рисунок 2. Классификация проблем качества данных в источниках данных

2.1. Проблемы отдельных источников данных

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


Область/
Проблема
Загразненные
данные
Причины/
Примечания
Атрибут Недопустимые
значения
bdate=30.13.70 Значения вне
допустимой
области
Запись Нарушенные
логических
связей
age=22,
bdate=12.02.70
Возраст не
соответствует
году
рождения
Тип записи Нарушение
уникальности
emp1=(name="John Smith",
SSN="123456")
emp2=
(name="Peter Miller",
SSN="123456")
Нарушена
уникальность
SSN
(номера
социального
страхования)
Источник Нарушение
целостности
ссылок
emp=
(name="John Smith",
deptno=127)
Не определено
подразделение
127

Таблица 1. Примеры проблем отдельного источника данных на уровне схемы (нарушение ограничения целостности)

Для проблем и уровня схемы и уровня элемента данных можно разделить различные проблемные области: атрибут (поле), запись, тип и источник записи; примеры для различных случаев показаны в Таблицах 1 и 2. Следует заметить, что уникальность ограничений, определенная на уровне схемы, не защищает от дублирования элементов данных, например, если информация по одному и тому же объекту реального окружения вводится дважды, но с различными значениями атрибута (см. пример в Таблице 2).


Область/
Проблема
Загразненные
данные
Причины/
Примечения
Атрибут Утраченные
значения
phone=
9999-999999
Невведенные
значения
(бессмысленные
или
неопределенные)
Орфографические
ошибки
city="Liipzig" Обычно
опечатки,
фонетические
ошибки
Зашифрованные
значения и
абревиатуры
experince="B"
occupation=
"DB Prog."
 
Вложенные
значения
name="J.Smith
12.02.70
New York"
Множество
значений
в одном
атрибуте
(например,
в поле
свободного
формата)
Значения,
не соответсвующие
своим полям
city="Germany"  
Запись Нарушенные
логических
связей
city="Redmond",
zip=77777
Индекс должен
соответствовать
городу
Тип записи Перестановка
слов
name1="J.Smith",
name2="Miller P."
Обычно
втречается
в полях
свободного
формата
Дублирующиеся
записи
emp1=
(name="John Smith",...);
emp2=
(name="J.Smith",...)
В результате
ошибок
при вводе
данных
некое лицо
присутствует
дважды
Противоречивые
записи
emp1=
(name="John Smith",
bdate=12.02.70);
emp2=
(name="J.Smith",
bdate=12.12.70)
Один и тот же
объект реального
окружения
описывается
различными
значениями
Источник Неверные
ссылки
emp=
(name="John Smith",
deptno=17)
Подразделение 17
определено,
но не
соответствует
объекту

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

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

2.2. Проблемы множественных источников данных

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

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

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


Потребитель (источник 1)

ID
потреб
Имя Ул Гор Пол
11 Kristen
Smith
2
Hurley
P1
South
Fork,
MN
48503
0
14 Chrisian
Smith
Hurley
St
2
S
Fork
MN
1

Клиент (источник 2)


кл
Фам Имя Род Адр Тел/
Факс
24 Smith Cristoph F 23
Harley
St,
Chicago
IL,
60633
-2394
333-222-6542/
333-222-6599
493 Smith Kris L. M 2
Hurley
Place,
South
Fork
MN,
48503-5998
444-555-6666

Потребители (объединение целевых данных с очищенными)

Фам Им Род Ул Гор Шт Инд Тел Факс ID
потр

кл
1 Smith Kristen L. F 2
Hurley
Place
South
Fork
MN 48
503-
5998
444-
555-
666
  11 493
2 Smith Christian M 2
Hurley
Place
South
Fork
MN 48
503-
5998
    24  
3 Smith Christoph M 23
Harley
Street
Chicago IL 60
633-
2394
333-
222-
6542
333-
222-
6599
  24

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

Хотя оба источника из примера на Рис. 3 представлены в реляционном формате, однако они отражают конфликты схемы и данных. На уровне схемы существуют конфликты имен (синонимы Потребитель/Клиент, Идентификатор/Номер, Пол/Род) и структурные конфликты (различные представления имен и адресов). На уровне элемента данных можно наблюдать различные представления рода ("0"/"1" против "F"/"M") и вероятно дублирующиеся записи (Кристен Смит). Последнее также позволяет увидеть, что, несмотря на то, что Идентификатор/Номер оба являются идентификторами, характерными для конкретных источников, их содержимое не сравнимо между собой; различные номера (11/493) могут относиться к одному и тому же лицу, а различные лица могут иметь один и тот же номер (24). Решение данных проблем требует одновременно и интеграции схемы и очистки данных; третья таблица демонстрирует возможное решение. Следует отметить, что конфликты схемы необходимо урегулировать в первую очередь, чтобы обеспечить возможность очистки данных, в особенности - выявление дубликатов на основе унифицированного представления имен и адресов и сопоставления значений Род/Пол.

3. Методы очистки данных

В целом, очистка данных включает несколько этапов:

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

  • Определение порядка и правил преобразования данных: В зависимости от числа источников данных, степени их неоднородности и загрязненности данных, они могут требовать достаточно обширного преобразования и очистки. Иногда для отображения источников для общей модели данных используется трансляция схемы; для Хранилищ данных обычно используется реляционное представление. Первые шаги по очистке данных могут скорректировать проблемы отдельных источников данных и подготовить данные для интеграции. Дальнейшие шаги должны быть направлены на интеграцию схемы/данных и устранение проблем множественных элементов, например - дубликатов. Для Хранилищ в процессе работы по определению ETL должны быть определены методы контроля и поток данных, подлежащий преобразованию и очистке (Рис. 1).

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

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

  • Преобразования: выполнение преобразований либо в процессе ETL для загрузки и обновления Хранилища данных, либо при ответе на запросы по множеству источников.

  • Противоток очищенных данных: После того, как ошибки (отдельного источника) удалены, очищенные данные должны заместить загрязненные данные в исходных источниках, чтобы улучшенные данные попали и в унаследованные приложения и в дальнейшем при извлечении не требовали дополнительной очистки. Для Хранилищ данных очищенные данные находятся в области хранения данных (Рис. 1).

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

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

3.1. Анализ данных

Метаданные, отраженные в схемах, обычно недостаточны для достижения качества данных, соответствующего источнику, особенно если ограничений целостности совсем немного. Поэтому для получения реальных (модернизированных) метаданных с характеристиками данных или необычными моделями значений важно анализировать реальные примеры. Такие метаданные облегчают поиск проблем с качеством данных. Более того, они могут эффективно способствовать идентификации соответствий атрибутов между исходными схемами (сопоставления схем) в зависимости от того, какие автоматические преобразования данных производятся. Существует два связанных между собою метода анализа: профилирование данных и data mining. Профайлинг данных ориентирован на примерный анализ отдельных атрибутов. При этом происходит получение такой информации, как тип, длина, спектр значений, дискретные значения данных и их частота, изменение, уникальность, наличие неопределенных значений, типичных строковых моделей (например, для номеров телефонов) и др., что позволяет обеспечить точное представление различных аспектов качества атрибута. Таблица 3 показывает примеры выявления проблем качества данных с помощью метаданных.


Проблемы Метаданные Примеры/пояснения
Недопустимые значения Количество элементов Например, количество элементов(Пол)>2 указывает на проблему
Max, min Max и min не должны выходить за пределы области допустимых значений
Несоответствия, отклонения Несоответствия и отклонения статистических величин не должны превышать пороговых
Орфографические
ошибки
Значения атрибутов Сортировка по значениям часто ставит знаечния с ошибками рядом с правильными
Утраченные значения Неопределенные значения Процент/число неопределенных значений
Значения атрибутов + значения по умолчанию Наличие значения по умолчанию может указывать на отсутствие настоящего значения
Различные представления значений Значения атрибутов Сравнение множества значений атрибутов столбца одной таблицы с тем же множеством для столбца другой таблицы
Дубликаты Количество элементов + уникальность Номер атрибута должен быть равен номеру ряда
Значения атрибутов Сортировка значений числу вхождений; более 1 вхождения означает дубликат.

Таблица 3. Примеры использования модернизированных метаданных для работы с проблемами качества данных

Data mining помогает найти специфические модели данных в больших наборах данных - например, отношения между несколькими атрибутами. Именно на это направлены так называемые описательные модели data mining, включая группировку, обобщение, поиск ассоциаций и последовательностей. При этом могут быть получены ограничения целостности в атрибутах - например, функциональные зависимости или характерные для конкретных приложений бизнес-правила, - которые можно использовать для восполнения утраченных и исправления недопустимых значений, а также для выявления дубликатов записей в источниках данных. Например, правило объединения с высокой вероятностью может предсказать проблемы с качеством данных в элементах данных, нарушающих это правило. Таким образом, 99%-ная вероятность правила "итого=количество*единицу " демонстрирует несоответствие и потребность в более детальном исследовании для 1% записей.

3.2. Определение преобразований данных

Процесс преобразования данных обычно состоит из множества шагов, каждый из которых может выполнять и преобразования уровня схемы и преобразования уровня элемента данных (маппирование). Чтобы обеспечить системе преобразования и очистки данных возможность генерации программного кода для преобразования и тем самым уменьшить объем самопрограммирования, следует описать необходимые преобразования на соответствующем языке, например, поддерживаемом графическим интерфейсом пользователя. Различные средства ETL (см. Раздел 4) содержат такую возможность, поддерживая собственные языки правил. Более общий и гибкий подход заключается в применении стандартного языка запросов SQL для выполнения преобразований данных и использования возможностей расширений языков приложений, в особенности функций, определенных пользователем (UDFs), поддерживаемых в SQL:99. UDFs могут быть реализованы в SQL или на языке программирования общего назначения, содержащем вложенные операторы SQL. Они позволяют реализовывать широкий спектр преобразований данных и поддерживают простое использование различных преобразований и обработки запросов. Более того, их выполнение СУБД может снизить стоимость доступа к данным. И, наконец, UDFs являются частью стандарта SQL:99 и должны (в конечном счете) быть переносимыми на множество других платформ и СУБД.


CREATE VIEW Customer2
(LName, FName, Gender,
Street, City, State, ZIP, CID)
AS SELECT LastNameExtract(Name), FirstNameExtract (Name),
Sex, Street, CityExtract (City), StateExtract (City),
ZIPExtract (City), CID FROM Customer

Рисунок 4. Пример описания шага преобразования

Рис. 4 показывает один из шагов преобразования, определенный в SQL:99. Этот пример связан с Рис. 3 и охватывает часть необходимых преобразований данных, применяющихся к первому источнику. Эти преобразования определяют представление, согласно которому могут выполняться последующие маппирования. Преобразования выполняет изменение схемы, путем добавления новых атрибутов, полученных расщеплением имени и адреса источника. Необходимые извлечения данных достигаются с помощью UDFs (показаны жирным шрифтом). Реализации UDF могут содержать логику очистки, например, для удаления неверного написания наименований городов или восстановления утраченных индексов. UDFs по-прежнему могут предполагать существенные затраты на реализацию и не поддерживать все необходимые преобразования схемы. В особенности простые и часто используемые функции, - такие, как расщепление или слияние атрибутов, - поддерживаются не всегда, поэтому требуют повторной реализации в подходящем для приложения виде (см. специфические функции извлечения на Рис. 4). Более сложные реструктуризации схемы (например, свертывание и развертывание атрибутов) не поддерживаются вообще. Для полной поддержки связанных со схемой преобразований, необходимы расширения языка - такие, как предложение SchemaSQL. Очистка данных на уровне элемента данных может также выиграть от использования специализированных расширений языка - таких, как оператор Match, поддерживающий "приблизительные объединения" (см. ниже). Системная поддержка для таких мощных операторов может существенно упростить программирование преобразований данных.

3.3. Разрешение конфликтов

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

  • Извлечение значений из атрибутов свободного формата (расщепление атрибутов): Атрибуты свободного формата часто содержат множество отдельных значений, подлежащих извлечению для повышения точности представления и поддержки последующих этапов очистки - таких, как сопоставление элементов данных и исключение дубликатов. Типичными примерами являются поля имен и адресов (Таблица 2, Рис. 3, Рис. 4). Необходимые на этом этапе преобразования перераспределяют значения в поле для получения возможности перемещения слов и извлекают значения для расщепленных атрибутов.

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

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

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

В простейшем случае для каждой записи существует идентификационный атрибут или комбинация атрибутов, которую можно использовать для сопоставления записей, например, если различные источники имеют общий первичный ключ или если существуют различные другие общие уникальные атрибуты. Сопоставление элементов данных между различными источниками достигается за счет стандартного объединения по идентифицирующему(им) атрибуту(ам). В случае отдельного набора данных сопоставления могут определяться сортировкой по идентифицирующему атрибуту и проверкой согласованности соседних записей. В обоих случаях эффективная реализация может достигаться даже для больших наборов данных. К сожалению, без общего ключа и при наличии загрязненных данных такие прямые методы часто слишком ограничены. Для определения большинства или даже всех сопоставлений в "нечетком сопоставлении" (приблизительном объединении) необходимо найти сходные записи, основанные на правиле сопоставления, например, декларативно определенные или реализованные с помощью определенных пользователем функций. Например, такое правило может утверждать, что записи по некоторому лицу, скорее всего, согласованы, если согласованы имя и фрагменты. Степень схожести между записями часто измеряется числовыми значениями между 0 и 1, обычно зависящими от характеристик приложения. Например, различные атрибуты в правиле сопоставления могут придавать различное значение общему уровню сходства. Для строковых компонент (например, имени потребителя, наименования компании и др.) могут оказаться полезными точное сопоставление и неявные методы, основанные на групповых символах, частоте знаков, редакторских расстояниях, расстояниях клавиатуры и фонетического сходства (soundex). Общим подходом к сопоставлению текстовых данных является использование общей метрики извлечения информации. WHIRL отражает многообещающее представление этой категории с использованием косинусного расстояния в модели векторного пространства для определения степени сходства между текстовыми элементами.

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

4. Поддержка инструментов

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

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

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

4.1. Средства анализа и модернизации данных

Согласно классификации, данной в разделе 3.1, средства анализа данных могут быть разделены на средства профайлинга данных и средства data mining.

MIGRATIONARCHITECT (Evoke Software) является одним из немногих коммерческих инструментов профайлинга данных. Для каждого атрибута он определяет следующие метаданные: тип данных, длину, множество элементов, дискретные значения и их процентное отношение, минимальные и максимальные значения, утраченные значения и уникальность. MIGRATIONARCHITECT также может помочь в разработке целевой схемы для миграции данных. Средства data mining - такие, как WIZRULE (WizSoft) и DATAMININGSUITE (InformationDiscovery), выводят отношения между атрибутами и их значениями и вычисляют уровень достоверности, отражающий число квалифицирующих рядов. В частности, WIZRULE может отражать три вида правил: математическую формулу, правила if-then (если-то) и правила правописания, отсеивающие неверно написанные имена, - например, "значение Edinburgh 52 раза встречается в поле Потребитель; 2 случая(ев) содержат одинаковые значения". WIZRULE также автоматически указывает на отклонения от набора обнаруженных правил как на возможные ошибки. Средства модернизации данных, например, INTEGRITY (Vality), используют обнаруженные шаблоны и правила для определения и выполнения очищающих преобразований, т.е. модернизируют унаследованные данные. В INTEGRITY элементы данных подвергаются ряду обработок - разбору, типизации, анализу шаблонов и частот. Результатом этих действий является табличное представление содержимого полей, их шаблонов и частот, в зависимости от того, какие шаблоны можно выбрать для стандартизации данных. Для определения очищающих преобразований INTEGRITY предлагает язык с набором операторов для преобразований столбцов (например, перемещения, расщепления, удаления) и рядов. Более полный список поставщиков и инструментов можно найти на соответствующих коммерческих сайтах - Data Warehouse Information Center (www.dwinfocenter.org), Data Management Review (www.dmreview.com), Data Warehousing Institute (www.dw-institute.com) (например, слияние и расщепление). INTEGRITY идентифицирует и консолидирует записи с помощью метода статистического соответствия. При вычислении оценок для упорядочивания соответствий, по которым пользователь отбирает настоящие дубликаты, используются взвешенные коэффициенты.

4.2. Специальные средства очистки

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

  • Очистка специфической области: Имена и адреса записаны в различных источниках и обычно имеют множество элементов. И поиск соответствий для потребителя имеет большое значение для управления отношениями с клиентами. Ряд коммерческих инструментов, - например, IDCENTRIC (FirstLogic), PUREINTEGRATE (Oracle), QUICKADDRESS (QASSystems), REUNION (PitneyBowes) и TRILLIUM (TrilliumSoftware), - предназначены для очистки именно таких данных. Они содержат методы - например, извлечение и преобразования имен и адресов в отдельные стандартные элементы, проверку допустимости названий улиц, городов и индексов, вместе с возможностями сопоставления на основе очищенных данных. Они включают огромную библиотеку предопределенных правил относительно проблем, часто встречающихся в данных такого рода. Например, модуль извлечение TRILLIUM (парсер) и модуль сопоставления содержат свыше 200000 бизнес-правил. Эти инструменты обеспечивают и возможности настройки или расширения библиотеки правил за счет правил, определенных пользователем для собственных специфических случаев.

  • Исключение дубликатов: Примерами средств для выявления и удаления дубликатов являются DATACLEANSER (EDD), MERGE/PURGELIBRARY (Sagent/QMSoftware), MATCHIT (HelpITSystems) и MASTERMERGE (PitneyBowes). Обычно они требуют, чтобы источник данных уже был очищен и подготовлен для согласования. Ими поддерживается несколько подходов к согласованию значений атрибутов; такие средства, как DATACLEANSER и MERGE/PURGE LIBRARY позволяют также интегрировать правила согласования, определенные пользователем.

4.3. Инструменты ETL

Многие коммерческие инструменты поддерживают процесс ETL для Хранилищ данных на комплексном уровне, например, COPYMANAGER (InformationBuilders), DATASTAGE (Informix/Ardent), EXTRACT (ETI), POWERMART (Informatica), DECISIONBASE (CA/Platinum), DATATRANSFORMATIONSERVICE (Microsoft), METASUITE (Minerva/Carleton), SAGENTSOLUTIONPLATFORM (Sagent) и WAREHOUSEADMINISTRATOR (SAS). Для единообразного управления всеми метаданными по источникам данных, целевым схемам, маппированиям, скриптам и т.д. они используют репозиторий на основе СУБД. Схемы и данные извлекаются из оперативных источников данных как через "родной" файл и шлюзы СУБД DBMS, так и через стандартные интерфейсы - например, ODBC и EDA. Преобразовании данных определяются через простой графический интерфейс. Для определения индивидуальных шагов маппирования обычно существует собственный язык правил и комплексная библиотека предопределенных функций преобразования. Эти средства поддерживают и повторное использование существующих преобразованных решений, например, внешних процедур C/C++ с помощью имеющегося в них интерфейса для их интеграции во внутреннюю библиотеку преобразований. Процесс преобразования выполняется либо системой, интерпретирующей специфические преобразования в процессе работы, либо откомпилированным кодом. Все средства на базе системы (например, COPYMANAGER, DECISIONBASE, POWERMART, DATASTAGE, WAREHOUSEADMINISTRATOR), имеют планировщик и поддерживают технологические процессы со сложными зависимостями выполнения между этапами преобразования. Технологический процесс может также помогать работе внешних средств, например - в специфических задачах очистки - например, таких, как очистка имен/адресов или исключение дубликатов.

Средства ETL обычно содержат мало встроенных возможностей очистки, но позволяют пользователю определять функциональность очистки через собственный API. Как правило, анализ данных для автоматического выявления ошибок и несоответствий в данных не поддерживается. Тем не менее, пользователи могут реализовывать такую логику при работе с метаданными и путем определения характеристик содержимого с помощью функций агрегации (sum, count, min, max, median, variance, deviation,…). Поставляемая библиотека преобразований отвечает различным потребностям преобразования и очистки данных - например, конверсию типов данных (в частности - переформатирование данных), строковые функции (например, расщепление, слияние, замена, поиск по подстроке), арифметические, научные и статистические функции и т.д. Извлечение значений из атрибутов свободного формата автоматизировано не полностью, и пользователю приходится определять разделители, разграничивающие фрагменты значений.

Языки правил обычно охватывают конструкции if-then и case, способствующие обработке исключений в значениях данных - например, неверных написаний, аббревиатур, утраченных или зашифрованных значений и значений вне допустимого диапазона. Эти проблемы могут также решаться с помощью функциональных возможностей по выборке данных из таблиц. Поддержка согласования элементов данных обычно ограничена использованием возможностей объединения и нескольких простых строковых функций соответствия, Например, точного или группового соответствия или soundex. Тем не менее, определенные пользователем функции соответствия полей, так же, как и функции корреляции сходства полей, могут программироваться и добавляться во внутреннюю библиотеку преобразований.

5. Выводы

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