6. Подмножество sql для определения данных: предложение create table, правила записи. Примеры.

Реляционная модель данных определяет два базовых требования целостности, которые поддерживаются любой РСУБД:

• требование целостности сущностей,

• требование целостности по ссылкам.

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

Кроме этого, могут быть установлены и следующие ограничения:

• UNIQUE – уникальность атрибутов; определяет альтернативные ключи отношения;

• NOT NULL – обязательность значения; при вставке новых или модификации существующих элементов отношения значения соответствующих атрибутов должны быть заданы;

• CHECK (условие) – допустимые значения атрибутов; вставляемые значения должны удовлетворять указанному условию.

Ссылочные ограничения целостности в РМД представляют собой условия, накладываемые на сосуществование кортежей в связанных отношениях. Как уже говорилось, в реляционной БД связи между отношениями представляются с помощью внешних ключей. Вернемся к примеру, в котором рассматривались отношения ОТДЕЛ и СОТРУДНИК:

ОТДЕЛ (Номер отдела, Название (АК))

СОТРУДНИК (Номер сотрудника, Имя, Год рождения, Номер отдела (FK))

Атрибут внешнего ключа Номер отдела в отношении СОТРУДНИК позволяет получить полную информацию о том конкретном отделе, в котором работает конкретный сотрудник.

Обычно отношение, в котором определяется внешний ключ, называется дочерним отношением, а отношение, на которое ссылается внешний ключ – родительским отношением. Так, в нашем примере отношение СОТРУДНИК – дочернее, а отношение ОТДЕЛ – родительское.

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

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

• при вставке нового элемента этот элемент должен иметь допустимое значение атрибутов внешнего ключа;

• удаление элемента выполняется без каких-либо ограничений;

• при модификации внешнего ключа некоторого элемента этот элемент должен получить допустимое значение атрибутов внешнего ключа.

Операции с родительским отношением выполняются следующим образом:

• вставка нового элемента выполняется без каких-либо ограничений;

• удаление элемента не должно привести к нарушению ссылочной целостности. Если в дочернем отношении существует элемент, ссылающийся на удаляемый элемент родительского отношения, как поступить с ним? Здесь возможны три подхода:

1. restrict – удаление элемента из родительского отношения не выполняется, если в дочернем отношении есть хотя бы один элемент, ссылающийся на удаляемый;

2. cascade – вместе с элементом родительского отношения удаляются все ссылающиеся на него элементы дочернего отношения;

3. set NULL – атрибутам внешнего ключа дочернего отношения присваивается пустое значение (каждая СУБД использует собственный способ задания пустого значения); этот подход возможен, если для атрибутов внешнего ключа дочернего отношения не установлено ограничение обязательности значения;

• модификация значения первичного ключа существующего элемента также не должна привести к нарушению ссылочной целостности. Здесь также возможны те же три подхода. При этом в случае cascade одинаковые изменения происходят и с элементом родительского отношения, и с элементом дочернего.

Например, отношение ДЕТАЛЬ на SQL для СУБД MS SQL Server м.б. определено так:

create table P (

P_ID smallint identity (1, 1) constraint P_PK primary key, --1

PNAME varchar (20) not null constraint P_UQ_01 unique, --2

PRICE money not null constraint P_CH_01 check (price > 0) --3

)

1 – определено ограничение первичного ключа (ограничение PRIMARY KEY, имя ограничения – P_PK), значения которого должны устанавливаться автоматически, начиная с 1 и с шагом 1 (т.е. в первой записи будет установлено значение 1, во второй – значение 2 и т.д.)

2 – определены ограничения уникальности (имя– P_UQ_01) и обязательности значения;

3 – определено условие (имя – P_CH_01): значение атрибута должно быть больше нуля.

Отношение ПОСТАВЩИК может быть определено следующим образом:

create table S (

S_ID smallint identity(1,1) constraint S_PK primary key,

SNAME varchar(30) not null,

ADDRESS varchar(80))

Теперь определим отношение связи ПОСТАВКА:

create table SP (

S_ID smallint not null constraint SP_FK_01 references S(S_ID), --1

P_ID smallint not null constraint SP_FK_02 references P(P_ID), --1

QTY int not null constraint SP_CH_01 check(QTY > 0),

constraint SP_PK primary key(S_ID, P_ID) --2

)

1 – определяется внешний ключ; в ограничении внешнего ключа (ключевое слово REFERENCES) указывается родительская таблица и ее первичный ключ; по умолчанию правило удаления определяется как restrict.

2 – определяется ограничение первичного ключа; так как в данном примере первичный ключ составной, определение первичного ключа дается как ограничение уровня таблицы (ограничение внешнего ключа в данном примере, устанавливаемое только для одного атрибута, является ограничением уровня атрибута).