UNIVERSIDAD TCNICA DE AMBATO

FACULTAD DE INGENIERA EN SISTEMAS,

ELECTRNICA E INDUSTRIAL
CARRERA DE INGENIERA INDUSTRIAL EN PROCESOS DE
AUTOMATIZACION

REGLAS DE INTEGRIDAD Y CONSISTENCIA DE LAS BDD

INTEGRANTES: Espn Nez Leonardo Israel.
Oate Nieto Geovanny Paul
NIVEL: 3ro Industrial B
FECHA DE ENTREGA: 29 de junio de 2015
MODULO: Base De Datos
PROFESOR: Ing. Alba de los Cielos Miranda Villacs

OBJETIVOS:

Conocer la estructura, funcionamiento y finalidad de reglas de integridad y consistencia

de bases de datos.
Identificar los principios que integran las reglas de integridad de base de datos.
Analizar los puntos esenciales de las consistencias de base de datos.

RESUMEN:
La integridad en una base de datos se refiere a la correccin y exactitud de la informacin
contenida. Una base de datos determinada podra estar sujeta a cualquier cantidad de
restricciones de integridad (en general) de una complejidad arbitraria. En la mayora de los
sistemas actuales, la verificacin de la integridad se realiza mediante cdigos de procedimientos
escritos por los usuarios.
La propiedad de Consistencia se asegura que cualquier transaccin llevar a la base de datos de
un estado vlido a otro estado vlido. Cualquier dato que se escriba en la base de datos tiene que
ser vlido de acuerdo a todas las reglas definidas, incluyendo (pero no limitado a) los
constraints, los cascades, los triggers, y cualquier combinacin de estos.

MARCO TEORICO
REGLAS DE INTEGRIDAD
Una base de datos contiene unos datos que, en cada momento, deben reflejar la realidad o, ms
concretamente, la situacin de una porcin del mundo real. En el caso de las bases de datos
relacionales, esto significa que la extensin de las relaciones (es decir, las tuplas que contienen
las relaciones) deben tener valores que reflejen la realidad correctamente.
Suele ser bastante frecuente que determinadas configuraciones de valores para las tuplas de las
relaciones no tengan sentido, porque no representan ninguna situacin posible del mundo real.
Un sueldo negativo
En la relacin de esquema EMPLEADOS (DNI, nombre, apellido, sueldo), una tupla que tiene
un valor de 1.000 para el sueldo probablemente no tiene sentido, porque los sueldos no pueden
ser negativos.

Denominamos integridad la propiedad de los datos de corresponder a representaciones

plausibles del mundo real.
Como es evidente, para que los datos sean ntegros, es preciso que cumplan varias condiciones.
El hecho de que los sueldos no puedan ser negativos es una condicin que se debera cumplir en
la relacin EMPLEADOS.
En general, las condiciones que garantizan la integridad de los datos pueden ser de dos tipos:
1) Las restricciones de integridad de usuario son condiciones especficas de una base de datos
concreta; es decir, son las que se deben cumplir en una base de datos particular con unos
usuarios concretos, pero que no son necesariamente relevantes en otra base de datos.

Restriccin de integridad de usuario en EMPLEADOS

ste sera el caso de la condicin anterior, segn la cual los sueldos no podan ser negativos.
Observad que esta condicin era necesaria en la base de datos concreta de este ejemplo porque
apareca el atributo sueldo, al que se quera dar un significado; sin embargo, podra no ser
necesaria en otra base de datos diferente donde, por ejemplo, no hubiese sueldos.
2) Las reglas de integridad de modelo, en cambio, son condiciones ms generales, propias de
un modelo de datos, y se deben cumplir en toda base de datos que siga dicho modelo.
Ejemplo de regla de integridad del modelo de datos relacional
En el caso del modelo de datos relacional, habr una regla de integridad para garantizar que los
valores de una clave primaria de una relacin no se repitan en tuplas diferentes de la relacin.
Toda base de datos relacional debe cumplir esta regla que, por lo tanto, es una regla de
integridad del modelo.
Los SGBD deben proporcionar la forma de definir las restricciones de integridad de usuario de
una base de datos; una vez definidas, deben velar por su cumplimiento.
Las reglas de integridad del modelo, en cambio, no se deben definir para cada base de datos
concreta, porque se consideran preestablecidas para todas las base de datos de un modelo. Un
SGBD de un modelo determinado debe velar por el cumplimiento de las reglas de integridad
preestablecidas por su modelo.
A continuacin estudiaremos con detalle las reglas de integridad del modelo relacional, reglas
que todo SGBD relacional debe obligar a cumplir.
1. Regla de integridad de unicidad de la clave primaria
La regla de integridad de unicidad est relacionada con la definicin de clave primaria.
Concretamente, establece que toda clave primaria que se elija para una relacin no debe
tener valores repetidos.
Ejemplo
Tenemos la siguiente relacin:
DESPACHOS
edificio
Marina
Marina
Marina
Diagonal

