Контрольное ограничение - это тип ограничения целостности в 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 NULL
IS 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())
Для обхода этих ограничений можно использовать определяемые пользователем триггеры . Хотя реализация схожа, семантически ясно, что триггеры будут срабатывать только при непосредственном изменении таблицы, и что разработчик несет ответственность за обработку косвенных, важных изменений в других таблицах; ограничения, с другой стороны, должны быть «истинными в любое время», независимо от действий пользователя или отсутствия предвидения дизайнера.
Ссылки
- ^ Документация по PostgreSQL 13, Глава 5. Определение данных , раздел 5.4.2. Ограничения Not-Null , веб-сайт: https://www.postgresql.org/docs/13/ddl-constraints.html , дата обращения 9 января 2021 г.