Использование ограничений целостности
• Когда использовать ограничения целостности
• Использование преимуществ ограничений целостности
• Использование ограничений целостности NOT NULL
• Установка умалчиваемых значений столбцов
• Когда использовать умалчиваемые значения
• Использование ограничений целостности UNIQUE
• Выбор первичного ключа таблицы
• Использование ссылочных ограничений целостности
• Пустые значения и внешние ключи
• Связи между родительскими и порожденными таблицами
• Множественные ограничения FOREIGN KEY
• Управление одновременным доступом, индексы и внешние ключи
• Использование ограничений целостности CHECK
• Условия для ограничений CHECK
• Проектирование ограничений CHECK
• Множественные ограничения CHECK
• Ограничения целостности CHECK и NOT NULL
Определение ограничений целостности
• Определение ограничений целостности в команде CREATE TABLE
• Определение ограничений целостности в команде ALTER TABLE
• Привилегии, требуемые для создания ограничений целостности
• Именование ограничений целостности
• Включение и выключение ограничений целостности при их определении
• Определение ограничений целостности UNIQUE, PRIMARY KEY и FOREIGN KEY
Включение и выключение ограничений целостности
• Зачем включать или выключать ограничения?
• Нарушения ограничений целостности
• Включение и выключение ограничений целостности при их определении
• Выключение ограничений при их определении
• Включение и выключение существующих ограничений целостности
• Включение выключенных ограничений
• Выключение включенных ограничений
• Управление ограничениями целостности UNIQUE, PRIMARY KEY и FOREIGN KEY
• Вывод исключений ограничений
• Изменение ограничений целостности
• Удаление ограничений целостности
Управление ограничениями целостности FOREIGN KEY
• Определение ограничений целостности FOREIGN KEY
• Совпадение типов данных
• Составные внешние ключи
• Подразумеваемая ссылка на первичный ключ
• Привилегии, требуемые для ограничений целостности FOREIGN KEY
• Задание ссылочных действий для внешних ключей
• Включение ограничений целостности FOREIGN KEY
Вывод определений ограничений целостности
• Пример 1: Вывод всех доступных ограничений
• Пример 2: Распознавание ограничений NOT NULL и CHECK
• Пример 3: Вывод имен столбцов, составляющих ограничение целостности

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

• различные типы ограничений целостности
• ограничения NOT NULL
• ограничения UNIQUE
• ограничения PRIMARY KEY
• ограничения FOREIGN KEY (ссылочные)
• ограничения CHECK
• как определять, включать, выключать и удалять различные типы ограничений целостности

[Trusted]

Если вы используете Trusted ORACLE, обратитесь к документу Trusted ORACLE7 Server Administrator's Guide для дополнительной информации об определении, включении, выключении и удалении ограничений целостности в этом окружении.

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

Реализация правил через ограничения целостности обходится дешевле, чем реализация эквивалентных правил путем выдачи предложений SQL в вашем приложении. Семантика ограничений целостности очень четко определена, так что внутренние операции, которые ORACLE выполняет для их реализации, оптимизированы на более низком уровне, чем уровень предложений SQL. Так как ваши приложения используют SQL, вы не можете достичь такой степени оптимизации.

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

Пример

Чтобы гарантировать, что каждый сотрудник в таблице EMP числится в одном из отделов, перечисленных в таблице DEPT, сначала создадим ограничение PRIMARY KEY по столбцу DEPTNO таблицы DEPT с помощью следующего приложения:

Затем создадим ограничение ссылочной целостности по столбцу DEPTNO таблицы EMP, ссылающееся на первичный ключ таблицы DEPT:

Если вы впоследствии будете добавлять новую запись о сотруднике в таблицу EMP, ORACLE автоматически проверит, чтобы номер отдела этого сотрудника появлялся в таблице отделов.

Чтобы реализовать это же правило без ограничений целостности, ваше приложение должно проверять каждую новую запись о сотруднике, чтобы гарантировать, что номер отдела принадлежит существующему отделу. Эта проверка включает выдачу предложения SELECT для опроса таблицы DEPT.

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

Однако в некоторых случаях вы можете захотеть реализовывать организационные правила также и в самом приложении. Такой способ может обеспечить более быструю обратную связь с пользователем, чем ограничение целостности. Например, если ваше приложение принимает от пользователя 20 значений, а затем выдает предложение INSERT, содержащее все эти значения, вы можете захотеть немедленно извещать пользователя, когда он вводит значение, нарушающее организационное правило. Так как ограничения целостности действуют лишь после того, как выдано предложение SQL, ваше ограничение целостности сможет сообщить пользователю о некорректном значении лишь после того, как пользователь введет все 20 значений, и приложение выдаст предложение INSERT. Вместо этого вы можете спроектировать приложение так, чтобы оно само проверяло каждое значение по мере его ввода, и немедленно уведомляло пользователя о некорректном значении.

По умолчанию, все столбцы в таблице допускают пустые значения (т.е. отсутствие значения). Определяйте ограничение NOT NULL только для тех столбцов таблицы, которые действительно требуют, чтобы значение было всегда.