nmero
120
122
230
120

superficie
10
15
20
10

En esta relacin, dado que la clave primaria est formada por edificio y nmero, no hay
ningn despacho que repita tanto edificio como nmero de otro despacho. Sin embargo,
s se repiten valores de edificio (por ejemplo, Marina); y tambin se repiten valores de
nmero (120). A pesar de ello, el edificio y el nmero no se repiten nunca al mismo
tiempo.
A continuacin explicamos esta regla de forma ms precisa.

La regla de integridad de unicidad de la clave primaria establece que si el conjunto de

atributos CP es la clave primaria de una relacin R, entonces la extensin de R no puede
tener en ningn momento dos tuplas con la misma combinacin de valores para los
atributos de CP.
Un SGBD relacional deber garantizar el cumplimiento de esta regla de integridad en
todas las inserciones, as como en todas las modificaciones que afecten a atributos que
pertenecen a la clave primaria de la relacin.
Ejemplo
Tenemos la siguiente relacin:
DESPACHOS
edificio
Marina
Marina
Marina
Diagonal

nmero
120
122
230
120

superficie
10
15
20
10

En esta relacin no se debera poder insertar la tupla <Diagonal, 120, 30>, ni modificar
la tupla <Marina, 122, 15>, de modo que pasara a ser <Marina, 120, 15>.
2. Regla de integridad de entidad de la clave primaria
La regla de integridad de entidad de la clave primaria dispone que los atributos de la
clave primaria de una relacin no puedan tener valores nulos.
Ejemplo
Tenemos la siguiente relacin:
DESPACHOS
edificio

nmero

superficie

Marina

120

10

Marina

122

15

Marina

230

20

Diagonal

120

10

En esta relacin, puesto que la clave primaria est formada por edificio y nmero, no
hay ningn despacho que tenga un valor nulo para edificio, ni tampoco para nmero.
Esta regla es necesaria para que los valores de las claves primarias puedan identificar las
tuplas individuales de las relaciones. Si las claves primarias tuviesen valores nulos, es
posible que algunas tuplas no se pudieran distinguir.
Ejemplo de clave primaria incorrecta con valores nulos
En el ejemplo anterior, si un despacho tuviese un valor nulo para edificio porque
en un momento dado el nombre de este edificio no se conoce, por ejemplo

<NULO, 120, 30>, la clave primaria no nos permitira distinguirlo del despacho
<Marina, 120, 10> ni del despacho <Diagonal, 120,10>. No podramos estar
seguros de que el valor desconocido de edificio no es ni Marina ni Diagonal.
A continuacin definimos esta regla de forma ms precisa.
La regla de integridad de entidad de la clave primaria establece que si el conjunto de
atributos CP es la clave primaria de una relacin R, la extensin de R no puede tener
ninguna tupla con algn valor nulo para alguno de los atributos de CP.
Un SGBD relacional tendr que garantizar el cumplimiento de esta regla de integridad
en todas las inserciones y, tambin, en todas las modificaciones que afecten a atributos
que pertenecen a la clave primaria de la relacin.
Ejemplo
En la relacin DESPACHOS anterior, no se debera insertar la tupla <Diagonal,
NULO, 15>. Tampoco debera ser posible modificar la tupla <Marina, 120, 10>
de modo que pasara a ser <NULO, 120, 10>.
3. Regla de integridad referencial
La regla de integridad referencial est relacionada con el concepto de clave fornea.
Concretamente, determina que todos los valores que toma una clave fornea deben ser
valores nulos o valores que existen en la clave primaria que referencia.
Ejemplo
Si tenemos las siguientes relaciones:
Relacin DESPACHOS:
DESPACHOS
edificio

