Целостность полей целостность сущностей ссылочная целостность реферат
Обновлено: 02.07.2024
• Ограничение целостности – это логическое
выражение, связанное с некоторой базой
данных, результатом вычисления которого
всегда должно быть значение TRUE
– Ограничения должны быть явно указаны на
языке БД, после чего СУБД будет
автоматически контролировать их при
выполнении операций вставки и обновления
3. Виды ограничений целостности
• Ограничения базы данных
– Ограничение на значения, которые разрешено
принимать переменным отношения в базе данных
• Относится к двум или более переменным отношения
• Ограничения переменной отношения
– Ограничение на значения, которые разрешено
принимать конкретной переменной отношения
• Ограничения атрибута
– Ограничение на значения, которые разрешено
принимать указанному атрибуту
• Определяется типом атрибута
4. Предикаты
• Предикат – это выражение, принимающее
логическое значение (Истина/Ложь),
определяемое на основании значений
указанных переменных
5. Предикаты в СУБД
• В СУБД для предикатов используется
трехуровневая логика (3VL) и предикат
может принимать три значения
– TRUE (Истина)
– FALSE (Ложь)
– UNKNOWN (Неизвестно)
6. Предикаты в СУБД
• Комбинации предикатов
– FALSE AND UNKNOWN = FALSE
– TRUE AND UNKNOWN = UNKNOWN
– FALSE OR UNKNOWN = UNKNOWN
– TRUE OR UNKNOWN = TRUE
7. Предикаты в SQL
Сравнения (отношения)
Попадания во множество (IN)
Принадлежности диапазону (BETWEEN)
Подобия (LIKE)
Проверки NULL-значений
8. Предикаты в SQL
• Сравнения (отношения)
– [NOT] <=|>| =| >
• Числа сравниваются по их значениям
• Символьные строки сравниваются по алфавиту
– Если строки разной длины, то более короткая строка
дополняется пробелами до необходимой длины
• Дата и время сравнивается в хронологическом
порядке
– Если хотя бы одно выражение имеет значение
NULL – результат сравнения UNKNOWN
9. Предикаты в SQL
• Попадания во множество
– IN::=
[NOT] IN
<( ) | ( . )>
• SELECT должен сформировать столбец значений,
совместимых по типу с проверяемым выражением
• Если SELECT возвратил пустую таблицу – результат
будет FALSE
10. Предикаты в SQL
11. Предикаты в SQL
12. Предикаты в SQL
13. Ограничения целостности в SQL
• Ограничения целостности накладываются на
значения атрибутов таблицы
–
–
–
–
–
NOT NULL
UNIQUE
PRIMARY KEY
FOREIGN KEY
CHECK
• Этот набор ограничений шире, чем требует
формальное определение ограничения
целостности
14. Ограничения целостности в SQL
• NOT NULL
– Значение атрибут должно быть обязательно
установлено (значение NULL не допускается)
• UNIQUE
– Все значения атрибута в колонке должны быть
различными (уникальными)
– Значение NULL является допустимым и может
быть у любого числа атрибутов в колонке
15. Ограничения целостности в SQL
• PRIMARY KEY
– Задает ограничение первичного ключа
• значение атрибута должно быть установлено
(значение NULL недопустимо)
• значение атрибута должно быть уникально для
однозначной идентификации строки таблицы по
значению этого атрибута
– Представляет собой комбинацию ограничений
NOT NULL и UNIQUE
16. Ограничения целостности в SQL
• FOREIGN KEY (внешний ключ)
– Задает ограничение внешнего ключа
• Значение атрибута должно быть установлено
(значение NULL недопустимо)
• Значение атрибута должно выбираться из числа
существующих значений первичного ключа другой
таблицы (существующей)
– Позволяет однозначно идентифицировать
строку другой таблицы
17. Ограничения целостности в SQL
• CHECK
– Проверяет, что значение атрибута
удовлетворяет заданным условиям
• Например CHECK (a > b AND c )
REFERENCES [ ( ) ]
[ON DELETE ]
[ON UPDATE ]
• Ссылочные действия
–
–
–
–
–
NO ACTION
RESTRICT
CASCADE
SET DEFAULT
SET NULL
Во второй части реляционной модели данных определяются два ограничения, которые должны выполняться в любой реляционной базе данных. Это:
Целостность внешних ключей.
Прежде, чем описывать целостность сущностей, необходимо описать использование null-значений в реляционных базах данных.
Основное назначение баз данных состоит в том, чтобы хранить и предоставлять информацию о реальном мире. Для представления этой информации в базе данных используются привычные для программистов типы данных - строковые, численные, логические и т.п. Однако в реальном мире часто встречается ситуация, когда данные неизвестны или не полны. Например, место жительства или дата рождения человека могут быть неизвестны (база данных разыскиваемых преступников). Если вместо неизвестного адреса уместно было бы вводить пустую строку, то что вводить вместо неизвестной даты? Ответ - пустую дату - не вполне удовлетворителен, т.к. простейший запрос "выдать список людей в порядке возрастания дат рождения" даст заведомо неправильных ответ.
Для того чтобы обойти проблему неполных или неизвестных данных, в базах данных могут использоваться типы данных, пополненные так называемым null-значением. Null-значение - это, собственно, не значение, а некий маркер, показывающий, что значение неизвестно.
Таким образом, в ситуации, когда возможно появление неизвестных или неполных данных, разработчик имеет на выбор два варианта.
Первый вариант состоит в том, чтобы ограничиться использованием обычных типов данных и не использовать null-значения, а вместо неизвестных данных вводить либо нулевые значения, либо значения специального вида - например, договориться, что строка "АДРЕС НЕИЗВЕСТЕН" и есть те данные, которые нужно вводить вместо неизвестного адреса. В любом случае на пользователя (или на разработчика) ложится ответственность на правильную трактовку таких данных. В частности, может потребоваться написание специального программного кода, который в нужных случаях "вылавливал" бы такие данные. Проблемы, возникающие при этом очевидны - не все данные становятся равноправны, требуется дополнительный программный код, "отслеживающий" эту неравноправность, в результате чего усложняется разработка и сопровождение приложений.
Второй вариант состоит в использовании null-значений вместо неизвестных данных. За кажущейся естественностью такого подхода скрываются менее очевидные и более глубокие проблемы. Наиболее бросающейся в глаза проблемой является необходимость использования трехзначной логики при оперировании с данными, которые могут содержать null-значения. В этом случае при неаккуратном формулировании запросов, даже самые естественные запросы могут давать неправильные ответы. Есть более фундаментальные проблемы, связанные с теоретическим обоснованием корректности введения null-значений, например, непонятно вообще, входят ли null-значения в домены или нет.
Вопрос о проблемах использования null-значений в теории реляционных баз данных окончательно не решен. Основоположник реляционного подхода Кодд считал null-значения неотъемлемой частью реляционной модели, хотя К. Дейт выступает против null-значений[8] .
2.2 Потенциальные ключи и целостность сущностей
По определению, тело отношения есть множество кортежей, поэтому отношения не могут содержать одинаковые кортежи. Это значит, что каждый кортеж должен обладать свойством уникальности. На самом деле, свойством уникальности в пределах отношения могут обладать отдельные атрибуты кортежей или группы атрибутов. Такие уникальные атрибуты удобно использовать для идентификации кортежей.
Пусть дано отношение . Подмножество атрибутов отношения будем называть потенциальным ключом, если обладает следующими свойствами:
Свойством уникальности - в отношении не может быть двух различных кортежей, с одинаковым значением .
Свойством неизбыточности - никакое подмножество в не обладает свойством уникальности.
Любое отношение имеет по крайней мере один потенциальный ключ. Действительно, если никакой атрибут или группа атрибутов не являются потенциальным ключом, то, в силу уникальности кортежей, все атрибуты вместе образуют потенциальный ключ. Потенциальный ключ, состоящий из одного атрибута, называется простым. Потенциальный ключ, состоящий из нескольких атрибутов, называется составным. Отношение может иметь несколько потенциальных ключей. Традиционно, один из потенциальных ключей объявляется первичным, а остальные - альтернативными. Различия между первичным и альтернативными ключами могут быть важны в конкретной реализации реляционной СУБД, но с точки зрения реляционной модели данных, нет оснований выделять таким образом один из потенциальных ключей. Понятие потенциального ключа является семантическим понятием и отражает некоторый смысл (трактовку) понятий из конкретной предметной области. Для того чтобы проиллюстрировать этот факт, рассмотрим отношение "Сотрудники" (Приложение 1).
При первом взгляде на таблицу, изображающую это отношение, может показаться, что в таблице имеется три потенциальных ключа - в каждой колонке таблицы содержатся уникальные данные. Однако среди сотрудников могут быть однофамильцы и сотрудники с одинаковой зарплатой. Табельный же номер по сути свой уникален для каждого сотрудника. Какие же соображения привели нас к пониманию того, что в данном отношении только один потенциальный ключ - "Табельный номер"? Именно понимание смысла данных, содержащихся в отношении.
Попробуем представить это отношение в другом виде, изменив наименования атрибутов:
| A | B | C |
| 1 | Иванов | 1000 |
| 2 | Петров | 2000 |
| 3 | Сидоров | 3000 |
Предъявим кому-нибудь эту таблицу и не сообщим смысл наименований атрибутов. Очевидно, что невозможно судить, не понимая смысла данных, может или не может в этом отношении появиться, например, кортеж (1, Петров, 3000). Если бы, кстати, такой кортеж появился (что, на первый взгляд, вполне возможно, т.к. не нарушается уникальность кортежей), то мы точно смогли бы сказать, что не является альтернативным ключом - ни один из атрибутов по отдельности. Но мы не сможем сказать, что же является первичным ключом[9] .
Потенциальные ключи служат средством идентификации объектов предметной области, данные о которых хранятся в отношении. Объекты предметной области должны быть различимы.
Потенциальные ключи служат единственным средством адресации на уровне кортежей в отношении. Точно указать какой-нибудь кортеж можно только зная значение его потенциального ключа.
Т.к. потенциальные ключи фактически служат идентификаторами объектов предметной области (т.е. предназначены для различения объектов), то значения этих идентификаторов не могут содержать неизвестные значения. Действительно, если бы идентификаторы могли содержать null-значения, то мы не могли бы дать ответ "да" или "нет" на вопрос, совпадают или нет два идентификатора.
Это определяет следующее правило целостности сущностей:
Атрибуты, входящие в состав некоторого потенциального ключа не могут принимать null-значений.
Объект реального мира представляется в реляционной базе данных как кортеж некоторого отношения. Требование целостности сущностей заключается в следующем:
каждый кортеж любого отношения должен отличатся от любого другого кортежа этого отношения (т.е. любое отношение должно обладать первичным ключом).
- при добавлении записей в таблицу проверяется уникальность их первичных ключей
- не позволяется изменение значений атрибутов, входящих в первичный ключ.
4.3.2. Целостность ссылок
- Связи между данными отношениями описываются в терминах функциональных зависимостей.
- Для отражения функциональных зависимостей между кортежами разных отношений используется дублирование первичного ключа одного отношения (родительского) в другое (дочернее). Атрибуты, представляющие собой копии ключей родительских отношений, называются внешними ключами.
для каждого значения внешнего ключа, появляющегося в дочернем отношении, в родительском отношении должен найтись кортеж с таким же значением первичного ключа.
Пусть, например, даны отношения ОТДЕЛ ( N_ОТДЕЛА , ИМЯ_ОТДЕЛА) и СОТРУДНИК ( N_СОТРУДНИКА , N_ОТДЕЛА, ИМЯ_СОТРУДНИКА), в которых хранятся сведения о работниках предприятия и подразделениях, где они работают. Отношение ОТДЕЛ в данной паре является родительским, поэтому его первичный ключ "N_отдела" присутствует в дочернем отношении СОТРУДНИК. Требование целостности по ссылкам означает здесь, что в таблице СОТРУДНИК не может присутствовать кортеж со значением атрибута "N_отдела" , которое не встречается в таблице ОТДЕЛ. Если такое значение в отношении ОТДЕЛ отсутствует, значение внешнего ключа в отношении СОТРУДНИК считается неопределенным.
Как правило, поддержание целостности ссылок также возлагается на систему управления базой данных. Например, она может не позволить пользователю добавить запись, содержащую внешний ключ с несуществующим (неопределенным) значением.
В заключение этого раздела отметим, что часто вместо выражения "целостность по ссылкам" употребляют его синонимы "ссылочная целостность", "целостность связей" или "требование внешнего ключа".
Когда в предыдущих разделах мы говорили об основных понятиях реляционных баз данных, мы не опирались на какую-либо конкретную реализацию. Эти рассуждения в равной степени относились к любой системе, при построении которой использовался реляционный подход.
Другими словами, мы использовали понятия так называемой реляционной модели данных. Модель данных описывает некоторый набор родовых понятий и признаков, которыми должны обладать все конкретные СУБД и управляемые ими базы данных, если они основываются на этой модели. Наличие модели данных позволяет сравнивать конкретные реализации, используя один общий язык.
Хотя понятие модели данных является общим, и можно говорить о иерархической, сетевой, некоторой семантической и т.д. моделях данных, нужно отметить, что это понятие было введено в обиход применительно к реляционным системам и наиболее эффективно используется именно в этом контексте. Попытки прямолинейного применения аналогичных моделей к дореляционным организациям показывают, что реляционная модель слишком "велика" для них, а для постреляционных организаций она оказывается "мала".
4.3.1. Общая характеристика
Наиболее распространенная трактовка реляционной модели данных, по-видимому, принадлежит Дейту, который воспроизводит ее (с различными уточнениями) практически во всех своих книгах. Согласно Дейту реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части.
В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение. По сути дела, в предыдущих двух разделах этой лекции мы рассматривали именно понятия и свойства структурной составляющей реляционной модели.
В манипуляционной части модели утверждаются два фундаментальных механизма манипулирования реляционными БД - реляционная алгебра и реляционное исчисление. Первый механизм базируется в основном на классической теории множеств (с некоторыми уточнениями), а второй - на классическом логическом аппарате исчисления предикатов первого порядка. Мы рассмотрим эти механизмы более подробно на следующей лекции, а пока лишь заметим, что основной функцией манипуляционной части реляционной модели является обеспечение меры реляционности любого конкретного языка реляционных БД: язык называется реляционным, если он обладает не меньшей выразительностью и мощностью, чем реляционная алгебра или реляционное исчисление.
4.3.2. Целостность сущности и ссылок
Наконец, в целостной части реляционной модели данных фиксируются два базовых требования целостности, которые должны поддерживаться в любой реляционной СУБД. Первое требование называется требованием целостности сущностей. Объекту или сущности реального мира в реляционных БД соответствуют кортежи отношений. Конкретно требование состоит в том, что любой кортеж любого отношения отличим от любого другого кортежа этого отношения, т.е. другими словами, любое отношение должно обладать первичным ключом. Как мы видели в предыдущем разделе, это требование автоматически удовлетворяется, если в системе не нарушаются базовые свойства отношений.
Второе требование называется требованием целостности по ссылкам и является несколько более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности реального мира представляются в реляционной БД в виде нескольких кортежей нескольких отношений. Например, представим, что нам требуется представить в реляционной базе данных сущность ОТДЕЛ с атрибутами ОТД_НОМЕР (номер отдела), ОТД_КОЛ (количество сотрудников) и ОТД_СОТР (набор сотрудников отдела). Для каждого сотрудника нужно хранить СОТР_НОМЕР (номер сотрудника), СОТР_ИМЯ (имя сотрудника) и СОТР_ЗАРП (заработная плата сотрудника). Как мы вскоре увидим, при правильном проектировании соответствующей БД в ней появятся два отношения: ОТДЕЛЫ ( ОТД_НОМЕР, ОТД_КОЛ ) (первичный ключ - ОТД_НОМЕР) и СОТРУДНИКИ ( СОТР_НОМЕР, СОТР_ИМЯ, СОТР_ЗАРП, СОТР_ОТД_НОМ ) (первичный ключ - СОТР_НОМЕР).
Как видно, атрибут СОТР_ОТД_НОМ появляется в отношении СОТРУДНИКИ не потому, что номер отдела является собственным свойством сотрудника, а лишь для того, чтобы иметь возможность восстановить при необходимости полную сущность ОТДЕЛ. Значение атрибута СОТР_ОТД_НОМ в любом кортеже отношения СОТРУДНИКИ должно соответствовать значению атрибута ОТД_НОМ в некотором кортеже отношения ОТДЕЛЫ. Атрибут такого рода называется внешним ключом, поскольку его значения однозначно характеризуют сущности, представленные кортежами некоторого другого отношения (т.е. задают значения их первичного ключа). Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом.
Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в отношении, на которое ведет ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать). Для нашего примера это означает, что если для сотрудника указан номер отдела, то этот отдел должен существовать.
Ограничения целостности сущности и по ссылкам должны поддерживаться СУБД. Для соблюдения целостности сущности достаточно гарантировать отсутствие в любом отношении кортежей с одним и тем же значением первичного ключа. С целостностью по ссылкам дела обстоят несколько более сложно.
Понятно, что при обновлении ссылающегося отношения (вставке новых кортежей или модификации значения внешнего ключа в существующих кортежах) достаточно следить за тем, чтобы не появлялись некорректные значения внешнего ключа. Но как быть при удалении кортежа из отношения, на которое ведет ссылка?
Здесь существуют три подхода, каждый из которых поддерживает целостность по ссылкам. Первый подход заключается в том, что запрещается производить удаление кортежа, на который существуют ссылки (т.е. сначала нужно либо удалить ссылающиеся кортежи, либо соответствующим образом изменить значения их внешнего ключа). При втором подходе при удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение внешнего ключа автоматически становится неопределенным. Наконец, третий подход (каскадное удаление) состоит в том, что при удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи.
В развитых реляционных СУБД обычно можно выбрать способ поддержания целостности по ссылкам для каждой отдельной ситуации определения внешнего ключа. Конечно, для принятия такого решения необходимо анализировать требования конкретной прикладной области.
Реляционная модель данных определяет два базовых требования целостности, которые поддерживаются любой РСУБД:
- требование целостности сущностей,
- требование целостности по ссылкам.
Объекту или сущности реального мира в реляционной БД соответствует кортеж отношения. Требование целостности сущностей состоит в следующем:
Любой кортеж любого отношения должен быть отличим от любого другого кортежа этого же отношения.
Это требование означает, что каждое отношение должно иметь первичный ключ. Это требование выполняется автоматически, если в системе не нарушаются базовые свойства отношений.
Кроме этого, могут быть установлены и следующие ограничения:
- UNIQUE – уникальность значения атрибутов; определяет альтернативные ключи отношения;
- NOT NULL – обязательность значения; при вставке новых или модификации существующих элементов отношения значения соответствующих атрибутов должны быть заданы;
- CHECK (условие) – допустимые значения атрибутов; вставляемые значения должны удовлетворять указанному условию.
Например, отношение ДЕТАЛЬ на SQL для СУБД MS SQL Server может быть определено следующим образом:
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): значение атрибута должно быть строго положительным.
При определении ограничений полезно задавать их имена, которые обычно строятся по следующему правилу: в имя ограничения включается имя таблицы, затем условное название типа ограничения и номер ограничения данного типа, если их в данной таблице может быть несколько.
Ссылочные ограничения целостности в РМД представляют собой условия, накладываемые на сосуществование кортежей в связанных отношениях. Как уже говорилось, в реляционной БД связи между отношениями представляются с помощью внешних ключей. Вернемся к примеру, в котором рассматривались отношения ОТДЕЛ и СОТРУДНИК:
ОТДЕЛ ( Номер отдела, Название (АК) )
СОТРУДНИК Номер сотрудника, Имя, Год рождения, Номер отдела (FK) )
Атрибут внешнего ключа Номер отдела в отношении СОТРУДНИК позволяет получить полную информацию о том конкретном отделе, в котором работает конкретный сотрудник.
Обычно отношение, в котором определяется внешний ключ, называется дочерним отношением, а отношение, на которое ссылается внешний ключ – родительским отношением. Так, в нашем примере отношение СОТРУДНИК – дочернее, а отношение ОТДЕЛ – родительское.
Требование ссылочной целостности состоит в следующем:
Значение атрибута внешнего ключа в любом кортеже дочернего отношения должно соответствовать значению атрибута первичного ключа в некотором кортеже родительского отношения.
Другими словами, требование целостности по ссылкам означает, что должно существовать то, на что ссылаемся.
При выполнении операций, связанных с модификацией отношений (операции вставки, удаления и модификации значения соответствующего ключа) необходимо следить за требованиями целостности. Рассмотрим особенности выполнения этих операций.
1. Все операции с дочерним отношением должны удовлетворять требованиям ссылочной целостности:
- при вставке нового элемента этот элемент должен иметь допустимое значение атрибутов внешнего ключа;
- удаление элемента выполняется без каких-либо ограничений;
- при модификации внешнего ключа некоторого элемента этот элемент должен получить допустимое значение атрибутов внешнего ключа.
2. Операции с родительским отношением выполняются в соответствии со следующими правилами:
- вставка нового элемента выполняется без каких-либо ограничений;
- удаление элемента не должно привести к нарушению ссылочной целостности. Если в дочернем отношении существует элемент, ссылающийся на удаляемый элемент родительского отношения, как поступить с ним? Здесь возможны три подхода:
a) restrict – удаление элемента из родительского отношения не выполняется, если в дочернем отношении есть хотя бы один элемент, ссылающийся на удаляемый;
b) cascade – вместе с элементом родительского отношения удаляются все ссылающиеся на него элементы дочернего отношения;
c) set NULL – атрибутам внешнего ключа дочернего отношения присваивается пустое значение (каждая СУБД использует собственный способ задания пустого значения); этот подход возможен, если для атрибутов внешнего ключа дочернего отношения не установлено ограничение обязательности значения;
- модификация значения первичного ключа существующего элемента также не должна привести к нарушению ссылочной целостности. Здесь также возможны те же три подхода:
a) restrict – модификация первичного ключа элемента из родительского отношения не выполняется, если в дочернем отношении есть хотя бы один элемент, ссылающийся на модифицируемый;
b) cascade – вместе с элементом родительского отношения модифицируются значения атрибутов внешнего ключа всех ссылающихся на него элементов дочернего отношения;
c) set NULL – атрибутам внешнего ключа дочернего отношения присваивается пустое значение; этот подход возможен, если для атрибутов внешнего ключа дочернего отношения не установлено ограничение обязательности значения.
Например, отношение связи ПОСТАВКА может быть определено на SQL для MS SQL Server следующим образом. Так как отношение ПОСТАВКА является отношением связи (дочерним отношением) между отношениями ПОСТАВЩИК и ДЕТАЛЬ (родительскими отношениями), прежде чем определять дочернее отношение, необходимо определить родительские.
Определение отношения ДЕТАЛЬ приведено выше.
Отношение ПОСТАВЩИК может быть определено следующим образом:
S_ID SMALLINT IDENTITY(1,1) CONSTRAINT S_PK PRIMARY KEY,
SNAME VARCHAR(30) NOT NULL,
Теперь определим отношение связи ПОСТАВКА:
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 – определяется ограничение первичного ключа; так как в данном примере первичный ключ составной, определение первичного ключа дается как ограничение уровня таблицы (ограничение внешнего ключа в данном примере, устанавливаемое только для одного атрибута, является ограничением уровня атрибута).
Читайте также: