Tema 9: Implementar la integridad de los datos

Introducción a la integridad de los datos

Las tablas en una base de datos SQL Server pueden incluir diferentes tipos de propiedades para asegurar la integridad de los datos. Estas propiedades incluyen: tipos de dato, definiciones NOT NULL, definiciones DEFAULT, propiedades IDENTITY, restricciones, reglas, desencadenadores e índices. A continuación se presenta una introducción de todos estos tipos de integridad de datos soportados por SQL Server. Además, se discutirán los diferentes tipos de integridad de datos, incluyendo integridad de entidad, integridad de dominio, integridad referencial e integridad definida por el usuario.

Asegurar la integridad de los datos

Asegurar la integridad de los datos garantiza la calidad de los datos. Por ejemplo, suponga que Ud. crea la tabla Clientes en su base de datos. Los valores en la columna Cliente_ID deberían identificar unívocamente a cada cliente que es ingresado a la tabla. Como resultado, si un cliente tiene un Cliente_ID de 438, ningún otro cliente debería tener el valor Cliente_ID en 438. Luego, suponga que se ha creado una columna Cliente_Eval que es utilizada para evaluar a cada cliente con una calificación de 1 a 8. En este caso, la columna Cliente_Eval no deberá aceptar un valor de 9 o cualquier otro valor que no esté entre 1 y 8. En ambos casos, se deben usar métodos soportados por SQL Server para asegurar la integridad de los datos.

SQL Server soporta varios métodos para asegurar la integridad de los datos, que incluyen: tipos de dato, definiciones NOT NULL, definiciones DEFAULT, propiedades IDENTITY, restricciones, reglas, desencadenadores e índices. Ya se han visto algunos de estos métodos. Un breve resumen de ellos es incluido aquí a fin de mostrar una visión comprehensiva de los distintos modos de asegurar la integridad de los datos. Algunas de esta propiedades de la tablas, tales como las definiciones NOT NULL y DEFAULT, son a veces consideradas tipos de restricciones. Para los propósitos de este Kit, sin embargo, son tratadas de forma separada.

Tipos de Dato

Un tipo de dato es un atributo que especifica el tipo de dato (carácter, entero, binario, etc.) que puede ser almacenado en una columna, parámetro o variable. SQL Server provee de un conjunto de tipos de dato, aún cuando se pueden crear tipos de dato definidos por el usuario que se crean sobre la base de tipos de dato provisto por el SQL Server. Los tipos de dato provistos por el sistema definen todos los tipos de dato que se pueden usar en SQL Server. Los tipos de dato pueden ser utilizados para asegurar la integridad de los datos porque los datos ingresados o modificados deben cumplir con el tipo de dato especificado para el objeto correspondiente. Por ejemplo, no se puede almacenar el nombre de alguien en una columna con un tipo de dato datetime, ya que esta columna solo aceptará valores válidos de fecha y hora.

Definiciones NOT NULL

La anulabilidad de una columna determina si las filas en la tabla pueden contener valores nulos para esa columna. Un valor nulo no es lo mismo que un cero, un blanco o una cadena de caracteres de longitud cero. Un valor nulo significa que no se ha ingresado ningún valor para esa columna o que el valor es desconocido o indefinido. La anulabilidad de una columna se define cuando se crea o se modifica una tabla. Si se usan columnas que permiten o no valores nulos, se debería  usar siempre las cláusula NULL y NOT NULL dada la complejidad que tiene el SQL Server para manejar los valores nulos y no prestarse a confusión. La cláusula NULL se usa si se permiten valores nulos en la columna y la cláusula NOT NULL si no.

Definiciones DEFAULT

Los valores por defecto indican que valor será guardado en una columna si no se especifica un valor para la columna cuando se inserta una fila. Las definiciones DEFAULT pueden ser creadas cuando la tabla es creada (como parte de la definición de la tabla) o pueden ser agregadas a una tabla existente. Cada columna en una tabla puede contener una sola definición DEFAULT.

Propiedades IDENTITY

