Ограничение проверки — это тип ограничения целостности в SQL , которое определяет требование, которому должна соответствовать каждая строка в таблице базы данных . Ограничение должно быть предикатом . Оно может ссылаться на один столбец или несколько столбцов таблицы. Результатом предиката может быть либо TRUE, FALSE, либо UNKNOWN, в зависимости от наличия значений NULL . Если предикат оценивается как UNKNOWN, то ограничение не нарушается, и строку можно вставить или обновить в таблице. Это противоречит предикатам в WHEREпредложениях SELECTили UPDATEоператорах.
Например, в таблице, содержащей продукты, можно добавить проверочное ограничение таким образом, чтобы цена продукта и количество продукта были неотрицательными значениями:
цена >= 0
количество >= 0
Если бы эти ограничения не были установлены, то можно было бы получить отрицательную цену (-30 долл. США) или количество (-3 единицы).
Проверочные ограничения используются для обеспечения действительности данных в базе данных и обеспечения целостности данных . Если они используются на уровне базы данных, приложения, использующие базу данных, не смогут добавлять недействительные данные или изменять действительные данные, так что данные станут недействительными, даже если само приложение принимает недействительные данные.
Каждое проверочное ограничение должно быть определено в операторе CREATE TABLEor ALTER TABLEс использованием синтаксиса:
СОЗДАТЬ ТАБЛИЦУ имя_таблицы ( ..., CONSTRAINT имя_ограничения ПРОВЕРКА ( предикат ), ...)
ALTER TABLE table_name ADD CONSTRAINT constraint_name CHECK ( предикат )
Если проверочное ограничение относится только к одному столбцу, можно указать ограничение как часть определения столбца.
СОЗДАТЬ ТАБЛИЦУ имя_таблицы ( ... тип column_name CHECK ( предикат ), ...)
Ограничение функционально эквивалентно следующему проверочному ограничению с предикатом:NOT NULLIS NOT NULL
ПРОВЕРКА ( столбец НЕ 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())Для обхода этих ограничений можно использовать определяемые пользователем триггеры . Хотя реализация схожа, семантически ясно, что триггеры будут срабатывать только при непосредственном изменении таблицы, и что дизайнер несет ответственность за обработку косвенных, важных изменений в других таблицах; с другой стороны, ограничения должны быть «истинными всегда», независимо от действий пользователя или недальновидности дизайнера.