Грязные данные

A Taxonomy of Dirty Data (2003)

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

Когда находишься в ситуации а с чего начать помогает таксономия грязных данных. Хотя в учебниках и дают список проблем, но он обычно неполный, вот постоянно искал исследования, которые рассматривают эту тему подробней. Попалась работа T.Gschwandtner, J.Gartner, W.Aigner, S.Miksch хотя они ее делали для рассмотрения способов очистки данных связанных с датами и временем но, на мой взгляд, это оказалось исключение, которое потребовало разобраться с правилами поглубже чем в учебниках. По собственному опыту знаю, что сопряжение дат и времени вынос мозга практически в прямом смысле и поэтому и зацепился за исследование этих авторов.

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

Это третья статья из цикла

1. Таксономия форматов времени и дат в неочищенных данных, 2012 г.

2. Очистка данных: проблемы и современные подходы 2000 г.

3. Таксономия грязных данных 2003 г.

4. Проблемы, методы и вызовы комплексной очистки данных 2003 г.

5. Формальное определение проблем качества данных 2005 г.

6. Обзор инструментов качества данных 2005 г.

Sorry, если ссылки не работают, это временно так как пока не залил их на Хабр.

Предисловие

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

1. Введение

Сегодня системы хранения данных становятся ключевым элементом корпоративной инфраструктуры информационных технологий. Корпорации признали ценность имеющихся в их распоряжении данных как важного актива, который может сделать их более конкурентоспособными в сегодняшней динамичной бизнес-среде. Объединяя данные из разрозненных источников данных в центральное хранилище данных, корпорации могут запускать приложения для анализа данных и получать информацию, имеющую стратегическое и тактическое значение для их бизнеса [TechGuide-1, Ballou and Tayi 99, Inmon 99]. Хранилища данных создаются в различных отраслях промышленности, таких как телекоммуникации, финансовые услуги, страхование, розничная торговля, здравоохранение и т.д. Существует множество программных продуктов, которые помогают в создании хранилищ данных [Golfarelli and Rizzi 99, Inmon 96, Kimball et al 98], анализе данных [Berson and Smith 97], интеллектуальном анализе данных [Berry and Linoff 97, Westphal and Blaxton 98] и управлении взаимоотношениями с клиентами (CRM) [Applied Technology 98, First Logic, TechGuide-2, IBM 99].

Эти приложения основаны на использовании бизнес-аналитики, полученной из хранилищ данных или баз данных, и подчеркивают важность высококачественных данных. Качество данных было предметом давних дискуссий [English 99, Wang et al 95], и на рынке есть даже программные продукты, которые помогают очистить грязные данные [Vality, Trillium, Trillium 98, Williams 97]. Однако только сейчас начинает признаваться, что чрезмерная доля данных в большинстве источников данных является грязной. Грубо говоря, грязные данные означают либо отсутствующие данные, либо неправильные данные, либо нестандартные представления одних и тех же данных [Williams 97, Cutter 98]. Прежде чем приложения анализа данных будут применены к каким-либо данным, данные должны быть очищены для удаления или восстановления грязных данных. Кроме того, данные из устаревших источников данных (например, программы COBOL на базе мэйнфреймов) даже не имеют метаданных, описывающих их. Насколько нам известно, не существует всеобъемлющей формальной таксономии грязных данных или метрики качества данных. Без такой таксономии или метрики будет трудно с высокой степенью уверенности определить качество бизнес-аналитики, полученной из хранилищ данных, и качество решений, принимаемых на основе такой бизнес-аналитики.

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

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

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

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

Мы ограничиваем объем статьи следующими допущениями.

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

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

- В этой статье мы рассматриваем только грязные данные, а не метаданные. Один из авторов этой статьи уже представил таксономию семантической неоднородности метаданных, возникающей при интеграции различных, независимо созданных баз данных [Kim and Seo 91, Kim et al 93].

2. Таксономия грязных данных

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

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

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

Как мы покажем в следующем разделе, если мы начнем с разных предпосылок, то получим разные таксономии. Однако набор грязных типов данных в каждой таксономии будет одинаковым. Отметим также, что мы уверены только в том, что наша таксономия может быть примерно на 95% (то есть очень близкой, но не совсем) всеобъемлющей. (Мы объясним причину нашего хеджирования позже в этом разделе.) Однако тот факт, что наша таксономия не может быть на 100% всеобъемлющей, не умаляет ее значимости и полезности. (Это станет ясно в разделе 3.)

Таблица 1: Классификация грязные данные

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

Узел пропущенных данных (1) делится на (1.1) пропущенные данные из-за того, что данные неизвестны или им все равно (когда разрешены нулевые данные), и (1.2) пропущенные данные, несмотря на то, что пропущенный ввод данных (т. е. Нулевые данные) не разрешен. Ясно, что в отношении пустых данных, разрешенных или нет, не может быть третьего дочернего узла. Отсутствующие данные (1.1) известны как Нулевые данные [Дата 2000]. В этом случае нулевые данные не являются грязными данными. Однако, когда данные становятся известными, нулевые данные должны быть заменены известными правильными данными. Если такая замена не выполняется, данные становятся грязными. Примером отсутствующих данных категории (1.1) является отсутствие Руководителя сотрудника (из-за его неизвестности) в записи сотрудника на начальном этапе работы Сотрудника. Примером отсутствующих данных категории (1.2) может быть идентификационный номер Сотрудника, который является обязательным для любого Сотрудника.

Вероятностные характеристики нулевых данных рассматривались в литературе в контексте реляционных баз данных. [Codd 1979] предложил трехзначную логику для решения проблемы неопределенности в отношениях и включения нулей в реляционную алгебру для решения проблемы недостающей информации. [Dey and Sarkar 1996] предложили вероятностную реляционную модель, подход к неопределенности значений данных, основанный на теории вероятностей вместо нулей и трехзначной логики. [Дата 1998] описал системный подход к проблеме недостающей информации, основанный на специальных значениях и двузначной логике вместо нулей и трехзначной логики.

Узел данных (2) делится на две дочерние узлы: неверные данные (а значит непригодными) (2.1) и не-неправильно, но бесполезными данными (2.2). Ясно, что третьего дочернего узла быть не может. Неверные (и поэтому непригодные) данные - это данные, которые отличаются от истинного значения данных в момент обращения к ним. Не-неправильные, но непригодные для использования данные - это данные, которые в некотором смысле не являются неправильными, но могут привести к неправильным результатам в запросе или анализе. Примеры неверных данных включают использование символьной строки в поле, требуемым типом данных которого является целое число, 225 для возраста сотрудника, 25 в качестве возраста Сотрудника, когда в той же записи год рождения Сотрудника вводится как 1980 (то есть истинный возраст Сотрудника равен 20), неправильное написание Президент Клинтон как Персидент Клинтон и т. Д. Примеры не ошибочных, но непригодных для использования данных включают использование названия города Майами без указания его штата (Майами-это город как в штате Флорида, так и в штате Огайо), использование аббревиатуры ste вместо suite, использование различных представлений даты (15 апреля, 4/15, 04/15) и т.д.

Не ошибочные, но непригодные для использования данные (2.2) - это грязные данные, возникающие из-за различий между данными, хранящимися в более чем двух независимых базах данных, или из-за неполной или нестандартной спецификации данных в одной базе данных. Например, зарплата Джона Смита в одной базе данных составляет 40000, а в другой - 20000. Каждая информация может быть верной, так как Джон Смит держит две работы. Однако, когда эти две базы данных будут интегрированы, это вызовет путаницу. Например, также, если адрес компании хранится в записи как ste. 256, но если условие поиска в запросе включает люкс, то запрос не будет соответствовать сохраненной записи. Аналогично, если запрос ищет сохраненные записи с 15 апреля в поле даты с помощью условия поиска 4/15, записи с 15 апреля не будут найдены.

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

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

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

В целом, существует два типа механизмов обеспечения целостности баз данных в современных реляционных системах баз данных. Это заданные пользователем ограничения целостности ((2.1.1.1.1) и (1.2)) [Silberschatz et al 97] и управление транзакциями (2.1.1.1.2) [Traiger et al 82, Gray and Reuter 93]. Заданные пользователем ограничения целостности включают ограничение типа данных (или домена) для каждого поля (2.1.1.1.1.1), ограничение ссылочной целостности (или внешнего ключа-первичного ключа) (2.1.1.1.1.2), ограничение уникальности (2.1.1.1.1.3), триггеры (2.1.1.1.1.4) и ограничение Null-not-allowed (1.2). Отметим, что пользователи (разработчики приложений) должны указать эти ограничения, а системы баз данных автоматически применяют их только после того, как они были указаны. Системы баз данных не могут знать, какие ограничения целостности следует применять, поскольку они не знают семантики данных.

Ограничение типа данных определяет тип данных (и даже длину и точность данных), но не содержание данных, которые могут быть введены в поле. Например, если ограничение типа данных на то, что тип данных поля возраст сотрудника является целочисленным, система баз данных запретит ввод строковых данных в это поле. Однако система баз данных не в состоянии определить, является ли возраст конкретного Сотрудника 26 или 25 лет, или даже является ли 225 допустимым возрастом для Сотрудника. Особым типом данных является тип данных диапазон значений (например, целое число 18..65 для возраста сотрудника), который может быть использован в некоторой степени для управления содержимым данных. Ограничения типа данных, применяемые в современных реляционных системах баз данных, работают со строковыми данными, булевыми данными и непрерывными числовыми данными. Другими словами, поддержка ограничений типа данных для категориальных данных слаба (мы обсудим это вкратце ниже).

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

Большое разнообразие взаимно несогласованных данных (2.1.1.1.1.4) может быть предотвращено с помощью триггеров. Триггер-это правило базовой формы <ЕСЛИ условие, ТО действие>. Условие может быть любым логическим выражением, а действие - любым действием, которое может выполнить система баз данных. Например, триггер (ЕСЛИ Employee.age > 69, ТО удалить сотрудника) приведет к удалению записи сотрудника, когда возраст сотрудника станет больше 69. Триггер-это мощный механизм, который является более общим, чем для обеспечения ограничений целостности данных в отдельных записях. Из-за общности определяемого пользователем действия (и условия) триггер может быть особенно мощным в обеспечении ограничений целостности, охватывающих несколько таблиц/файлов. Например, ЕСЛИ задание сотрудника обновлено до менеджер, ТО вставьте новую запись в таблицу Отдел или обновите поле менеджер в таблице Отдел для Отдела Сотрудника и отправьте электронное письмо с объявлением о повышении всем сотрудникам.

Средства управления транзакциями (2.1.1.1.2) в современных системах реляционных баз данных предотвращают четыре других типа неправильных данных: через контроль параллелизма для предотвращения потерянного обновления (2.1.1.1.2.1), грязного чтения (2.1.1.1.2.2) и неповторимого чтения (2.1.1.1.2.3); и через восстановление для предотвращения потерянной транзакции (2.1.1.1.2.4). Мы отмечаем, что средства управления транзакциями гарантируют, что четыре типа грязных данных не возникнут до тех пор, пока компьютерная система, управляющая этими данными, не будет уничтожена. Это действительно сильная гарантия.

Когда две или более транзакции одновременно читают и обновляют одни и те же данные, могут возникнуть два типа аномалий. Потерянное обновление происходит, когда, например, транзакция T1 считывает количество свободных мест в полете как 1, назначает его клиенту и уменьшает количество доступных мест до 0, в то время как транзакция T2 одновременно считывает те же данные, назначает их другому клиенту и уменьшает количество доступных мест до 0. В этом случае одно из двух обновлений было потеряно. Грязное считывание данных происходит, когда, например, транзакция T1 увеличивает доступное количество мест из-за отмены с 2 до 3, затем транзакция T2 считывает обновленное доступное количество мест и назначает 3 места 3 клиентам, а затем транзакция T1 прерывается (тем самым отменяя первое обновление). В этом случае транзакция T2 считала грязные данные (этот термин используется в контексте управления транзакциями и относится к незафиксированным данным внутри транзакции), записанным транзакцией Tl. Когда транзакция Tl читает количество свободных мест в рейсе и находит его равным 5, а транзакция T2 обновляет количество мест до 10, чтобы отразить отмену бронирования пяти мест. Если транзакция Tl снова считывает количество мест и обнаруживает, что оно равно 10, считывание считается неповторимым. Неповторимые чтения нежелательны, так как различные чтения означают грязные данные (незафиксированные данные), которые могут измениться снова. Потерянная транзакция происходит, когда, например, в транзакции перевода средств дебет в размере 200 долларов производится по сберегательному счету, и до того, как 200 долларов зачисляются на расчетный счет, транзакция или компьютерная система выходят из строя. Если система не сможет должным образом восстановиться после сбоя, 200 долларов со сберегательного счета испарятся. Свойства атомарности и долговечности транзакций, поддерживаемые средствами управления транзакциями (либо в системах реляционных баз данных, либо в мониторах обработки транзакций [Gray and Reuter 93]), гарантируют, что все обновления в рамках транзакции либо фиксируются, либо резервируются как единое целое (atomic), и что после фиксации транзакции последствия являются постоянными (durable).