Cada tabla puede tener sólo una columna de identificación, la que contendrá una secuencia de valores generados por el sistema que unívocamente identifican a cada fila de la tabla. Las columnas de identificación contienen valores únicos dentro de la tabla para la cual son definidas, no así con relación a otras tablas que pueden contener esos valores en sus propias columnas de identificación. Esta situación no es generalmente un problema, pero en los casos que así lo sea (por ejemplo cuando diferentes tablas referidas a una misma entidad conceptual, como ser clientes, son cargadas en diferentes servidores distribuidos en el mundo y existe la posibilidad que en algún momento para generar reporte o consolidación de información sean unidas) se pueden utilizar columnas ROWGUIDCOL como se vio anteriormente.

Restricciones (constraints)

Las restricciones permiten definir el modo en que SQL Server automáticamente fuerza la integridad de la base de datos. Las restricciones definen reglas indicando los valores permitidos en las columnas y son el mecanismo estándar para asegurar integridad. Usar restricciones es preferible a usar desencadenadores, reglas o valores por defecto. El query optimizer (optimizador de consultas) de SQL Server utiliza definiciones de restricciones para construir planes de ejecución de consultas de alto rendimiento.

Reglas (rules)

Las reglas son capacidades mantenidas por compatibilidad con versiones anteriores de SQL Server, que realizan algunas de las mismas funcionalidades que las restricciones CHECK. Las restricciones CHECK son el modo preferido y estándar de restringir valores para una columna. Las restricciones CHECK, por otro lado, son mas concisas que las reglas; se puede aplicar solo una regla por columna mientras que se pueden aplicar múltiples restricciones CHECK. Las restricciones CHECK son especificadas como parte del comando CREATE TABLE, mientras que las reglas son creadas como objetos separados y luego vinculadas a la columna.

Se utiliza el comando CREATE RULE para crear una regla, y luego se debe utilizar el procedimiento almacenado sp_bindrule para vincular la regla a una columna o a un tipo de dato definido por el usuario.

Desencadenadores

Los desencadenadores son una clase especial de procedimientos almacenados que son definidos para ser ejecutados automáticamente cuando es ejecutado un comando UPDATE, INSERT o DELETE sobre una tabla o una vista. Los desencadenadores son poderosas herramientas que pueden ser utilizados para aplicar las reglas de negocio de manera automática en el momento en que los datos son modificados. Los desencadenadores pueden comprender el control lógico que realizan loas restricciones, valores por defecto, y reglas de SQL Server (aún cuando es recomendable usar restricciones y valores por defecto antes que desencadenadores en la medida que respondan a todas las necesidades de control de integridad de datos).

Indices

Un índice es una estructura que ordena los datos de una o más columnas en una tabla de base de datos. Un índice provee de punteros a los valores de los datos almacenados en columnas especificadas de una tabla y luego ordena esos punteros de acuerdo al orden que se especifique. Las bases de datos utilizan los índices del mismos modo que se utilizan los índices de un libro: se busca en el índice para encontrar un determinado valor y luego se sigue un puntero a la fila que contiene ese valor. Un índice con clave única asegura la unicidad en la columna.

Tipos de integridad de datos

SQL Server soporta cuatro tipos de integridad de datos: integridad de entidad, integridad de dominio, integridad referencial e integridad definida por el usuario.

Integridad de entidad

La integridad de entidad define una fila como una única instancia de una entidad para una tabla en particular. La integridad de entidad asegura la integridad de la columna de identificación o la clave primaria de una tabla ( a través de índices, estricciones UNIQUE, restricciones PRIMARY KEY, o propiedades IDENTITY).

Integridad de dominio

La integridad de dominio es la validación de las entradas en una determinada columna. Se puede asegurar la integridad de dominio restringiendo el tipo (a través de tipos de datos), el formato (a través de las restricciones CHECK y de las reglas), o el rango de valores posibles ( a través de restricciones FOREIGN KEY, restricciones CHECK, definiciones DEFAULT, definiciones NOT NULL, y reglas)

Integridad referencial

