В.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.