Неправильные данные, возникающие из-за несоблюдения ограничений целостности, которые не поддерживаются в современных системах реляционных баз данных, но которые теоретически могут быть поддержаны с помощью расширений для современных систем, (2.1.1.2) разветвляются на три дочерних узла. К ним относятся ограничения целостности, которые возможны для категориальных данных (2.1.1.2.1), временных данных (2.1.1.2.2) и пространственных данных (2.1.1.2.3). Это представление хорошо зарекомендовало себя в области базы данных. Несмотря на три десятилетия исследований временных данных (точка времени, интервал времени, иерархия атрибутов времени) [Snodgrass 95, Etzion et al 98] и пространственных данных (точка, линия, полигон) [Ooi 90, Laurini and Thompson 93, Schneider 97], современные системы реляционных баз данных поддерживают только голый минимум возможностей для этих типов данных. Необходимость поддержки категориальных данных (50 штатов США; статус дохода в терминах сверхбогатый, богатый, средний доход, бедный, бедный) в последнее время был усилен из-за ограничений в типах входных данных, которые могут принимать алгоритмы интеллектуального анализа данных [Stokes et al 95, Berry and Linoff 97, Berson and Smith 97].

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

Ограничение временных данных определяет момент времени или интервал времени, в течение которого данные являются действительными (например, зарплата сотрудника, введенная в поле, больше не действительна, когда зарплата сотрудника повышается). Ограничение пространственных данных определяет пространственные отношения, которые должны быть выполнены (например, координаты точек должны объединяться, чтобы получить замкнутый прямоугольник). Пространственное ограничение может включать данные по нескольким полям внутри записи, поскольку координатные данные могут быть заданы в комбинации полей, а не в одном поле. Возможно, что версии объектно-реляционных систем баз данных fiiture [Kim 95, Stonebraker 96] будут обеспечивать собственную поддержку для применения ограничений на временные и пространственные данные, рассматривая их как абстрактные типы данных.

Мы отмечаем, что можно привести доводы в пользу включения того, что мы классифицируем как различные представления несоставных данных (2.2.3.1) и различные представления составных данных (2.2.3.2) в качестве дочерних узлов (2,1.1.2). Если принять точку зрения, что различные представления одних и тех же данных могут быть предотвращены, если стандартное представление задано и принудительно применено как форма ограничения целостности, то эти типы грязных данных могут рассматриваться как неправильные данные. Однако, если принять точку зрения, что даже если будет применено одно стандартное представление, если будет интегрировано более одной базы данных, различия вызовут конфликт, который должен быть разрешен. Тогда эти различные представления одних и тех же данных действительно не являются ошибочными данными, а просто непригодны для использования до тех пор, пока не будет принят единый стандарт и несоответствующие представления не будут приведены в соответствие. Мы придерживаемся последней точки зрения.

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

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

Мы разлагаем (2.1.2.1.1) на три типа неверных данных (2.1.2.1.1.1 - 2.1.2.1.1.3). Хотя мы не смогли придумать дополнительные дочерние узлы, учитывая творческий способ, которым люди могут делать ошибки ввода данных [Vality] и тонкую семантику данных, мы подозреваем, что несколько дополнительных типов неправильных данных могут быть возможны в соответствии с (2.1.2.1.1). Одним из возможных дочерних узлов являются неправильные данные из-за несогласованности данных в нескольких полях. Например, если в поле возраст указано 25 лет, а в поле год рождения - 1980, то, по крайней мере, одно из данных неверно. Неверные данные, связанные с пространственными данными, как мы видели выше, имеют тенденцию попадать в этот тип. Однако из-за существования неправильного типа данных (2.1.1.1.1.4 взаимно несовместимые данные) мы решили не создавать новый дочерний узел (2.1.2.1.1).

Примером ошибочной записи (2.1.2.1.1.1) является 26 лет для возраста сотрудника, а не 25, из-за скользкого пальца. Неверные данные из-за орфографической ошибки (2.1.2.1.1.2) очевидны. Примером посторонних данных (2.1.2.1.1.3) является запись имени и должности (Джон Уильямс, президент и генеральный директор) в поле имя.

Неправильные данные из-за ошибки ввода данных, включающей несколько полей (2.1.2.1.2), разбиваются на два узла: ввод в неправильные поля и неправильные данные производного поля из сохраненных данных. Здесь опять же мы подозреваем, что в соответствии с (2.1.2.1.2) возможны некоторые дополнительные типы неверных данных. Примером записи в неправильные поля (2.1.2.1.2.1) является запись уличного адреса в поле имя. Неправильные данные из-за неправильных данных производного поля (2.1.2.1.2.2) возникают из-за ошибок в вычислении данных для производного поля. Примеры включают неправильный расчет чистого дохода работника путем неправильного расчета налога; и неправильное сочетание адреса улицы, округа, города и штата в неправильном порядке.

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

Не ошибочные, но непригодные данные (2.2) разлагаются на три дочерних узла: непригодные из-за различий между несколькими базами данных (2.2.1), непригодные из-за неоднозначности (2.2.2) и непригодные из-за несоответствия стандартам (2.2.3). Мы не смогли придумать четвертую возможность. Как мы уже отмечали ранее, не-неправильные, но непригодные для использования данные могут рассматриваться как неправильные данные, если такие данные были введены, несмотря на наличие ограничений или политики для принятия единого стандартного представления. Однако если требуется интегрировать более одной независимой базы данных, они становятся непригодными для использования в контексте интегрированной базы данных, даже если каждая из них верна. Можно отметить, что такая же ситуация возникает, если, например, данные были введены в разные базы данных с использованием разных типов данных, различных ограничений целостности, разного количества полей для представления определенных данных (например, домашний адрес сотрудника) и т. Д. Это, конечно, справедливая точка зрения. Однако это вопрос неоднородности на уровне схемы (метаданных) и выходит за рамки данной статьи. Мы отсылаем читателей, заинтересованных в классификации и нейтрализации гетерогенности на уровне схемы, к [Kim and Seo 91, and Kim et al 93].

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

Неоднозначные данные (2.2.2) декомпозируются на два дочерних узла: неоднозначность из-за использования аббревиатуры (2.2.2.1) и неоднозначность из-за неполного контекста (2.2.2.2). Опять же, мы не смогли придумать другой возможности. Примером неоднозначных данных из-за использования аббревиатуры является MS, которая может означать Microsoft, MicroStrategy, Morgan Stanley и т. Д. (как название корпорации). Примеры неоднозначных данных из-за неполного контекста включают вышеупомянутое название города Майами, которое может находиться в штате Флорида или штате Огайо; и омонимы hot (температура) и hot (специя), pool (бильярд) и (бассейн) и т. д. Некоторые омонимы, вероятно, будут вставлены правильно в одно и то же поле (из разных записей) и могут привести к ошибочным ответам на определенные типы запросов.

Непригодные для использования данные из-за несоответствия стандартам (2.2.3) делятся на два дочерних узла: различные представления несоставных данных (2.2.3.1) и различные представления составных данных (2.2.3.2). Третий дочерний узел невозможен.

Отметим, что существуют различные предложения по представлению неполных данных в контексте реляционных баз данных. Один из них-разрешить многозначные атрибуты наряду с расширенной семантикой реляционных операторов [Buckles and Petry 1982]. Другие пытались включить распределения возможностей, нечеткие множества и грубые множества в реляционные базы данных [Zemenkova and Kandel 1985, Galindo et al 2001, Sozat and Yazici 2001]. Недавно было предложено использовать теоретико-информационную коннекционистскую сеть для обнаружения ненадежных данных в реляционной базе данных [Maimon et al 2001].

Различные представления несоставных данных (2.2.3.1) разветвляются на два дочерних узла: один, для которого алгоритмическое преобразование невозможно (2.2.3.1.1), и один, для которого алгоритмическое преобразование возможно (2.2.3.1.2). Третий дочерний узел невозможен. Различные представления несоставных данных, для которых алгоритмические преобразования невозможны (2.2.3.1.1), включают в себя два дочерних узла: использование аббревиатуры (2.2.3.1.1.1) и использование псевдонима/ника (2.2.3.1.1.2). Одно представление может быть сопоставлено со стандартным представлением только с помощью таблицы сопоставления, адресного каталога и т. Д., и для каждого стандартного представления может быть несколько эквивалентных представлений. Примеры аббревиатура (2.2.3.1.1.1) расположена на шоссе за шоссе и СТЭ за люкс. Примерами псевдонимов или прозвищ (2.2.3.1.1.2) являются Mopac, Loop 1 и Highway 1 для одного и того же шоссе в Остине, штат Техас; Президент Клинтон, Билл Клинтон и Уильям Джефферсон Клинтон для одного и того же человека.

Различные представления несоставных данных, для которых возможны алгоритмические преобразования (2.2.3.1.2), включают в себя три дочерних узла: форматы кодирования (2.2.3.1.2.1), представления (2.2.3.1.2.2) и единицы измерения (2.2.3.1.2.3). Мы не смогли придумать другой возможности. Примерами форматов кодирования являются ASCII и EBCDIC; а также мужчина и женщина в поле пола сотрудника в m и f. Примерами представлений являются отрицательное число (-250 или (250)), валюта (-$250, ($250), -250.39, (250.39)), дата (15 апреля, 4/15), время (1:25:30, 85:30), точность (одиночный против двойная точность), дробь (четверть, восьмая) - то есть, по крайней мере, те, которые поддерживаются в электронной таблице Microsoft Excel. Примерами измерений являются дата (в единицах 100 дней), время (в единицах 15 минут), валюта (в единицах тысячи долларов), расстояние (ярд против метра), вес (фунт против килограмма), площадь (квадратные футы против квадратных метров), объем (галлон против литра) и т.д.

Различные представления составных данных (2.2.3.2) разбиваются на два дочерних узла: объединенные данные (2.2.3.2.1) и иерархические данные (2.2.3.2.2). Объединенные составные данные-это данные, состоящие из двух или более элементов, таких как имя человека (имя, отчество, фамилия) или адрес улицы (номер квартиры, номер, улица). Упорядочение между элементами сцепленных данных имеет важное значение. Однако концептуальная иерархия между элементами не подразумевается; то есть фамилия не включает имя, или наоборот. Иерархические составные данные-это в основном сцепленные данные, в которых существует концептуальная иерархия, подразумеваемая среди некоторых элементов данных. Что касается структуры составных данных, то ясно, что третий дочерний узел невозможен.

Отметим, что несоответствие стандартам составных данных может проявляться по-разному. Соответственно, (2.2.3.2.1) и (2.2.3.2.2) разделены на три дочерних узла: сокращенная версия, использование специальных символов и различные порядки. Мы не смогли придумать четвертой возможности. Примером использования сокращенных версий в сцепленных данных является использование имени человека без отчества, например Джон Кеннеди, а не Джон Фицджеральд Кеннеди. Примером использования специальных (разделительных) символов в сцепленных данных является представление телефонного номера (512-249-9759 против 5122499759 против (512) 249-9759). Пример использования различных упорядочений в объединенную данные (Джон Кеннеди и Кеннеди, Джон). Примером использования сокращенных иерархических составных данных является адресная иерархия, уличный адрес-город-штат, а не полная иерархия уличного адреса-город - округ-штат-почтовый индекс. Примером использования специальных символов в иерархических составных данных является (Texas, Williamson, Austin vs. Техас, (Уильямсон), Остин). Примером использования различных порядков для иерархических составных данных является (Texas, Williamson, Austin vs. Остин, Уильямсон, Техас).

3. Таксономия методов работы с с грязными данными

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

Таблица 2. Таксономия работы с грязными данными

