Читаем Базы данных: конспект лекций полностью

Create tableимя базового отношения

{имя базового атрибута

тип значений базового атрибута

check (ограничение значения атрибута)

{Null | not Null}

default (значение по умолчанию)

},..

[имя виртуального атрибута

as (формула вычисления)

],..

[,check (ограничение кортежа)]

[,primary key (имя атрибута,..)]

[,candidate key (имя атрибута,..)]…

[,foreign key (имя атрибута,..) referencesимя ссылочного отношения (имя атрибута,..)

on update {Restrict | Cascade | Set Null}

on delete {Restrict | Cascade | Set Null}

]…

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

Далее рассмотрим подробнее механизм объявления базовых атрибутов.

При описании в операторе создания базового отношения любого атрибута в общем случае задаются его имя, тип, ограничения его значений, флажок допустимости Null-значений и значения по умолчанию. Нетрудно понять, что тип атрибута и ограничения его значений определяют его домен, т. е. буквально множество допустимых значений данного конкретного атрибута. Ограничение значений атрибута записывается как условие, зависящее от имени атрибута. Вот небольшой пример для облегчения понимания этого материала:

Create tableимя базового отношения

Курс

integer

check (1 = Курс and Курс = 5;

Здесь условие «1 = Курс and Курс = 5» вместе с определением целого типа данных действительно полностью обусловливают множество допустимых значений атрибута, т. е. буквально его домен.

Флажок допустимости Null-значений (Null | not Null) запрещает (not Null) или, наоборот, разрешает (Null) появление Null-значений среди значений атрибутов.

Если взять рассмотренный только что пример, то механизм применения флажков допустимости Null-значений выглядит следующим образом:

Create tableимя базового отношения

Курс

integer

check (1 = Курс and Курс = 5);

Not Null;

Итак, порядковый номер курса студента никогда не может принимать Null-значения, не может быть неизвестным составителям базы данных и не может не существовать.

Значения по умолчанию (default (значение по умолчанию)) используются при вставке кортежа в отношения, если в операторе вставки значения атрибутов явно не заданы.

Интересно заметить, что значения по умолчанию могут быть и Null-значениями, если только Null-значения для данного конкретного атрибута объявлены допустимыми.

Теперь рассмотрим определение виртуального атрибута в операторе создания базового отношения.

Как мы уже говорили ранее, задание виртуального атрибута заключается в задании формул его вычисления через другие базовые атрибуты. Рассмотрим пример объявления виртуального атрибута «Стоимость Руб.» в виде формулы, зависящей от базовых атрибутов «Вес Кг» и «Цена Руб. за Кг».

Create tableимя базового отношения

Вес Кг

тип значений базового атрибута Вес Кг

check (ограничение значения атрибута Вес Кг)

not Null

default (значение по умолчанию)

Цена Руб. за Кг

тип значений базового атрибута Цена Руб. за Кг

check (ограничение значения атрибута Цена Руб. за Кг)

not Null

default (значение по умолчанию)

Стоимость Руб.

as (Вес Кг * Цена Руб. за Кг)

Чуть выше мы рассмотрели ограничения атрибутов, которые записывались как условия, зависящие от имен атрибутов. Теперь рассмотрим второй вид ограничений, объявляемых при создании базового отношения, а именно ограничения кортежа.

Что такое ограничение кортежа, чем оно отличается от ограничения атрибута? Ограничение кортежа тоже записывается как условие, зависящее от имени базового атрибута, но только в случае ограничения кортежа, условие может зависеть от нескольких имен атрибутов одновременно.

Рассмотрим пример, иллюстрирующий механизм работы с ограничениями кортежей:

Перейти на страницу:

Похожие книги

97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

Успешная карьера архитектора программного обеспечения требует хорошего владения как технической, так и деловой сторонами вопросов, связанных с проектированием архитектуры. В этой необычной книге ведущие архитекторы ПО со всего света обсуждают важные принципы разработки, выходящие далеко за пределы чисто технических вопросов.?Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT