Из Википедии, свободной энциклопедии
Перейти к навигацииПерейти к поиску

Контрольное ограничение - это тип ограничения целостности в SQL, который определяет требование, которому должна соответствовать каждая строка в таблице базы данных . Ограничение должно быть предикатом . Он может относиться к одному или нескольким столбцам таблицы. Результат предиката может быть либо TRUE, FALSEили UNKNOWN, в зависимости от наличия значения NULL . Если предикат имеет значение UNKNOWN, то ограничение не нарушается, и строку можно вставить или обновить в таблице. Это противоречит предикатам в WHEREпредложениях в операторах SELECTили UPDATE.

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

 ЦЕНА> = 0
 КОЛИЧЕСТВО> = 0

Если бы этих ограничений не было, можно было бы получить отрицательную цену (-30 долларов) или количество (-3 элемента).

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

Определение

Каждое проверочное ограничение должно быть определено в операторе CREATE TABLEили ALTER TABLEс использованием синтаксиса:

СОЗДАТЬ ТАБЛИЦУ имя_таблицы ( ..., CONSTRAINT имя_ограничение ПРОВЕРКА ( предикат ), ... )
ALTER TABLE table_name ADD CONSTRAINT constraint_name ПРОВЕРКА ( сказуемое )

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

СОЗДАТЬ ТАБЛИЦУ имя_таблицы ( ... имя_столбца  тип ПРОВЕРКА ( предикат ), ... )

Ограничение NOT NULL

Ограничение функционально эквивалентно следующему проверочного ограничения с предикатом:NOT NULLIS NOT NULL

ПРОВЕРИТЬ ( столбец НЕ ПУСТОЙ)

Некоторые системы управления реляционными базами данных могут оптимизировать производительность, когда используется NOT NULLсинтаксис ограничения в отличие от CHECKсинтаксиса ограничения, приведенного выше. [1]

Общие ограничения

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

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

  • CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)
  • CHECK (dateInserted = CURRENT_DATE)
  • CHECK (countItems = RAND())

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

Ссылки

  1. ^ Документация по PostgreSQL 13, Глава 5. Определение данных , раздел 5.4.2. Ограничения Not-Null , веб-сайт: https://www.postgresql.org/docs/13/ddl-constraints.html , дата обращения 9 января 2021 г.