Мы отмечаем, что из 33 типов грязных данных конечного уровня, по крайней мере, 25 из них требуют вмешательства эксперта домена сегодня. Из 33 типов грязных данных конечного уровня только 9 могут быть предотвращены автоматически (1.2, 2.1.1.1.1.1-2.1.1.1.1.4 и 2.1.1.1.2.1-2.1.1.1.2.4); и 8 из 9 требуют, чтобы пользователи указывали ограничения (единственным исключением является 2.1.1.1.2.4 предотвращение потерянных транзакций).

Различные коммерческие программные средства для создания хранилищ данных или преобразования данных для многомерного анализа или интеллектуального анализа данных предоставляют несколько способов замены отсутствующих данных (1.1) [SAS 99]. Они обычно позволяют пользователям заменять отсутствующие данные в поле средним значением (среднее арифметическое), медианным значением (50-й процентиль), средним значением (среднее значение диапазона между максимальным и минимальным значениями) и т.д.

Коммерческие инструменты качества данных, такие как Trillium, First Logic и Vality, разрабатывались на протяжении многих лет и оказались весьма полезными при преобразовании имен и адресов в нескольких странах в их стандартные и полные представления с помощью общестрановых каталогов имен и адресов [Vality, First Logic, Trillium]. Например, эти инструменты могут даже обнаруживать и исправлять неправильно введенные уличные адреса. Однако их полезность в значительной степени ограничивается помощью в выявлении ошибочных и нестандартных форм имен и адресов. В нашей таксономии они применимы только к 11 типам грязных данных листового уровня: (2.1.2.1.1.2 - орфография с ошибками), (2.2.2.1 - двусмысленность из-за использования аббревиатуры), (2.2.2.2.2 - двусмысленность из-за неполного контекста), (2.2.3.1.1.1-нестандартное соответствие с использованием аббревиатуры), (2.2.3.1.1.2 - нестандартное соответствие с использованием псевдонимов/псевдонимов), (2.2.3.2.1.1-2.2.3.2.1.3 - объединенные составные данные) и (2.2.3.3.2.1.1).через 2.2.3.2.2.3-иерархические составные данные). Они даже не способны справиться со всеми или большинством ситуаций в любом из этих 11 грязных типов данных.

Пять неправильных типов данных можно предотвратить, установив определенные пользователем ограничения целостности, применяемые системами обработки баз данных и транзакций, как мы показали в предыдущем разделе. Это (1.2 - отсутствующие данные, где Null не допускается), (2.1.1.1.1.1 - неправильный тип данных для поля), (2.1.1.1.1.2 - висячая ссылка, где она не допускается), (2.1.1.1.13 - дублированные данные, где дублирование не допускается) и (2.1.1.1.1.4 - сложные ограничения, применяемые через триггер). Когда эти типы неверных данных вводятся в базу данных, и нет метаданных, описывающих такие ограничения, метод, известный как профилирование данных [Olson], может быть использован для вывода таких ограничений (т. е. метаданных) из данных. Из-за наличия грязных данных или отсутствующих данных профилирование данных может вывести только статистическую вероятность ограничений. Профилирование данных, как правило, требует повторного сканирования всех записей в таблице и занимает много времени. Есть какие-то данные инструменты профилирования на рынке, например, вызывают программного обеспечения [Olson].

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

Ограничения целостности могут быть определены для категориальных, временных и пространственных данных в определяемых пользователем методах для использования в предотвращении или исправлении неправильных типов данных (2.1.1.2.1), (2.1.1.2.2) и (2.1.1.2.3) соответственно. Объектно-ориентированные системы баз данных или объектно-реляционные системы баз данных обеспечивают инфраструктуру для поддержки таких пользовательских методов, но не реляционные системы баз данных.

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

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

4. Влияние грязных данных на интеллектуальный анализ данных

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

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

Неверные числовые данные (10 000 вместо 1000) или неверные строковые данные (Нью-Йорк вместо Нью-Джерси) или отсутствующие данные при использовании без преобразования, вероятно, будут способствовать получению ненадежного результата в зависимости от доли неверных или отсутствующих данных относительно всего набора данных. Неправильные числовые данные или неправильные строковые данные при преобразовании в категориальные данные или числовые данные между 0 и 1 также могут попасть в неправильную категорию или неправильное числовое представление. Недостающие данные, независимо от того, исключаются ли они из расчета или заполняются какими-то репрезентативными данными, также могут способствовать неверному результату. Очевидно, что если доля грязных данных, которые приводят к неправильному преобразованию, или доля отсутствующих данных высока по отношению ко всему набору данных, результаты интеллектуального анализа данных, скорее всего, будут ненадежными. Однако величина ошибки относительно преобразования данных также имеет значение. Например, числовые данные, представляющие зарплату, 75 500 вместо 75 400, при преобразовании в категориальные данные в гранулах 10 000, не повлияют на результат; но 100 000 вместо 10 000 повлияют.

Влияние грязных данных также зависит от алгоритмов интеллектуального анализа данных. Некоторые алгоритмы интеллектуального анализа данных, такие как деревья решений, нейронные сети и байесовские сети, требуют обучения (а также тестирования и оценки). Наличие высокой доли грязных данных в обучающем наборе данных и/или тестовом наборе данных, вероятно, сделает полученную модель менее надежной. Если набор данных не должен быть должным образом очищен перед использованием для обучения и тестирования модели, следует использовать по крайней мере больший набор данных, чтобы уменьшить влияние грязных данных. Известно, что деревья принятия решений восприимчивы к шумам, особенно если они имеют более высокий порядок, чем два (бинарные деревья) [Berry and Linoff 97]. Известно также, что нейронные сети восприимчивы к шумам. Байесовские сети относительно менее чувствительны к шумам, возникающим из-за отсутствия данных, заполняя их с помощью методов выборки и распределения. Некоторые алгоритмы интеллектуального анализа данных, такие как рассуждение на основе памяти (алгоритм K- means) и автоматический кластерный анализ (алгоритм K-средних), требуют формулировки и использования функций расстояния, мер ассоциации и сходства. Функции расстояния и меры ассоциации и сходства вычисляются на основе данных в наборе данных. Если данные, используемые при их вычислении, грязны, они, в свою очередь, ошибочны, и результаты алгоритмов становятся ненадежными.

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

5. Заключительные замечания

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

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

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

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

Acknowledgements

We thank the anonymous referees, Heikki Mannila, Raghu Ramakrishnan, and Jung-Won Lee (Ewha University, Korea) for their helpful comments. Their comments helped to improve the contents of the paper.

References

[Applied Technology 98] The Applied Technology Group, Building a Successful CRM Environment, White Paper, http://www.techguide.com/, The Applied Technology Group, 1998.

[Ballou and Tayi 99] D. Ballou and G.K. Tayi, Enhancing Data Quality in Data Warehouse Environments, Communications of the ACM, vol. 42, no. 1, pp. 73-78, Jan. 1999.

[Berry and Linoff 97] M. Berry and G. Linoff, Data Mining Techniques for Marketing, Sales and Customer Support, John Wiley and Sons, 1997.

[Berson and Smith 97] A. Berson and S. Smith, Data Warehousing, Data Mining, and OLAP (Data Warehousing/Data Management), Computing McGraw-Hill, 1997.

[Buckles and Petry 1982] B. Buckles and E. Petry, A Fuzzy Representation of Data for Relational Databases, Fuzzy Sets and Systems, vol. 7, pp. 213-226, 1982,

[Codd 1979] E.F. Codd, Extending the Database Relational Model to Capture More Meaning, ACM Transaction on Database Systems, vol. 4, no.4, December 1979.

[Cutter 98] Cutter Information Corporation, Data Management Strategies Newsletter on the State of the Data Warehousing Industry, Management Science 31, pp. 150-162, Feb.1998.

[Date 1998] C. Date, Faults and Defaults, (in five parts), in Relational Database Writing 1994- 1997 C.J.Date, H.Darwen, and D.McGoveran (eds), Addison-Wesley, 1998.

[Date 2000] C. Date. An Introduction to Database Systems, 7^th edition, Addison-Wesley, 2000.

[Dey and Sarkar 1996] D.Dey and S.Sarkar, A Probabilistic Relational Model and Algebra, ACM Transactions on Database Systems, vol. 21, no. 3, September, 1996.

[English 99] L. English, Improving Data Warehouse and Business Information Quality-Method for Reducing Costs and Increasing Profits, Wiley & Sons, 1999.

[Etzion et al 98] O. Etzion, S. Jajodia and S. Sripada (Eds.^), Temporal Databases : Research and Practice, Lecture Notes in Computer Science, 1399, Springer Verlag, 1998.

[First Logic] First Logic Inc., Customer Data Quality- Building the Foundation for a One-to-One Customer Relationship, White Paper, http://www.firstlogic.com/.

[Galindo et al 2001] J. Galindo; J. M. Medina, and M. Aranda-Garrido, Fuzzy Division in Fuzzy Relational Databases: An Approach, Fuzzy Sets and Systems, vol. 121, pp. 471 -490, 2001

[Golfarelli and Rizzi 99] M. Golfarelli and S. Rizzi, Designing the Data Warehouse: Key Steps and Crucial Issues, Journal of Computer Science and Information Management, vol.2, no. 3,1999.

[Gray and Reuter 93] J. Gray and A. Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufmann, 1993.

[IBM 99] IBM NUMA-Q, Modeling Customer Relationship, White Paper, http://www.sequent.com/solutions/crm/whitepapers/mcr wp.htmh IBM NUMA-Q,

1999.

[Inmon 96] W.H. Inmon, Building the Data Warehouse, John Wiley & Sons, 1996.

[Inmon 99] W.H. Imnon, Data Warehouse Performance, John Wiley & Sons, 1999.

[Kim and Seo 91] W. Kim, and JY Seo. On Classifying Schematic and Data Heterogeneity in Multidatabase Systems, IEEE Computer, December 1991.

[Kim et al 93] W. Kim, IJ Choi, S. Gala, M. Scheevel. On Resolving Schema Heterogeneity in Multidatabase Systems, Distributed and Parallel Databases, an International Journal, Kluwer Academic Publishers, 1993.

[Kim 95] W. Kim, Modern Database Systems, ACM Press, 1995.

[Kim et al 99] W. Kim, KJ Chae, DS Cho, BJ Choi, M Kim, KH Lee, MJ Lee, SH Lee, SS Park, HS Yong, A Component-Based Knowledge Engineering Architecture, Journal of Object-Oriented Programming, vol.12, no. 6, pp. 40-48, 1999.

[Kimball et al 98] R. Kimball, et al., The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and Deploying Data Warehouses, John Wiley & Sons, 1998.

[Laurini and Thompson 93] R. Lauriniand D. Thompson, Fundamentals of Spatial Information Systems (A.P.I.C. Series, No 37), Academic Press, 1993.

[Maimon et al 2001] O. Maimon, A. Kandel, and M. Last, Information-Theoretic Fuzzy Approach to Data Reliability and Data Mining, Fuzzy Sets and Systems, vol. 117 pp. 183-194, 2001

[Olson] J. Olson, Data Profiling, White Paper, Evoke -- Software Corporation http://www.evokesoft.com/products/ProdWPDP.html.

[Ooi 90] B. Ooi, Efficient Query Processing in Geographic Information Systems, Lecture Notes in Computer Science, Springer-Verlag, 1990.

[SAS 99] SAS Institute Inc., Finding the Solution to Data Mining - a Map of the Features and Components of SAS Enterprise Miner Software version 3, White Paper, http ://www.sas.com, 1999.

[Schneider 97] M. Schneider, Spatial Data Types for Database Systems: Finite Resolution Geometry for Geographic Information Systems, Lecture Notes in Computer Science, 1288, Springer Verlag, 1997.

[Silberschatz et al 97] A. Silberschatz, H. Korth and S. Sudarchan, Database System Concepts, McGraw-Hill, 1997.

[Snodgrass 95] R. Snodgrass (ed), The TSQL2 Temporal Query Language, Kluwer Academic Publishers, 1995.

[Sozat and Yazici 2001] M. I. Sozat and A. Yazici, A Complete Axiomatization for Fuzzy Functional and Multivalued Dependencies in Fuzzy Database Relations, Fuzzy Sets and Systems, vol. 117, pp. 161-181, 2001

[Stokes et al 95] M.E. Stokes, C.S. Davis and G.G. Koch, Categorical Data Analysis Using the SAS System, SAS Institute, Inc., 1995.

[Stonebraker 96] M. Stonebraker, Object-Relational DBMSs: The Next Great Wave, Morgan Kauftnann Publishers, 1996.

[TechGuide-1] The Technology Guide Series, A Practical Guide to Achieving Enterprise Data Quality-Trillium Software, White Paper, http://www.techguide.com/.

