таты из предыдущего издания этой книги в разделе 5.3 этой главы.) Обратите внимание на то, что отношение пг не нормализовано (оно не содержит ровно по одному значению каждого атрибута в каждом кортеже). В действительности пг вовсе не является отношением в контексте релящ1онной модели. Как бы то ни было, в данной работе рассматривается один из вариантов идеи NF~. В частности, автор определяет для NF-отношений исчисление и алгебру (см. главы 6 и 7) и доказывает их эквивалентность. Он также ссылается на другие работы, посвященные этой теме. *

Ответы к некоторым упражнениям

5.1.

а) Очевидные изменения суммированы и даны ниже.

TABLE заменяется на RELVAR

COLUMN ATTRIBUTE

TABNAME RVNAME

COLCOUNT DEGREE

ROWCOUNT CARDINALITY (сокращенно - CARD)

COLNAME ATTRNAME

Обратите внимание, что переменная-отношение TABLE (теперь уже RELVAR) должна иметь еще один атрибут (RVKIND), значения которого указывают ее тип (базовая переменная-отношение или представление). Структура каталога будет выглядеть таким образом.

RELVAR

RVNAME DEGREE CARD RVKIND

ATTRIBUTE

RVNAME

ATTRNAME

6) Нужна новая переменная-отношение каталога (TYPE), содержащая элемент для каждого типа, а также новый атрибут (TYPENAME) в переменной-отношении ATTRIBUTE, представляющий тип каждого атрибута каждой переменной-отношения. Структура каталога будет подобна следующей. TYPE

TYPENAME

RELVAR RVNAME DEGREE CARD RVKIND

ATTRIBUTE RVNAME ATTRNAME TYPENAME

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

в) (ATTRIBUTE WHERE TYPENAME = NAME(EMPi)) {RVNAME}

Здесь обратите внимание на вызов оператора выбора NAME (см. ответ к упр. 5.2).

г) Если системой не поддерживаются типы, определенные пользователем, то очевидно, что невозможно написать запрос к каталогу относительно этих типов! Можно только написать запрос относительно атрибутов. Вообще говоря, ре-Глава 5. Домены, отношения и базовые переменные-отношения 185

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

TYPENAME определен на домене NAME

RVNAME NAME

ATTRNAME NAME

DEGREE NONNEG INTEGER

CARD NONNEG INTEGER

RVKIND RVKIND

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

NAME - это множество всех допустимых имен.

NONNEG INTEGER - множество неотрицательных целых чисел, не превышающих некоторый верхний предел.

RVKIND - это, грубо говоря, множество { Base , View }.

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

5.3.

а) TYPE Pi POSSREP ( CHAR ) ; TYPE QTY POSSREP ( INTEGER ) ;

VAR PART STRUCTURE BASE RELATION { MAJOR Pi Pi,

MINORPi PI,

QTY QTY } PRIMARY KEY { MAJOR Pi, MINORJI } ;

б) Ha рис. 5.4 показаны только новые элементы каталога. Обратите внимание, что элемент CARD в переменной-отношении RELVAR должен быть увеличен на единицу и для самой переменной-отношения RELVAR. Также кардинальность переменной-отношения PART STRUCTURE показана равной О, а не 7 (несмотря на то, что на рис. 4.6 она содержит семь кортежей), поскольку отношение, конечно же, будет пустым, если оно только что создано.

в) DROP VAR PART STRUCTURE ; DROP TYPE QTY ;

DROP TYPE PI :

TYPE

RELVAR

ATTRIBUTE

Рис. 5.4. Элементы каталога для переменной-отношения PART STRUCTURE

5.4. TYPE Si POSSREP ( CHAR )

POSSREP( CHAR )

POSSREP( CHAR )

POSSREP( CHAR )

TYPE Si TYPE NAME TYPE PI TYPE COLOR TYPE WEIGHT TYPE Jl TYPE QTY

POSSREP( RATIONAL POSSREP( CHAR ) ; POSSREP( INTEGER

VAR S BASE RELATION { SI SI,

SNAME NAME, STATUS INTEGER, CITY CHAR } PRIMARY KEY {SI},

VAR P BASE RELATION

{ Pt PNAME COLOR WEIGHT CITY

NAME, COLOR, WEIGHT, CHAR }

PRIMARY KEY { Pi }

VAR J BASE RELATION { Jl Jl, JNAME NAME, CITY CHAR } PRIMARY KEY { J }

VAR SPJ BASE RELATION { Si Si, PI Pi, Jl Jl, QTY QTY }