3. Преобразование конкретизации и обобщений объектных множеств

Теперь рассмотрим рис. 3. Объектное множество PERSON легко пре­образуется:

PERSON (SS#, NAME, ADDRESS)

Но что делать с объектом MARRIED-PERSON (ЖЕНАТЫЙ-ЧЕЛОВЕК)? Поскольку он является подобъектом объекта PERSON, он наследует атри­буты объекта PERSON. Кроме того, у него есть свои собственные атрибуты. Следовательно, мы выводим такую реляционную таблицу:

MARRIED-PERSON (SS#, NAME, ADDRESS, SPOUSE). Внешний ключ: SS# ссылается на PERSON

Рис. 3. Конкретизация объектного множества PERSON

Таким образом, конкретизация объектного множества будет иметь все атрибуты объектного множества, которое оно конкретизирует, плюс свои собственные атрибуты. Важно отметить, что ключ SS# таблицы конкрети­зации (MARRIED-PERSON в нашем примере) также является внешним ключом, указывающим на таблицу обобщения (в нашем случае, PERSON). Это так, поскольку каждый элемент конкретизированного множества должен лежать также в обобщающем множестве. Следовательно, NAME и ADDRESS в реляционной таблице MARRIED-PERSON содержат повторяю­щуюся информацию. Для того чтобы избежать такой избыточности данных, мы просто удалим из реляционной таблицы конкретизации все повторяю­щиеся не ключевые атрибуты. В конце концов наша реляционная таблица MARRIED-PERSON будет выглядеть следующим образом:

MARRIED-PERSON (SS#, SPOUSE)

Внешний ключ: SS# ссылается на PERSON.

4. Преобразование отношений

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

Отношения один – к - одному. Рассмотрим пример банка. Отношение HAS-CHKG-ACCOUNT (ИМЕЕТ ТЕКУЩИЙ СЧЕТ), пред­ставленное на рис. 4, имеет мощность один – к - одному. Это означает» что клиент имеет не более одного текущего счета и каждым текущим счетом пользуется только один клиент.

Рис. 4. Мощности отношений модели банка

Если мы решим, что ключами являются CUSTOMER-# (№-КЛИЕНТА) для CUSTOMER (КЛИЕНТ) и CH-ACCOUNT-# (НОМЕР-ТЕКУЩЕГО-СЧЕТА) для CHECKING-ACCOUNT (ТЕКУЩИЙ-СЧЕТ), то мы получим две реляционные таблицы, каждая из которых со­стоит из одного столбца:

CUSTOMER (CUSTOMER-#)

CHECKING-ACCOUNT (CH-ACCOUNT-#)

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

CUSTOMER (CUSTOMER-#, CH-ACCOUNT-#)

Внешний ключ: CH-ACCOUNT-# ссылается на CHECKING-ACCOUNT.

CHECKING-ACCOUNT (CH-ACCOUNT-#, CUSTOMER-#)

Внешний ключ: CUSTOMER-# ссылается на CUSTOMER.

Очевидно, что при таком решении данные дублируются, так как необхо­димой является только одна комбинация CUSTOMER-#, CH-ACCOUNT-#. Какую из них исключить? Если клиент не имеет текущего счета, то значе­ние атрибута CH-ACCOUNT-# таблицы CUSTOMER для этого клиента явля­ется пустым. В то же время в таблице CHECKING-ACCOUNT значение атри­бута CUSTOMER-# будет определено для каждого текущего счета. Это пока­зывают минимальные мощности отношения на рис. 4. Итак, минималь­ная мощность со стороны CHECKING-ACCOUNT равна нулю, тогда как ми­нимальная мощность со стороны CUSTOMER равна одному. Таким образом, в этом случае лучшим решением будет исключить CH-ACCOUNT-# из таб­лицы CUSTOMER. Мы получим:

CUSTOMER (CUSTOMER-#)

CHECKING-ACCOUNT (CH-ACCOUNT-#, CUSTOMER-#) Внешний ключ: CUSTOMER-# ссылается на CUSTOMER

Разумеется, в полной схеме базы данных для реального приложения обе эти таблицы будут иметь множество других атрибутов. Здесь мы показываем только те атрибуты, которые нужны для преобразования простой концепту­альной модели, приведенной на рис. 4. Если бы объектные множества на рис. 4 имели другие атрибуты, то они были бы помещены в соответст­вующие таблицы. Разумеется, объект CUSTOMER может иметь атрибуты NAME, ADDRESS, PHONE-# (№-ТЕЛЕФОНА), a CHECKING-ACCOUNT мо­жет иметь атрибуты BALANCE (БАЛАНС) и DATE-OPENED (ДАТА-ОТКРЫТИЯ). Эти дополнительные атрибуты следующим образом видоизме­няют схему нашей базы данных:

CUSTOMER (CUSTOMER-#, NAME, ADDRESS, PHONE-#)

CHECKING-ACCOUNT(CH-ACCOUNT-#, CUSTOMER-#, BALANCE, DATE-OPENED)

Внешний: ключ: CUSTOMER-# ссылается на CUSTOMER

Резюме: отношение один – к - одному преобразуется путем помещения од­ного из объектных множеств в качестве атрибута в таблицу второго объект­ного множества. Его выбор определяется потребностями конкретного при­ложения. Во многих случаях оба варианта приемлемы.

Отношение один – ко - многим. Предположим, что отношение HAS-CHKG-ACCOUNT (ИМЕЕТ-ТЕКУЩИЙ-СЧЕТ) имеет мощность «много» со стороны CHECKING-ACCOUNT. Это означает, что у клиента может быть несколько текущих счетов, но каждым текущим счетом по-прежнему пользуется только один клиент. В этом случае мощность один – ко - многим сама по себе определяет следующую структуру реляционных таблиц:

CHECKING-ACCOUNT (CH-ACCOUNT-#, CUSTOMER-#) Внешний ключ: CUSTOMER-# ссылается на CUSTOMER

CUSTOMER (CUSTOMER-#)

Таким образом, в любом отношении один – ко - многим в таблицу, описы­вающую объект, мощность со стороны которого равна «многим», включается столбец, являющийся внешним ключом, указывающим на другой объект. В нашем примере объект, мощность со стороны которого равна «многим», опи­сывает таблица CHECKING-ACCOUNT, поэтому в нее включается внешний ключ CUSTOMER-#.

Отношение много – ко - многим. На рис. отношение ИМЕЕТ-CHECKING-ACCOUNT имеет мощность много – ко - многим. Таким образом, мы предполагаем, что у клиента может быть несколько текущих счетов, и что каждым текущим счетом могут пользоваться несколько клиентов.

Рис. 5. Отношение модели банка, имеющее мощность много – ко - многим

Для того чтобы преобразовать отношение много – ко - многим, мы создаем таблицу пере­сечения. В нашем случае нам потребуются три таблицы: по одной на каждое объектное множество и одна для отношения HAS-CHKG-ACCOUNT:

CUSTOMER (CUSTOMER-#)

CHECKING-ACCOUNT (CH-ACCOUNT-#)

HAS-CHKG-ACCOUNT (CUSTOMER-#, CH-ACCOUNT-#)

Внешние ключи: CUSTOMER-# ссылается на CUSTOMER

CH-ACCOUNT-# ссылается на CHECKING-ACCOUNTТаблица пересечения. Таблица, представляющая элементы двух других таблиц, находящихся в отношении много -ко- многим.

Поскольку CUSTOMER-# не определяет CH-ACCOUNT-#, а СН-ACCOUNT-# не определяет CUSTOMERS, ключом таблицы HAS-GHKG-ACCOUNT будут оба этих столбца. Таблица HAS-CHKG-ACCOUNT содержит данные, определяющие, какие клиенты владеют каждым текущим счетом, На рис. 6 представлены образцы данных наших трех таблиц.

Рис. 6. Таблица пересечения для отношения много – ко - многим

Обратите внимание, что каждый из клиентов 1111 и 2222 имеет по два разных теку­щих счета, а каждым из счетов ТС777 и ТС888 владеют два разных клиента. Эти отношения показывает таблица HAS-CHKG-ACCOUNT.

Обратите также внимание, что в таблице HAS-CHKG-ACCOUNT исполь­зованы только ключевые столбцы таблиц CUSTOMER и CHECKING-ACCOUNT. Таким образом, даже если бы таблицы CUSTOMER и CHECKING-ACCOUNT имели дополнительные столбцы, таблица HAS-CHKG-ACCOUNT содержала бы только ключевые столбцы этих двух таблиц. Это иллюстри­рует следующая схема:

CUSTOMER (CUSTOMER-#, NAME, ADDRESS, PHONE-#) CHECKING-ACCOUNT (CH-ACCOUNT-#, BALANCE, DATE OPENED) HAS-CHKG-ACCOUNT (CUSTOMER-#, CH-ACCOUNT-#])

Внешние ключи:

CUSTOMER-# ссылается на CUSTOMER

CH-ACCOUNT-# ссылается на CHECKING-ACCOUNT.

Описания внешних ключей показывают, что оба ключевых атрибута таблицы HAS-CHKG-ACCOUNT являются также внешними ключами. Таб­лица HAS-CHKG-ACCOUNT называется таблицей пересечения, так как она показывает, как связаны элементы таблиц CUSTOMER и CHECKING-ACCOUNT. Как мы увидим в следующем разделе, таблица пересечения, та­кая как HAS-CHKG-ACCOUNT, может иметь дополнительные неключевые атрибуты, присущие только ей.