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

Вопросы совместимости данных

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

Обработка неочищенных данных

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

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

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

Тем не менее, один из авторов этой книги впервые участвовал в дискуссии по поводу важности ЗНФ в 1973 году, работая над проектом е использовцнием ассемблера IBM Systein/370 и ISAM-файлов.

Загрузка устаревших кодов

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

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

Таблица, которая обычно определялась следующим образом:

CREATE TABLE cancellation reasons

( reason code CHAR(l) PRIMARY KEY

, rea3on text VARCHAR2 (30) NOT NULL ) ;

может быть трансформирована в таблицу, поддерживаюшую и устаревшие, и текущие коды с помощью дополнительного столбца и ограничения:

CREATE TABLE cancellation reasons

( reason code CHAR(l) PRIMARY KEY

, reason text VARCHAR2(30) NOT NULL

, current CHAR(l) DEFAULT N NOT NULL CONSTRAINT canc reason current CHECK (current IN (Y,N))

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

CREATE OR REPLACE VIEW current cancellation reasons ( reason code , reason text ) AS

SELECT reason code , reason text FROM cancellation reasons WHERE current = Y;

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

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

Загрузка данных с нарушенной ссылочной целостностью

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

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

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

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

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