[TechGuide-2] The Technology Guide Series, Achieving Business Success through Customer Relationship Management (CRM)-Mosaix, White Paper, http://wwwdechguid.e.com/.

[Traiger et al 82] I. Traiger, J. Gray, C. A. Galtieri and B. Lindsay, Transactions and Consistency in Distributed database systems, ACM Trans, Database Systems, vol. 7, no. 3 pp. 323 - 342, Sep. 1982.

[Trillium] Trillium Software User Manual

[Trillium 98] Trillium Software System, A Practical Guide to Achieving Enterprise Data Quality White Paper, http://www.trilliumsoft.com/, Trillium Software, 1998.

[Vality] Vality Technology Inc., The Five Legacy Data Contaminants You Will Encounter in Your Warehouse Migration White Paper, http://www.valitv.com/.

[Wang et al 95] R. Wang, V. Storey and C. Firth, A Framework for Analysis of Data Quality Research IEEE Transactions on Knowledge and Engineering, vol. 7, no. 4, pp. 623- 640, Aug. 1995.

[Westphal and Blaxton 98] C. Westphal and T. Blaxton, Data Mining Solutions: Methods and Tools for Solving Real-World Problems, John Wiley & Sons, 1998.

[Williams 97] J. Williams, Tools for Traveling Data DBMS, Miller Freeman Inc., June 1997.

[Zemankova and Kandel 1985] M. Zemankova and A. Kandel, Implementing Imprecision in Information Systems, Information Sciences, vol. 37, pp. 107-141,1985

Problems, Methods, and Challenges in Comprehensive Data Cleansing (2003)

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

Когда находишься в ситуации а с чего начать помогает таксономия грязных данных. Хотя в учебниках и дают список проблем, но он обычно неполный, вот постоянно искал исследования, которые рассматривают эту тему подробней. Попалась работа T.Gschwandtner, J.Gartner, W.Aigner, S.Miksch хотя они ее делали для рассмотрения способов очистки данных связанных с датами и временем но, на мой взгляд, это оказалось исключение, которое потребовало разобраться с правилами поглубже чем в учебниках. По собственному опыту знаю, что сопряжение дат и времени вынос мозга практически в прямом смысле и поэтому и зацепился за исследование этих авторов.

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

Это третья статья из цикла

1. Таксономия форматов времени и дат в неочищенных данных, 2012 г.

2. Очистка данных: проблемы и современные подходы 2000 г.

3. Таксономия грязных данных 2003 г.

4. Проблемы, методы и вызовы комплексной очистки данных 2003 г.

5. Формульное определение проблем качества данных 2005 г.

6. Обзор инструментов качества данных 2005 г.

Sorry, если ссылки не работают, это временно так как пока не залил их на Хабр.

Предисловие

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

1. Введение

Применение и использование огромных объемов данных играет все возрастающую роль в современной экономике, государственном управлении и исследованиях. Аномалии и примеси в данных вызывают раздражение и препятствуют их эффективному использованию, блокируя высокопроизводительную обработку и подтверждение результатов и выводов, полученных в результате интерпретации и анализа данных. Это приводит к более высокой стоимости и меньшей выгоде для обработки данных, что, возможно, делает его приложение бесполезным для потребителя. В [Eng00] перечислено несколько проблем, вызванных аномалиями данных, среди прочего, что неверные данные о ценах в розничных базах данных обходятся американским потребителям в 2,5 миллиарда долларов в виде ежегодных завышенных цен. В этом контексте очистка данных с годами вызывает все больший интерес. Мы полагаемся на безошибочные данные и способность использовать их в соответствии с нашими потребностями. Это развертывание включает эффективную интеграцию, применение, интерпретацию и анализ данных для поддержки бизнес-процессов, административных задач, принятия решений и научного обоснования.

Наличие аномалий и примесей в реальных данных хорошо известно. В [Orr98, Red98] их типичные показатели оцениваются в 5%. Это привело к разработке широкого спектра методов, направленных на выявление и устранение их в существующих данных. Мы относим все это к термину очистка данных; другие названия - очистка данных, очистка или согласование. Нет единого описания целей и масштабов комплексной очистки данных. Очистка данных применяется с разным пониманием и потребностями в различных областях обработки и обслуживания данных. Первоначальной целью очистки данных было устранение дубликатов в сборе данных - проблема, возникающая уже в отдельных приложениях базы данных и усугубляющаяся при интеграции данных из разных источников. Поэтому очистка данных часто рассматривается как неотъемлемая часть процесса интеграции данных. Помимо устранения дубликатов, процесс интеграции включает преобразование данных в форму, желаемую предполагаемое приложение и соблюдение доменно-зависимых ограничений на данные.

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

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

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

Структура статьи следующая. В следующем разделе мы мотивируем необходимость очистки данных, описывая различные способы управления данными, возникающие проблемы и вытекающие из них последствия аномалий в данных. В разделе 3 мы более подробно классифицируем аномалии данных. В Разделе 4 определяется наше восприятие очистки данных и указывается набор критериев качества, которые представляют меры для состояния данных - до и после выполнения процесса очистки. Следовательно, эти критерии могут использоваться для измерения необходимости и успеха приложений для очистки данных. В Разделе 5 мы описываем различные этапы очистки данных. В разделе 6 перечислены и кратко описаны методы, используемые при очистке данных. В разделе 7 дается обзор и сравнение существующих проектов очистки данных в соответствии с нашей спецификацией комплексной очистки данных. Раздел 8 описывает существующие проблемы и открытые проблемы в области исследований очистки данных. Мы завершаем раздел 9.

2 Мотивация

Обработка и анализ данных мотивированы разными целями. Данные - это символические представления информации, то есть факты или сущности из мира, представленные символическими значениями. Данные собираются, чтобы сформировать представление об определенной части мира, называемой мини-миром (M) или Вселенной дискурса (UoD) [EN00]. В оставшейся части этой статьи мы рассматриваем элементы данных как кортежи, то есть наборы связанных дискретных значений из конечного набора областей. Каждый кортеж представляет собой сущность из мини-мира, каждое из ее значений в свою очередь представляет одно из свойств сущности, например, людей с их именем свойства, датой рождения, ростом и весом.

Основная цель сбора и обработки данных - выполнение различных задач в (i) администрировании, например, отслеживание сотрудников компании, клиентов нашей компании или объем продаж филиалов нашей компании, (ii) поддержка бизнес-процесс, например, использование списка адресов клиентов для прямой рассылки с целью рекламы новых продуктов, и (iii) анализ и интерпретация для поддержки принятия решений и генерирования новой информации и знаний. Принятие решений в бизнесе и правительстве основано на анализе данных для выявления тенденций и отслеживания событий и инвестиций. Ученые анализируют данные, чтобы получить новую информацию и знания о разделе мира, который они исследуют.

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

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

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

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

Анализ: в исследовании генома функциональная аннотация белков используется для оценки функции не охарактеризованных белков путем сравнения их аминокислотных последовательностей и передачи функциональной аннотации в случае высокого сходства последовательностей. Таким образом, существующие ошибки в аннотациях распространяются на недавно обнаруженный белок. В [Bre99] частота ошибок для функциональной аннотации белков оценивается более чем в 8% при сравнении результатов анализа трех независимых исследовательских групп, аннотирующих протеом Mycoplasma genitalium. С увеличением зависимости от методов автоматического аннотирования из-за большого объема данных можно ожидать, что частота ошибок только возрастет.

3. Аномалии данных

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

3.1 Модель данных

Мы предполагаем существование непустого множества D = {D1, ..., Dm} областей, значениями которых являются последовательности символов из конечного непустого алфавита D. Для каждой области Di, 1 <i <m, существует произвольная грамматика, описывающая синтаксис значений домена. Таким образом, домены представляют собой регулярные языки, то есть слова из ZD, порожденные грамматикой G(Di), называемой форматом домена.

Схема отношения R - это имя и список атрибутов A1, ..., An, обозначенный R(A1, ..., An). Степень #R схемы отношения R - это количество атрибутов n. Каждый атрибут A - это имя роли, которую играет некоторый домен из D, обозначенный dom(A) в схеме отношения. Отношение (или экземпляр отношения) r схемы отношения R представляет собой набор n-кратных кортежей r = {t1, ..., tn}. Каждый ti представляет собой список из n значений ti = <vi1, , Vin>, где каждое значение vj 1 <j <n является элементом dom (Aj). Степень #t кортежа - это количество значений n. Набор значений для атрибута Aj, например r для R (A1,., An), обозначается val(r, Aj).

Схема базы данных S содержит набор реляционных схем {R1,., Rk} и набор ограничений целостности r, которые должны выполняться для каждого экземпляра S = ({R1, ..., Rk}, T). Экземпляр s схемы базы данных - это список экземпляров отношения, обозначенный s = <r1,., Rk>, где каждый экземпляр ri, 1 <i <k, является экземпляром реляционной схемы Ri, удовлетворяющим ограничениям в r . Каждое ограничение целостности y e r - это функция, которая связывает логическое значение с экземпляром s. Экземпляр базы данных s удовлетворяет y, если y(s) = true. Мы называем экземпляр базы данных сбором данных, если схема и ограничения целостности не полностью выполняются программными компонентами, называемыми системой управления базой данных.

3.2. Классификация аномалий данных

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

3.2.1 Синтаксические аномалии

Лексическими ошибками называются несоответствия между структурой элементов данных и заданным форматом. Это тот случай, если количество значений неожиданно низкое / высокое для кортежа t, то есть степень кортежа #t отличается от #R, степени ожидаемой схемы отношения для кортежа. Например, предположим, что данные хранятся в виде таблицы, где каждая строка представляет кортеж, а каждый столбец - атрибут (рисунок 1). Если мы ожидаем, что таблица будет иметь пять столбцов, потому что каждый кортеж имеет пять атрибутов, но некоторые или все строки содержат только четыре столбца, то фактическая структура данных не соответствует указанному формату. Лексически правильные данные могут быть проанализированы в указанную структуру токена, выводимую из реляционной схемы.

Рисунок 1: Таблица данных с лексическими ошибками

Ошибки формата домена определяют ошибки, когда заданное значение атрибута A не соответствует с ожидаемым форматом домена G (dom (A)). Например, атрибут NAME может есть домен, указанный как D *, D *. Учитывая конкретное значение Джон Смит, в то время как это возможно правильное имя, оно не соответствует определенному формату значений домена из-за пропущенная запятая между словами.

Ошибки формата домена определяют ошибки, когда заданное значение атрибута A не соответствует ожидаемому формату домена G (dom (A)). Например, для атрибута NAME может быть указан домен ZD, ZD. Учитывая конкретное значение Джон Смит, хотя это, возможно, правильное имя, оно не удовлетворяет заданному формату значений домена из-за отсутствия запятой между словами.

Лексические ошибки классов аномалий и ошибки формата домена часто подпадают под термин синтаксическая ошибка, поскольку они представляют собой нарушения общего формата.

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

3.2.2 Семантические аномалии

Нарушения ограничения целостности описывают кортежи (или наборы кортежей), которые не удовлетворяют одному или нескольким ограничениям целостности в r. Ограничения целостности используются для описания нашего понимания мини-мира путем ограничения набора допустимых экземпляров. Каждое ограничение - это правило, представляющее знания о предметной области и значениях, разрешенных для представления определенных фактов, например, ВОЗРАСТ> 0.

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

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

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

3.2.3 Аномалии покрытия

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

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

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

4. Очистка данных и качество данных

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

4.1. Качество данных

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

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

Рисунок 2: Иерархия критериев качества данных

4.2. Критерии качества

Критерии качества, определенные для комплексной очистки данных, образуют иерархию. Эта иерархия является результатом разделения критериев качества на более мелкие критерии качества, т. Е. Критерии, используемые в качестве кратчайшего пути для набора критериев качества. На рисунке 2 показана итоговая иерархия критериев, определенных ниже. Для каждого из критериев мы описываем, как оценить показатель качества для данной коллекции данных. Здесь мы предполагаем, что каждый набор состоит только из одного реляционного экземпляра, то есть S = ({R}, F) и, следовательно, s = r. Мы не предполагаем соблюдения ограничений целостности на r, т.е. не каждое ограничение y e r истинно для всех кортежей в r. Набор сущностей в мини-мире обозначен буквой M. На оценку каждого критерия качества влияет одна или несколько аномалий, определенных в разделе 3.2. В таблице 1 мы показываем критерии качества и аномалии, влияющие на них.