nmero

superficie

Marina

120

10

Marina

122

15

Marina

230

20

Diagonal

120

10

Relacin EMPLEADOS:
EMPLEADOS
DNI

nombre

apellido

edificiodesp

nmerodesp

40.444.255

Juan

Garca

Marina

120

33.567.711

Marta

Roca

Marina

120

55.898.425

Carlos

Buenda

Diagonal

120

77.232.144

Elena

Pla

NULO

NULO

Donde edificiodesp y nmerodesp de la relacin EMPLEADOS forman una

clave fornea que referencia la relacin DESPACHOS. Debe ocurrir que los
valores no nulos de edificiodesp y nmerodesp de la relacin EMPLEADOS
estn en la relacin DESPACHOS como valores de edificio y nmero. Por
ejemplo, el empleado <40.444.255, Juan Garca, Marina, 120> tiene el valor
Marina para edificiodesp, y el valor 120 para nmerodesp, de modo que en la
relacin DESPA CHOS hay un despacho con valor Marina para edificio y con
valor 120 para nmero.
La necesidad de la regla de integridad relacional proviene del hecho de que las claves
forneas tienen por objetivo establecer una conexin con la clave primaria que
referencian. Si un valor de una clave fornea no estuviese presente en la clave primaria
correspondiente, representara una referencia o una conexin incorrecta.
Referencia incorrecta
Supongamos que en el ejemplo anterior hubiese un empleado con los valores
<56.666.789, Pedro, Lpez, Valencia, 325>. Ya que no hay un despacho con los
valores Valencia y 325 para edificio y nmero, la tupla de este empleado hace
una referencia incorrecta; es decir, indica un despacho para el empleado que, de
hecho, no existe.
A continuacin explicamos la regla de modo ms preciso.
La regla de integridad referencial establece que si el conjunto de atributos CF es una
clave fornea de una relacin R que referencia una relacin S (no necesariamente
diferente de R), que tiene por clave primaria CP, entonces, para toda tupla t de la
extensin de R, los valores para el conjunto de atributos CF de t son valores nulos, o
bien valores que coinciden con los valores para CP de alguna tupla s de S.

En el caso de que una tupla t de la extensin de R tenga valores para CF que coincidan
con los valores para CP de una tupla s de S, decimos que t es una tupla que referencia s
y que s es una tupla que tiene una clave primaria referenciada por t.
Un SGBD relacional tendr que hacer cumplir esta regla de integridad. Deber efectuar
comprobaciones cuando se produzcan las siguientes operaciones:
a) Inserciones en una relacin que tenga una clave fornea.
b) Modificaciones que afecten a atributos que pertenecen a la clave fornea de una
relacin.
c) Borrados en relaciones referenciadas por otras relaciones.
d) Modificaciones que afecten a atributos que pertenecen a la clave primaria de una
relacin referenciada por otra relacin.
Ejemplo
Retomamos el ejemplo anterior, donde edificiodesp y nmerodesp de la relacin
EMPLEADOS forman una clave fornea que referencia la relacin
DESPACHOS:
Relacin DESPACHOS:

DESPACHOS
edificio

nmero

superficie

Marina

120

10

Marina

122

15

Marina

230

20

Diagonal

120

10

Relacin EMPLEADOS:
EMPLEADOS
DNI

nombre apellido

edificiodesp

nmerodesp

40.444.255

Juan

Marina

120

Garca

Marta
33.567.711

Marina
Roca

/td>

120
/td>

55.898.425

Carlos

Buenda

Diagonal

120

77.232.144

Elena

Pla

NULO

NULO

Las siguientes operaciones provocaran el incumplimiento de la regla de

