Una restricción de verificación es un tipo de restricción de integridad en SQL que especifica un requisito que debe cumplir cada fila en una tabla de base de datos . La restricción debe ser un predicado . Puede hacer referencia a una sola columna o a varias columnas de la tabla. El resultado del predicado puede ser TRUE
, FALSE
o UNKNOWN
, dependiendo de la presencia de valores NULL . Si el predicado evalúa a UNKNOWN
, entonces la restricción no se viola y la fila se puede insertar o actualizar en la tabla. Esto es contrario a los predicados en WHERE
cláusulas SELECT
o UPDATE
declaraciones.
Por ejemplo, en una tabla que contiene productos, se podría agregar una restricción de verificación tal que el precio de un producto y la cantidad de un producto sea un valor no negativo:
PRECIO> = 0
CANTIDAD> = 0
Si estas restricciones no estuvieran en su lugar, sería posible tener un precio negativo (- $ 30) o una cantidad (−3 artículos).
Las restricciones de verificación se utilizan para garantizar la validez de los datos en una base de datos y para proporcionar integridad a los datos . Si se utilizan en el nivel de la base de datos, las aplicaciones que utilizan la base de datos no podrán agregar datos no válidos o modificar datos válidos, por lo que los datos se vuelven inválidos, incluso si la propia aplicación acepta datos no válidos.
Definición
Cada restricción de verificación debe definirse en la instrucción CREATE TABLE
o ALTER TABLE
utilizando la sintaxis:
CREAR TABLA nombre_tabla ( ..., CONSTRAINT constraint_name CHECK ( predicado ), ... )
ALTER TABLE nombre_tabla ADD CONSTRAINT constraint_name CHECK ( predicado )
Si la restricción de verificación se refiere solo a una columna, es posible especificar la restricción como parte de la definición de la columna.
CREAR TABLA nombre_tabla ( ... nombre_columna tipo CHECK ( predicado ), ... )
Restricción NOT NULL
Una restricción es funcionalmente equivalente a la siguiente restricción de verificación con un predicado:NOT NULL
IS NOT NULL
COMPROBAR (la columna NO ES NULO)
Algunos sistemas de administración de bases de datos relacionales pueden optimizar el rendimiento cuando NOT NULL
se usa la CHECK
sintaxis de restricción en contraposición a la sintaxis de restricción dada anteriormente. [1]
Restricciones comunes
La mayoría de los sistemas de administración de bases de datos restringen las restricciones de verificación a una sola fila, con acceso a constantes y funciones deterministas, pero no a datos en otras tablas, ni a datos invisibles para la transacción actual debido al aislamiento de la transacción .
Estas restricciones no son realmente restricciones de verificación de tabla, sino restricciones de verificación de fila . Debido a que estas restricciones generalmente solo se verifican cuando una fila se actualiza directamente (por razones de rendimiento) y, a menudo, se implementan implícitamente INSERT
o como UPDATE
desencadenantes, las restricciones de integridad podrían violarse mediante una acción indirecta si no fuera por estas limitaciones. Además, la CHECK
restricción evitaría las modificaciones válidas de estos registros . Algunos ejemplos de restricciones peligrosas incluyen:
CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)
CHECK (dateInserted = CURRENT_DATE)
CHECK (countItems = RAND())
Se pueden utilizar activadores definidos por el usuario para evitar estas restricciones. Aunque es similar en implementación, está semánticamente claro que los disparadores solo se activarán cuando la tabla se modifique directamente, y que es responsabilidad del diseñador manejar cambios importantes e indirectos en otras tablas; las restricciones, por otro lado, están destinadas a ser "verdaderas en todo momento" independientemente de las acciones del usuario o de la falta de previsión del diseñador.
Referencias
- ^ Documentación de PostgreSQL 13, Capítulo 5. Definición de datos , Sección 5.4.2. Restricciones no nulas , sitio web: https://www.postgresql.org/docs/13/ddl-constraints.html , consultado el 9 de enero de 2021