Точность в [Nau02] определяется как отношение количества правильных значений в сборе данных к общему количеству значений. Здесь мы используем термин точность по-другому.

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

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

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

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

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

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

Соответствие схеме - это отношение кортежей в r, соответствующих синтаксической структуре, определенной схемой R, и общему количеству кортежей в r. Это включает в себя форматы домена G (dom (Ai)) атрибутов Ai, ... An в R. Некоторые системы не обеспечивают полную синтаксическую структуру, что позволяет использовать кортежи в коллекции, которые не полностью соответствуют формату. Это особенно верно для систем реляционных баз данных, где соблюдение форматов доменов является обязанностью пользователя.

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

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

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

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

Таблица 1. Аномалии данных, влияющие на критерии качества данных

5. Перспективы процесса очистки данных

Комплексная очистка данных определяется как совокупность операций, выполняемых с существующими данными для удаления аномалий и получения сбора данных, являющегося точным и уникальным представлением мини-мира. Это (полу) автоматический процесс операций, выполняемых с данными, которые выполняют, предпочтительно в этом порядке, (i) адаптацию формата для кортежей и значений, (ii) обеспечение соблюдения ограничений целостности, (iii) вывод отсутствующих значений из существующих, (iv) устранение противоречий внутри или между кортежами, (v) слияние и удаление дубликатов и (vi) обнаружение выбросов, т. е. кортежей и значений, имеющих высокий потенциал недействительности. Очистка данных может включать в себя структурное преобразование, то есть преобразование данных в формат, который лучше поддается управлению или лучше подходит для мини-мира. Однако качество схемы не является прямым вопросом очистки данных и, следовательно, не входит в список критериев качества, определенных выше. Более подробно методы очистки данных мы перечислим в разделе 6.

Согласно [MM00, RH01], процесс очистки данных включает три основных этапа (i) аудит данных для определения типов аномалий, снижающих качество данных, (ii) выбор подходящих методов для их автоматического обнаружения и удаления и (iii) ), применяя методы к кортежам в сборе данных. Шаги (ii) и (iii) можно рассматривать как спецификацию и выполнение рабочего процесса очистки данных. Мы добавляем еще одну задачу (iv), этап постобработки или контроля, на котором мы проверяем результаты и выполняем обработку исключений для кортежей, не исправленных в фактическая обработка. На рисунке 3 показаны этапы процесса очистки данных. Спецификация процесса очистки данных и контроль его выполнения осуществляется одним или несколькими экспертами в предметной области, то есть экспертами со знаниями о мини-мире, его закономерностях и особенностях.

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

Рисунок 3: Процесс очистки данных

5.1. Аудит данных

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

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

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

5.2. Спецификация рабочего процесса

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

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

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

В [RD00] после определения рабочего процесса очистки и перед его выполнением определяется следующий шаг - проверка. Здесь проверяется и оценивается правильность и эффективность рабочего процесса. Мы предполагаем, что этот этап проверки является неотъемлемой частью спецификации рабочего процесса.

5.3 Выполнение рабочего процесса

Рабочий процесс очистки данных выполняется после уточнения и проверки правильности. Реализация должна обеспечивать эффективную работу даже с большими наборами данных. Это часто является компромиссом, потому что выполнение операции очистки данных может потребовать значительных вычислительных ресурсов, особенно если требуется полное и 100% полное устранение аномалий. Поэтому нам нужна эвристика, чтобы достичь максимальной точности, сохраняя при этом приемлемую скорость выполнения [GFSSS01b].

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

5.4. Постобработка и контроль

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

6. Методы, используемые для очистки данных

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

6.1. Парсинг

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

Наличие и количество синтаксических ошибок в сборе данных зависит от степени применения схемы в среде, в которой хранятся данные. Если данные содержатся в плоских файлах, существует вероятность лексических ошибок и ошибок домена. В этом случае используется грамматика, полученная из файловой структуры, а строки представляют собой полные кортежи. Ожидается, что данные, управляемые системами управления базами данных, не будут содержать лексических или доменных ошибок. Тем не менее, ошибки формата домена могут существовать для каждого из атрибутов. Грамматика, используемая для синтаксического анализа, - это формат домена G(A). Спецификация форматов предметной области может поддерживаться методами изучения шаблонов, подобными описанным в [RH01]. Они используют примерный набор значений, чтобы определить формат домена. Они также генерируют детектор несоответствия, который используется для обнаружения аномалий.

6.2. Преобразование данных

Преобразование данных предназначено для преобразования данных из заданного формата в формат, ожидаемый приложением [ACMM + 99]. Преобразования влияют на схему кортежей, а также на области их значений. Преобразование схемы часто выполняется одновременно с очисткой данных. Данные из различных источников отображаются в общую схему, которая лучше соответствует потребностям предполагаемого приложения. Корректировку значений необходимо производить только в тех случаях, когда входные данные не соответствуют его схеме, что приводит к сбоям в процессе преобразования. Это делает очистку данных и преобразование схемы дополнительными задачами.

Стандартизация и нормализация - это преобразования на уровне экземпляра, используемые с целью удаления несоответствий в данных. Это включает в себя простые функции преобразования или преобразования значений, а также нормализацию числовых значений, чтобы они лежали в фиксированном интервале, заданном минимальным и максимальным значениями [SS01].

6.3 Обеспечение соблюдения ограничений целостности

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

В [EBRS + 01] показано, что применение ограничений целостности в некоторой степени применимо к очистке данных, но также имеет некоторые ограничения. Основная идея состоит в том, чтобы автоматически идентифицировать из набора ограничений целостности серию модификаций и применять их к сбору данных, чтобы впоследствии коллекция не содержала никаких дальнейших нарушений ограничений целостности. Авторы описывают некоторые ограничения применения этих методов для очистки данных (или согласования данных, как они это называют). Основное ограничение основано на том факте, что методы обеспечения целостности работают с действительными состояниями базы данных и отдельными транзакциями, нарушая некоторые ограничения. При очистке данных у нас есть большой объем данных и нарушений ограничений и, следовательно, большое пространство поиска, соответственно еще больший объем исправлений (потому что мы могли бы сначала восстановить кортеж 1, а затем на основе этого кортежа 2 или наоборот, что привело бы к другим результатам). Кроме того, сгенерированные ремонты в первую очередь сосредоточены на вставке или удаление кортежей вместо исправления отдельных значений для устранения нарушений ограничений. Другая проблема основана на том факте, что существующие подходы используют стратегии для ограничения набора возможных ремонтов. Показано, что эти стратегии устраняют важные ремонты с точки зрения их области применения.

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

6.4. Удаление дубликатов

Существует несколько подходов к удалению дубликатов или связыванию записей, что является частью очистки данных. Каждый предложенный метод обнаружения дублирования требует алгоритма для определения того, являются ли два или более кортежа дублированными представлениями одного и того же объекта. Для эффективного обнаружения дублирования каждый кортеж должен сравниваться с любым другим кортежем с использованием этого метода обнаружения дублирования. В [HS95] разработан быстрый метод (метод отсортированной окрестности) для уменьшения количества требуемых сравнений. Кортежи сортируются по ключу, возможно, созданному из атрибутов отношения, что, как мы надеемся, сближает повторяющиеся кортежи с другими. Затем только кортежи в небольшом окне (плавающем над отношением) сравниваются друг с другом для поиска дубликатов. Идентификация того, являются ли два кортежа дубликатами, выполняется с помощью правил, основанных на знании предметной области. Для повышения точности результаты нескольких проходов обнаружения дубликатов могут быть объединены путем явного вычисления транзитивного замыкания всех обнаруженных попарно повторяющихся кортежей. О том, как объединяются дубликаты, сказано не так много. В [LLLK99] этот подход дополнительно расширен на кортежи с синтаксически структурированными атрибутами, то есть не соответствующими формату домена. Из-за ошибок формата повторяющиеся кортежи могут не располагаться близко друг к другу после сортировки. Следовательно, значения атрибутов токенизируются в лексические единицы, а затем токены сортируются внутри каждого атрибута перед сортировкой всего отношения. Алгоритмы попарного сопоставления кортежей, использованные в большинстве предыдущих работ, были специфичными для приложения. В [ME97] используется независимый от предметной области алгоритм сопоставления, который может использоваться без каких-либо изменений в различных приложениях. Поэтому используется алгоритм расстояния редактирования, основанный на алгоритме Смита-Уотермана [SM81]. В [ACG02] авторы предлагают подход, позволяющий избежать проблем, связанных с методами сортировки. Они полагаются на иерархии измерений, обычно связанные с таблицами измерений в хранилище данных [ACG02]. Это иерархии таблиц, обычно в отношениях 1: n, выраженные отношениями ключ-внешний ключ. Каждый кортеж в 1-отношении связан с набором кортежей в n-отношении. Степень перекрытия между наборами, связанными с двумя кортежами из отношения 1, является мерой совместной встречаемости между ними и может использоваться для обнаружения дубликатов.

6.5. Статистические методы

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

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

Еще одна аномалия, которую обрабатывают статистические методы, - это пропущенные значения. Пропущенные значения обрабатываются на основе заполнения (подстановки) одного или нескольких правдоподобных значений [Win99]. Генерация вменений требует вычислительно-интенсивных алгоритмов увеличения данных, как описано в [Sch97, Tan96].

7. Существующие подходы к очистке данных

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

7.1. AJAX

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

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

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

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

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

7.2. FraQL

FraQL [SCS00, SS01] - еще один декларативный язык, поддерживающий спецификацию процесса очистки данных. Этот язык является расширением SQL на основе объектно-реляционной модели данных. Он поддерживает спецификацию преобразований схемы, а также преобразования данных на уровне экземпляра, то есть стандартизацию и нормализацию значений. Это можно сделать с помощью пользовательских функций. Реализация определяемой пользователем функции должна выполняться в соответствии с требованиями домена в рамках индивидуального процесса очистки данных.

Благодаря расширенным операторам соединения и объединения в сочетании с определяемыми пользователем функциями согласования FraQL поддерживает идентификацию и устранение дубликатов. Подобно SQL, операторы объединения и объединения могут быть уточнены предложением on, указав атрибуты сравнения (для оператора объединения) соответственно. выражение сравнения (для операторов соединения). Операторы объединения и объединения могут применяться с дополнительным условием согласования по, которое обозначает используемую определенную функцию для разрешения противоречий между кортежами, выполняющими предложение сравнения.

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

7.3. Potters Wheel

Potters Wheel [RH01] - это интерактивная система очистки данных, которая объединяет преобразование данных и обнаружение ошибок с использованием интерфейса, подобного электронным таблицам. Эффект от выполненных операций сразу отображается на кортежах, видимых на экране. Обнаружение ошибок для всего сбора данных выполняется автоматически в фоновом режиме. Определен набор операций, называемых преобразованиями, которые поддерживают преобразования общей схемы без явного программирования. Это преобразования значений, которые применяют функцию к каждому значению в столбце, сопоставления один-к-одному, которые представляют собой операции столбца, преобразующие отдельные строки, и сопоставления строк многие-ко-многим, решающие схематические неоднородности, где информация хранится частично в значениях данных, и частично в схеме. Аномалии, устраняемые этим подходом - это синтаксические ошибки и нарушения.

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

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

7.4. ARKTOS

ARKTOS [VVSKS01] - это фреймворк, способный моделировать и выполнять процесс ExtractionTransformation-Load (процесс ETL) для создания хранилища данных. Авторы рассматривают очистку данных как неотъемлемую часть этого процесса ETL, который состоит из отдельных шагов, которые извлекают соответствующие данные из источников, преобразуют их в целевой формат и очищают их, а затем загружают в хранилище данных. Указана метамодель, позволяющая моделировать весь процесс ETL. Отдельные шаги (операции очистки) внутри процесса называются действиями. Каждое действие связано с отношениями ввода и вывода. Логика, выполняемая действием, декларативно описывается SQL-оператором. Каждый оператор связан с определенным типом ошибки и политикой, которая определяет поведение (действие, которое необходимо выполнить) в случае возникновения ошибки.

В рамках процесса ETL, указанного и выполняемого в среде ARKTOS, можно рассматривать шесть типов ошибок. НАРУШЕНИЕ ПЕРВИЧНОГО КЛЮЧА, НАРУШЕНИЕ УНИКАЛЬНОСТИ и НАРУШЕНИЕ ССЛКИ - это особые случаи нарушения ограничений целостности. Тип ошибки NULL EXISTENCE связан с устранением пропущенных значений. Остальные типы ошибок - это DOMAIN MISMATCH и FORMAT MISMATCH, относящиеся к лексическим ошибкам и ошибкам формата домена.