La integridad referencial preserva las relaciones definidas entre tablas, cuando se entran, modifican o borran registros. En SQL Server, la integridad referencial esta basada en interrelaciones entre claves ajenas y claves primarias o entre claves ajenas y claves únicas (a través de la restricciones FOREIGN KEY  y CHECK). La integridad referencial asegura que los valores de las claves son consistentes a través de distintas tablas. Tal consistencia requiere que no existan referencia a valores inexistentes y que, si un valor clave cambia, todas las referencias cambien consistentemente a lo largo de la base de datos.

Cuando se fuerza la integridad referencial, SQL Server previene a los usuarios de realizar lo siguiente:

·        Agregar registros a una tabla relacionada si no hay registros asociados en la correspondiente tabla primaria.

·        Cambiar valores en la tabla primaria que resulten en registros huérfanos en las tablas relacionadas.

·        Borrar registros desde una tabla primaria si existen registros relacionados en la tabla ajena.

Por ejemplo, con las tablas Ventas y Títulos en la base de datos Pubs, la integridad referencial está basada sobre las relaciones entre la clave ajena (tit_ID) en la tabla ventas y la clave primaria (tit_ID) en la tabla Titulos.

Integridad definida por el usuario

La integridad definida por el usuario permite definir reglas de negocios específicas que no caigan dentro de alguna de las categorías anteriores. Todas las categorías soportan integridad definida por el usuario (todas las restricciones a nivel columna y a nivel tabla en el comando CREATE TABLE, procedimientos almacenados y desencadenadores)

Implementar restricciones de integridad

Una restricción es una propiedad asignada a una tabla o a una columna que previene que datos inválidos sean grabados en la o las columnas especificadas. Por ejemplo, una restricción UNIQUE  o PRIMARY KEY previene de inserciones de valores que dupliquen un valor existente, mientras que las restricciones CHECK previenen de inserciones que no igualen una condición de búsqueda, y una restricción FOREIGN KEY asegura la consistencia de la relación entre dos tablas.

Introducción a las restricciones de integridad

La restricciones permiten definir la forma en que SQL Server automáticamente asegurará la integridad de la base de datos. Las restricciones definen reglas en base a los valores permitidos en las columnas y son los mecanismos estándar para asegurar la integridad. Se deberían usar restricciones en vez de desencadenadores, procedimientos almacenados, valores por defecto o reglas.

Las restricciones pueden ser restricciones de columnas o de tablas:

·        Una restricción de columna es especificada como parte de la definición de la columna y se aplica solo a esta columna.

·        Una restricción de tabla es declarada independientemente de las definiciones de la columna y se puede aplicar a mas de una columna en la tabla.

Las restricciones de tabla deben ser usadas cuando mas de una columna se incluye en la formulación de la condición. Por ejemplo, si una tabla tiene dos o mas columnas en la clave primaria, se debe usar una restricción de tabla para incluirlas a todas en la clave primaria. Supongamos una tabla que registra eventos que suceden en una computadora de una fábrica. Dicha tabla registra eventos de diferente tipo que pueden suceder al mismo tiempo, pero no pueden suceder dos eventos del mismo tipo al mismo tiempo. Esta regla puede ser forzada incluyendo a ambas columnas; tipos de eventos y tiempo, en una clave primaria de dos columnas, como se muestra en el siguiente comando CREATE TABLE:

CREATE TABLE Procesos
(
TipoEvento int,
TiempoEvento datetime,
LugarEvento char(50),
DescripEvento char(1024),
CONSTRAINT event_key PRIMARY KEY (TipoEvento, TiempoEvento)
)

SQL Server soporta cuatro clases principales de restricciones: PRIMARY KEY, UNIQUE, FOREIGN KEY y CHECK.

Restricciones PRIMARY KEY

Una tabla usualmente tiene una columna (o una combinación de columnas) que identifica unívocamente cada fila de la tabla. Esta columna (o columnas) son llamadas “clave primaria” de la tabla y aseguran la integridad de la entidad de la tabla. Se puede crear una clave primaria usando la restricción PRIMARY KEY cuando se crea o modifica la tabla.