Например, в таблице EMP может быть несущественно, если временно опущены дата приема сотрудника или его руководитель. Кроме того, некоторые сотрудники не должны иметь комиссионных. Такие столбцы не могут быть хорошими кандидатами на ограничения целостности NOT NULL. С другой стороны, может считаться недопустимым, чтобы отсутствовало имя сотрудника. Такой столбец является хорошим кандидатом на ограничение целостности NOT NULL.

Рис.6-1. Ограничения целостности NOT NULL

Ограничения целостности NOT NULL часто комбинируются с другими типами ограничений целостности, чтобы еще более ограничить значения, которые могут существовать в специфических столбцах таблицы. Используйте комбинацию ограничений целостности NOT NULL и UNIQUE, чтобы осуществлять ввод значений в уникальный ключ; эта комбинация ограничений целостности гарантирует, что данные новых строк никогда не совпадут с данными существующих строк. Для дополнительной информации о таких комбинациях обратитесь к секции "Связи между родительскими и порожденными таблицами" на странице 6-8.

Допустимые умалчиваемые значения включают любые литералы, а также выражения, которые НЕ ссылаются на столбец и не содержат LEVEL, ROWNUM или PRIOR. Умалчиваемые значения МОГУТ включать выражения SYSDATE, USER, USERENV и UID. Тип данных литерала или выражения, специфицирующего умалчиваемое значение, должен совпадать с типом данных столбца или быть преобразуемым в него.

Если вы явно не определяете умалчиваемого значения для столбца, то его умалчиваемое значение неявно устанавливается в NULL.

Рис.6-2. Ограничение целостности UNIQUE

Когда использовать умалчиваемые значения

Назначайте умалчиваемые значения лишь тем столбцам, которые имеют некоторое типичное значение. Например, в таблице DEPT, если некоторые отделы расположены в одном месте, умалчиваемое значение для столбца LOC может быть установлено в это типичное значение (такое как NEW YORK).

Умолчания также полезны, когда вы используете обзор, чтобы сделать видимыми подмножество столбцов таблицы. Например, вы могли бы разрешить пользователям вставлять строки в таблицу через обзор. Обзор определяется лишь с теми столбцами, которые имеют отношение к операциям конечных пользователей; однако базовая таблица может также содержать столбец с именем, скажем, INSERTER, не включенный в определение обзора, который регистрирует того пользователя, который изначально вставил в таблицу любую данную строку. Чтобы обеспечить автоматическую регистрацию имени пользователя, вставляющего строку, в столбце INSERTER, определите этот столбец с функцией USER:

Еще один пример назначения столбцу умалчиваемого значения приведен в секции "Создание таблиц" на странице 2-3.

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

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

Некоторые примеры хороших уникальных ключей включают:

• номер социального страхования сотрудника (первичным ключом служит номер сотрудника)
• номер лицензионной карты грузовика (первичным ключом служит номер грузовика)
• номер телефона заказчика, состоящий из двух столбцов AREA и PHONE (первичным ключом служит номер заказчика)
• название и местоположение отдела (первичным ключом служит номер отдела)

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

Выбирайте столбец, значения данных которого уникальны.

Выбирайте столбец, значения данных которого никогда не изменяются.

Выбирайте столбец, который не содержит пустых значений.

Выбирайте короткий числовой столбец.

Избегайте составных первичных ключей.

Всегда, когда две таблицы связаны друг с другом через общий столбец (или группу столбцов), определяйте ограничение PRIMARY KEY или UNIQUE по столбцу в родительской таблице, и ограничение FOREIGN KEY по столбцу в порожденной таблице, чтобы поддержать эту связь между таблицами. В зависимости от характера этой связи, вы можете захотеть определить дополнительные ограничения целостности, включающие внешний ключ, как показано в секции "Связи между родительскими и порожденными таблицами" на странице 6-8.

Рис.6-3 показывает внешний ключ, определенный по столбцу DEPTNO таблицы EMP. Он гарантирует, что каждое значение в этом столбце совпадает с значением первичного ключа таблицы DEPT (столбца DEPTNO); поэтому в столбце DEPTNO таблицы EMP не может существовать ошибочных значений.

Рис.6-3. Ограничения ссылочной целостности

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

Пустые значения и внешние ключи

По умолчанию (т.е. при отсутствии ограничений NOT NULL или CHECK), и в согласии со стандартом ANSI/ISO, ограничение FOREIGN KEY вводит в действие правило "match none" для составных внешних ключей (т.е. такие ключи могут быть частично пустыми, считаясь при этом полностью пустыми). Правила "match full" и "partial" также могут быть задействованы с помощью ограничений CHECK и NOT NULL, а именно:

• Правило match partial требует, чтобы либо все компоненты внешнего ключа были пусты, либо комбинация непустых значений, содержащихся во внешнем ключе, должна встретиться в соответствующей порции первичного или уникального ключа ровно в одной строке адресуемой таблицы. В общем случае, такое правило невозможно реализовать через декларативное ограничение целостности. Однако часто этот случай можно обработать через триггеры, как описано в главе 8.

предыдущая часть | содержание | следующая часть

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Обсудить на форуме Oracle
Отправить ссылку на страницу по e-mail