Введение
Тип ограничения целостности в SQL. Контрольное ограничение — это тип ограничения целостности в SQL, который задает требование, которому должна удовлетворять каждая строка в таблице базы данных. Ограничение должно быть представлено предикатом. Предикат может относиться к одному или нескольким столбцам таблицы. Результат предиката может быть TRUE, FALSE или UNKNOWN в зависимости от наличия значений NULL. Если предикат вычисляется как UNKNOWN, то ограничение не нарушается, и строку можно вставить или обновить в таблице. Это отличается от предикатов в предложениях WHERE в операторах SELECT или UPDATE. Например, в таблице, содержащей информацию о продуктах, можно добавить контрольное ограничение, чтобы цена и количество продукта были неотрицательными:
A check constraint is a type of integrity constraint in SQL which specifies a requirement that must be met by each row in a database table. The constraint must be a predicate. It can refer to a single column, or multiple columns of the table. The result of the predicate can be either TRUE, FALSE, or UNKNOWN, depending on the presence of NULLs. If the predicate evaluates to UNKNOWN, then the constraint is not violated and the row can be inserted or updated in the table. This is contrary to predicates in WHERE clauses in SELECT or UPDATE statements. For example, in a table containing products, one could add a check constraint such that the price of a product and quantity of a product is a non negative value:
цена >= 0
количество >= 0
Если бы эти ограничения отсутствовали, было бы возможно иметь отрицательную цену (например, -30 долларов) или отрицательное количество (например, -3 единицы). Контрольные ограничения используются для обеспечения корректности данных в базе данных и поддержания целостности данных. Если они реализованы на уровне базы данных, приложения, использующие эту базу данных, не смогут добавлять некорректные данные или изменять корректные данные таким образом, чтобы они стали некорректными, даже если само приложение допускает ввод некорректных данных.
Общие ограничения
Большинство систем управления базами данных ограничивают ограничения проверки одной строкой, предоставляя доступ к константам и детерминированным функциям, но не к данным в других таблицах или к данным, невидимым для текущей транзакции из-за уровня изоляции транзакций. Такие ограничения фактически являются не ограничениями проверки таблицы, а ограничениями проверки строки. Поскольку эти ограничения обычно проверяются только при прямом обновлении строки (в целях производительности) и часто реализуются как неявные триггеры INSERT или UPDATE, ограничения целостности могли бы быть нарушены косвенными действиями, если бы не эти ограничения. Более того, в противном случае, ограничение CHECK заблокировало бы вполне допустимые изменения в этих записях. Примеры опасных ограничений включают:
Пользовательские триггеры могут быть использованы для обхода этих ограничений. Хотя их реализация схожа, семантически понятно, что триггеры будут срабатывать только при прямом изменении таблицы, и ответственность за обработку косвенных, важных изменений в других таблицах лежит на разработчике; в то время как ограничения, напротив, должны быть "истинными всегда", независимо от действий пользователя или недостатка предвидения разработчика.