integridad referencial:
Insercin de <12.764.411, Jorge, Puig, Diagonal, 220> en EMPLEADOS.
Modificacin de <40.444.255, Juan, Garca, Marina, 120> de EMPLEADOS
por <40.444.255, Juan, Garca, Marina, 400>.
Borrado de <Marina, 120, 10> de DESPACHOS.
Modificacin de <Diagonal, 120, 10
Un SGBD relacional debe procurar que se cumplan las reglas de integridad del
modelo. Una forma habitual de mantener estas reglas consiste en rechazar toda
operacin de actualizacin que deje la base de datos en un estado en el que alguna regla
no se cumpla. En algunos casos, sin embargo, el SGBD tiene la posibilidad de aceptar la
operacin y efectuar acciones adicionales compensatorias, de modo que el estado que se
obtenga satisfaga las reglas de integridad, a pesar de haber ejecutado la operacin.
Esta ltima poltica se puede aplicar en las siguientes operaciones de actualizacin que
violaran la regla de integridad:
a) Borrado de una tupla que tiene una clave primaria referenciada.
b) Modificacin de los valores de los atributos de la clave primaria de una tupla que
tiene una clave primaria referenciada.

En los casos anteriores, algunas de las polticas que se podrn aplicar sern las
siguientes: restriccin, actualizacin en cascada y anulacin. A continuacin explicamos
el significado de las tres posibilidades mencionadas.
3.1. Restriccin
La poltica de restriccin consiste en no aceptar la operacin de actualizacin.
Ms concretamente, la restriccin en caso de borrado, consiste en no permitir borrar una
tupla si tiene una clave primaria referenciada por alguna clave fornea.
De forma similar, la restriccin en caso de modificacin consiste en no permitir
modificar ningn atributo de la clave primaria de una tupla si tiene una clave primaria
referenciada por alguna clave fornea.
3.2. Actualizacin en cascada
La poltica de actualizacin en cascada consiste en permitir la operacin de
actualizacin de la tupla, y en efectuar operaciones compensatorias que propaguen en
cascada la actualizacin a las tuplas que la referenciaban; se acta de este modo para
mantener la integridad referencial.
3.3. Anulacin
Esta poltica consiste en permitir la operacin de actualizacin de la tupla y en efectuar
operaciones compensatorias que pongan valores nulos a los atributos de la clave
fornea de las tuplas que la referencian; esta accin se lleva a cabo para mantener la
integridad referencial.
Puesto que generalmente los SGBD relacionales permiten establecer que un
determinado atributo de una relacin no admite valores nulos, slo se puede aplicar la
poltica de anulacin si los atributos de la clave fornea s los admiten.
3.4. Seleccin de la poltica de mantenimiento de la integridad referencial
Hemos visto que en caso de borrado o modificacin de una clave primaria referenciada
por alguna clave fornea hay varias polticas de mantenimiento de la regla de
integridad referencial.
El diseador puede elegir para cada clave fornea qu poltica se aplicar en caso de
borrado de la clave primaria referenciada, y cul en caso de modificacin de sta. El
diseador deber tener en cuenta el significado de cada clave fornea concreta para
poder elegir adecuadamente.
4. Regla de integridad de dominio
La regla de integridad de dominio est relacionada, como su nombre indica, con la nocin
de dominio. Esta regla establece dos condiciones.
La primera condicin consiste en que un valor no nulo de un atributo Ah debe pertenecer al
dominio del atributo Ai; es decir, debe pertenecer a dominio (Ai).
Esta condicin implica que todos los valores no nulos que contiene la base de datos para un
determinado atributo deben ser del dominio declarado para dicho atributo.
Ejemplo:
Si en la relacin EMPLEADOS(DNI, nombre, apellido, edademp) hemos declarado que
dominio(DNI) es el dominio predefinido de los enteros, entonces no podremos insertar, por
ejemplo, ningn empleado que tenga por DNI el valor Luis, que no es un entero.
Recordemos que los dominios pueden ser de dos tipos: predefinidos o definidos por el
usuario.

