Ослабление ограничений Foreign Key с помощью неопределенных значений

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

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

SELECT е.emp name , c.cust name FROM customers с , emoloyees e WHERE c.country = USA

AND c.sales id = e.employee id;

не возвратит клиентов, у которых в столбце SALES ID стоит неопределенное значение, даже если клиент находится в США. Чтобы получить правильный ответ, необходимо изменить этот запрос так:

SELECT NVL(е.emp name, NOT assigned) , c.cust name FROM customers с , emoloyees e WHERE c.country = USA

AND с sales id = e.employee id(+);

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

Однако, если мы попробуем ввести служащего, который называется Not assigned ( Не назначен ) и не имеет ни номера социального страхования, ни адреса, ни зарплаты, то это может вызвать проблемы при обработке платежных ведомостей. Правильное решение - признать, что наша исходная модель была неверной. Нам нужна новая сушность, которую мы можем назвать список клиентов . Введя такой список, в котором нет назначений продавцов, мы можем переписать первоначальный запрос так, чтобы работать без внешнего соединения. (Измененная модель данных показана на рис. 8.1.) Теперь мы можем выдать такой запрос:

SELECT l.list responsibility , с.cust name

FROM customers с , cust lists 1 WHERE c.country = USA

AND c.list id = l.list id;

Однако отметим, что в данном случае мы имеем отношение один к одному между сущностями CUSTOMER LISTS и EMPLOYEES, необязательное на обеих сторонах. Помните - прежде чем ставить под сомнение модель данных, необходимо много поработать с приемом унаследованных данных.

USTdMER LISTS,

lOSTOMEB

Рис 8 1 Новая модель данных

Этапы переноса данных

Процесс переноса данных можно разбить на следующие этапы: Извлечение

Чтение данных из места их хранения.

Трансформация

Внесение необходимых корректировок.

иеремещение

Передача данных из одной системы в другую

Загрузка

Вставка данных в базу данных.

Как видно из рис. 8.2, рис. 8.3 и рис. 8 4, эти этапы могут быть организованы по-разному - в зависимости от того, когда и где выполняется

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

fзагрузка

извлечение -

трансформация *

перемещение

✓

Рис. 8.2. Извлечение, трансформация, перемещение, загрузка (предпочтительный подход)

1 Щ загрузка

извлечение

трансформация гч/ трансформация

перемещение

Рис. 8.3. Извлечение, трансформация, перемещение, трансформация, загрузка (компромиссный подход)