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

Данная статья является вольным переводом английского текста. Оригинал на английском языке вы найдете . Вы могли видеть публикации, в которых говорится, что большая часть времени проекта по созданию хранилища данных уходит на построение средств для начального и периодического извлечения, преобразования и загрузки данных. Однако трудно найти материалы, в которых обсуждались бы те ошибки в неочищенных данных, на исправление которых вы потратите свое время. Если вы знаете о возможности существования определенных ошибок, вам будет легче их обнаружить и спланировать ваш проект с тем, чтобы лучше с ними справиться. Может быть, материал этой статьи поможет вам сформировать список ошибок, наличие которых вы будете проверять. Далее следует список часто встречающихся ошибок. Если вы являетесь экспертом в области реляционных баз данных, смиритесь с неточным использованием некоторых терминов. И наконец, заметьте, что когда в тексте встречается ссылка на хранилище данных, имеется в виду база данных, которая непосредственно наполняется данными из систем-источников, а не киоски данных, которые наполняются уже очищенными данными. Категории "ошибок". "Ошибки" можно разделить на четыре категории. Слово ошибки взято в кавычки, т.к. некоторые из ошибок не являются в метафизическом смысле ошибочными. Мы называем ошибочными те данные, которые являются: Противоречивыми. Пропущенные записи Это означает, что запись, которая должна быть в системе-источнике, отсутствует. Заметьте, что вы можете не найти этот тип ошибок если у вас нет другой системы или старых отчетов для сравнения. Пропущенные поля Это поля, которые должны присутствовать, но не присутствуют. Зачастую существует ошибочное мнение о том, что система-источник требует ввода значения в поле. Записи или поля, сбор данных из которых не предусмотрен дизайном То есть, умышленная или неумышленная разработка приводит к тому, что данные, которые вы хотите поместить в хранилище, нигде не записываются. Далее я разделяю эту ситуацию на три категории. Первое, могут существовать атрибуты таблицы измерения, которые вы хотели бы записывать, но которых нет ни в одной системе-источнике данных для хранилища. Например, пользователь отдела маркетинга может иметь свою собственную клиссификацию продуктов, показывающую степень продвижения каждого из продуктов. Второе, если вы собираете один и тот же тип данных из различных систем, вы можете обнаружить, что одна из систем-источников не записывает поле, которое ваш пользователь хочет хранить в хранилище. Третье, могут существовать "транзакции", которые вам нужно хранить в хранилище данных, но которые не записаны явно. Например, обновление данных системы-источника не обязательно приводит запись транзакции. Или иногда в данные систем-источников вносятся поправки. Поправки проводок в бухгалтерских системах часто являются такими нарушителями. Неправильные (но иногда правильные) коды Это обычно происходит, когда старая транзакционная система назначает новый код, о котором пользователи транзакционной системы не заботятся. Теперь если код является неправильным, вы сможете его выловить. Неприятность происходит, когда код является неправильным, но допустимым. Например, вам может понадобиться извлекать данные из древней системы ввода заказов на запасные части, которая была запрограммирована в 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% непротиворечивости требует еще одного гигантского скачка в усилиях. Что же касается достижения стопроцентной непротиворечивости базы данных реального размера, возможно, вы решите, что послать человека на Марс гораздо легче. Противоречивые бизнес-правила Это, в большинстве своем, является причудливым способом в

Hosted by uCoz