Observar que los dominios definidos por el usuario resultan muy tiles, porque nos
permiten determinar de forma ms especfica cules sern los valores admitidos por los
atributos.
Ejemplo:
Supongamos ahora que en la relacin EMPLEADOS(DNI, nombre, apellido, edademp)
hemos declarado que dominio(edademp) es el dominio definido por el usuario edad.
Supongamos tambin que el dominio edad se ha definido como el conjunto de los enteros
que estn entre 16 y 65. En este caso, por ejemplo, no ser posible insertar un empleado con
un valor de 90 para edademp.
La segunda condicin de la regla de integridad de dominio es ms compleja, especialmente
en el caso de dominios definidos por el usuario; los SGBD actuales no la soportan para
estos ltimos dominios. Por estos motivos slo la presentaremos superficialmente.
Esta segunda condicin sirve para establecer que los operadores que pueden aplicarse sobre
los valores dependen de los dominios de estos valores; es decir, un operador determinado
slo se puede aplicar sobre valores que tengan dominios que le sean adecuados.
Ejemplo:
Analizaremos esta segunda condicin de la regla de integridad de dominio con un ejemplo
concreto. Si en la relacin EMPLEADOS(DNI, nombre, apellido, edademp) se ha declarado
que dominio(DNI) es el dominio predefinido de los enteros, entonces no se permitir
consultar todos aquellos empleados cuyo DNI sea igual a Elena (DNI = Elena). El
motivo es que no tiene sentido que el operador de comparacin = se aplique entre un DNI
que tiene por dominio los enteros, y el valor Elena, que es una serie de caracteres.
De este modo, el hecho de que los operadores que se pueden aplicar sobre los valores
dependan del dominio de estos valores permite detectar errores que se podran cometer
cuando se consulta o se actualiza la base de datos. Los dominios definidos por el usuario
son muy tiles, porque nos permitirn determinar de forma ms especfica cules sern los
operadores que se podrn aplicar sobre los valores.
Ejemplo:
Veamos otro ejemplo con dominios definidos por el usuario. Supongamos que en la
conocida relacin EMPLEADOS(DNI, nombre, apellido, edademp) se ha declarado que
dominio(DNI) es el dominio definido por el usuario nmerosDNI y que dominio(edademp)
es el dominio definido por el usuario edad. Supongamos que nmerosDNI corresponde a los
enteros positivos y que edad corresponde a los enteros que estn entre 16 y 65. En este caso,
ser incorrecto, por ejemplo, consultar los empleados que tienen el valor de DNI igual al
valor de edademp. El motivo es que, aunque tanto los valores de DNI como los de edademp
sean enteros, sus dominios son diferentes; por ello, segn el significado que el usuario les
da, no tiene sentido compararlos.
Sin embargo, los actuales SGBD relacionales no dan apoyo a la segunda condicin de la
regla de integridad de dominio para dominios definidos por el usuario. Si se quisiera hacer,
sera necesario que el diseador tuviese alguna forma de especificar, para cada operador que
se desease utilizar, para qu combinaciones de dominios definidos por el usuario tiene
sentido que se aplique.

CONSISTENCIA DE BASES DE DATOS.

Una base de datos tiene un concepto de Consistencia si se encuentra en un estado coherente en
la informacin o datos que contiene y que relaciona, en el cual la informacin cumple las
necesidades o expectativas de quien la requiera. El trmino en referencia es un complemento de