Политики исправления ошибок - просто ИГНОРИРОВАТЬ, но без явной пометки ошибочного кортежа, УДАЛИТЬ, а также ЗАПИСАТЬ В ФАЙЛ и ВСТАВИТЬ В ТАБЛИЦУ с ожидаемой семантикой. Последние два предоставляют единственную возможность взаимодействия с пользователем.

Успех очистки данных можно измерить для каждого действия, выполнив аналогичный оператор SQL, подсчитывая совпадающие / нарушающие кортежи. Авторы определяют два языка для декларативного описания процесса ETL. Это сопровождается графическим построителем сценариев.

7.5. IntelliClean

IntelliClean [LLL00, LLL01] - это основанный на правилах подход к очистке данных с основным упором на устранение дубликатов. Предлагаемая структура состоит из трех этапов. На этапе предварительной обработки устраняются синтаксические ошибки, а значения стандартизируются по формату и последовательности используемых сокращений. Подробно не уточняется, как это делается. Этап обработки представляет собой оценку правил очистки для условных элементов данных, которые определяют действия, которые необходимо предпринять при определенных обстоятельствах. Есть четыре разных класса правил. Правила идентификации дубликатов определяют условия, при которых кортежи классифицируются как дубликаты. Правила слияния / очистки определяют, как следует обрабатывать повторяющиеся кортежи. Не указано, как должно выполняться слияние или как его функциональность может быть объявлена. Если правило слияния / очистки не указано, повторяющиеся кортежи также можно объединить вручную на следующем этапе. Правила обновления определяют способ обновления данных в конкретной ситуации. Это позволяет специфицировать правила применения ограничений целостности. Для каждого ограничения целостности правило обновления определяет, как изменить кортеж, чтобы удовлетворить ограничению. Правила обновления также можно использовать, чтобы указать, как должны быть заполнены отсутствующие значения. Правила предупреждений определяют условия, при которых пользователь получает уведомление о разрешении определенных действий.

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

7.6. Сравнение

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

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

8. Вызовы и открытые проблемы

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

8.1. Исправление ошибок и разрешение конфликтов

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

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

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

8.2. Ведение очищенных данных

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

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

8.3. Очистка данных в виртуально интегрированных средах

Проблемы, упомянутые в предыдущем разделе, усиливаются при выполнении очистки данных в средах с виртуально интегрированными источниками, такими как IBM DiscoveryLink [HSKK + 01]. В таких средах часто невозможно вносить поправки в источники из-за их автономности. Следовательно, очистка данных должна выполняться каждый раз при доступе к данным. Это значительно сокращает время отклика. Путем сбора и управления соответствующими метаданными, такими как очистка происхождения и выполняемых операций в промежуточном программном обеспечении для очистки данных, производительность может быть значительно увеличена. Это также может предотвратить ненужную очистку данных, если данные в источниках не меняются между обращениями к источникам. По-прежнему остается выбор между сбором огромных объемов метаданных и материализацией полного интегрированного сбора данных. Промежуточное ПО должно собирать столько данных, сколько необходимо, но при этом обеспечивать быструю очистку данных.

8.4. Структура очистки данных

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

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

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

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

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

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

9. Заключение

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

Literature

[ACG02] R. Ananthakrishna, S. Chaudhuri, V. Ganti Eliminating Fuzzy Duplicates in Data Warehouses.Proceedings of the 28^th VLDB Conference, Hong Kong, China, 2002

[ACMM+99] S. Abiteboul, S. Cluet, T. Milo, P. Mogilevsky, J, Simeon, S. Zohar Tools for Data Translation and Integration. Bulletin of the Technical Committee on Data Engineering, March 1999, Vol. 22, No. 1, 3-8

[AIS93] R. Agrawal, T. Imielinski, A. Swami Mining Association Rules between Sets of Items in Large Databases.Proceedings of the ACM SIGMOD on Management of Data, 1993, 207-216

[AU79] A.V. Aho, J.D. Ullman Principles of Compiler Design. Addison-Wesley Publishing Company, 1979, ISBN 0-201-00022-9

[Bre99] S. E. Brenner Errors in genome annotation Trends in Genetics, 1999, 15, 4, 132-133

[EBRS+01] S. M. Embury, S. M. Brand, J. S. Robinson, I. Sutherland, F. A. Bisby, W.
A. Gray, A. C. Jones, R. J. White Adapting integrity enforcement techniques for data reconciliation Information Systems, Vol. 26, 2001, 657-68

[EN00] R. Elmasri, S.B. Navathe, Fundamentals of Database Systems. Addison Wesley Pub Co., ISBN 0201542633

[Eng00] L. P. English Plain English on Data Quality: Information Quality Management: The Next Frontier. Published in DM Review in April 2000

[GFSS00] H. Galhardas, D. Florescu, D. Shasha, E. Simon AJAX: An extensible data cleaning tool. Proceedings of the ACM SIGMOD on Management of data, Dallas, TX USA, May 2000

[GFSSSOla] H. Galhardas, D. Florescu, D. Shasha, E. Simon, C.-A. Saita
Improving data cleaning quality using a data lineage facility. Proceedings of the 3rd International Workshop on Design and Management of Data Warehouses, Interlaken, Switzerland, June 2001

[GFSSS01b] H. Galhardas, D. Florescu, D. Shasha, E. Simon, C.-A. Saita Declarative data cleaning: Language, model, and algorithms.Proceedings of the 27th VLDB Conference, Roma, Italy, 2001

[HS95] M. A. Hernandez, S.J. Stolfo The merge/purge problem for large databases. Proceedings of the ACM SIGMOD Conference, 1995

[HSKK+01] L.M. Haas, P.M. Schwarz, P. Kodali, E. Kotlar, J.E. Rice, W.C. Swope DiscoveryLink: A system for integrated access to life sciences data sources. IBM Systems Journal, 2001, Vol. 40, No. 2, 489-511

[LLLK99] Mong Li Lee, Hongjun Lu, Tok Wang Ling, Yee Teng Ko Cleansing data for mining and warehousing. Proceedings of the 10th International Conference on Database and Expert Systems Applications, Florence, Italy, August 1999

[LLL00] Mong Li Lee, Tok Wang Ling, Wai Lup Low IntelliClean: A knowledge-based intelligent data cleaner. Proceedings of the ACM SIGKDD, Boston, USA, 2000

[LLL01] Wai Lup Low, Mong Li Lee and Tok Wang Ling A knowledge-based approach for duplicate elimination in data cleaning Information Systems, Vol. 26, 2001, 585-606

[ME97] A.E. Monge, C.P. Elkan An efficient domain-independent algorithm for detecting approximately duplicate database tuples. Proceedings of the SIGMOD 1997 workshop on data mining and knowledge discovery, 1997

[MM00] J.I. Maletic, A. Marcus Data Cleansing: Beyond Integrity Analysis. Proceedings of the Conference on Information Quality, October 2000

[Mot89] A. Motro Integrity = Validity + Completeness. ACM Transactions on Database Systems (TODS), Vol. 14, No. 4, 1989, 480-502

[MT99] Enric Mayol, Ernest Teniente A Survey of Current Methods for Integrity Constraint Maintenance and View Updating. ER Workshops 1999: 62-73

[Nau02] F. Naumann Quality-Driven Query Answering for Integrated Information Systems Lecture Notes in Computer Science, LNCS 2261, Springer, 2002

[Orr98] K. Orr Data Quality and Systems Theory. Communications of the ACM, Vol. 41, No. 2, 1998, 66-71

[RD00] E. Rahm, Hong Hai Do Data Cleaning: Problems and current approaches. IEEE Bulletin of the Technical Committee on Data Engineering, 2000, 24, 4

[Red98] T. Redman The impact of Poor Data Quality on the Typical Enterprise. Communications of the ACM, Vol. 41, No. 2, 1998, 79-82

[RH01] V. Raman, J.M. Hellerstein Potters Wheel: An Interactive Framework for Data Transformation and Cleaning. Proceedings of the 27th VLDB Conference, Roma, Italy, 2001

[Sch97] J. L. Schafer Analysis of Incomplete Multivariate Data. Chapmann & Hall, London, 199

[SCS00] K. -U. Sattler, S. Conrad, G. Saake Adding Conflict Resolution Features to a Query Language for Database Federations. Proc. 3nd Int. Workshop on Engineering Federated Information Systems, Dublin, Ireland, 2000

[SS01] K.-U. Sattler, E. Schallehn A Data Preparation Framework based on a Multidatabase Language. International Database Engineering Applications Symposium (IDEAS), Grenoble, France, 2001

[SW81] T.F. Smith, M.S. Watermann Identification of common molecular subsequences. Journal of Molecular Biology, Vol. 147, 1981, 195-197

[Tan96] M.A. Tanner Tools for Statistical Inference (third edition). Springer, New York, 1

[Ton00] D. Tonn Data Cleansing Verfahren fur Data Warehouses. Diploma Thesis, Humboldt University Berlin, 2000

[VVSKS01] P. Vassiliadis, Z.a Vagena, S. Skiadopoulos, N. Karayannidis, T. Sellis ARKTOS: towards the modeling, design, control and execution of ETL processes Information Systems, Vol. 26, 2001, 537-561

[Win99] W. E. Winkler State of Statistical Data Editing and Current Research Problems. UN/ECE Work Session on Stat. Data Editing, Rome, Italy, 1999

A survey of data quality tools (2005)

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

Когда находишься в ситуации а с чего начать помогает таксономия грязных данных. Хотя в учебниках и дают список проблем, но он обычно неполный, вот постоянно искал исследования, которые рассматривают эту тему подробней. Попалась работа T.Gschwandtner, J.Gartner, W.Aigner, S.Miksch хотя они ее делали для рассмотрения способов очистки данных связанных с датами и временем но, на мой взгляд, это оказалось исключение, которое потребовало разобраться с правилами поглубже чем в учебниках. По собственному опыту знаю, что сопряжение дат и времени вынос мозга практически в прямом смысле и поэтому и зацепился за исследование этих авторов.

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

Это шестая статья из цикла

1. Таксономия форматов времени и дат в неочищенных данных, 2012 г.

2. Очистка данных: проблемы и современные подходы 2000 г.

3. Таксономия грязных данных 2003 г.

4. Проблемы, методы и вызовы комплексной очистки данных 2003 г.

5. Формальное определение проблем качества данных 2005 г.

6. Обзор инструментов качества данных 2005 г.

Sorry, если ссылки не работают, это временно так как пока не залил их на Хабр.

Предисловие

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

1. Введение

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

Удаление грязных данных в информационных системах обычно называется очисткой данных (также известной как очистка или очистка данных) и направлена на получение данных высокого качества. Это важная задача в различных сценариях применения. В рамках единого источника данных (например, списка клиентов) важно исправить проблемы целостности, стандартизировать значения, заполнить недостающие данные и объединить повторяющиеся вхождения. Построение хранилища данных (DW) [1] требует важного шага, называемого процессом ETL (извлечение, преобразование и загрузка), который отвечает за извлечение информации из рабочих источников данных, преобразование и загрузку ее в схему данных DW. Процессы миграции данных (например, когда прекращается выпуск программного пакета) нацелены на преобразование устаревших данных, хранящихся в источниках с определенной схемой, в целевые источники данных, схема которых отличается и предопределена [2].

В зависимости от контекста, в котором применяется очистка данных, он может быть известен под разными именами. Например, при обнаружении и удалении повторяющихся записей в одном файле происходит процесс связывания записей или удаления дубликатов. В контексте DW процесс ETL включает в себя задачи очистки данных, и некоторые авторы [3] назначают конкретное хранилище данных, называемое промежуточной областью данных в архитектуре DW, для сбора промежуточных результатов преобразований очистки данных. В этой статье мы называем процесс качества данных последовательностью преобразований данных (часто моделируемой в виде графика [4]), которые должны применяться к данным с проблемами, чтобы получить данные хорошего качества. Инструменты качества данных - это программные артефакты, которые участвуют в этом процессе.

