Geum.ru

Дейт К. Д27 Руководство по реляционной субд db2/ Пер с англ и предисл. М. Р. Когаловского

Вид материалаРуководство
В.4. процедура проектирования: последовательность основных шагов
В.5. регистрация проектных решений: псевдояод
Подобный материал:
1   ...   26   27   28   29   30   31   32   33   34

В.4. ПРОЦЕДУРА ПРОЕКТИРОВАНИЯ: ПОСЛЕДОВАТЕЛЬНОСТЬ ОСНОВНЫХ ШАГОВ



Теперь мы имеем возможность представить последовательность основных шагов процедуры проектирования.

Примечание. В последующем для краткости вместо «тип сущностей» будем говорить «сущность».

1. Представьте каждый стержень (независимую сущность) как базовую таблицу. Специфицируйте первичный ключ этой базовой таблицы.

2. Представьте каждую ассоциацию (связь вида «многие-ко-многим» или «многие-ко-многим-ко-многим» и т. д. между сущностями) как базовую таблицу. Используйте в этой таблице внешние ключи для идентификации участников ассоциации. Специфицируйте ограничения, связанные с каждым из этих внешних ключей. Специфицируйте первичный ключ этой таблицы, являющийся, вероятно, комбинацией всех внешних ключей, идентифицирующих участников ассоциации.

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

4. Представьте каждое обозначение (связь вида «многие-к-одной» между двумя сущностями), с которыми мы еще не имели дела в п. 3, как внешний ключ в базовой таблице, представляющей обозначающую сущность. Специфицируйте связанные с каждым таким внешним ключом ограничения.

5. Представьте каждое свойство как поле в базовой таблице, представляющей сущность, которая непосредственно описывается чтим свойством.

6. Используйте для первичных и внешних ключей рецепты, приведенные ниже в разделах В.6 и В.7.

7. Для того чтобы исключить в проекте непреднамеренные нарушения каких-либо принципов нормализации, выполните процедуру, описанную в разделе В.8.

8. Повторяйте перечисленные шаги до тех пор, пока не будет завершена разработка проекта.

В.5. РЕГИСТРАЦИЯ ПРОЕКТНЫХ РЕШЕНИЙ: ПСЕВДОЯОД



Когда осуществляется процесс проектирования, необходимо, конечно, регистрировать принимаемые проектные решения, и лучше это делать некоторым более или менее формальным образом. Вопрос состоит в том, какой следует использовать для этого формализм. Есть много возможных ответов на этот вопрос, и ни один из них не является, очевидно, более предпочтительным, чем остальные. Это, до некоторой степени,— исключительно дело вкуса. Однако одним из весомых кандидатов на роль такого формализма являются предложения языка определения данных (предложения ЯОД). В конце концов, такие предложения рано или поздно должны быть сформулированы, когда проект будет трансформироваться в определение базы данных. К сожалению, одни только предложения ЯОД системы DB2 оказываются неадекватными поставленной задаче по той важной причине, что они не поддерживают некоторых понятий, в частности, первичных и внешних ключей, что чрезвычайно критично для процесса проектирования, как мы уже могли убедиться. Поэтому здесь предлагается формализм, который можно было бы назвать «псевдоЯОД». ПсевдоЯОД основан на обычном ЯОД, входящем в SQL, но включает конструкции для непосредственной поддержки необходимых отсутствующих понятий. Рассмотрим, например, тип стержневых сущностей «поставщики». Уже говорилось, что каждый тип стержневых сущностей будет отображаться в базовую таблицу системы DB2. Таким образом, можно было бы написать предложение псевдоЯОД:

CREATE TABLE S /* поставщики (стержневые сущности) * /

PRIMARY KEY (НОМЕР_ПОСТАВЩИКА)

FIELDS (НОМЕР_ПОСТАВЩИКА . . . );

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

Ниже приведен пример предложения псевдоЯОД для поставок, показывающий возможное множество спецификаций внешних ключей:

CREATE TABLE SP /*поставки — связывает S и Р*/

PRIMARY KEY (НОМЕР_ПОСТАВЩИКА, НОМЕР_ДЕТАЛИ)

FOREIGN KEY (НОМЕР_ПОСТАВЩИКА IDENTIFIES S

NULLS NOT ALLOWED

DELETE OF S.RESTRICTED

UPDATE OF S. НОМЕР_ПОСТАВЩИКА

CASCADES)

FOREIGN KEY (НОМЕР_ДЕТАЛИ IDENTIFIES P

NULLS NOT ALLOWED

DELETE OF P.RESTRICTED

UPDATE OF P.НОМЕР_ДЕТАЛИ

RESTRICTED)

FIELDS (НОМЕР_ПОСТАВЩИКА . . ., НОМЕР_ДЕТАЛИ . .

., КОЛИЧЕСТВО . . .);

Фразы PRIMARY KEY (первичный ключ) и FOREIGN KEY (внешний ключ) в псевдоЯОД имеют следующий общий синтаксис:

Фраза-PRIMARY-KEY

:: = PRIMARY KEY (первичный—ключ),

где «первичный — ключ» — это либо единственное имя-поля, например НОМЕР_ПОСТАВЩИКА, либо заключенный в круглые скобки список имен-полей, разделенных запятыми, например (НОМЕР_ПОСТАВЩИКА, НОМЕР_ДЕТАЛИ).

Фраза-FOREIGN-KEY

: : = FOREIGN KEY (внешний—ключ IDENTIFIES цель

NULLS [NOT] ALLOWED

DELETE OF цель эффект

UPDATE OF первичный — ключ — цели эффект),

где а) «внешний—ключ»—то же самое, что было сказано выше о «первичном-ключе», т. е. либо единственное имя-поля, либо заключенный в круглые скобки список имен-полей, разделенных запятыми; б) «цель» — имя-таблицы; в) «первичный-ключ-цели» специфицирует «первичный-ключ» для «цели» и, наконец, г) «эффект—CASCADES (каскадируется), RESTRICTED (ограничивается) или NULLIFIES (устанавливается неопределенное значение).

Примечание. Фразы PRIMARY KEY и FOREIGN KEY, подобные приведенным выше, были бы в высшей степени желательными расширениями существующего ЯОД системы DB2.