Una tabla puede tener solo una restricción PRIMARY KEY, y ninguna columna que participa de la clave primaria puede aceptar nulos. Cuando se especifica una restricción PRIMARY KEY para una tabla, SQL Server 2000 asegura la unicidad de los datos creando un índice principal para las columnas de la clave primaria. Este índice permite, además, un acceso rápido a las filas cuando la clave primaria se usa para formular consultas.

Si se define la restricción PRIMARY KEY para mas de una columna, los valores se pueden duplicar para una columna, pero cada combinación de valores para todas las columnas de la clave principal de una fila debe ser única para toda la tabla. La figura muestra como las columnas Autor_ID y Titulo_ID de la tabla TituloAutor forman una restricción PRIMARY KEY, la que asegura que las combinaciones Autor_ID  Titulo_ID son únicas.

Crear restricciones PRIMARY KEY

Se pueden crear restricciones PRIMARY KEY utilizando uno de los siguientes métodos:

·        Crear la restricción cuando se crea la tabla

·        Agregar la restricción a una tabla ya existente, siempre que no exista otra restricción PRIMARY KEY para esa tabla.

Se puede modificar o eliminar una restricción PRIMARY KEY después que ha sido creada.

Por ejemplo se podría querer que la restricción PRIMARY KEY de la tabla referencie a otras columnas, o querer cambiar el orden de las columnas, nombre de índice, agrupamiento o factor de llenado definido con un restricción PRIMARY KEY.

El siguiente comando CREATE TABLE crea la tabla Tabla1 y define la columna Col1 como clave primaria:

CREATE TABLE Tabla1
(
Col1 int PRIMARY KEY,
Col2 varchar(30)
)

Se puede definir la misma restricción utilizando la definición a nivel de tabla:

CREATE TABLE Tabla1
(Col1 int,
Col2 varchar(30),
CONSTRAINT tabla_pk PRIMARY KEY (Col1)
)

Se puede usar el comando ALTER TABLE para agregar una restricción PRIMARY KEY a una tabla existente:

ALTER TABLE Tabla1
ADD CONSTRAINT tabla_pk PRIMARY KEY (Col1)

Cuando una restricción PRIMARY KEY se agrega a una columna (o columnas) existente en un tabla, SQL Server 2000 controla los datos ya existentes en las columnas para asegurar que se cumplen las siguientes reglas:

·        No hay valores nulos

·        No hay valores duplicados

Si se agrega una restricción PRIMARY KEY a una columna que tiene valores nulos o duplicados, SQL Server emite un mensaje de error y no agrega la restricción.

SQL Server automáticamente crea un índice único para asegurar la unicidad de los valores de la restricción PRIMARY KEY. Si no existe un índice agrupado ( o no se especifica un índice no-agrupado) se crea un índice único y no agrupado para asegurar la restricción PRIMARY KEY (ver índices mas adelante en este módulo).

Restricciones UNIQUE

Se pueden usar las restricciones UNIQUE para asegurar que no sean entrados valores duplicados en columnas específicas que no participan de la clave primaria. Aunque tanto la restricción PRIMARY KEY como la restricción UNIQUE aseguran unicidad, se debería usar UNIQUE  en vez de PRIMARY KEY en los siguientes casos:

·        Si una columna ( o combinación de columnas) no son la clave primaria. Se  pueden definir muchas restricciones UNIQUE  para una tabla, muientras que solo una restricción PRIMARY KEY,

·        Si la columna permite valores nulos. Las restricciones UNIQUE permiten que se las defina para aceptar valores nulos, mientra que las restricciones PRIMARY KEY no lo permiten.

Una restricción UNIQUE pueden ser referenciadas por una restricción FOREIGN KEY.

Crear restricciones UNIQUE

Se pueden crear restricciones UNIQUE en el mismo modo que se crean restricciones PRIMARY KEY:

·        Creando la restricción al momento de crear la tabla ( como parte de la definición de la tabla)

·        Agregando la restricción a una tabla existente, previendo que la o las columnas comprendidas en la restricción UNIQUE contengan solo valores no duplicados o valores nulos. Una tabla puede aceptar múltiples restricciones UNIQUE.