la Redundancia ya que para lograr la consistencia se debe lograr eliminar o controlar las
redundancias de datos existentes, lo que traer como resultado una baja tasa en el riesgo de
inconsistencias.
Adems es importante agregar que una base de datos est en un estado consistente si obedece
todas hace referencia a un registro en otra tabla y el registro correspondiente existe.
Supongamos el siguiente ejemplo, una situacin coherente apropiada de base de datos de una
aerolnea. La idea en definitiva es que un mismo asiento no sea asignado a dos pasajeros,
aunque esta regla las restricciones de integridad definidas sobre ella, es decir, cuando un
registro en una tabla
De integridad podra violarse durante breves momentos al efectuar una transaccin al moverse
los pasajeros entre los asientos, pero finalmente el administrador de transacciones del sistema
deber verificar que una vez terminadas esta accin la base de datos volver a ser coherente y
ser capaz de satisfacer las condiciones de consistencia que se hayan supuesto. Por lo tanto,
segn se logra visualizar, esto (Consistencia) corresponde a una propiedad que asegura que slo
se empieza aquello que se puede acabar ya que se ejecutan aquellas operaciones que no van a
romper las reglas y directrices de integridad de la base de datos (Integridad).
Sin embargo, si el DBMS no est al tanto de alguna accin de duplicidad, es decir, la
redundancia no est controlada, entonces necesariamente los registros no generarn
coincidencias o simplemente la informacin de retorno no ser coherente y fidedigna. En ese
caso decimos que la base de datos es inconsistente pues resulta claro que una base de datos en
un estado inconsistente no ser capaz de proporcionar a sus usuarios informacin correcta y til.
1. Cundo una base de datos est en un estado consistente
Una base de datos est en un estado consistente si obedece todas las restricciones de
integridad definidas en ella (esto significa que cuando un registro en una tabla haga
referencia a un registro en otra tabla, el registro correspondiente debe existir).
Los cambios de estado ocurren debido a actualizaciones, inserciones y supresiones de
informacin. Por supuesto, se quiere asegurar que la base de datos nunca entre en un estado
de inconsistencia.
Sin embargo, durante la ejecucin de una transaccin, la base de datos puede estar
temporalmente en un estado inconsistente.
El punto importante aqu es asegurar que la base de datos regresa a un estado consistente al
fin de la ejecucin de una transaccin.
2. Rol de la consistencia en las transacciones de bases de datos.
Dentro de las propiedades fundamentales de una transaccin en una base de datos se
encuentra la consistencia, y para que una transaccin se realice exitosamente, la
consistencia cumple un rol fundamental.
Pero es necesario partir sabiendo unos conceptos bsicos de transaccin.

2.1. Transaccin
Una transaccin es una unidad de la ejecucin de un programa. Puede consistir en
varias operaciones de acceso a la base de datos. Cada transaccin puede estar
compuesta de mltiples operaciones realizadas en datos que estn dispersos en uno o
varios procesos o en una o varias mquinas. Cada transaccin asegura el trabajo de
proteger la integridad del estado de un sistema, al proveer cuatro garantas bsicas
conocidas como las propiedades ACID: atomicidad, consistencia, aislamiento y
durabilidad.
2.2. Ejemplos De Consistencia
Ejemplo 01: Una transaccin mantendr la consistencia de la base de datos. Esto es, si
la base de datos se encuentra en un estado interno de consistencia antes de ejecutar la
transaccin, una vez que sta termine la consistencia de la base de datos deber
conservarse. En trminos de base de datos esto significa que se satisfacen todas las
restricciones en cuanto a su integridad que incluyen:

Todos los valores de las llaves primarias son nicos.

La base de datos mantiene integridad referencial lo que significa que los
registros solo referencian informacin que existe.
Ciertas condiciones se mantienen. Por ejemplo: el nmero de horas que un
empleado puede trabajar en una semana no puede exceder un lmite especfico
de horas

A diferencia de la atomicidad, el aislamiento y la durabilidad, la consistencia es una

prctica de programacin. La atomicidad, el aislamiento y la durabilidad estn
aseguradas estn o no programadas para preservar la consistencia. Es responsabilidad
del administrador de la base de datos asegurar que su programa preserva la
consistencia.
Ejemplo 02: Eliminando o controlando las redundancias de datos se reduce en gran
medida el riesgo de que haya inconsistencias. Si un dato est almacenado una sola vez,
cualquier actualizacin se debe realizar slo una vez, y est disponible para todos los
usuarios inmediatamente. Si un dato est duplicado y el sistema conoce esta
redundancia, el propio sistema puede encargarse de garantizar que todas las copias se
mantienen consistentes.
La consistencia es un trmino ms amplio que el de integridad. Podra definirse como
la coherencia entre todos los datos de la base de datos. Cuando se pierde la integridad
tambin se pierde la consistencia. Pero la consistencia tambin puede perderse por
razones de funcionamiento.

