Загрузка поврежденных данных

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

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

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

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

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

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

Загрузка данных, не удовлетворяющих ограничениям сущностей

Ограничение сущности - это ограничение, которое может применяться в контексте одной сущности. Этот термин используется также для описания ограничений, применяемых к отдельной строке. Вот два примера ограничений сущностей:

user name VARCHAR(30)

CONSTRAINT secu user case

CHECK (user name = UPPER(user name))

discuont NUMBER NOT NULL

CONSTRAINT ordr discount CHECK ((discount = 0) OR

((discount approval IS NOT NULL) discount < ordr value)))

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

Загрузка неопределенных значений

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

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

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

Мы - за разумный подход

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

либо изменить данные,

либо изменить правила.

В большинстве проектов приходится делать и то, и другое.

Триггеры и декларативные ограничения

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

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

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

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