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 г.

Предисловие

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

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