3. Restricciones de consistencia
Los valores de los datos que se almacenan en la base de datos deben satisfacer ciertos tipos
de restricciones de consistencia. Estas restricciones se hacen cumplir en el sistema
aadiendo cdigos apropiados en los diversos programas de aplicacin. Para aadir aquellos
cdigos se utiliza el Lenguaje de definicin de datos (LDD), que tambin se ocupa para
especificar esquemas de bases de datos. El objetivo primordial de la restriccin de
consistencia es la conservacin de la consistencia en un sistema de base de datos.
El Administrador de Bases de Datos (DBA) debe aplicar estas restricciones de consistencia
en las bases de datos. Bajo su supervisin los sistemas de bases de datos deben comprobar
estas restricciones cada vez que se actualiza la base de datos, si estas actualizaciones dan
como resultado una violacin de restriccin, el DBA debe proveer la accin apropiada para
su correccin.
4. Otras definiciones para consistencia
Consistencia: La consistencia de una transaccin es simplemente su correccin. En otras
palabras, una transaccin es un programa correcto que lleva a la base de datos de un estado
consistente a otro con la misma caracterstica. Debido a esto, las transacciones no violan las
restricciones de integridad de una base de datos.
Consistencia: es la propiedad que asegura que slo se empieza aquello que se puede acabar.
Por lo tanto se ejecutan aquellas operaciones que no van a romper la reglas y directrices de
integridad de la base de datos.
Consistencia: una base de datos generalmente tiene un concepto de un estado coherente,
en el cual la informacin cumple las expectativas que podamos tener. Por ejemplo, una
situacin coherente apropiada de la base de datos de una aerolnea que un mismo asiento no
sea asignado a dos pasajeros. Aunque pueda violarse esta condicin durante breves
momentos al efectuar una transaccin al moverse los pasajeros entre los asientos, el
administrador de transacciones deber cerciorarse de que, una vez terminadas estas, la base
de datos satisfaga las condiciones de consistencia que se hayan supuesto.

DISCUSIN:

Los conceptos que interactan con la Consistencia, como por ejemplo la Integridad y la
Consistencia. Fue interesante entender que la consistencia es importante en la
administracin de un sistema de Base de Datos y que se encuentra presente en varios
procesos de ella.
Logramos comprender que un dato es consistente cuando cumple con lo esperado,
cuando se ejecuta una accin y se espera un resultado que se relaciona con el conjunto
de lo requerido y entrega datos que a la vez son coherentes. Cuando las piezas encajan
podemos decir que es algo consistente, como un rompecabezas.
Por tanto, podemos resumir que se entiende por consistencia, si cumple con todo lo
establecido algo es consistente

CONCLUSIONES:

En conclusin, podemos afirmar en referencia a lo expuesto mediante este informe, que

una Base de Datos y la informacin contenida en esta, se encuentra en un estado
consistente si obedece todas las restricciones de integridad (significa que cuando un
registro en una tabla haga referencia a un registro en otra tabla, el registro
correspondientes debe existir) definidas sobre ella.
Es importante mencionar que los cambios de estado, ocurren debido a actualizaciones,
inserciones y supresiones de informacin. Por supuesto, se requiere asegurar, que la
Base de Datos nunca entre en un estado de inconsistencia.
Por otro lado, existe la posibilidad que durante la ejecucin de una transaccin, la base
de datos puede estar temporalmente en un estado inconsistente, pero debido a los
DBMS tenemos una alta tasa de asegurar que la Base de Datos regresa a un estado
consistente al fin de la ejecucin de la transaccin.

BIBLIOGRAFA:

Sitio Web Taller de Base de Datos

http://es.scribd.com/doc/32352648/Taller-de-Base-de-Datos#outer_page_29
Sitio Web El blog de Ingensistemas Unidad 4: Control de Transacciones
http://tallerdebasededatos.obolog.com/unidad-cuatro-control-trasacciones-444803
Sitio Web Monografas.com - Apuntes de Administracin de Bases de Datos
http://www.monografias.com/trabajos19/administracion-base-datos/administracionbase-datos.shtml
Sitio Web DATAPRIX del Web
http://www.dataprix.com/reglas-integridad
Sitio Web del Departamento de Sistemas y Computacin del Instituto Tecnolgico de
La Paz, Mxico.

http://sistemas.itlp.edu.mx/tutoriales/tallerdebasesdedatos/t42.htm