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

К сведению

Обратите внимание на ограничение WITH CHECK OPTION, Оно не даст использовать представление для вставки в таблицу строк, которые не удовлетворяют предложению WHERE запроса, использованного при создании представления. Следовательно, данное определение представления позволяет создавать только допустимые подтипы.

Все это создается следующим скриптом:

CREATE TABLE mc patients (Id NUMBER(9) NOT NULL

,ptype VARCHAR2(10) NOT NULL

CONSTRAINT mc pat ccl CHECK (ptype IN (INPATIENT

, OUTPATIENT))

,surname VARCHAR2(30) NOT NULL

,forename VARCHAR2(30) NOT NULL

,date of birth DATE ,f bal bed NUMBER(9)

,CONSTRAINT mc pat pk PRIMARY KEY (id) ,CONSTRAINT mc pat bal fк FOREIGN KEY

REFERENCES mc bed allocations ,CONSTRAINT mc pat cc2 CHECK (ptype = INPATIENT OR

f bal bed IS NULL));

CREATE VIEW mc outpatients v AS SELECT pat.id

, pat,surname , pat,forename , date of birth FROM mc patient3 pat WHERE pat.ptype = OUTPATIENT WITH CHECK OPTION CONSTRAINT mc opt ccl;

CREATE VIEW mc inpatients v , , .

Omnoiiiemm многие ко многим

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

назвать правильной или неправильной - все зависит от того, должна ли система регистрировать архивные данные.

АВТОМОБИЛЬ,

ДВИГАТЕЛЬ

л приводится 1 в движение...

установлен на...

Статическое

АВТОМОБИЛЬ

ДВИГАТЕЛЬ

b,jnpueoaumc установлен

** -в движение .Г. а ... -

Временное

Рис. 3.22. Статическое и временное представление одной и той же конструкции

Поскольку отношение многие ко многим нельзя непосредственно реализовать в реляционной базе данных, оно разрешается с помошыо новой сущности , размещаемой посередине. Так, пример на рис. 3.23 разрешается путем создания новой сущности, показанной на рис. 3.24. Эту новую сущность называют по-разному - связующей, ассоциативной или сущностью-пересечением. Если вам не приходит в голову никакое выразительное имя для этой сущности, можете назвать ее Entity] Entity2 Link ( Связь Сущность 1-Суицгость2 ) или как-нибудь вроде этого. На некоторой стадии вы, возможно, обнаружите, что связующая сущность имеет собственные атрибуты. В нашем примере новая сущность JOB TASK LINK может иметь важный атрибут - Task Order ( Порядок задач ), определяющий порядок выполнения задачи (TASK) в пределах задания (JOB). Если вы найдете новые атрибуты, обратитесь к аналитикам - зачем вам делать их работу? Если то, что вы обнаружили, является важным, то, как правило, это означает, что свою работу они сделали не до конца.

TASK

-состоит из

является частью...

Рис. 3.23. Отношение многие ко многим между заданиями и задачами

Наименование

Частота

JOB TASK LINK , TASK

Порядок задач i. i Наименование

I юрядок задач jq j

Рис 3 24 Разрешение отношения многие ко многим с помощью связующей сущности

Первичный ключ связующей сущности почти всегда состоит из комбинации внешних ключей сущностей, которые она связывает (такие сущности часто называют кардинальными). Когда мы приступаем к реализации этой сущности в виде таблицы, порядок, в котором определены компоненты ключа, имеет большое значение. Oracle может использовать индекс лишь в том случае, если известна его лидирующая порция (т.е. первый компонент). Если мы всегда перемещаемся по базе данных от задания к задаче (как это, скорее всего, и происходит в данном случае), то важно, чтобы первичный ключ сущности JOB TASK LINK был определен как (Job Name, Task Name) ( Имя задания , Имя задачи ). Если по отношению можно проходить в обоих направлениях (от задания к задаче и наоборот), то необходимо определить дополнительный индекс по имени задачи (Task Name) или имени задачи и имени задания (Task Name, Job Name). Дополнрггельная информация по этому вопросу и об индексах вообще предлагается в главе 6.

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

Такие же факторы действуют при удалении задания. Если у вас есть решение, то вы должны определить, как его реализовать. Фактически, оба варианта в данном случае лучше всего реализуются ограничениями по внешним ключам, предлагаемыми в Oracle. Простое включение ограничения по внешнему ключу будет препятствовать удалению, если существуют дочерние элементы; добавление части предложения CASCADE DELETE приводит к удалению дочерних элементов вместе с их родителем.

Отношения один к одному

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