В.9. РАЗЛИЧНЫЕ СОВЕТЫ И РЕКОМЕНДАЦИИ

 

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

 

Составные ключи

Использование составных (состоящих из нескольких полей) первичных ключей может оказаться весьма неудобным. Если выясняется, что в Вашем проекте имеется таблица с составным первичным ключом, примите во внимание те преимущества, которые обеспечиваются введением нового, несоставного поля, которое могло бы служить первичным ключом вместо первоначально выбранного. Например, можно ввести в таблицу SP поле номера поставки НОМЕР_ПОСТАВКИ.

 

Подтипы сущностей

Иногда заданная сущность может быть одновременно нескольких типов. Один и тот же человек, например, может быть одновременно служащим, акционером и покупателем. Кроме того, некоторые типы сущностей являются подтипами других типов. Так, все директора являются служащими. Тип сущностей Y называется подтипом типа сущностей X, если каждый экземпляр Y обязательно является экземпляром X. Все свойства, обозначения и т. д., относящиеся к X, относятся также и к Y, но не наоборот. Например, директора имеют зарплату, поскольку зарплату имеют все служащие, но они имеют также и бюджет, которого не имеют служащие, не являющиеся директорами. Такая ситуация может быть удобно представлена следующим образом (снова с помощью псевдоЯОД):

 

CREATE TABLE СЛУЖАЩИЕ /* служащие (стержневые сущности)*/

PRIMARY KEY (НОМЕР_СЛУЖАЩЕГО)

FIELDS (НОМЕР_СЛУЖАЩЕГО . . ., ЗАРПЛАТА . . .);

CREATE TABLE ДИРЕКТОРА /* директора — подтип типа сущностей

СЛУЖАЩИЕ*/

PRIMARY KEY (НОМЕР_СЛУЖАЩЕГО)

FOREIGN KEY (НОМЕР_СЛУЖАЩЕГО

IDENTIFIES СЛУЖАЩИЕ и т. д.)

FIELDS (НОМЕР_СЛУЖАЩЕГО . .., БЮДЖЕТ . . .);

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

Домены

Хотя система DB2 не поддерживает понятие домена, оно может быть все же полезно в процессе проектирования и может быть, однако, представлено средствами псевдоЯОД. Например;

CREATE DOMAIN НОМЕР_СЛУЖАЩЕГО CHAR (5); /*номера

поставщиков */

CREATE TABLE S

FIELDS (НОМЕР_СЛУЖАЩЕГО DOMAIN

(НОМЕР_СЛУЖАЩЕГО), . . .);

CREATE TABLE SP

FIELDS (НОМЕР_СЛУЖАЩЕГО DOMAIN

(НОМЕР_СЛУЖАЩЕГО), . . .);

Рекомендация. Всегда, когда это возможно, следует давать каждому полю то же самое имя, что и у определяющего домена. Если же такой возможности нет, давайте полю имя этого домена с использованием некоторого уточнителя в качестве префикса, который обеспечивает уникальность полного имени в содержащей его таблице Так, например, можно использовать НОМЕР_ПОСТАВЩИКА, S.HOMEP_ПОСТАВЩИКА или SP.HOMEP_ПOСТАВЩИКА и т. д. в качестве имен полей, содержащих номера поставщиков. Не используйте, например, НОМЕР_ПОСТАВЩИКА в одной таблице, НОМ_ПОСТ — в другой, а НОМЕР_ПОСТ — в третьей и т. д. Одна из причин использования этого правила состоит в том, что оно облегчает жизнь пользователю— нужно запоминать меньше различных имен, допускается меньше произвола. Другая, возможно, более важная причина—это правило позволяет с помощью запроса к каталогу узнать все случаи использования данного домена. Например:

SELECT NAME, TBNAME

FROM SYSIBM. SYSCOLUMNS

WHERE NAME LIKE ' % НОМЕР_ПОСТАВЩИКА';