Современные технологии пытаются решить проблемы качества данных тремя различными способами: (i) специальные программы, написанные на языке программирования, таком как C или Java, или на проприетарном языке системы управления реляционными базами данных (RDBMS), таком как Oracle PL / SQL [5] ; (ii) механизмы РСУБД для обеспечения ограничений целостности; или (в) сценариях преобразования данных с использованием инструмента качества данных. Использование языка общего назначения или собственного языка РСУБД затрудняет поддержку и оптимизацию программ контроля качества данных. Механизмы, поддерживаемые СУБД, обеспечивают соблюдение ограничений целостности, но не решают значительное количество проблем, которые влияют на содержимое записей данных (например, несогласованность данных, ошибки данных). Существует обширный рынок инструментов для поддержки преобразования данных для загрузки в хранилище данных, так называемых инструментов ETL, которые также предоставляют некоторые функции очистки данных. Другие инструменты качества данных были разработаны с нуля для решения конкретных проблем качества данных, таких как стандартизация адресов и сопоставление имен.

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

Работа организована следующим образом. В разделе 2 представлена таксономия проблем качества данных. В разделе 3 обобщены общие функции всех проанализированных инструментов качества данных. В разделе 4 мы сгруппировали инструменты по шести категориям. Затем в Разделе 5 описывается, как проблемы качества данных решаются с помощью инструментов качества данных. Наконец, мы завершаем раздел 6.

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

Представленная здесь таксономия проблем с данными основана на четырех соответствующих работах, найденных в литературе [6, 7, 8, 9]. Мы разделяем проблемы качества данных на проблемы с данными на уровне схемы и на уровне экземпляра. Проблем с данными на уровне схемы можно избежать с помощью улучшенного дизайна схемы, которые не зависят от фактического содержимого данных. Проблемы с данными на уровне экземпляра связаны с содержимым данных, и их нельзя избежать с помощью лучшего определения схемы, поскольку языки определения схемы недостаточно мощны, чтобы указать все требуемые ограничения данных. В нашей таксономии проблемы с данными на уровне экземпляра включают в себя все проблемы с данными, которые не являются проблемами данных на уровне схемы, поэтому на этом таксономия завершена.

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

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

2.1.1 Поддерживается СУБД

Во время проектирования базы данных можно определить ограничения целостности, чтобы указать условия, которым должны удовлетворять объекты базы данных [10]. SQL: 1999 [11] поддерживает язык, обеспечивающий следующие декларативные ограничения целостности: (i) ограничение not null, чтобы столбец не принимал нулевое значение; (это) ограничение по умолчанию для указания значения по умолчанию для данного столбца; (in) ограничение уникальности, определяющее, что столбец или набор столбцов должны иметь уникальные значения в таблице; (iv) ограничение первичного ключа, которое соответствует уникальным и не нулевым ограничениям; (v) ограничение ссылочной целостности для определения атрибутов, значения которых должны совпадать со значениями первичного или уникального ключа сторонней таблицы; (vi) проверка ограничения для определения определяемого пользователем условия; (vii) ограничение домена для определения значений домена с ограничениями; (viii) ограничение утверждения определяет ограничение целостности, не зависящее от таблицы. SQL: 1999 также позволяет процедурное определение ограничений целостности с помощью триггеров, то есть процедур, вызываемых СУБД в ответ на определенные события базы данных.

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

- Отсутствующие данные: данные, которые не были заполнены. Ограничение not null может избежать этой проблемы.

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

- Неверное значение данных: нарушение ограничения диапазона данных. Если возраст сотрудника должен находиться в диапазоне [18, 65], то возраст 15 лет является неверным значением данных. Чтобы избежать этой проблемы, используются ограничения проверки и домена.

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

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

- Ограничения домена: записи или значения атрибутов, которые нарушают ограничение домена (например, зависимости атрибутов или заранее определенное максимальное количество строк). Ограничения домена и утверждения предназначены для того, чтобы избежать этой проблемы. Однако эти функции не предоставляются большинством СУБД (например, Oracle 9i), которые решают эту проблему с данными с помощью триггеров.

2.1.2 Не поддерживается СУБД

Следующие проблемы качества данных не могут быть обработаны ограничениями целостности СУБД:

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

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

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

- Конфликты имен: одно и то же имя поля используется для разных объектов (омонимы) или разные имена используются для одного и того же объекта (синонимы).

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

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

2.2 Проблемы качества данных на уровне записи

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

2.2.1 Одиночная запись

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

- Отсутствующие данные в ненулевом поле: атрибут заполняется каким-то '' фиктивным '' значением. Например, номер социального страхования -999999 - это неопределенное значение, используемое для преодоления ограничения Ненулевое значение.

- Ошибочные данные: данные действительны, но не соответствуют реальному объекту. Примером ошибочных данных является 31 год для возраста сотрудника, когда ей на самом деле 30 лет.

- Орфографические ошибки: слова с ошибками в полях базы данных (например, Джон Стивенс вместо Джон Стивенс).

- Встроенные значения: наличие посторонних данных в некотором поле данных. Распространенным примером встроенных значений является вставка заголовка в поле имени (например, Президент Джон Стивенс).

- Ошибочные значения: данные хранятся в неправильном поле. Например, рассмотрим значение Португалия в атрибуте города.

- Неоднозначные данные: данные, которые можно интерпретировать более чем одним способом с разными значениями. Неоднозначные данные могут возникнуть из-за наличия аббревиатуры или неполного контекста, а именно:

- Аббревиатура: Сокращенное наименование Дж. Стивенс можно расширить по-разному, например: Джон Стивенс, Джек Стивенс, Джефф Стивенси т. Д.

- Неполный контекст: название города Майами может означать штат Флорида или штат Огайо.

2.2.2 Несколько записей

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

- Повторяющиеся записи: записи, относящиеся к одному и тому же реальному объекту и не содержащие противоречивой информации. Следующие записи сотрудников считаются дубликатами: Empl (имя = Джон Стивенс, адрес = 23, First Avenue, New York City, дата рождения = 01.01.1975); Emp2 (Имя = Дж. Стивенс, адрес = 23, 1-я авеню, Нью-Йорк, дата рождения = 01.01.1975).

