Достаточно часто каждый аналитик сталкивается с ситуацией, когда загрузил данные в блок анализа, а в ответ – тишина, хотя в тестовом режиме все работает. Причина обычно в том, что данные недостаточно очищены, где в этой ситуации искать аналитику засаду и с чего начинать обычно задачка не из легких. Можно конечно использовать механизмы сглаживания, но каждый знает, что если из черного ящика с красными и зелеными шарами отсыпать килограмм шаров и вместо них вбросить килограмм белых, то в понимании распределения красных и зеленых это мало приблизит. Когда находишься в ситуации «а с чего начать» помогает таксономия «грязных данных». Хотя в учебниках и дают список проблем, но он обычно неполный, вот постоянно искал исследования, которые рассматривают эту тему подробней. Попалась работа T.Gschwandtner, J.Gartner, W.Aigner, S.Miksch хотя они ее делали для рассмотрения способов очистки данных связанных с датами и временем но, на мой взгляд, это оказалось исключение, которое потребовало разобраться с правилами поглубже чем в учебниках. По собственному опыту знаю, что сопряжение дат и времени «вынос мозга» практически в прямом смысле и поэтому и зацепился за исследование этих авторов. В своей работе они проанализировали несколько работ других авторов и составили мощный список «загрязнений данных» логика их анализа заслуживает уважения и, с другой стороны, дает возможность более «со стороны» посмотреть на любую задачу очистки данных. Все это видно когда сопоставляешь всю совокупность работ, по которым они делают сравнительный анализ. Поэтому и сделал перевод самых используемых ими 5 статей, список с ссылками на эти переводы ниже.  Это шестая статья из цикла: Таксономия форматов времени и дат в неочищенных данных, 2012 г.  Очистка данных: проблемы и современные подходы 2000 г.  Таксономия «грязных данных» 2003 г. Проблемы, методы и вызовы комплексной очистки данных 2003 г.  Формальное определение проблем качества данных 2005 г.  Обзор инструментов качества данных 2005 г.  Инструменты качества данных направлены на обнаружение и исправление проблем с данными, которые влияют на точность и эффективность приложений анализа данных. Мы предлагаем классификацию наиболее актуальных коммерческих и исследовательских инструментов качества данных, которые можно использовать в качестве основы для сравнения инструментов и понимания их функций. Сегодняшним организациям требуется высокий уровень качества данных для эффективной работы своих приложений анализа данных (например, систем поддержки принятия решений, интеллектуального анализа данных, управления взаимоотношениями с клиентами) и получения точных результатов. Объем обрабатываемых в настоящее время данных огромен, обычно не осуществляется адекватный контроль ввода данных, и данные часто получают путем слияния различных источников данных. Как следствие, аномалии данных, такие как несоответствия, пропущенные значения, повторяющиеся записи и нестандартные представления данных, встречаются чаще, чем хотелось бы. Существование этих проблем с данными, обычно называемых грязными данными, значительно снижает качество информации, что напрямую влияет на эффективность поддерживаемого бизнеса. Удаление грязных данных в информационных системах обычно называется очисткой данных (также известной как очистка или очистка данных) и направлена на получение данных высокого качества. Это важная задача в различных сценариях применения. В рамках единого источника данных (например, списка клиентов) важно исправить проблемы целостности, стандартизировать значения, заполнить недостающие данные и объединить повторяющиеся вхождения. Построение хранилища данных (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. Представленная здесь таксономия проблем с данными основана на четырех соответствующих работах, найденных в литературе [6, 7, 8, 9]. Мы разделяем проблемы качества данных на проблемы с данными на уровне схемы и на уровне экземпляра. Проблем с данными на уровне схемы можно избежать с помощью улучшенного дизайна схемы, которые не зависят от фактического содержимого данных. Проблемы с данными на уровне экземпляра связаны с содержимым данных, и их нельзя избежать с помощью лучшего определения схемы, поскольку языки определения схемы недостаточно мощны, чтобы указать все требуемые ограничения данных. В нашей таксономии проблемы с данными на уровне экземпляра включают в себя все проблемы с данными, которые не являются проблемами данных на уровне схемы, поэтому на этом таксономия завершена. Проблемы с качеством данных на уровне схемы можно предотвратить с помощью улучшенного проектирования схемы, ее преобразования и интеграции. Современные СУБД предоставляют важные механизмы для обеспечения определений схемы. Поэтому мы различаем проблемы с данными на уровне схемы, поддерживаемые СУБД, и проблемы с данными на уровне схемы, не поддерживаемые СУБД. Во время проектирования базы данных можно определить ограничения целостности, чтобы указать условия, которым должны удовлетворять объекты базы данных [10]. SQL: 1999 [11] поддерживает язык, обеспечивающий следующие декларативные ограничения целостности: (i) ограничение not null, чтобы столбец не принимал нулевое значение; (это) ограничение по умолчанию для указания значения по умолчанию для данного столбца; (in) ограничение уникальности, определяющее, что столбец или набор столбцов должны иметь уникальные значения в таблице; (iv) ограничение первичного ключа, которое соответствует уникальным и не нулевым ограничениям; (v) ограничение ссылочной целостности для определения атрибутов, значения которых должны совпадать со значениями первичного или уникального ключа сторонней таблицы; (vi) проверка ограничения для определения определяемого пользователем условия; (vii) ограничение домена для определения значений домена с ограничениями; (viii) ограничение утверждения определяет ограничение целостности, не зависящее от таблицы. SQL: 1999 также позволяет процедурное определение ограничений целостности с помощью триггеров, то есть процедур, вызываемых СУБД в ответ на определенные события базы данных. В следующем списке перечислены проблемы качества данных, которых можно избежать с помощью адекватного определения ограничения целостности. Отсутствующие данные: данные, которые не были заполнены. Ограничение not null может избежать этой проблемы. Неверный тип данных: нарушение ограничения типа данных, например, возраст сотрудника 'XY'. Ограничения домена позволяют избежать этой проблемы. Неверное значение данных: нарушение ограничения диапазона данных. Если возраст сотрудника должен находиться в диапазоне [18, 65], то возраст 15 лет является неверным значением данных. Чтобы избежать этой проблемы, используются ограничения проверки и домена. Висячие данные: данные в одной таблице не имеют аналогов в другой таблице. Например, идентификатор отдела не существует в таблице «Отдел», и есть ссылка на это значение в таблице «Сотрудник». Эта проблема решается ограничениями ссылочной целостности (то есть внешними ключами). Точные повторяющиеся данные: разные записи имеют одно и то же значение в поле (или комбинации полей), для которого недопустимы повторяющиеся значения (например, номер социального страхования сотрудника). Ограничения уникальности и первичного ключа позволяют избежать точных дубликатов. Ограничения домена: записи или значения атрибутов, которые нарушают ограничение домена (например, зависимости атрибутов или заранее определенное максимальное количество строк). Ограничения домена и утверждения предназначены для того, чтобы избежать этой проблемы. Однако эти функции не предоставляются большинством СУБД (например, Oracle 9i), которые решают эту проблему с данными с помощью триггеров. Следующие проблемы качества данных не могут быть обработаны ограничениями целостности СУБД: Неверные категориальные данные: значение категории, выходящее за пределы диапазона категории (например, страны и соответствующие штаты). Использование неправильного уровня абстракции (например, «замороженные продукты» или «замороженная пицца» вместо «еда») также считается типом неверных категориальных данных. Устаревшие временные данные: данные, которые нарушают временное ограничение, определяющее момент времени или интервал, в котором данные действительны. Например, зарплата сотрудника больше недействительна при повышении зарплаты этого сотрудника. Несогласованные пространственные данные: несоответствия между пространственными данными (например, координатами, формами), когда они хранятся в нескольких полях. Например, координаты точек в таблице прямоугольников следует объединить, чтобы получить замкнутый прямоугольник. Конфликты имен: одно и то же имя поля используется для разных объектов (омонимы) или разные имена используются для одного и того же объекта (синонимы). Структурные конфликты: разные представления схемы одного и того же объекта в разных таблицах или базах данных. Например, адрес может быть представлен в поле произвольной формы или разложен на поля улица, город, штат и т.д. Хотя в рамках одной схемы данных могут возникать конфликты имен и структурные конфликты, они часто возникают в сценариях с несколькими схемами. Проблемы с данными на уровне экземпляра относятся к ошибкам и несогласованности данных, которые не видны или которых нельзя избежать на уровне схемы. Обратите внимание, что экземпляры данных также отражают проблемы на уровне схемы (например, запись с нулевым значением в обязательном поле). Мы считаем, что проблемы с данными на уровне экземпляра делятся на проблемы с одной записью и с несколькими записями. Проблемы с данными отдельной записи касаются одного или различных атрибутов одной записи. Другими словами, такого рода проблема связана с одним объектом и не зависит от другой информации, хранящейся в базе данных. Отсутствующие данные в ненулевом поле: атрибут заполняется каким-то '' фиктивным '' значением. Например, номер социального страхования -999999 - это неопределенное значение, используемое для преодоления ограничения «Ненулевое значение». Ошибочные данные: данные действительны, но не соответствуют реальному объекту. Примером ошибочных данных является 31 год для возраста сотрудника, когда ей на самом деле 30 лет. Орфографические ошибки: слова с ошибками в полях базы данных (например, «Джон Стивенс» вместо «Джон Стивенс»). Встроенные значения: наличие посторонних данных в некотором поле данных. Распространенным примером встроенных значений является вставка заголовка в поле имени (например, «Президент Джон Стивенс»).  Ошибочные значения: данные хранятся в неправильном поле. Например, рассмотрим значение «Португалия» в атрибуте города. Неоднозначные данные: данные, которые можно интерпретировать более чем одним способом с разными значениями. Неоднозначные данные могут возникнуть из-за наличия аббревиатуры или неполного контекста, а именно: Аббревиатура: Сокращенное наименование «Дж. Стивенс »можно расширить по-разному, например: «Джон Стивенс», «Джек Стивенс», «Джефф Стивенс»и т. Д. Неполный контекст: название города «Майами» может означать штат Флорида или штат Огайо. Проблемы с данными нескольких записей не могут быть обнаружены, если рассматривать каждую запись отдельно как проблему с данными.касается более чем одной записи. Обратите внимание, что проблемы с несколькими записями могут возникать среди записей, принадлежащих к одному и тому же набору сущностей (или таблице) или к разным наборам сущностей (соответствующим разным таблицам или даже разным базам данных). Повторяющиеся записи: записи, относящиеся к одному и тому же реальному объекту и не содержащие противоречивой информации. Следующие записи сотрудников считаются дубликатами: 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 и т.д. Единица измерения: в разных записях используются разные единицы, например расстояния в сантиметрах и дюймах. В этом разделе мы познакомим вас с основными функциями проанализированных нами инструментов качества данных. Сначала мы описываем каждую функцию. Затем мы суммируем в таблицах 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) предоставляют возможности для получения данных и проверки. В программах качества данных, смоделированных в виде графиков преобразований данных, эта возможность чрезвычайно важна, поскольку позволяет анализировать происхождение всех записей данных (в частности, записей исключений), подвергающихся процессу преобразования. Механизмы отладки, обработка исключений и происхождение данных - это функции, которые поддерживают совершенствование программ обеспечения качества данных. Уточнение программ качества данных, которые обрабатывают большие объемы данных с определенной степенью загрязнения, имеет решающее значение, поскольку критерии автоматической очистки не могут охватывать все элементы данных. Обнаруживая исключения и их источник, пользователь может уточнить правила качества соответствующим образом или вручную исправить ошибочные записи, которые не могут быть очищены автоматически. Принято считать, что инструменты качества данных можно сгруппировать в соответствии с той частью процесса качества данных, которую они охватывают [29]. Профилирование и анализ данных помогают в обнаружении проблем с данными. Преобразование данных, очистка данных, устранение дубликатов и улучшение данных позволяют решить обнаруженные или ранее известные проблемы с качеством данных. Анализ данных: действия, включающие статистическую оценку, логическое изучение значений данных и применение алгоритмов интеллектуального анализа данных для определения шаблонов данных и правил, гарантирующих, что данные не нарушают ограничения домена приложения. Набор коммерческих и исследовательских инструментов, обеспечивающих методы анализа данных, следующий: Таблица 2: Общие функции инструментов качества исследовательских данных Рис. 1. Профилирование данных: процесс анализа источников данных в отношении области качества данных (Область качества данных - это приложение или использование данных, которое налагает набор правил качества данных, то есть спецификацию одной или нескольких проблем качества данных, которые не должны существовать в наборе данных.) [34] для выявления и определения приоритетов проблем качества данных. Профилирование данных сообщает о полноте наборов данных и записей данных, систематизирует проблемы данных по важности, выводит распределение проблем качества данных в наборе данных и перечисляет отсутствующие значения в существующих записях [29]. Выявление проблем с качеством данных до начала проекта очистки данных имеет решающее значение для обеспечения предоставления точной информации. Следующий набор коммерческих и исследовательских инструментов реализует методы профилирования данных: Рис. 2. Преобразование данных: набор операций (схема / преобразование данных и интеграция, фильтрация и агрегирование), которым должны подвергнуться исходные данные, чтобы надлежащим образом соответствовать целевой схеме. Для преобразования данных требуются метаданные, такие как схемы данных, характеристики данных на уровне экземпляра и сопоставления данных. Набор коммерческих и исследовательских инструментов, которые можно отнести к инструментам преобразования данных, следующий. Рис. 3. Очистка данных: процесс обнаружения, удаления и / или исправления грязных данных. (Данные, которые являются неправильными, устаревшими, избыточными, несогласованными, неполными или неправильно отформатированными.) Очистка данных направлена не только на очистку данных, но и на обеспечение согласованности различных наборов данных, которые были объединены из отдельных баз данных. Доступны сложные программные приложения для очистки данных с использованием определенных функций, правил и справочных таблиц. Раньше эта задача выполнялась вручную и поэтому допускала человеческую ошибку. Следующий набор коммерческих и исследовательских инструментов реализует методы очистки данных: Рис. 4. Устранение дубликатов: процесс, который идентифицирует повторяющиеся записи (относящиеся к одному и тому же реальному объекту) и объединяет их в одну запись. Процессы устранения дублирования дорогостоящие и отнимают очень много времени. Обычно они требуют следующих шагов: (i) стандартизировать несоответствия формата; (ii) перевод сокращений или цифровых кодов; (in) для выполнения правил точного и приблизительного сопоставления и (iv) для объединения повторяющихся записей. Набор коммерческих и исследовательских инструментов, обеспечивающих методы устранения дублирования, представлен ниже. Рис. 5. Обогащение данных (также известное как улучшение данных). Процесс использования дополнительной информации из внутренних или внешних источников данных для улучшения качества входных данных, которые были неполными, неспецифическими или устаревшими. Пополнение почтовых адресов, геокодирование и добавление демографических данных являются типичными процедурами обогащения данных. Набор инструментов для пополнения коммерческих и исследовательских данных приведен ниже: Рис. 6. На этом этапе мы определили проблемы качества данных (в Разделе 2) и классифицировали инструменты качества данных по шести категориям (в Разделе 4). Теперь в таблице 3 мы предлагаем соответствие между каждой категорией инструментов качества данных и проблемами качества данных, которые они решают. Мы не рассматривали инструменты профилирования и анализа, поскольку мы фокусируемся на классах инструментов, направленных на исправление аномалий данных. Неправильные категориальные данные могут быть удалены с помощью таблицы поиска, которая содержит набор допустимых категорий. Ошибочное значение данных может быть обнаружено при сравнении со всеми записями справочной таблицы. Специфичные для домена инструменты, такие как QuickAddress Batch для адресов, могут решить эту проблему. Как устаревшие временные данные, так и несогласованные пространственные данные требуют взаимодействия человека и не могут быть исправлены автоматически. Конфликты имен и структурные конфликты требуют преобразования схемы данных. Что касается проблем экземпляров данных, отсутствующие данные могут быть обнаружены и устранены только в том случае, если «нулевая» кодировка (например, ’9999’) правильно идентифицирована. Таблица может использоваться для сопоставления «нулевых» значений кодирования и соответствующих значений. Ошибочные, неверно введенные данные и встроенные значения не могут быть исправлены автоматически. В документации некоторых коммерческих инструментов говорится, что они включают в себя средство проверки орфографии, которое можно использовать для исправления орфографических ошибок. Инструменты очистки и обогащения данных (такие как FirstLogic или QuickAddress Batch) способны устранять неоднозначные и нестандартные данные. Приблизительные дубликаты обнаруживаются с помощью инструментов очистки данных и удаления дубликатов, которые реализуют алгоритмы приблизительного сопоставления [64]. Наконец, противоречивые записи могут быть обнаружены с помощью инструментов очистки данных и удаления дубликатов, но их объединение должно осуществляться с помощью пользователя. Инструменты качества данных преобразуют данные с проблемами в данные хорошего качества для определенной области приложения. В этой статье представлена классификация коммерческих и исследовательских инструментов качества данных с трех различных точек зрения. Во-первых, мы представили таксономию проблем качества данных и выделили те, которые не решаются текущей технологией РСУБД. Во-вторых, мы перечислили общие функции, которыми должны обладать эти инструменты для выполнения своих основных задач, а именно извлечение данных из источников данных, их преобразование для повышения их качества и загрузка полученных данных в целевые источники. Затем инструменты качества данных были разделены на группы в зависимости от типа выполняемой задачи качества данных. Мы выделили шесть различных категорий инструментов: (i) профилирование данных; (ii) анализ данных; (в) преобразование данных; (iv) очистка данных; (v) устранение дубликатов и (vi) обогащение данных. Первые две категории предназначены для обнаружения проблем с качеством данных, а последние четыре предоставляют методы их исправления. Эти категории могут перекрываться в том смысле, что некоторые задачи (например, очистка данных) включают другие (устранение дубликатов и обогащение данных). Наконец, для каждой выявленной проблемы качества данных мы подробно описали, какие из них решаются с помощью четырех категорий инструментов качества данных, которые исправляют проблемы с данными. Из-за нехватки места мы не стали описывать далее методы, используемые инструментами качества данных для решения проблем качества данных. Было бы интересно прояснить, как, например, инструменты очистки данных устраняют орфографические ошибки или обрабатывают повторяющиеся записи. Кроме того, было бы полезно провести сравнение различных методов, реализованных разными инструментами для решения одной и той же проблемы. Другой аспект, который следует рассмотреть, касается инструментов профилирования и анализа данных. В [29] Олсон дает хорошее представление о функциональных возможностях, которые должны обеспечивать эти инструменты. Однако еще предстоит провести классификацию существующих инструментов по списку важных функций профилирования и анализа. Предыдущие обзоры инструментов качества данных можно найти в [65] и [66] или в некоторых коммерческих отчетах [67], [68] и [69]. Однако, насколько известно авторам, ни один из них не предназначался для предоставления рамок классификации, как это делаем мы здесь. Более того, ни одна из предыдущих работ не касалась коммерческих инструментов, а также инструментов качества исследовательских данных. Таблица 3. Проблемы качества данных, решаемые каждой категорией инструментов качества данных.  [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 Int’l 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 Int’l Conf. on Very Large Data Bases (VLDB’01), 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 CAISE’OB), 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. Potter’s 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 Int’l 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 Int’l Conf. on Very Large Data Bases (VLDB’00), 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, EFIS’00, 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 (VLDB’98), 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. Специалист