Материал: Graber_Martin_-_SQL_dlya_prostykh_smertnykh_-_2014

Итоги

SELECT *

FROM Customers

WHERE rating <= 100;

Однако, если определено значение по умолчанию (DEFAULT) как ООО для поля rating, покупатели без рейтингов будут выбраны наряду с остальными. Какой из мето­

дов лучше зависит от ситуации: используется ли поле в запросах, нужно ли включать

строки без значений в выходные данные запроса?

Другая характеристика значений по умолчанию этого типа состоит в том, что они позволяют объявлять поле в запросе NOT NULL. Если значения по умолчанию ис­ пользуются для исключения NULL-значений, то это может оказаться хорошей защи­ той от ошибок.

Можно также использовать с этим полем ограничения UNIQUE или PRIMARY КЕУ. Однако надо помнить, что только одна строка в единицу времени может иметь значение по умолчанию. Любая строка, его содержащая, будет обновляться до тех пор, пока не будет вставлена новая строка со значением по умолчанию. Поэтому ограниче­ ния UNIQUE и PRIMARY КЕУ (особенно последнее) обычно не размещаются в стро­

ках со значениями по умолчанию.

Итоги

В главе были рассмотрены способы контроля вводимых в таблицы значений. Огра­ ничение NOT NULL можно использовать для исключения NULL-значений, UNIQUE - для поддержания уникальности одного или нескольких столбцов, PRIMARY КЕУ - для того, чтобы сделать все то же, что и с помощью UNIQUE, но с другой целью; СНЕСК - для определения собственного критерия, какие значения могут быть введены. Кроме того, можно использовать предложение DEFAULT для ав­ томатической подстановки значения по умолчанию в любое поле, имя которого не указано в INSERT. Например, NULL-значения вставляются, когда предложение DEFAULT не представлено и нет ограничения NOT NULL.

Ограничения FOREIGN КЕУ или REFERENCES, о которых пойдет речь в главе 19,

сходны с рассмотренными, за исключением того, что они относятся к группе из одно­

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

введены для этих групп.

195

Работаем на SQL

1.Создайте таблицу Orders так, чтобы все значения столбца onum, как и все комби­ нации cnum и snum, бьши различными и NULL-значения не содержались в поле

date.

2.Создайте таблицу Sa\espeople так, чтобы комиссионные по умолчанию составляли 10%, причем NULL-значения запрещены, nоле snum является первичным ключом, а все имена расположены в алфавитном порядке между 'А' и 'М' включительно (пред­ полаrается, что все имена заданы большими буквами).

3.Создайте таблицу Orders, причем вы должны быть уверены в том, значение поля

onum больше значения поля cnum, а значение поля cnum больше значения поля snum. Предположим, что NULL-значения недопустимы ни для одного из этих трех полей.

(Ответы см. в приложении А.)

196

Глава 19. Поддер;жка целостности даниых

Ранее рассматривались определенные связи между некоторыми полями в табли­

цах. Например, поле snum таблицы Customers связывает поле snum в таблицах Salespeople и Orders. Этот тип связи называется ссылочной целостностью. И здесь мы обсудим некоторые вопросы ее использования.

В этой главе мы рассмотрим ссылочную целостность более детально, выявим ряд

ограничений, которыми можно воспользоваться для управления ею и выясним, как

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

Внешние и родительские ключи

Когда все значения одного из полей таблицы должны быть представлены в поле дру­ гой таблицы, это означает,что поле ссылается на (refers to) или является ссылкой (refe1·ences) на таблицу. Это свидетельствует о прямой связи между значениями двух по­ лей. Например, каждый из покупателей таблицы Customers имеет поле snum, которое оп­ ределяет продавца, назначенного ему и определенного в таблице Salespeople. Для каждой заявки в таблице Orders существует только один продавец и только один покупатель. Они определяются полями snum и cnum в таблице Orders.

Когда поле таблицы ссылается на другое поле (в другой таблице), оно называется внешним ключо-•1 (f01·eig11 key); поле, на которое он ссылается, называется его роди­ тельскш1 ключом (parent key). Таким образом, поле snum в таблице Customers являет­ ся внешним ключом, а поле snum, на которое он ссылается в таблице Salespeople - родительским ключом. Поля cnum и snum таблицы Orders также являются внешними ключами, ссы::~ающимися на их родительские ключи с теми же именами в таблицах Customers и Salespeople. Имена внешнего и родительского ключей могут быть неоди­

наковыми; в данном случае это просто соглашение, принятое с целью сделать связи

более понятными.

Внешние ключи из нескольких столбцов

Внешний ключ, как и первичный, может быть определен на любом количестве по­ лей, которые все вместе рассматриваются как единое целое. Внешний ключ и роди­ тельский ключ, на который он ссылается, должны быть определены на одинаковом множестве полей (по количеству полей, типам полей и порядку следования полей). В простых таблицах, рассматриваемых здесь в качестве примера, используются только внешние ключи, определенные на единственном поле; возможно, они наиболее часто применяются и на практике. С целью упрощения речь пойдет о внешнем ключе как о единственном столбце. Далее, все, что будет говориться о поле, являющемся внешним

198

Ограничения FOREIGN КЕУ (виешнего ключа)

ключом, справедливо и для внешнего ключа, определенного на группе полей, если

специально не оговаривается иное.

Смысл внешних и родительских ключей

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

ет, что система находится в состоянии ссьuючной целостности.

Внешний ключ snum в таблице Customers имеет значение 1001 для строк Hoffman и Clemens. Предположим, есть две строки строки в таблице Salesperson со значением поля snum = 1001. Как узнать, к какому именно из двух продавцов относятся покупатели

Hoffman и Clemens? Кроме того, если бы в таблице Salespeople не было таких строк, то это значило бы, что Hoffman и Clemens назначены продавцу, которого не существует! Заключение очевидно: каждое значение внешнего ключа должно быть представлено в

родительском ключе один и только один раз.

Из утверждения, что данное значение внешнего ключа может ссылаться только на

одно значение родительского ключа, не следует, что верно и обратное: любое число внешних ключей может ссылаться на одно и то же значение родительского ключа. Это ясно из таблиц, рассматриваемых здесь в качестве примера. Hoffinan и Clemens назначе­ ны Рее\, значения их внешнего ключа соответствуют одному и тому же родительскому ключу. Значение внешнего ключа должно ссылаться только на единственное значение родительского ключа, но на это значение родительского ключа может ссылаться любое

количество значений внешних ключей.

Например, значения внешнего ключа из таблицы Customers, соответствующие их родительским ключам в таблице Salespeople, показаны на рис. 19.1. Для большей на­

глядности рисунка опущены не относящиеся к делу поля.

Ограничения FOREIGN КЕУ (внешнего

ключа)

SQL поддерживает ссылочную целостность с ограничением FOREIGN КЕУ. Это важное ограничение является новым в SQL, и поэтому еще не имеет универсальной

поддержки. Бо.1ее того, некоторые его программные реализации являются весьма гро­

моздкими. Назначение FOREIGN КЕУ - ограничить вводимые в базу данных значе­ ния так, чтобы внешний ключ и его родительский ключ соответствовали принципам ссылочной целостности. Один из эффектов поддержки ограничения (внешнего клю­ ча) - исключение значений для поля (полей) внешнего ключа, не представленных в данный момент в родительском ключе. Это ограничение относится и к возможности

199