- Противоречивые записи: записи, которые остаются в силе. для одного и того же реального объекта и содержат некоторую противоречивую информацию. Снова рассмотрим Empl и Emp2, но со следующей информацией: Empl (Name = John Стивенс "Адрес =" 23, Первая авеню, Нью-Йорк ", дата рождения = 01.01.1975); Emp2 (Имя = Джон Стивенс, адрес = 23, Первая авеню, Нью-Йорк, дата рождения = 01.01.1965).

- Нестандартизированные данные: разные записи не используют одинаковые представления данных, что делает их сравнение недействительным.

- Перестановка слов: в одном поле слова могут появляться в разном порядке. Например, в именах Джон Стивенс и Смит, Джек не используется одно и то же правило упорядочивания.

- Формат кодирования: использование различных форматов кодирования, например, ASCII, UTF-8.

- Формат представления: разные форматы представления одной и той же информации. Примером может служить формат валюты, который может быть <510,5, 10,5 <5 и т.д.

- Единица измерения: в разных записях используются разные единицы, например расстояния в сантиметрах и дюймах.

3 Общие функции

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

Источники данных: возможность извлекать данные из разных и разнородных источников данных. Источниками данных могут быть реляционные базы данных, плоские файлы, файлы XML, электронные таблицы, устаревшие системы и пакеты приложений, такие как SAP, источники на основе We и программное обеспечение EAI (Enterprise Application Integration). Некоторые коммерческие инструменты (например, Sunopsis [12]) поддерживают только реляционные базы данных. Другие инструменты, такие как ETLQ [13,14], поддерживают широкий спектр типов источников данных, от обычных коннекторов (например, ODBC, JDBC) до пакетов приложений, таких как SAP R / 3.

Возможности извлечения: процесс извлечения данных из источников данных должен обеспечивать следующие важные возможности: (i) возможность планировать извлечения по времени, интервалу или событию; (ii) набор правил для выбора данных из источника и (в) возможность выбирать и объединять записи из нескольких источников. Ряд коммерческих инструментов, таких как Informatica [15] и Data Integrator [16], предоставляют большую часть этих функций извлечения.

Возможности загрузки: процесс загрузки данных в целевую систему должен иметь возможность: (i) загружать данные в несколько типов целевых систем; (ii) загружать данные в разнородные целевые системы параллельно; (in) обновлять и добавлять данные в целевой источник данных и (iv) автоматически создавать целевые таблицы. Sagent [17] - это пример коммерческого инструмента, который предоставляет все возможности загрузки, перечисленные выше.

Инкрементальные обновления: возможность постепенно обновлять целевые объекты данных вместо того, чтобы каждый раз перестраивать их с нуля. В идеале стратегия инкрементного обновления должна выполняться во время извлечения, чтобы извлекались только новые или обновленные записи, что значительно повышает эффективность и временные затраты. Альтернативная стратегия - выполнять инкрементные обновления во время загрузки, что является очень дорогостоящим и неэффективным процессом. Hummingbird ETL [18] обеспечивает добавочные обновления во время извлечения, используя Sybase Replication Server в качестве механизма для обнаружения измененных данных.

Интерфейс: некоторые продукты предлагают интегрированную визуальную среду разработки, которая упрощает их использование. Эти графические инструменты позволяют пользователю определять процессы качества данных, моделируемые как рабочие процессы, с помощью интерфейса укажи и щелкни. Большинство коммерческих инструментов, например FirstLogic [19, 20], dfPower [21, 22] и Trillium [23], предоставляют полностью интегрированный графический интерфейс. Неграфические инструменты, такие как Ajax [4, 24] и DataFusion [25], обычно предоставляют язык для определения программ качества данных.

Репозиторий метаданных: репозиторий, в котором хранятся схемы данных и информация о структуре процесса обеспечения качества данных. Эта информация потребляется во время выполнения процессов качества данных. Некоторые инструменты, такие как Informatica, используют реляционную базу данных для хранения репозитория метаданных.

Методы повышения производительности: набор функций для ускорения процессов очистки данных и обеспечения масштабируемости. Важными методами повышения производительности являются секционирование, параллельная обработка, потоки, кластеризация и балансировка нагрузки. DataStage [26] и Hummingbird ETL, например, обеспечивают параллельную обработку (разделение и конвейерную обработку) и многопоточное выполнение преобразований данных соответственно.

Управление версиями: механизм управления версиями со стандартными параметрами управления (например, регистрация, проверка), который позволяет разработчикам отслеживать различные разрабатываемые версии исходного кода. Некоторые коммерческие инструменты, например DataStage и Hummingbird ETL, обеспечивают поддержку контроля версий.

Библиотека функций: набор встроенных функций, таких как преобразователи типов данных и функции стандартизации, которые решают конкретные проблемы качества данных. Важной особенностью является возможность расширения библиотеки функций новыми функциями. Это может быть достигнуто с помощью языка программирования или путем добавления внешних функций из библиотеки динамической компоновки (DLL). Ряд коммерческих инструментов, например Informatica ETL, Data Integrator и Hummingbird ETL предоставляют библиотеки функций с возможностями расширения.

Привязка к языку: встроенная поддержка языка программирования для разработки новых функций с целью расширения библиотеки функций. Эта поддержка может варьироваться от существующего языка программирования (например, C или Perl) до родного языка. DataStage поддерживает как собственный язык, так и существующие языки программирования (Perl и Basic).

Таблица 1: Общие функции инструментов качества коммерческих данных.

Отладка и трассировка: средства трассировки документируют выполнение программ качества данных с помощью полезной информации (например, время начала и окончания выполнения важных подпрограмм, количество входных и выходных записей). Обычно средства трассировки предоставляются в виде подробного файла журнала (например, DataStage и Datalntegrator). Более сложные механизмы можно найти в DataFusion [25]. Отладка - это средство для отслеживания и анализа выполнения программ обеспечения качества данных с целью обнаружения проблем и уточнения спецификации правил преобразования данных. Сложные механизмы отладки поддерживаются исследовательскими инструментами Ajax и Arktos [27].

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

Происхождение данных: Происхождение или происхождение данных идентифицирует набор элементов исходных данных, которые создали данный элемент данных [28]. Как коммерческие (например, Data Integrator), так и исследовательские инструменты (например, Ajax) предоставляют возможности для получения данных и проверки. В программах качества данных, смоделированных в виде графиков преобразований данных, эта возможность чрезвычайно важна, поскольку позволяет анализировать происхождение всех записей данных (в частности, записей исключений), подвергающихся процессу преобразования.

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

4 Категории инструментов

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

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

Таблица 2: Общие функции инструментов качества исследовательских данных

Рис. 1.

Профилирование данных: процесс анализа источников данных в отношении области качества данных (Область качества данных - это приложение или использование данных, которое налагает набор правил качества данных, то есть спецификацию одной или нескольких проблем качества данных, которые не должны существовать в наборе данных.) [34] для выявления и определения приоритетов проблем качества данных. Профилирование данных сообщает о полноте наборов данных и записей данных, систематизирует проблемы данных по важности, выводит распределение проблем качества данных в наборе данных и перечисляет отсутствующие значения в существующих записях [29]. Выявление проблем с качеством данных до начала проекта очистки данных имеет решающее значение для обеспечения предоставления точной информации. Следующий набор коммерческих и исследовательских инструментов реализует методы профилирования данных:

Рис. 2.

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

Рис. 3.

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

Рис. 4.

Устранение дубликатов: процесс, который идентифицирует повторяющиеся записи (относящиеся к одному и тому же реальному объекту) и объединяет их в одну запись. Процессы устранения дублирования дорогостоящие и отнимают очень много времени. Обычно они требуют следующих шагов: (i) стандартизировать несоответствия формата; (ii) перевод сокращений или цифровых кодов; (in) для выполнения правил точного и приблизительного сопоставления и (iv) для объединения повторяющихся записей. Набор коммерческих и исследовательских инструментов, обеспечивающих методы устранения дублирования, представлен ниже.

Рис. 5.

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

Рис. 6.

5 Решение проблем качества данных

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

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

Что касается проблем экземпляров данных, отсутствующие данные могут быть обнаружены и устранены только в том случае, если нулевая кодировка (например, 9999) правильно идентифицирована. Таблица может использоваться для сопоставления нулевых значений кодирования и соответствующих значений. Ошибочные, неверно введенные данные и встроенные значения не могут быть исправлены автоматически. В документации некоторых коммерческих инструментов говорится, что они включают в себя средство проверки орфографии, которое можно использовать для исправления орфографических ошибок. Инструменты очистки и обогащения данных (такие как FirstLogic или QuickAddress Batch) способны устранять неоднозначные и нестандартные данные. Приблизительные дубликаты обнаруживаются с помощью инструментов очистки данных и удаления дубликатов, которые реализуют алгоритмы приблизительного сопоставления [64]. Наконец, противоречивые записи могут быть обнаружены с помощью инструментов очистки данных и удаления дубликатов, но их объединение должно осуществляться с помощью пользователя.

6. Выводы

Инструменты качества данных преобразуют данные с проблемами в данные хорошего качества для определенной области приложения. В этой статье представлена классификация коммерческих и исследовательских инструментов качества данных с трех различных точек зрения. Во-первых, мы представили таксономию проблем качества данных и выделили те, которые не решаются текущей технологией РСУБД. Во-вторых, мы перечислили общие функции, которыми должны обладать эти инструменты для выполнения своих основных задач, а именно извлечение данных из источников данных, их преобразование для повышения их качества и загрузка полученных данных в целевые источники. Затем инструменты качества данных были разделены на группы в зависимости от типа выполняемой задачи качества данных. Мы выделили шесть различных категорий инструментов: (i) профилирование данных; (ii) анализ данных; (в) преобразование данных; (iv) очистка данных; (v) устранение дубликатов и (vi) обогащение данных. Первые две категории предназначены для обнаружения проблем с качеством данных, а последние четыре предоставляют методы их исправления. Эти категории могут перекрываться в том смысле, что некоторые задачи (например, очистка данных) включают другие (устранение дубликатов и обогащение данных). Наконец, для каждой выявленной проблемы качества данных мы подробно описали, какие из них решаются с помощью четырех категорий инструментов качества данных, которые исправляют проблемы с данными.

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

Предыдущие обзоры инструментов качества данных можно найти в [65] и [66] или в некоторых коммерческих отчетах [67], [68] и [69]. Однако, насколько известно авторам, ни один из них не предназначался для предоставления рамок классификации, как это делаем мы здесь. Более того, ни одна из предыдущих работ не касалась коммерческих инструментов, а также инструментов качества исследовательских данных.

Таблица 3. Проблемы качества данных, решаемые каждой категорией инструментов качества данных.

References

[1] S. Chaudhuri and U. Dayal. An overview of data warehousing and olap technology. SIGMOD Record, 26(l):65-74, 1997.

[2] P. Carreira and H. Galhardas. Efficient development of data migration transformations. Demo paper. In ACM SIGMOD Intl Conf. on the Managment of Data, Paris, France, June 2004.

[3] R. Kimball, L. Reeves, M. Ross, and W. Thornthwaite. The Datawarehouse lifecycle toolkit: Expert Methods for Designing, Developing, and Deploying Data Warehouses. Wiley, 1998.

[4] H. Galhardas, D. Florescu, D. Shasha, E. Simon, and C. A. Saita. Declarative data cleaning: Language, model, and algorithms. In Proc. of the Intl Conf. on Very Large Data Bases (VLDB01), Rome, Italy, September 2001.

[5] Oracle PL/SQL. http://www.oracle.com/technology/ tech/pl_sql.

[6] Won Kim, Byoung-Ju Choi, Eui-Kyeong Hong, Soo-Kyung Kim, and Doheon Lee. A taxonomy of dirty data. Data Mining and Knowledge Discovery, 2559:19-34, December 2002.

[7] Erhard Rahm and Hong Do. Data cleaning: Problems and current approaches. In IEEE Techn. Bulletin on Data En-gineering, December 2000.

[8] P. Oliveira, F. Rodrigues, P. Henriques, and H. Galhardas. A taxonomy of data quality problems. International Workshop on Data Quality (in conjunction with CAISEOB), 2005.

[9] Heiko Muller and Johann-Christoph Freytag. Problems, methods, and challenges in comprehensive data cleansing. Technical Report HUB-IB-164, Humboldt University Berlin, 2003.

[10] Can Turker and Michael Gertz. Semantic integrity constraint support in sql:1999 and commercial object relational database management systems. In The VLDB Journal 10, pages 241-269, 2001.

[11] International Organization for Standardization (ISO) and American National Standards Institute (ANSI). ISO International Standard: Database Language SQL - part 2. September 1999.

[12] Sunopsis. http://www.sunopsis.com.

[13] ETLQ (SAS). http://www.sas.com.

[14] Bloor Research. ETLQ data quality report, 2004.

[15] Informatica ETL. http://www.informatica.com.

[16] Data Integrator (Business Objects). http://www.businessobjects.com.

[17] Sagent (Group 1 Software), http://www.sagent.com.

[18] Hummingbird ETL (Genio). http://www.hummingbird. com.

[19] Firstlogic. http://www.firstlogic.com.

[20] Firstlogic introduces next-generation data quality platform, 2005.

[21] dfPower (DataFlux a SAS Company). http://www.dataflux.com.

[22] R. Chandras. A smart response to bad data, 2005.

[23] Trillium, http://www.trilliumsoft.com.

[24] Helena Galhardas. Nettoyage de donnees: Modele, langage declaratif et algorithmes. PhD thesis, Universite de Versailles Saint-Quentin-en-Yvelines, September 2001.

[25] DataFusion (Oblog). http://www.oblog.pt.

[26] DataStage (Ascential). http://www.ascential.com.

[27] A. Simitsis. Modeling and managing ETL processes. In VLDB PhD Workshop, Berlin, 2003.

[28] Yingwei Cui. Lineage Tracing in Data Warehouses. PhD thesis, Stanford University, 2001.

[29] Jack Olson. Data Quality - The Accuracy Dimension. Morgan Kaufman Publishers, 2003.

[30] Migration Architect (Evoke Software). http://www.evokesoft.com.

[31] Whiz Why (WizSoft). http://www.wizsoft.com.

[32] V. Raman and J. Hellerstein. Potters wheel: An interactive data cleaning system. VLDB, 27:381-390, 2001.

[33] J. Maletic and A. Marcus. Automated identification of errors in data sets. IQ2000, 2000.

[34] Brian Marshall. Data Quality and Data Profiling A Glossary of Terms. http://www.agt.net/public/bmarshal/ dataqual.htm.

[35] SQL Server 2000 DTS (Microsoft). http://www.microsoft.com.

[36] SQL Server 2005 (Microsoft), http://www.microsoft.com.

[37] S. Chaudhuri, K.Ganjam, V.Ganti, R. Kapoor, V. Narasayya, and T.Vassilakis. Data Cleaning in Microsoft SQL Server 2005. In ACM SIGMOD/PODS Conference, 2005.

[38] R. J. Miller, L. M. Haas, M. Hernandez, C. T. H. Ho, R. Fagin, and L. Popa. The Clio Project: Managing Heterogeneity. SIGMOD Record, 1(30), March 2001.

[39] R. J. Miller. Using Schematically Heterogeneous Structures. Proc. of ACM SIGMOD Intl Conf. on the Managment of Data, 2(22):189-200, June 1998.

[40] R. J. Miller, L. M. Haas, and M. Hernandez. Schema Mapping as Query Discovery. In Proc. of the Intl Conf. on Very Large Data Bases (VLDB00), pages 77-78, Cairo, Egypt, September 2000.

[41] Kay-Uwe Sattler, Stefan Conrad, and Gunter Saake. Adding conflict resolution features to a query language for database federations. Int. Workshop on Engineering Federated Information Systems, EFIS00, pages 42-52, June 2000.

[42] Kay-Uwe Sattler and Eike Schallehn. A data preparation framework based on a multidatabase language. Proceedings of the International Database Engineering and Applications Symposium, pages 219 - 228, 2000.

[43] T. Milo and S. Zhoar. Using schema matching to simplify heterogeneous data translation. In Proc. of the Int l Conf. on Very Large Data Bases (VLDB98), New York, USA, August 1998.

[44] DataBlade (IBM), http://www.informix.com.

[45] ETI*Data Cleanser (ETI). http://www.eti.com.

[46] NaDIS (MSI), http://www.msi.com.au.

[47] QuickAddress Batch (QAS). http://www.qas.com.

[48] WhizRule (WizSoft). http://www.wizsoft.com.

[49] Centrus Merge/Purge Library (Group 1 Software), http: //www.centrus.com.

[50] Choicemaker. http://www.choicemaker.com.

[51] M. Buechi, A. Borthwick, A. Winkel, and A. Goldberg. Cluemaker: A language for approximate record matching. In 8th International Conference on Data Quality, Boston, November 2003.

[52] A. Borthwick and M. Soffer. Business requirements of a record matching system. In Ninth International Conerence on Information Quality (MIT ICIQ), Cambridge, September 2004.

[53] A. Borthwick. The ChoiceMaker 2 record matching system. In White Paper, November 2004.

[54] DeDupe (HelpIT Systems), http://www.dedupeit.com.

[55] DoubleTake (Peoplesmith). http://www.peoplesmith.com.

[56] Identity Search Server (Identity Systems), http://www.identitysystems.com.

[57] MatchIT (HelpIT Systems), http://www.helpit.com.

[58] Merge/Puge Plus (Group 1 Software), http://www.gl.com.

[59] WhizSame (WizSoft). http://www.wizsoft.com.

[60] Liang Jin, Chen Li, and Shared Mehrotra. Efficient record linkage in large data sets. In Eighth International Conference on Database Systems for Advanced Applications, Kyoto, Japan, 2003.

[61] Liang Jin, Nick Koudas, and Chen Li. NNH: Improving performance of nearest-neighbor searches using histograms. In Extending Database Technology (EDBT), Crete, Greece, 2004.

[62] Liang Jin, Nick Koudas, Chen Li, and Anthony Tung. Indexing mixed types for approximate retrieval. In VLDB, 2005.

[63] Mong Lee, Tok Ling, and Wai Low. Intelliclean: A knowledge-based intelligent data cleaner. In ACM SIGKDD, Boston, 2000.

[64] William W. Cohen, Pradeep Ravikumar, and Stephen Fienberg. A comparison of string metrics for matching names and records. KDD Workshop on Data Cleaning and Object Consolidation, 2003.

[65] Data Quality products review DMReview. http://www.dmreview.com/resources/reviews3.cfm?Topic=230005.

[66] Data Cleaning and Integration tools H. Galhardas. http://web.tagus.ist.utl.pt/"helena.galhardas/ cleaning.html.

[67] Data Quality Tools METAspectrum Evaluation. www. firstlogic.com/pdfs/METAspectrumDQT.pdf.

[68] Wayne Eckerson and Colin White. Evaluating ETL and data integration platforms. TDWI Report Series, 2003.

[69] Data Quality Tools for Data Warehousing A Small Sample Survey, http://www.ctg.albany.edu/publications/ reports/data_quality_tools.

[70] Javed Beg and Shadab Hussain. Data quality - a problem and an approach. White Paper, March 2003.