Данная статья является вольным переводом английского текста. Оригинал на английском языке вы найдете здесь.

Ошибки в неочищенных данных

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

Категории "ошибок".

"Ошибки" можно разделить на четыре категории. Слово ошибки взято в кавычки, т.к. некоторые из ошибок не являются в метафизическом смысле ошибочными. Мы называем ошибочными те данные, которые являются:

• Неполными
• Неправильными
• Малопонятными
• Противоречивыми.

Ошибки неполных данных

Они включают в себя:

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

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

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

Ошибки неправильных данных

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

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

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

• Ввод неправильной информации в системы-источники
  Иногда система-источник содержит данные, которые были просто неправильно введены в систему. Например, кто-то мог ввести 6/9/96 как 9/6/96. В данном случае очевидным действием было бы исправление данных в системе-источнике. Однако иногда по разным причинам данные в источнике исправить невозможно. Заметьте, что если у вас в системе-источнике много ошибок, которые нельзя исправить, то на самом деле ваша проблема заключается в отсутствии надежной оперативной системы.

• Некорректное сопоставление кодов
  Это лучше продемонстрировать на примере. Иногда, предполагается наличие существования правил, которые утверждают, что если часть суффикса серийного номера детали имеет значение XXX, то код категории должен быть A, B или C. Говоря более техническим языком, существует неарифметическое отношение между атрибутами, правила которого были нарушены.

Ошибки малопонятности

Это типы условий, которые делают исходные данные плохо читаемыми.

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

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

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

• Файлы электронных таблиц и текстовых процессоров
  Часто для выполнения начальной загрузки данных в хранилище необходимо извлекать критически важные данные, хранящиеся в файлах электронных таблиц и/или в файлах "merge list". Однако в этих файлах зачастую можно найти все что угодно. Они могут содержать подобие наполовину проверенных структурированных данных.

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

Ошибки противоречивости

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

• Противоречивое использование различных кодов
  Большинство литературы по хранилищам данных приводит пример, когда в одной системе для кодирования пола используются символы "М" и "Ж", а вдругой - "1" и "2". Желаю вам, чтобы подобные проблемы были самыми сложными проблемамиочистки данных.

• Неправильное значение кода
  Обычно существует проблема, когда определение организации изменяется со временем. Например, в 1995 году у вас были клиенты А, Б, В и Г. В 1996 году клиент А покупает клиента Б. В 1997 году клиент А покупает клиента В. В 1998 году клиент А продает часть, которая раньше была клиентами А и В клиенту Г. Когда в 1999 году вы строите свое хранилище данных, вы можете столкнуться с диллемой: каким образом определять продажи клиентам А, Б, В и Г в предыдущие годы.

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

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

• Неправильные имена и адреса
  Строго говоря, это случай различных кодов с одинаковым значением. Ненаучное впечатление от проблем данного типа заключается в том, что приличное понимание поиска по тексту позволит вам сравнительно легко сделать информацию об именах и адресах непротиворечивой на 80%. Поход за 90% непротиворечивости требует достаточно серьезных усилий. Получение 95% непротиворечивости требует еще одного гигантского скачка в усилиях. Что же касается достижения стопроцентной непротиворечивости базы данных реального размера, возможно, вы решите, что послать человека на Марс гораздо легче.

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

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

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

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

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

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

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

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

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

Некоторые заключительные мысли

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

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

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

• Сложность хранилища данных возрастает в геометрической прогресии в зависимости от количества источников данных
  Причиной является необходимость объединения противоречивых данных. Например, если для объединения данных из двух систем-источников требуется 100 часов, можете ожидать, что для объединения данных из четырех систем потребуется не 200, а 400 часов.

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

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

Для удобства отслеживания новых публикаций на сайте рекомендую подписаться на рассылку или подписаться на канал RSS.

Если вы нашли в сети интересные ссылки на ресурсы по технологиям хранилищ данных, OLAP, CRM или data mining, и хотите поделиться ими с другими, присылайте их. Я с удовольствием размещу их на этом сайте.