6.1.2 Применение ограничений по ключу

в разделе 5.7.7 было сказано, что индексы не входят в стандарт SQL, но в каждой реализации SQL есть способ построения индексов в качестве части определения схемы БД. Обычно индекс строится на первичном ключе дпя поддержки запроса общего типа, определяющего значение этого первичного ключа. Можно также построить индексы иа других атрибутах, определенных с помошью UN QUE.

Заметим, что в примере 6.1 допустим любоП из эти.\ способов, так как пероичныП К-пюч - единственный атрибут. Но когда первичный к.1104 содержит более одного атрибута, необходимо применять способ, показанный на рнс. 6.2. Например, ключом oTHOHjeHHfl Movie является пара атрибутов title и year и при определении схемы этого отношения после списка агрибутов нужно ввести отдельную строку:

PRIMARY KEY (title, year)

Ключ опре.аеляется и с помощью ключевого слова UNIQUE, которое может стоять там же, где и слова PRIMARY KEY: либо за атрибутом и его ти1юм, либо в отдельно)! строке команды CREATE TABLE. Оно имеет такое же значение, как и определение первичного ключа, но определений UNIQUE может быть сколько угодно, а первичный ключ только один.

Пример 6.2. Строку (2) рнс. 6.1 можно заменить строкой

2) name CHAR(30) UNIQUE, а строку (3) строкой

3) address VARCHAR(255) UNIQUE.

если считать, что две кинозвезды не могут иметь один и тог же адрес (сомнительное допушенне). Аналогичным образом строку (6) рис. 6.2 при желании можно заменить на

6) UNIQUE (name) □

Ограничение по ключу - ЭТО ограничение, введенное с помощью PRIMARY KEY или UNIQUE.

. -=-=~-=-=-=-=-=-=-=-=--~

г Первичные ключи и уникальные атрибуты

I Описания с помощью PRIMARY KEY и UNIQUE - почти синонимы. Разница между ними в том, что таблица может иметь единственный первичный ключ и произвольное множество атрибутов шш множеств атрибутов типа UNIQUE. Охшако есть между ними н более мелю1е различия.

1. Внешний ключ может ссылаться только на первичный ключ отношения.

2. Реализация системы управления БД может приписывать первичному ключу особый смысл, не предусмотренный стандартом SQL2. Например. СУБД всегда может помешать индекс (как было показано в разделе 6.1.2) на первичном ключе (даже если он состоит из нескольких атрибутов), но при этом требовать, чтобы пользователь явно вызывал индекс совсем на других атрибутах. Альтернативным образом таблица южeт быть всегда отсортирована по своему первичнсму ключу, если он есть.

Когда пункт запроса WHERE содержит условие, приравнивающее ключ к отдельному значению, например name = Audrey Hepburn в 01учае отношения MovieStar из примера 6.1, соответствующи! кортеж будет найден очень быстро, без просмотра всех кортежей отношения.

Во многих реа-пизациях SQL при создании индексов применяется команда с ключевым словом UNIQUE, которая делает атрибуг ключом и одновремснгю создает на нем индекс. Например, команда

CREATE UNIQUE INDEX Yearlndex ON IVlovie(year):

дает тот же результат, что и команда создания индекса из раздела 5.7.7, но при этом еще вводит ограничение уникальности на атрибрте year отношения Movie.

Рассмотрим, как система SQL применяет ограничение по ключу. В принципе ограничение нужно проверять при каждом изменении БД. Однако совершенно ясно, что ограничение по ключу для отношения R можег быть нарушено только при изменении этого отношения. Фактически у.ааление кортежей из R не может нарушить Офаничение, нарушение могут вызвать только вставка или изменение. Поэтому обычно система SQL проверяет ограничение по ключу только при введении кортежей в отношение или при его изменении.

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

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

6.1.3 Упражнения к разделу 6.1

Упражнение 6.1.1. В примере БД из раздела 3.9 ключи определены для всех отношений. Измените описания SQL-схемы из упражнения 5.7.1, включив в иих определения ключей для каждого из этих отношений. Учтите, что ключом для Starsin являются все три атрибута.

Упрожнснне 6.1.2. Предложите подходящие ключи для отношений БД персональных компьютеров из упражнения 4.1.1. Измените схему из упражнения 5.7.2, включив в нее определения этих ключей.

Упражнение 6.1.3. Предложите подходящие ключи для отношений БД боевых кораблей из упражнения 4.1.3. Измените схему из упражнения 5.7.3, включив в нее определения этих к.чючей.

6.2 Ссылочная целостность и внешние ключи

Второй важный вид ограничений на БД состоит в том, что значения определенных атрибутов должны иметь смысл. Например, считается, что атрибут presC# отношения Studio должен относиться к конкретному администратору фильмов. Согласно такому ограничению ссылочной целостности, если кортеж какого-то фильма имеет в своем компоненте presC# конкретное значение с, то оно не фикция,

а сертификат реального аяминнстраггора фильмов. В терминах БД реальный администратор - это админиортор, упомянутый в отношении MovieExec. Значет, в MovieExec должен быть кортеж со значением с атрибута свгШ.

6.2.1 Описание ограничений по внешнему ключу

в SQL атрибут или атрибуты одного отиошения можно объявтъ внешним юиочом, относящимся к атрибуту или атрибутам другого отношения (возможно, того же самого). При этом мо-ут быть два следствия:

1. Атрибугы второго отношения, на которые делается ссылка, должны стать в нем первичным ключом.

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

Внешний ключ можно внести двумя способами.

a) Если внешний ключ - единственный атрибут, за его именем и типом вводится описание того, что он ссылается на другой атрибут (который должен быть первичным ключом) какой-то таблицы. Форма такого описания:

REFERENCES <таблица> (<атрибут>)

b) При наличии в команде CREATE TABLE списка атрибутов за ним вводятся описания, означающие, что множество атрибутов является внешним ключом. Затем указывается таблица и ее атрибуты (которые должны быть первичным ключом), к которым относится этот внешний ключ. Форма

. такого описания:

FOREIGN KEY <атрибугы> REFERENCES <таблица> (<атрибуты>)

Пример 6.3. Допустим, нужно описать отношение

Studlo(name, address, presC#)

имеющее первичный ключ name и внешний ключ presC#, ссылающийся на cerW отношения

MovleExec(name, address. cert#, netWorth)

Ссылку presC# на cert# можно задать непосредственно:

CREATE TABLE Studio (

name CHAR(30) PRIMARY KEY,

address VARCHAR(255),

presC# INT REFERENCES MovleExec(cert#)

Ho можно ввести внешний ключ и отдельно:

CREATE TABLE Studio (

name CHAR(30) PRIMARY KEY. address VARCHAR{255), presC# INT,

FOREIGN KEY presC# REFERENCES MovieExec(cert#)