Se pueden usar los mismos comandos Transact-SQL para crear restricciones UNIQUE  que los utilizados para crear restricciones PRIMARY KEY. Simplemente reemplace las palabras PRIMARY KEY por UNIQUE. Al igual que con las restricciones PRIMARY KEY las restricciones UNIQUE pueden ser modificadas o eliminadas una vez creadas.

Cuando se agrega una restricción UNIQUE a una columna (o columnas) existente en la tabla, SQL Server (por defecto) controla los datos existentes en las columnas para asegurar que todos los valores, excepto los nulos, son únicos. Si se agrega una restricción UNIQUE a una columna que tienen valores no nulos duplicados, SQL Server genera un mensaje de error y no agrega la restricción.

SQL Server automáticamente crea un índice UNIQUE para asegurar la unicidad requerida por la restricción UNIQUE. Por lo que, si se intenta ingresar un  nueva fila con valores duplicados para la columna (o combinación de columnas) especificada se genera una mensaje de error diciendo que ha sido violada la restricción UNIQUE y no se agrega la fila a tabla. Si no se especifica un índice agrupado, se creará un índice no-agrupado por defecto cuando se crea una restricción UNIQUE.

Restricciones FOREIGN KEY

Una clave ajena es una columna o combinación de columnas usadas para establecer y asegurar una conexión entre dos tablas. Al agregar una columna (o columnas) a una de las tablas y definir estas columnas con una restricción FOREIGN KEY se crea una conexión entre dos tablas. Las columnas tendrán únicamente valores que se encuentren en las columnas de la clave primaria de la segunda tabla.

Una tabla puede tener múltiples restricciones FOREIGN KEY.

Por ejemplo, la tabla Titulos en la base de datos Pubs tiene una conexión a la tabla Editores al haber una relación lógica entre autores y editores.

La columna Pub_ID en la tabla Titulos concuerda con la columna de clave principal en la tabla Editores, como muestra la Figura. La columna Pub_ID en la tabla Titulos es la clave ajena asociada la tabla Editores.

Se puede crear una clave ajena definiendo una restricción FOREIGN KEY cuando se crea o modifica una tabla. Además de a una PRIMARY KEY, una clave ajena puede referenciar a una restricción UNIQUE en otra tabla.

Una restricción FOREIGN KEY puede contener valores nulos; sin embargo, si cualquier columna de una restricción FOREIGN KEY compuesta contiene valores nulos, la verificación de la restricción FOREIGN KEY será omitida.

Una restricción FOREIGN KEY puede referenciar columnas en tablas de la misma base de datos o dentro de la misma tablas (tablas auto-referenciadas).

Aún cuando el propósito primario de una restricción FOREIGN KEY en es el de controlar que datos pueden ser guardados en la tabla de la clave ajena, también controla cambios a datos en la tabla de la clave primaria. Por ejemplo, si se elimina la fila de un editor de la tabla de editores y el ID de ese editor esta siendo utilizado en alguna fila de la tabla Titulos, la integridad entre las dos tablas se destruiría. Los libros del editor eliminado quedarían huérfanos, sin una conexión a los datos de la tabla Editores. Una restricción FOREIGN KEY previene esta situación. La restricción fuerza la integridad referencial al asegurar que no se puedan hacer cambios en los datos en la tabla de la clave primaria si esos cambios invalidan la conexión a los datos de la tabla de la clave ajena. Si se trata de eliminar una fila en la tabla de clave primaria o de cambiar un valor de clave primaria, dicha acción no se ejecutará si el valor de clave primaria cambiado o eliminado corresponde a un valor en la restricción FOREIGN KEY de otra tabla.

Para cambiar o eliminar una fila en una restricción FOREIGN KEY, se debe primero o bien eliminar los datos correspondientes en la tabla de clave ajena o cambiar los datos de clave ajena en la tabla de clave ajena, a través de conectar la clave ajena a distinto valor de la clave principal.

Crear restricciones FOREIGN KEY   

Se pueden crear restricciones FOEREIGN KEY utilizando alguno de los siguientes métodos:

·        Creando la restricción cuando se crea la tabla  (como parte de la definición de la tabla).

