3.3. Integridad de bases de datos

Departamento de Informática
Cátedra de Base de Datos I
Facultad Politécnica
Sección NA
Universidad Nacional de Asunción
Docente: José Rojas Dávalos
Unidad 3: Diseño de bases de datos relacionales
3.3. Integridad de bases de datos
Documentos de consulta
Fuente: http://es.wikipedia.org/wiki/Integridad_de_datos
Integridad de datos
El término integridad de datos se refiere a la corrección y completitud de los datos en una base de
datos. Cuando los contenidos se modifican con sentencias INSERT, DELETE o UPDATE, la
integridad de los datos almacenados puede perderse de muchas maneras diferentes. Pueden añadirse
datos no válidos a la base de datos, tales como un pedido que especifica un producto no existente.
Pueden modificarse datos existentes tomando un valor incorrecto, como por ejemplo si se reasigna
un vendedor a una oficina no existente. Los cambios en la base de datos pueden perderse debido a
un error del sistema o a un fallo en el suministro de energía. Los cambios pueden ser aplicados
parcialmente, como por ejemplo si se añade un pedido de un producto sin ajustar la cantidad
disponible para vender.
Una de las funciones importantes de un DBMS relacional es preservar la integridad de sus datos
almacenados en la mayor medida posible.
Tipos de restricciones de integridad [editar]
• Datos Requeridos: establece que una columna tenga un valor no NULL. Se define
efectuando la declaración de una columna es NOT NULL cuando la tabla que contiene las
columnas se crea por primera vez, como parte de la sentencia CREATE TABLE.
• Chequeo de Validez: cuando se crea una tabla cada columna tiene un tipo de datos y el
DBMS asegura que solamente los datos del tipo especificado sean ingresados en la tabla.
• Integridad de entidad: establece que la clave primaria de una tabla debe tener un valor
único para cada fila de la tabla; si no, la base de datos perderá su integridad. Se especifica en
la sentencia CREATE TABLE. El DBMS comprueba automáticamente la unicidad del valor
de la clave primaria con cada sentencia INSERT Y UPDATE. Un intento de insertar o
actualizar una fila con un valor de la clave primaria ya existente fallará.
• Integridad referencial: asegura la integridad entre las claves ajenas y primarias (relaciones
padre/hijo). Existen cuatro actualizaciones de la base de datos que pueden corromper la
integridad referencial:
• La inserción de una fila hijo se produce cuando no coincide la clave ajena con la
clave primaria del padre.
• La actualización en la clave ajena de la fila hijo, donde se produce una actualización
en la clave ajena de la fila hijo con una sentencia UPDATE y la misma no coincide
con ninguna clave primaria.
• La supresión de una fila padre, con la que, si una fila padre -que tiene uno o más
hijos- se suprime, las filas hijos quedarán huérfanas.
1/14 25/05/10 04:15:19 /media/JROJASD/fpuna/20122/bd1na/unidad3/documentosdeconsulta/d03-03.odt
Departamento de Informática
Cátedra de Base de Datos I
Facultad Politécnica
Sección NA
Universidad Nacional de Asunción
Docente: José Rojas Dávalos
Unidad 3: Diseño de bases de datos relacionales
3.3. Integridad de bases de datos
Documentos de consulta
Fuente: http://www.aulaclic.es/sql/b_8_1_1.htm
Conceptos básicos de integridad referencial.
Introducción
La integridad referencial es un sistema de reglas que utilizan la mayoría de las bases de datos
relacionales para asegurarse que los registros de tablas relacionadas son válidos y que no se
borren o cambien datos relacionados de forma accidental produciendo errores de integridad.
Primero repasemos un poco los tipos de relaciones.
Tipos de relaciones.
Entre dos tablas de cualquier base de datos relacional pueden haber dos tipos de relaciones,
relaciones uno a uno y relaciones uno a muchos:
Relación Uno a Uno: Cuando un registro de una tabla sólo puede estar relacionado con un
único registro de la otra tabla y viceversa.
Por ejemplo: tenemos dos tablas una de profesores y otra de departamentos y queremos saber qué
profesor es jefe de qué departamento, tenemos una relación uno a uno entre las dos tablas ya que un
departamento tiene un solo jefe y un profesor puede ser jefe de un solo departamento.
Relación Uno a Varios: Cuando un registro de una tabla (tabla secundaria) sólo puede estar
relacionado con un único registro de la otra tabla (tabla principal) y un registro de la tabla
principal puede tener más de un registro relacionado en la tabla secundaria, en este caso se
suele hacer referencia a la tabla principal como tabla 'padre' y a la tabla secundaria como tabla
'hijo', entonces la regla se convierte en 'un padre puede tener varios hijos pero un hijo solo tiene un
padre (regla más fácil de recordar).
Por ejemplo: tenemos dos tablas una con los datos de diferentes poblaciones y otra con los
habitantes, una población puede tener más de un habitante, pero un habitante pertenecerá (estará
empadronado) en una única población. En este caso la tabla principal será la de poblaciones y la
tabla secundaria será la de habitantes. Una población puede tener varios habitantes pero un
habitante pertenece a una sola población. Esta relación se representa incluyendo en la tabla 'hijo'
2/14 25/05/10 04:15:19 /media/JROJASD/fpuna/20122/bd1na/unidad3/documentosdeconsulta/d03-03.odt
Departamento de Informática
Cátedra de Base de Datos I
Facultad Politécnica
Sección NA
Universidad Nacional de Asunción
Docente: José Rojas Dávalos
Unidad 3: Diseño de bases de datos relacionales
3.3. Integridad de bases de datos
Documentos de consulta
una columna que se corresponde con la clave principal de la tabla 'padre', esta columna es lo
denominamos clave foránea (o clave ajena o clave externa).
Una clave foránea es pues un campo de una tabla que contiene una referencia a un registro de otra
tabla. Siguiendo nuestro ejemplo en la tabla habitantes tenemos una columna población que
contiene el código de la población en la que está empadronado el habitante, esta columna es clave
ajena de la tabla habitantes, y en la tabla poblaciones tenemos una columna codigo de poblacion
clave principal de la tabla.
Relación Varios a Varios: Cuando un registro de una tabla puede estar relacionado con más
de un registro de la otra tabla y viceversa. En este caso las dos tablas no pueden estar
relacionadas directamente, se tiene que añadir una tabla entre las dos que incluya los pares de
valores relacionados entre sí.
Por ejemplo: tenemos dos tablas una con los datos de clientes y otra con los artículos que se
venden en la empresa, un cliente podrá realizar un pedido con varios artículos, y un artículo podrá
ser vendido a más de un cliente.
No se puede definir entre clientes y artículos, hace falta otra tabla (por ejemplo una tabla de
pedidos) relacionada con clientes y con artículos. La tabla pedidos estará relacionada con cliente
por una relación uno a muchos y también estará relacionada con artículos por un relación uno a
muchos.
3/14 25/05/10 04:15:19 /media/JROJASD/fpuna/20122/bd1na/unidad3/documentosdeconsulta/d03-03.odt
Departamento de Informática
Cátedra de Base de Datos I
Facultad Politécnica
Sección NA
Universidad Nacional de Asunción
Docente: José Rojas Dávalos
Unidad 3: Diseño de bases de datos relacionales
3.3. Integridad de bases de datos
Documentos de consulta
Integridad referencial
Cuando se define una columna como clave foránea, las filas de la tabla pueden contener en esa
columna o bien el valor nulo (ningún valor), o bien un valor que existe en la otra tabla, un error
sería asignar a un habitante una población que no está en la tabla de poblaciones. Eso es lo que se
denomina integridad referencial y consiste en que los datos que referencian otros (claves
foráneas) deben ser correctos. La integridad referencial hace que el sistema gestor de la base de
datos se asegure de que no hayan en las claves foráneas valores que no estén en la tabla principal.
La integridad referencial se activa en cuanto creamos una clave foránea y a partir de ese
momento se comprueba cada vez que se modifiquen datos que puedan alterarla.
¿ Cuándo se pueden producir errores en los datos?
Cuando insertamos una nueva fila en la tabla secundaria y el valor de la clave foránea no
existe en la tabla principal. insertamos un nuevo habitante y en la columna poblacion escribimos
un código de poblacion que no está en la tabla de poblaciones (una población que no existe).
Cuando modificamos el valor de la clave principal de un registro que tiene 'hijos',
modificamos el codigo de Valencia, sustituimos el valor que tenía (1) por un nuevo valor (10), si
Valencia tenía habitantes asignados, qué pasa con esos habitantes, no pueden seguir teniendo el
codigo de población 1 porque la población 1 ya no existe, en este caso hay dos alternativas, no
dejar cambiar el codigo de Valencia o bien cambiar el codigo de población de todos los habitantes
de Valencia y asignarles el código 10.
Cuando modificamos el valor de la clave foránea, el nuevo valor debe existir en la tabla
principal. Por ejemplo cambiamos la población de un habitante, tenía asignada la población 1
(porque estaba empadronado en valencia) y ahora se le asigna la población 2 porque cambia de
lugar de residencia. La población 2 debe existir en la tabla de poblaciones.
Cuando queremos borrar una fila de la tabla principal y ese registro tiene 'hijos', por
ejemplo queremos borrar la población 1 (Valencia) si existen habitantes asignados a la población 1,
estos no se pueden quedar con el valor 1 en la columna población porque tendrían asignada una
población que no existe. En este caso tenemos dos alternativas, no dejar borrar la población 1 de la
4/14 25/05/10 04:15:19 /media/JROJASD/fpuna/20122/bd1na/unidad3/documentosdeconsulta/d03-03.odt
Departamento de Informática
Cátedra de Base de Datos I
Facultad Politécnica
Sección NA
Universidad Nacional de Asunción
Docente: José Rojas Dávalos
Unidad 3: Diseño de bases de datos relacionales
3.3. Integridad de bases de datos
Documentos de consulta
tabla de poblaciones, o bien borrarla y poner a valor nulo el campo poblacion de todos sus 'hijos'.
Asociada a la integridad referencial están los conceptos de actualizar los registros en cascada y
eliminar registros en cascada.
Actualización y borrado en cascada
El actualizar y/o eliminar registros en cascada, son opciones que se definen cuando definimos la
clave foránea y que le indican al sistema gestor qué hacer en los casos comentados en el punto
anterior.
Actualizar
registros
en
cascada:
Esta opción le indica al sistema gestor de la base de datos que cuando se cambie un valor del
campo clave de la tabla principal, automáticamente cambiará el valor de la clave foránea de
los
registros
relacionados
en
la
tabla
secundaria.
Por ejemplo, si cambiamos en la tabla de poblaciones (la tabla principal) el valor 1 por el valor 10
en el campo codigo (la clave principal), automáticamente se actualizan todos los habitantes (en la
tabla secundaria) que tienen el valor 1 en el campo poblacion (en la clave ajena) dejando 10 en vez
de 1.
Si no se tiene definida esta opción, no se puede cambiar los valores de la clave principal de la tabla
principal. En este caso, si intentamos cambiar el valor 1 del codigo de la tabla de poblaciones , no
se produce el cambio y el sistema nos devuelve un error o un mensaje que los registros no se han
podido modificar por infracciones de clave.
Eliminar
registros
en
cascada:
Esta opción le indica al sistema gestor de la base de datos que cuando se elimina un registro de la
tabla principal automáticamente se borran también los registros relacionados en la tabla
secundaria.
Por ejemplo: Si borramos la población Onteniente en la tabla de poblaciones, automáticamente
todos los habitantes de Onteniente se borrarán de la tabla de habitantes.
Si no se tiene definida esta opción, no se pueden borrar registros de la tabla principal si estos tienen
registros relacionados en la tabla secundaria. En este caso, si intentamos borrar la población
Onteniente, no se produce el borrado y el sistema nos devuelve un error o un mensaje que los
5/14 25/05/10 04:15:19 /media/JROJASD/fpuna/20122/bd1na/unidad3/documentosdeconsulta/d03-03.odt
Departamento de Informática
Cátedra de Base de Datos I
Facultad Politécnica
Sección NA
Universidad Nacional de Asunción
Docente: José Rojas Dávalos
Unidad 3: Diseño de bases de datos relacionales
3.3. Integridad de bases de datos
Documentos de consulta
registros no se han podido eliminar por infracciones de clave.
Fuente: http://msdn.microsoft.com/es-es
Integridad de los datos
La exigencia de integridad de los datos garantiza la calidad de los datos de la base de datos. Por
ejemplo, si se especifica para un empleado el valor de identificador de 123, la base de datos no debe
permitir que ningún otro empleado tenga el mismo valor de identificador. Si tiene una columna
employee_rating para la que se prevean valores entre 1 y 5, la base de datos no debe aceptar
valores fuera de ese intervalo. Si en la tabla hay una columna dept_id en la que se almacena el
número de departamento del empleado, la base de datos sólo debe permitir valores que
correspondan a los números de departamento de la empresa.
Dos pasos importantes en el diseño de las tablas son la identificación de valores válidos para una
columna y la determinación de cómo forzar la integridad de los datos en la columna. La integridad
de datos pertenece a una de las siguientes categorías:
•
•
•
•
Integridad de entidad
Integridad de dominio
Integridad referencial
Integridad definida por el usuario
Integridad de entidad
La integridad de entidad define una fila como entidad única para una tabla determinada. La
6/14 25/05/10 04:15:19 /media/JROJASD/fpuna/20122/bd1na/unidad3/documentosdeconsulta/d03-03.odt
Departamento de Informática
Cátedra de Base de Datos I
Facultad Politécnica
Sección NA
Universidad Nacional de Asunción
Docente: José Rojas Dávalos
Unidad 3: Diseño de bases de datos relacionales
3.3. Integridad de bases de datos
Documentos de consulta
integridad de entidad exige la integridad de las columnas de los identificadores o la clave principal
de una tabla, mediante índices y restricciones UNIQUE, o restricciones PRIMARY KEY.
Integridad de dominio
La integridad de dominio viene dada por la validez de las entradas para una columna determinada.
Puede exigir la integridad de dominio para restringir el tipo mediante tipos de datos, el formato
mediante reglas y restricciones CHECK, o el intervalo de valores posibles mediante restricciones
FOREIGN KEY, restricciones CHECK, definiciones DEFAULT, definiciones NOT NULL y reglas.
Integridad referencial
La integridad referencial protege las relaciones definidas entre las tablas cuando se crean o se
eliminan filas. En SQL Server la integridad referencial se basa en las relaciones entre claves
externas y claves principales o entre claves externas y claves exclusivas, mediante restricciones
FOREIGN KEY y CHECK.La integridad referencial garantiza que los valores de clave sean
coherentes en las distintas tablas. Para conseguir esa coherencia, es preciso que no haya referencias
a valores inexistentes y que, si cambia el valor de una clave, todas las referencias a ella se cambien
en consecuencia en toda la base de datos.
Cuando se exige la integridad referencial, SQL Server impide a los usuarios:
• Agregar o cambiar filas en una tabla relacionada si no hay ninguna fila asociada en la tabla
principal.
• Cambiar valores en una tabla principal que crea filas huérfanas en una tabla relacionada.
• Eliminar filas de una tabla principal cuando hay filas relacionadas coincidentes.
Por ejemplo, en las tablas Sales.SalesOrderDetail y Production.Product de la base de datos
AdventureWorks, la integridad referencial se basa en la relación entre la clave externa
(ProductID) de la tabla Sales.SalesOrderDetail y la clave principal (ProductID) de la tabla
Production.Product. Esta relación garantiza que un pedido de ventas no pueda nunca hacer
referencia a un producto que no existe en la tabla Production.Product.
7/14 25/05/10 04:15:19 /media/JROJASD/fpuna/20122/bd1na/unidad3/documentosdeconsulta/d03-03.odt
Departamento de Informática
Cátedra de Base de Datos I
Facultad Politécnica
Sección NA
Universidad Nacional de Asunción
Docente: José Rojas Dávalos
Unidad 3: Diseño de bases de datos relacionales
3.3. Integridad de bases de datos
Documentos de consulta
Integridad definida por el usuario
La integridad definida por el usuario permite definir reglas de empresa específicas que no
pertenecen a ninguna otra categoría de integridad. Todas las categorías de integridad admiten la
integridad definida por el usuario. Esto incluye todas las restricciones de nivel de columna y nivel
de tabla en CREATE TABLE, procedimientos almacenados y desencadenadores.
Exigir la integridad de datos
Planear y crear tablas requiere identificar los valores válidos para las columnas y decidir cómo
exigir la integridad de los datos en las columnas. SQL Server proporciona los siguientes
mecanismos para exigir la integridad de los datos en una columna:
• Restricciones PRIMARY KEY
Una tabla suele tener una columna o una combinación de columnas cuyos valores identifican de
forma única cada fila de la tabla. Estas columnas se denominan claves principales de la tabla y
exigen la integridad de entidad de la tabla. Puede crear una clave principal mediante la definición de
una restricción PRIMARY KEY cuando cree o modifique una tabla.
Una tabla sólo puede tener una restricción PRIMARY KEY y ninguna columna a la que se aplique
una restricción PRIMARY KEY puede aceptar valores NULL. Debido a que las restricciones
PRIMARY KEY garantizan datos únicos, con frecuencia se definen en una columna de identidad.
Cuando especifica una restricción PRIMARY KEY en una tabla, Database Engine (Motor de base
de datos) exige la unicidad de los datos mediante la creación de un índice único para las columnas
de clave principal.Este índice también permite un acceso rápido a los datos cuando se utiliza la
clave principal en las consultas. De esta forma, las claves principales que se eligen deben seguir las
reglas para crear índices únicos.
Si se define una restricción PRIMARY KEY para más de una columna, puede haber valores
8/14 25/05/10 04:15:19 /media/JROJASD/fpuna/20122/bd1na/unidad3/documentosdeconsulta/d03-03.odt
Departamento de Informática
Cátedra de Base de Datos I
Facultad Politécnica
Sección NA
Universidad Nacional de Asunción
Docente: José Rojas Dávalos
Unidad 3: Diseño de bases de datos relacionales
3.3. Integridad de bases de datos
Documentos de consulta
duplicados dentro de la misma columna, pero cada combinación de valores de todas las columnas
de la definición de la restricción PRIMARY KEY debe ser única.
Como se muestra en la siguiente ilustración, las columnas ProductID y VendorID de la tabla
Purchasing.ProductVendor forman una restricción PRIMARY KEY compuesta para esta tabla.
Así se garantiza que la combinación de ProductID y VendorID es única.
Cuando trabaja con combinaciones, las restricciones PRIMARY KEY relacionan una tabla con otra.
Por ejemplo, para determinar los proveedores que suministran determinados productos, puede
utilizar una combinación de tres elementos entre las tablas Purchasing.Vendor,
Production.Product y Purchasing.ProductVendor. Puesto que ProductVendor contiene las
columnas de ProductID y VendorID, se puede obtener acceso a las tablas Product y Vendor
mediante su relación con ProductVendor.
• Restricciones FOREIGN KEY
Una clave externa (FK) es una columna o combinación de columnas que se utiliza para establecer y
exigir un vínculo entre los datos de dos tablas. Puede crear una clave externa mediante la definición
de una restricción FOREIGN KEY cuando cree o modifique una tabla.
En una referencia de clave externa, se crea un vínculo entre dos tablas cuando las columnas de una
de ellas hacen referencia a las columnas de la otra que contienen el valor de clave principal. Esta
columna se convierte en una clave externa para la segunda tabla.
Por ejemplo, la tabla Sales.SalesOrderHeader de la base de datos AdventureWorks2008R2 tiene
un vínculo a la tabla Sales.SalesPerson porque existe una relación lógica entre pedidos de ventas y
personal de ventas. La columna SalesPersonID de la tabla SalesOrderHeader coincide con la
columna de clave principal de la tabla SalesPerson. La columna SalesPersonID de la tabla
SalesOrderHeader es la clave externa para la tabla SalesPerson.
9/14 25/05/10 04:15:19 /media/JROJASD/fpuna/20122/bd1na/unidad3/documentosdeconsulta/d03-03.odt
Departamento de Informática
Cátedra de Base de Datos I
Facultad Politécnica
Sección NA
Universidad Nacional de Asunción
Docente: José Rojas Dávalos
Unidad 3: Diseño de bases de datos relacionales
3.3. Integridad de bases de datos
Documentos de consulta
No es necesario que una restricción FOREIGN KEY esté vinculada únicamente a una restricción
PRIMARY KEY de otra tabla; también puede definirse para que haga referencia a las columnas de
una restricción UNIQUE de otra tabla. Una restricción FOREIGN KEY puede contener valores
NULL, pero si alguna columna de una restricción FOREIGN KEY compuesta contiene valores
NULL, se omitirá la comprobación de los valores que componen la restricción FOREIGN KEY.
Para asegurarse de que todos los valores de la restricción FOREIGN KEY compuesta se
comprueben, especifique NOT NULL en todas las columnas que participan.
Nota:
10/14 25/05/10 04:15:19 /media/JROJASD/fpuna/20122/bd1na/unidad3/documentosdeconsulta/d03-03.odt
Departamento de Informática
Cátedra de Base de Datos I
Facultad Politécnica
Sección NA
Universidad Nacional de Asunción
Docente: José Rojas Dávalos
Unidad 3: Diseño de bases de datos relacionales
3.3. Integridad de bases de datos
Documentos de consulta
Una restricción FOREIGN KEY puede hacer referencia a columnas de tablas de la misma base de
datos o a columnas de una misma tabla. Se denominan tablas con referencia a sí mismas. Suponga,
por ejemplo, una tabla de empleados con tres columnas: employee_number, employee_name y
manager_employee_number. Dado que el responsable también es un empleado, hay una relación
de clave externa desde la columna manager_employee_number a la columna employee_number.
Integridad referencial
Aunque el fin principal de una restricción FOREIGN KEY es controlar los datos que pueden
almacenarse en la tabla de la clave externa; también controla los cambios realizados en los datos de
la tabla de la clave principal. Por ejemplo, si se elimina la fila de un vendedor de la tabla
Sales.SalesPerson y el identificador del vendedor se utiliza para pedidos de ventas en la tabla
Sales.SalesOrderHeader, se rompe la integridad relacional entre ambas tablas: los pedidos del
vendedor eliminado quedarán sin correspondencia en la tabla SalesOrderHeader sin ningún
vínculo con los datos de la tabla SalesPerson.
Con una restricción FOREIGN KEY se evita esta situación. Esta restricción exige la integridad
referencial al garantizar que no se puedan realizar cambios en los datos de la tabla de la clave
principal si esos cambios anulan el vínculo con los datos de la tabla de la clave externa. Si se intenta
eliminar la fila de una tabla de la clave principal o cambiar un valor de clave principal, la acción no
progresará si el valor de la clave principal cambiado o eliminado corresponde a un valor de la
restricción FOREIGN KEY de otra tabla. Para cambiar o eliminar una fila de una restricción
FOREIGN KEY, debe antes eliminar o cambiar los datos de clave externa de la tabla de clave
externa, lo que vincula la clave externa con otros datos de clave principal.
Indizar restricciones FOREIGN KEY
La creación de un índice en una clave externa suele ser útil por las siguientes razones:
• Los cambios en las restricciones PRIMARY KEY se comprueban con restricciones
FOREIGN KEY en las tablas relacionadas.
• Las columnas de clave externa suelen utilizarse en los criterios de combinación cuando los
datos de las tablas relacionadas se combinan en consultas mediante la correspondencia de la
columna o columnas de la restricción FOREIGN KEY de una tabla y la columna o columnas
de la clave única o principal de la otra. Un índice permite al Database Engine (Motor de base
de datos) buscar con rapidez datos relacionados en la tabla de clave externa.No obstante, no
es necesario crear este índice. Pueden combinarse los datos de dos tablas relacionadas
aunque no se hayan definido restricciones PRIMARY KEY o FOREIGN KEY entre ellas,
pero una relación de clave externa entre dos tablas indica que éstas se han optimizado para
su combinación en una consulta que utilice las claves como criterio. Para obtener más
información acerca de cómo usar restricciones FOREIGN KEY con combinaciones, vea
Aspectos básicos de las combinaciones y Tipos de consultas e índices.
11/14 25/05/10 04:15:19 /media/JROJASD/fpuna/20122/bd1na/unidad3/documentosdeconsulta/d03-03.odt
Departamento de Informática
Cátedra de Base de Datos I
Facultad Politécnica
Sección NA
Universidad Nacional de Asunción
Docente: José Rojas Dávalos
Unidad 3: Diseño de bases de datos relacionales
3.3. Integridad de bases de datos
Documentos de consulta
Número de restricciones FOREIGN KEY en una tabla
SQL Server no establece un límite predefinido en el número de restricciones FOREIGN KEY que
una tabla puede incluir (que hagan referencia a otras tablas) ni el número de restricciones
FOREIGN KEY pertenecientes a otras tablas que hagan referencia a determinada tabla. No
obstante, el número real de restricciones FOREIGN KEY se ve limitado por la configuración de
hardware y el diseño de la base de datos y la aplicación. Se recomienda que una tabla no contenga
más de 253 restricciones FOREIGN KEY y que no sea referencia para más de 253 restricciones
FOREIGN KEY. Tenga en cuenta el costo de exigir restricciones FOREIGN KEY cuando diseñe la
base de datos y las aplicaciones.
• Restricciones UNIQUE
Puede utilizar restricciones UNIQUE para garantizar que no se escriben valores duplicados en
columnas específicas que no forman parte de una clave principal. Tanto la restricción UNIQUE
como la restricción PRIMARY KEY exigen la unicidad; sin embargo, debe utilizar la restricción
UNIQUE y no PRIMARY KEY si desea exigir la unicidad de una columna o una combinación de
columnas que no forman la clave principal.
En una tabla se pueden definir varias restricciones UNIQUE, pero sólo una restricción PRIMARY
KEY.
Además, a diferencia de las restricciones PRIMARY KEY, las restricciones UNIQUE admiten
valores NULL. Sin embargo, de la misma forma que cualquier valor incluido en una restricción
UNIQUE, sólo se admite un valor NULL por columna.
Es posible hacer referencia a una restricción UNIQUE con una restricción FOREIGN KEY.
• Restricciones CHECK
Las restricciones CHECK exigen la integridad del dominio mediante la limitación de los valores
que puede aceptar una columna. Son similares a las restricciones FOREIGN KEY porque controlan
los valores que se colocan en una columna. La diferencia reside en la forma en que determinan qué
valores son válidos: las restricciones FOREIGN KEY obtienen la lista de valores válidos de otra
tabla, mientras que las restricciones CHECK determinan los valores válidos a partir de una
expresión lógica que no se basa en datos de otra columna. Por ejemplo, es posible limitar el
intervalo de valores para una columna salary creando una restricción CHECK que sólo permita
datos entre 15.000 y 100.000 dólares. De este modo se impide que se escriban salarios superiores al
intervalo de salario normal.
Puede crear una restricción CHECK con cualquier expresión lógica (booleana) que devuelva TRUE
(verdadero) o FALSE (falso) basándose en operadores lógicos. Para el ejemplo anterior, la
expresión lógica sería:
Puede aplicar varias restricciones CHECK a una sola columna. También puede aplicar una sola
restricción CHECK a varias columnas si se crea en el nivel de la tabla. Por ejemplo, una restricción
12/14 25/05/10 04:15:19 /media/JROJASD/fpuna/20122/bd1na/unidad3/documentosdeconsulta/d03-03.odt
Departamento de Informática
Cátedra de Base de Datos I
Facultad Politécnica
Sección NA
Universidad Nacional de Asunción
Docente: José Rojas Dávalos
Unidad 3: Diseño de bases de datos relacionales
3.3. Integridad de bases de datos
Documentos de consulta
CHECK para varias columnas se puede utilizar para confirmar que cualquier fila con un valor USA
en la columna country/region tiene también un valor de dos caracteres en la columna state. Así se
pueden comprobar varias condiciones en un mismo sitio.
Limitaciones de las restricciones CHECK
Las restricciones CHECK rechazan los valores que se evalúan como FALSE. Puesto que los valores
nulos se evalúan como UNKNOWN, su presencia en las expresiones puede reemplazar una
restricción. Por ejemplo, supongamos que coloca una restricción en una columna intMyColumn
que especifica que MyColumn sólo puede contener el valor 10 (MyColumn=10). Si inserta el
valor NULL en MyColumn, Database Engine (Motor de base de datos) inserta NULL y no
devuelve un error.
Una restricción CHECK devuelve TRUE cuando la condición que está comprobando no es FALSE
para ninguna fila de la tabla. Si una tabla recién creada no tiene filas, cualquier restricción CHECK
en esta tabla se considerará válida. Esta situación puede generar resultados inesperados, como en el
siguiente ejemplo.
CREATE TABLE CheckTbl (col1 int, col2 int);
GO
CREATE FUNCTION CheckFnctn()
RETURNS int
AS
BEGIN
DECLARE @retval int
SELECT @retval = COUNT(*) FROM CheckTbl
RETURN @retval
END;
GO
ALTER TABLE CheckTbl
ADD CONSTRAINT chkRowCount CHECK (dbo.CheckFnctn() >= 1 );
GO
La restricción CHECK que se agrega especifica que como mínimo debe existir una fila en la tabla
CheckTbl. Sin embargo, puesto que no hay filas en la tabla contra la que se comprueba la
condición de esta restricción, la instrucción ALTER TABLE será correcta.
Las restricciones CHECK no se validan durante las instrucciones DELETE. Por lo tanto, la
ejecución de instrucciones DELETE en las tablas con ciertos tipos de restricciones CHECK puede
generar resultados inesperados. Por ejemplo, imaginemos que las siguientes instrucciones se
ejecutan en la tabla CheckTbl.
INSERT INTO CheckTbl VALUES (10, 10)
GO
DELETE CheckTbl WHERE col1 = 10;
13/14 25/05/10 04:15:19 /media/JROJASD/fpuna/20122/bd1na/unidad3/documentosdeconsulta/d03-03.odt
Departamento de Informática
Cátedra de Base de Datos I
Facultad Politécnica
Sección NA
Universidad Nacional de Asunción
Docente: José Rojas Dávalos
Unidad 3: Diseño de bases de datos relacionales
3.3. Integridad de bases de datos
Documentos de consulta
La instrucción DELETE será correcta aunque la restricción CHECK especifique que la tabla
CheckTbl debe tener al menos 1 fila.
• Definiciones DEFAULT
Cada columna de un registro debe contener un valor, aunque sea un valor NULL. Puede haber
situaciones en las que deba cargar una fila de datos en una tabla, pero no conozca el valor de una
columna o el valor ya no exista. Si la columna acepta valores NULL, puede cargar la fila con un
valor NULL. Pero, dado que puede no resultar conveniente utilizar columnas que acepten valores
NULL, una mejor solución podría ser establecer una definición DEFAULT para la columna siempre
que sea necesario. Por ejemplo, es habitual especificar el valor cero como valor predeterminado
para las columnas numéricas, o N/D (no disponible) como valor predeterminado para las columnas
de cadenas cuando no se especifica ningún valor.
Al cargar una fila en una tabla con una definición DEFAULT para una columna, se indica
implícitamente a Database Engine (Motor de base de datos) que cargue un valor predeterminado en
la columna en la que no se haya especificado ningún valor.
• Permitir valores NULL
La nulabilidad de una columna determina si las filas de una tabla pueden contener un valor NULL
en esa columna. Un valor NULL no es lo mismo que cero (0), en blanco o que una cadena de
caracteres de longitud cero, como "". NULL significa que no hay ninguna entrada. La presencia de
un valor NULL suele implicar que el valor es desconocido o no está definido. Por ejemplo, un valor
NULL en la columna SellEndDate de la tabla Production.Product de la base de datos
AdventureWorks2008R2 no implica que el artículo no tenga una fecha de venta final. El valor
NULL significa que se desconoce la fecha o que no se ha establecido.
Si se inserta una fila, pero no se incluye ningún valor para una columna que permita valores NULL,
Database Engine (Motor de base de datos) proporcionará el valor NULL, a menos que exista una
definición o un objeto DEFAULT. Una columna definida con la palabra clave NULL también acepta
una entrada explícita de NULL por parte del usuario, independientemente del tipo de datos de que
se trate o de si tiene un valor predeterminado asociado. El valor NULL no debe ponerse entre
comillas porque no será interpretado como un valor NULL, sino como la cadena de caracteres
"NULL".
Si se configura una columna para que no permita valores NULL, será más fácil mantener la
integridad de los datos, ya que se garantiza que una columna de una fila siempre contendrá datos. Si
no se aceptan valores NULL, el usuario que escriba los datos en la tabla deberá especificar un valor
para la columna; de lo contrario, no se podrá aceptar la fila de la tabla en la base de datos.
Fin del documento
14/14 25/05/10 04:15:19 /media/JROJASD/fpuna/20122/bd1na/unidad3/documentosdeconsulta/d03-03.odt