Разрешение ду?

Во многих случаях дуги можно трансформировать в конструкции под-тип-супертип. На рис. 3.28 показаны два варианта такой трансформации.

ACCOUNT

для... владелец...

, для... владелец...

PERSON

CORPORAflONi

Рис. 3.27. Дуга

ACCOUNT

PERSON

для... владелец...

ACCOUNT

IKeRSONIl ACCdONfi

PERSON

CORPORATE АССОи

в для... владелец

для... владелец...

CORPORA 4

Рис. 3 28. Преобразование дуги в конструкцию подтип-супертип

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

К сведению

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

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

Таблица 3.6. Реализация дуги при помощи пары внешних ключей и одного (родового) внешнего ключа

Решение 1а) Accounts (Счета)

Решение 16) Accounts (Счета)

Решение 16) часто называют родовой дугой. Здесь имеется один внешний ключ и столбец (в данном случае Holder Туре), который показывает, на какую таблицу ссылается этот внешний ключ. В Oracle? обычно более предпочтительным является решение 1а), поскольку для реализации этих отношений можно использовать ограничения по внешнему ключу. В решении 16) столбец Holder может содержать ссылку либо на таблицу физических лиц (PERSONS), либо на таблицу юридических лиц (CORPORATIONS), а определить условные ограничения по внешнему ключу невозможно. Поэтому для реализации решения 16) потребовалось бы создать триггеры. Они должны гарантировать, что если при вставке (а возможно, и при обновлении) столбец Holder Туре содержит значение Р, то столбец Holder ссылается на нужную строку в таблице PERSONS, а если Holder Туре содержит значение С, то столбец Holder ссылается на нужную строку в таблице CORPORATIONS.

Еще одно преимущество решения 1а) над решением 16) состоит в том, что для соединения таблиц используется более простой и понятный SQL-запрос:

/* 1а */

SELECT acc.credit limit ,асе.по

accounts асе

,persons per

per.id = acc.f per id

per.name = HEANEY;

FROM

WHERE AND

/* 16 */

SELECT acc.credit limit

,acc.no FROM accounts acc

,persons per WHERE per.id = acc.f hid id

AND асе.holder type = P AND per.name = HEANEY ;

2-it метод. Мы. должны разместить физических и юридических лиц в одной таблице, как показано в решении 1а) табл. 3.6. Это возможно лишь в случае, если физические и юридические лица имеют похожие атрибуты. Однако мы можем разместить в главной таблице только общие сведения и связать ее необязательными (условными) отношениями один ко одному с таблицами PERSONS и CORPORATIONS, содержащими характерные для каждой сущности атрибуты. В табл. 3.7 представлен пример того, как общие для физических и юридических лиц атрибуты реализованы в виде таблицы ACCOUNT HOLDERS (ВЛАДЕЛЬЦЫ СЧЕТОВ). Отметим, что в этом примере внешний ключ из ACCOUNTS на ACCOUNT HOLDERS может быть реализован через ограничение по внешнему ключу на ACCOUNTS.

Таблица 3.7. Реализация дуги при помощи подтипа, включающего общие атрибуты сущностей Accounts (Счета)

3-й метод. В этом решении (табл. 3.8) имеется внешний ключ из таблицы PERSONAL ACCOUNTS к таблице PERSONS и внешний ключ из таблицы CORPORATE ACCOUNTS к таблице CORPORATIONS. В обоих случаях столбец внешнего ключа должен быть столбцом с обязательными значениями - так вводится правило, согласно которому счет должен принадлежать какому-либо лицу: физическому или юридическому.

Таблица 3.8. Отдельные таблицы для счетов физических и юридических лиц Personal Accounts

1/ЪО