·        Agregando la restricción a una tabla existente, indicando que la restricción FOREING KEY esta conectada a una restricción PRIMARY KEY existente o a una restricción UNIQUE.

Se puede modificar o eliminar una restricción FOREIGN KEY una vez que esta ha sido creada.

Por ejemplo, se podría querer que la tabla de clave ajena referencie a otras columnas. No se puede cambiar la longitud de una columna definida con un restricción FOREIGN KEY.

Para modificar una restricción FOREIGN KEY utilizando Transact-SQL, se debe primero eliminar la restricción FOREIGN KEY anterior y luego recrearla con su nueva definición.

El siguiente comando CREATE TABLE crea la tabla Tabla1 y define la columna Col2 con una restricción FOREIGN KEY que apunta a la columna Empleado_ID que es clave primaria de la tabla Empleados.

CREATE TABLE Tabla1
(Col1 int PRIMARY KEY,
Col2 int REFERENCES Empleados(Empleado_ID)
)

Se puede definir, además la misma restricción usando la restricción FOREIGN KEY a nivel de tabla:

CREATE TABLE Tabla1
(
Col1 int PRIMARY KEY,
Col2 int,
CONSTRAIT col2_fk FOREIGN KEY (Col2)
REFERENCES Empleados(Empleado_ID)
)

Se puede usar el comando ALTER TABLE para agregar una restricción FOREIGN KEY a una tabla existente:

ALTER TABLE Tabla1
ADD CONSTRAIT col2_fk FOREIGN KEY (Col2)
REFERENCES Empleados(Empleado_ID)

Cuando se agrega una restricción FOEREING KEY a una columna (o columnas) existentes en un tabla, SQL Server 2000 (por defecto) controla los datos existentes en las columnas para asegurar que todos los valores, excepto los nulos, existen en las columnas referenciadas por las restricciones PRIMARY KEY o UNIQUE. Se puede configurar al SQL Server para que no realice este control y obligarlo a agregar la nueva restricción sin fijarse en los datos previos, esto puede ser útil cuando se quiere que la restricción funcione solo de aquí en adelante.

De todos modos, se deberá ser cuidadoso cuando se agregan restricciones sin controlar la consistencia de los datos previos dado que se pueden provocar inconsistencias no deseadas.

Deshabilitar restricciones FOREIGN KEY

Se pueden deshabilitar restricciones FOREIGN KEY preexistentes cuando se realicen alguna de las siguientes acciones:

·        Al ejecutar los comandos INSERT y UPDATE: Deshabilite una restricción FOREIGN KEY durante un comando INSERT o UPDATE si el dato nuevo violará la restricción o si la restricción se debe aplicar solo a datos ya existentes en la tabla. Deshabilitar restricciones permite que los datos sean modificados sin que sean validados por las restricciones.

·        Al implementar procesos de replicación: Deshabilite una restricción FOREIGN KEY durante el proceso de replicación si la restricción es específica de la base de datos fuente. Cuando se replica una tabla, los datos y la definición de la tabla son copiados desde una base de datos fuente a una base de datos destino. Estas bases de datos están generalmente (pero no necesariamente) sobre servidores separados. Si las restricciones FOREIGN KEY específicas de la base de datos fuente no están deshabilitadas, estas podrían innecesariamente prevenir que nuevos datos sean ingresados en la base de datos destino.

Restricciones CHECK

Las restricciones CHECK aseguran la integridad de dominio al limitar los valores que son aceptados para una columna. Son similares a lar restricciones FOREIGN KEY en que ambas controlan los valores que son puestos en una columna. La diferencia está en cómo se determina cuales son valores válidos. Las restricciones FOREIGN KEY toman los valores válidos de otra tabla, mientras que las restricciones CHECK determinan los valores válidos evaluando una expresión lógica que no se basa en datos de otra columna. Por ejemplo, es posible limitar el rango de valores para una columna Salario creando una restricción CHECK que permita solamente datos dentro del rango de $15.000 a $100.000. Este capacidad evita el ingreso de salarios fuera del rango normal de salarios de la compañía.

Se puede crear una restricción CHECK con una expresión lógica (Booleana) que retorne TRUE (verdadero) o FALSE (falso) basada en operadores lógicos. Para permitir solamente datos que se encuentren dentro del rango de $15.000 a $100.000, la expresión lógica será como la siguiente:

Salario >= 15000 AND Salario <= 100000

Se puede aplicar múltiples restricciones CHECK para una sola columna. Las restricciones son evaluadas en el orden en que han sido creadas. Además, se puede aplicar una misma restricción CHECK  a múltiples columnas creando la restricción a nivel de tabla. Por ejemplo, se puede usar una restricción CHECK para múltiples columnas para confirmar que cualquier fila con la columna País igual a USA tenga valor para la columna Estado que sea una cadena de dos caracteres. Esta posibilidad permite que múltiples condiciones sean controladas en un lugar.

Crear restricciones CHECK

Se pueden crear restricciones usando uno de los siguientes métodos:

·        Creando la restricción cuando se crea la tabla (como parte de las definiciones de la tabla)

·        Agregando la restricción a una tabla existente.

Se puede modificar o eliminar una restricción CHECK una vez que ha sido creada. Por ejemplo, se puede modificar la expresión usada por la restricción CHECK sobre una columna  en la tabla.

Para modificar una restricción CHECK primero se debe eliminar la antigua restricción y luego recrearla con su nueva definición.

El siguiente comando CREATE TABLE crea una tabla Tabla1 y define la columna Col2 con un restricción CHECK que limita los valores que puede tomar la columna al rango comprendido entre 0 y 100.

CREATE TABLE Tabla1
(
Col1 int PRIMARY KEY,
Col2 int
CONSTRAIT monto_limite CHECK (Col2 BETWEN 0 AND 100),
Col3 varchar(30)
)

También se puede definir la misma restricción usando restricción CHECK a nivel tabla:

CREATE TABLE Tabla1
(
Col1 int PRIMARY KEY,
Col2 int ,
Col3 varchar(30),
CONSTRAIT monto_limite CHECK (Col2 BETWEN 0 AND 100)
)

Se puede utilizar el comando ALTER TABLE para agregar una retricción CHECK a una tabla existente:

ALTER TABLE Tabla1
ADD CONSTRAIT monto_limite CHECK (Col2 BETWEN 0 AND 100)

Cuando se agrega una restricción CHECK a una tabla existente, la restricción CHECK puede aplicarse solo a los datos nuevos o también a los datos existentes. Por defecto la restricción CHECK se aplica a los datos existentes tanto como a los nuevos datos.

La opción de aplicar la restricción a los nuevos datos solamente es útil cuando las reglas de negocios requieren que la restricción se aplique de ahora en más.

Por ejemplo, una vieja restricción podría requerir códigos postales restringidos a 5 caracteres siendo los mismos aún válidos mientras que los nuevos códigos que se ingresen deberán tener nueve caracteres. Por lo que solo los datos nuevos deberían ser controlados para verificar que cumplen con la restricción.

Sin embargo, se debe ser cuidadoso cuando se agregan restricciones sin controlar los datos existentes, porque esta acción saltea los controles de SQL Server 2000 que aseguran la integridad para los datos de la tabla.

Deshabilitar restricciones CHECK

Se pueden deshabilitar restricciones CHECK preexistentes cuando se realicen alguna de las siguientes acciones:

·        Al ejecutar los comandos INSERT y UPDATE: Deshabilite una restricción CHECK durante un comando INSERT o UPDATE si el dato nuevo violará la restricción o si la restricción se debe aplicar solo a datos ya existentes en la tabla. Deshabilitar restricciones permite que los datos sean modificados sin que sean validados por las restricciones.

Al implementar procesos de replicación: Deshabilite una restricción CHECK durante el proceso de replicación si la restricción es específica de la base de datos fuente. Cuando se replica una tabla, los datos y la definición de la tabla son copiados desde una base de datos fuente a una base de datos destino. Estas bases de datos están generalmente (pero no necesariamente) sobre servidores separados. Si las restricciones CHECK específicas de la base de datos fuente no están deshabilitadas, estas podrían innecesariamente prevenir que nuevos datos sean ingresados en la base de datos destino.