Base de Datos distribuida (BDD):

Una Base de Datos Distribuida es, una base de datos construida sobre una red
computacional y no por el contrario en una mquina aislada. La informacin que
constituye la base de datos esta almacenada en diferentes sitios en la red, y las
aplicaciones que se ejecutan accesan datos en distintos sitios.
Una Base de Datos Distribuida entonces es una coleccin de datos que pertenecen
lgicamente a un slo sistema, pero se encuentra fsicamente esparcido en varios "sitios"
de la red. Un sistema de base de datos distribuidas se compone de un conjunto de sitios,
conectados entre s mediante algn tipo de red de comunicaciones, en el cual:

Cada sitio es un sistema de base de datos en s mismo, pero,
Los sitios han convenido en trabajar juntos ( si es necesario ) con el fin de que un
usuario de cualquier sitio pueda obtener acceso a los datos de cualquier punto de
la red tal como si todos los datos estuvieran almacenados en el sitio propio del
usuario.

En consecuencia, la llamada "base de datos distribuida" es en realidad una especie de
objeto virtual, cuyas partes componentes se almacenan fsicamente en varias bases de
datos "reales" distintas ubicadas en diferentes sitios. De hecho, es la unin lgica de esas
bases de datos. En otras palabras, cada sitio tiene sus propias bases de datos "reales"
locales, sus propios usuarios locales, sus propios DBMS y programas para la administracin
de transacciones ( incluyendo programas de bloqueo, bitcoras, recuperacin, etc ), y su
propio administrador local de comunicacin de datos (administrador DC ). En particular un
usuario dado puede realizar operaciones sobre los datos en su propio sitio local
exactamente como si ese sitio no participara en absoluto en el sistema distribuido ( al
menos, se es uno de los objetivos ). As pues, el sistema de bases de datos distribuidas
puede considerarse como una especie de sociedad entre los DBMS individuales locales de
todos los sitios. Un nuevo componente de software en cada sitio ( en el aspecto lgico,
una extensin del DBMS local ) realiza las funciones de sociedad necesarias; y es la
combinacin de este nuevo componente y el DBMS ya existente lo que constituye el
llamado "sistema de administracin de bases de datos distribuidas" (DDBMS, distributed
database management system ).

Ventajas
El acceso a los datos es ms rpido debido a que los datos se localizan ms
cercanos al lugar donde se utilizan.
El procesamiento es rpido debido a que varios nodos intervienen en el
procesamiento de una carga de trabajo
Nuevos nodos se pueden agregar fcil y rpidamente.
La probabilidad de que una falla en un solo nodo afecte al sistema es baja y existe
una autonoma e independencia entre los nodos.
Control local de los datos con que se interacta.
Mayor tolerancia a los fallos
Se pueden modificar, agregar o quitar sistemas de la base de datos distribuida sin
afectar a los dems sistemas (mddularidad)
Desventajas
Es ms complicado el control y la manipulacin de los datos
Es compleja el aseguramiento de la integridad de la informacin en presencia de
fallas no predecibles tanto de componentes de hardware como de software. La
integridad se refiere a la consistencia, validez y exactitud de la informacin.
Se vuelve difcil mantener la integridad, aplicar las reglas de integridad a travs de
la red puede ser muy caro en trminos de transmisin de datos.
El control de concurrencia y los mecanismos de recuperacin son mucho ms
complejos que en un sistema centralizado dado que los datos pueden estar
replicados.

La distribucin de la BD requiere determinar la fragmentacin y la localizacin. La
fragmentacin es el proceso de dividir una relacin en pequeas porciones llamadas
fragmentos [Meghini, 1991]. Las razones principales para la fragmentacin son el
incremento del nivel de concurrencia y el desempeo del sistema. Existen dos alternativas
para fragmentar datos: fragmentacin horizontal (FH) y fragmentacin vertical (FV). La
combinacin de las anteriores resulta en una fragmentacin hbrida. Es importante seguir
tres reglas, las cuales aseguran que la BD no tenga cambios semnticos durante la
fragmentacin: completitud, reconstruccin y disjuntura.
Sistema de Gestin de Base de Datos Distribuida:
Un sistema de gestin de bases de datos distribuidas (SGBDD) es un Sistema de Gestin de
bases de datos que gestiona la BD distribuida
Funcionalidades adicionales de un SGBDD
Accede a sitios remotos y transmite consultas y datos a travs de varios sitios
mediante una red de comunicacin.
Almacena el esquema de distribucin y replicacin de los datos en el catalogo del
sistema.
Establece las estrategias de ejecucin de las consultas y las transacciones que
acceden a los datos en ms de un sitio.
Decide sobre cual copia de los datos replicados acceder.
Mantiene la consistencia de las copias de los datos replicados.
Realiza la recuperacin ante los fallos.

Ambientes de bases de datos distribuidas:
Las BDD pueden ser:
Homogneas: Todos los sitios tienen el mismo SGBD, son conscientes de la
existencia de los dems sitios y cooperan en el procesamiento de las solicitudes.
Los sitios locales mantienen un mismo esquema y SGBD.
Heterogneas: Cada sitio puede tener un SGBD distinto as como esquemas
diferentes. Puede que algunos sitios no conozcan a otros. Puede que solo ofrezcan
facilidades limitadas para la cooperacin en el procesamiento de transacciones.
Problemas fundamentales a resolver en las bases de datos distribuidas:
Diseo de bases de datos distribuidas
Procesamiento y optimizacin de consultas
Manejo de transacciones y control de concurrencia
En el diseo de bases de datos distribuidas se debe considerar el problema de cmo
distribuirla informacin entre diferentes sitios. Existen razones organizacionales las cuales
determinan en gran medida lo anterior. Sin embargo, cuando se busca eficiencia en el
acceso a la informacin, se deben abordardos problemas relacionados. Primero, como
fragmentar la informacin. Segundo, como asignar cada fragmento entre los diferentes
sitios de la red.
En el diseo de la BDD tambin es importante considerar si la informacin est replicada,
es decir, si existen copias mltiples del mismo dato y, en este caso, como mantener la
consistencia de la informacin. Finalmente, una parte importante en el diseo de una BDD
se refiere al manejo del directorio. Si existen nicamente usuarios globales, se debe
manejar un solo directorio global. Sin embargo, si existen tambin usuarios locales, el
directorio combina informacin local con informacin global.

Etapas del diseo:
La etapa diferenciadora entre el diseo de una base de datos centralizada y una base de
datos distribuidas es el "Diseo de la distribucin" que consta de dos actividades :
Fragmentacin: Decidir "como" dividimos la BD y en "que" partes .
Asignacin: Decidir "donde" ubicamos cada parte, as como si tendremos replicacin de
datos.
Aspectos a considerar en el diseo de una BD distribuida:
Fragmentacin: Una relacin puede ser dividida en un nmero de sub-relaciones,
denominadas fragmentos, los cuales son entonces distribuidas
Asignacin: cada fragmento debe ser almacenado en un sitio en base a una
distribucin optima.
Replicacin: El SGBDD puede mantener una copia de un fragmento en diferentes
sitios
Fragmentacin:
El problema de fragmentacin se refiere al particionamiento de la informacin para
distribuir cada parte a los diferentes sitios de la red
Objetivos de la fragmentacin:
El objetivo de la fragmentacin consiste en dividir la relacin en un conjunto de relaciones
ms pequeas tal que algunas de las aplicaciones de usuario slo hagan uso de un
fragmento.
Sobre este marco, una fragmentacin ptima es aquella que produce un esquema de
divisin que minimiza el tiempo de ejecucin de las aplicaciones que emplean esos
fragmentos.
La unidad de fragmentacin ideal no es la tabla sino una subdivisin de sta.
Esto es debido a:
Las aplicaciones usan vistas definidas sobre varias relaciones, es decir, se forman a
partir de "trozos" de varias tablas. Si conseguimos que cada una de las vistas est
definida sobre subtablas locales (o en su defecto lo mas "cerca" posible) a cada
aplicacin, es de esperar un incremento en el rendimiento.
Si mltiples vistas de diferentes aplicaciones estn definidas sobre una tabla no
fragmentada, se tiene :
Si la tabla no est replicada entonces se produce generacin de trfico por accesos
remotos.
Si la tabla est replicada en todos o algunos de los sitios donde residen cada una
de las aplicaciones entonces la generacin de trafico innecesario es producida por
la necesidad de la actualizacin de las copias.
Ventajas
Al descomponer una relacin en fragmentos (unidades de distribucin) :
Permitimos el procesamiento concurrente de transacciones ya que no se bloquean
tablas enteras sino subtablas, por lo que dos consultas pueden acceder a la misma
tabla a fragmentos distintos.
Permitimos la paralelizacin de consultas al poder descomponerlas en
subconsultas, cada una de la cuales trabajar con un fragmento diferente
incrementndose as el rendimiento.
Desventajas
Degradacin del rendimiento en vistas definidas sobre varios fragmentos ubicados
en sitios distintos (es necesario realizar operaciones con esos trozos lo cual es
costoso)
El control semntico se dificulta y el rendimiento se degrada debido que la
verificacin de restricciones de integridad (claves ajenas, uniques, etc) implican
buscar fragmentos en mltiples localizaciones.
Por lo tanto divisin y ubicacin de los fragmentos no es trivial.
Existen tres tipos de fragmentacin:
Fragmentacin horizontal
Fragmentacin vertical
Fragmentacin hbrida
Para que una la fragmentacin de una relacin sea correcta debe satisfacer las siguientes
condiciones:
Condicin de completitud.
La descomposicin de una relacin R en los fragmentos R1, R2, ..., Rn es completa si y
solamente si cada elemento de datos en R se encuentra en alguno de los fragmentos Ri.
Condicin de Reconstruccin.
La descomposicin de una relacin R en los fragmentos R1, R2, ..., Rn es completa si y
solamente si cada elemento de datos en R se encuentra en alguno de los fragmentos Ri.
Condicin de Fragmentos Disjuntos.
Si la relacin R se descompone en los fragmentos R1, R2, ..., Rn, y el dato di est en Rj,
entonces, no debe estar en ningn otro fragmento Rk (k?j).
Fragmentacin horizontal:
La fragmentacin horizontal de una relacin R produce una serie de fragmentos R1, R2, ...,
Rr, cada uno de los cuales contiene un subconjunto de las tuplas de R que cumplen
determinadas propiedades (predicados)
Fragmentacin horizontal primaria y derivada
La Fragmentacin Horizontal Primaria (FHP) de una relacin se obtiene usando predicados
que estn definidos en esa relacin.
La Fragmentacin Horizontal Derivada (FHD) por otra parte, es el particionamiento de una
relacin como resultado de predicados que se definen en otra relacin.
Fragmentacin vertical:
La fragmentacin vertical de una relacin R produce una serie de fragmentos R1, R2, ...,
Rr cada uno de los cuales contiene un subconjunto de los atributos de R as como la clave
primaria de R.
Complejidad de la fragmentacin Vertical
La fragmentacin vertical resulta ms complicada que la horizontal. En el caso vertical, si
una relacin tiene m atributos clave no primarios, el nmero de posibles fragmentos es
igual a B(m), es decir el m-simo nmero de Bell [3]. Para valores grandes de m, B(m)(mm;
por ejemplo, para m = 10, B(m) ( 115.000, para m = 15, B(m) ( 109, para m = 30, B(m) =
1023.
Estos valores indican que la obtencin de una solucin ptima de la fragmentacin vertical
resultar una tarea imposible, sino nos apoyamos en el uso de heursticas.
El problema de la asignacin de fragmentos
Asumamos que hay un conjunto de fragmentos F = { F1, F2, ..., Fn } y una red que consiste
de los sitios S = { S1, S2, ..., Sm } en los cuales un conjunto Q = { q1, q2, ..., qq } de
consultas se van a ejecutar.
El problema de asignacin consiste en determinar la distribucin "ptima" de F en S.
La optimalidad puede ser definida de acuerdo a dos medidas:
Costo mnimo. Consiste del costo de comunicacin de datos, del costo
de almacenamiento, y del costo procesamiento (lecturas y actualizaciones a cada
fragmento). El problema de la asignacin, es encontrar un esquema de asignacin
o ubicacin que minimiza la funcin de costo combinada.
Rendimiento: La estrategia de asignacin se disea para mantener una mtrica de
rendimiento. Las dos mtricas ms utilizadas son el tiempo de respuesta y el
"throughput" (nmero de trabajos procesados por unidad de tiempo).
Asignacin de fragmentos:
Proceso mediante el cual se decide donde se ubicaran los fragmentos de la etapa anterior
y si se harn replicas de los mismos.
Hacer replicas tiene sentido por :
Confiabilidad : Mayor seguridad ante perdida de datos
Disponibilidad : Mayor tolerancia a fallos ante cadas de los computadores
Aumento del paralelismo : Mayor eficiencia en las consultas de lectura al
posibilitarse su descomposicin en subconsultas y la paralelizacin de stas.
Pero presenta el inconvenientes de las consultas de escritura, que conllevan las
actualizacin de todas las copias de la red.
En la prctica : Sopesar lecturas vs escrituras
Mas lecturas que escrituras : Replicacin es buena idea
Mas escrituras que lecturas : No replicamos.
Segn el grado de replicacin, distinguimos entre :
BD fragmentada : Fragmentos disjuntos, cada uno en un nodo (no hay replicas)
BD totalmente replicada : Se encuentra una copia de toda la BD en cada nodo
BD parcialmente replicada : Mezcla las anteriores. Algunos fragmentos estn
replicados.
Como se ve las tcnicas de fragmentacin y replicacin se combinan en la prctica.

Replicacin de fragmentos: El problema de la replicacin de segmentos asignacin
consiste en la determinacin de que fragmentos se replicarn en diferentes sitios a pesar
de los problemas que acarrea la actualizacin.

Las 12 reglas de un SGBDD:
El principio fundamental de las Bases de Datos Distribuidas o regla cero plantea que:
"Desde el punto de vista del usuario, un sistema distribuido deber ser idntico a un
sistema no distribuido"
La regla cero conduce a las restantes 12 reglas.
Todas las reglas no son independientes entre s, ni tienen igual importancia pero son tiles
para entender la tecnologa distribuida.
1. Autonoma Local: Los sitios de un sistema distribuido deben ser autnomos.
La autonoma Local Implica:
Propietario local.
Administracin local.
Responsabilidad local.
Integracin local.
Representacin local.
2. No dependencia de un sitio central
No debe existir un nico sitio, ya que implicara:
Cuello de botella.
Vulnerabilidad.
3. Operacin continua
Adicin de elementos
Actualizacin de versiones
4. Independencia de Localizacin
El usuario desconoce dnde estn fsicamente los datos.

5. Independencia de fragmentacin.
Deseable porque simplifica los programas de los usuarios y sus actividades en la terminal
6. Independencia de rplica
La creacin y destruccin de rplicas debe hacerse transparente al usuario.
La rplica proporciona:
Ventajas:
Mayor Prestacin: los datos son locales.
Mayor disponibilidad: los datos son accesibles siempre.
Desventajas
Hay que propagar las actualizaciones.
7. Procesamiento distribuido de consultas
Los Sistemas relacionales brindan herramientas de consulta muy eficientes.
Varias maneras de trasladar los datos
8. Manejo distribuido de transacciones
Transaccin distribuida: varios agentes de la transaccin en varios lugares.
Control de recuperacin: una transaccin atmica. Todos los agentes avanzan o
retroceden juntos.
Control de concurrencia: Bloqueos mediante paso de mensajes.
9. Independencia con respecto al equipo
El SGBD se ejecutar igual sea cual sea el equipo
10. Independencia con respecto al Sistema Operativo
El SGBD debe ser multioperativo sin afectar al usuario.
11. Independencia con respecto a la Red
El SGBD debe soportar mltiples redes sin afectar al usuario.
12. Independencia con respecto al SGBD
Se pueden manejar distintas copias de SGBD si manejan la misma norma estndar
de SQL: Oracle, Informix, Multibase, etc.

Seguridad en base de datos:

El objetivo es proteger la Base de Datos contra accesos no autorizados. Se llama tambin
privacidad.

Tipos de usuarios:

DBA, estn permitidas todas las operaciones, conceder privilegios y establecer usuarios

Usuario con derecho a crear, borrar y modificar objetos y que adems puede
conceder privilegios a otros usuarios sobre los objetos que ha creado.
Usuario con derecho a consultar, o actualizar, y sin derecho a crear o borrar
objetos.

Medidas de seguridad:

Un SMBDD cuenta con un subsistema de seguridad y autorizacin que se encarga de
garantizar la seguridad de porciones de la BD contra el acceso no autorizado.

Identificar y autorizar a los usuarios: uso de cdigos de acceso y palabras claves,
exmenes, impresiones digitales, reconocimiento de voz, barrido de la retina,
etc.
Autorizacin: usar derechos de acceso dados por el terminal, por la operacin
que puede realizar o por la hora del da.
Uso de tcnicas de cifrado: para proteger datos en Base de Datos distribuidas o
con acceso por red o internet.
Diferentes tipos de cuentas: en especial del ABD con permisos para: creacin de
cuentas, concesin y revocacin de privilegios y asignacin de los niveles de
seguridad.
Manejo de la tabla de usuarios con cdigo y contrasea, control de las operaciones
efectuadas en cada sesin de trabajo por cada usuario y anotadas en la bitcora, lo
cual facilita la auditora de la Base de Datos.

Otro aspecto importante de la seguridad, es el que tiene que ver con el uso no autorizado
de los recursos:

Lectura de datos.
Modificacin de datos.
Destruccin de datos.
Uso de recursos: ciclos de CPU, impresora, almacenamiento.



Principios bsicos para la seguridad
Suponer que el diseo del sistema es pblico.
El defecto debe ser: sin acceso.
Chequear permanentemente.
Los mecanismos de proteccin deben ser simples, uniformes y construidos en las
capas ms bsicas del sistema.
Los mecanismos deben ser aceptados sicolgicamente por los usuarios.
Los siguientes siete requisitos son esenciales para la seguridad de la base de datos:

La base de datos debe ser protegida contra el fuego, el robo y otras formas de
destruccin.
Los datos deben ser reconstruibles, porque por muchas precauciones que se
tomen, siempre ocurren accidentes.
Los datos deben poder ser sometidos a procesos de auditoria. La falta de auditoria
en los sistemas de computacin ha permitido la comisin de grandes delitos.
El sistema debe disearse a prueba de intromisiones. Los programadores, por
ingeniosos que sean, no deben poder pasar por alto los controles.
Ningn sistema puede evitar de manera absoluta las intromisiones
malintencionadas, pero es posible hacer que resulte muy difcil eludir los controles.
El sistema debe tener capacidad para verificar que sus acciones han sido
autorizadas. Las acciones de los usuarios deben ser supervisadas, de modo tal que
pueda descubrirse cualquier accin indebida o errnea.

Soluciones para evitar el acceso no autorizado a la base de datos:

Para proteger el acceso a las tablas, puede elegir de entre las siguientes opciones

Cambiar el perfil de usuario que emplea para acceder a un recurso por otro perfil
de usuario que ya tenga autorizacin sobre las tablas.
Aadir autorizacin para acceder a las tablas al perfil de usuario utilizado.
Utilizar una combinacin formada por los dos mtodos anteriores.



Tipos de seguridad de bases de Datos:

Seguridad lgica: este nivel de seguridad implica mantener la integridad y
consistencia de los datos en la base de datos cuando se realicen las operaciones de
altas, bajas y modificaciones en la base de datos del sistema.
Seguridad fsica: este nivel de seguridad implica mantener la integridad fsica de los
archivos donde se almacena la base de datos y el log de transacciones, en el disco
del servidor. Ser implementado con procedimientos de resguardo, back-up, y
restauracin. Dichos procedimientos sern realizados peridicamente por el
administrador de la aplicacin.
Seguridad de acceso: este nivel de seguridad implica restringir el acceso a los datos
por parte de usuarios no autorizados. Ser implementado tanto en la base de
datos como en la aplicacin. La administracin de la seguridad se realiza con un
mdulo especialmente diseado para esa tarea.



Confidencialidad:

En un SGBD existen diversos elementos que ayudan a controlar el acceso a los datos. En
primer lugar el sistema debe identificar y autenticar a los usuarios utilizando alguno de las
siguientes formas:
cdigo y contrasea
identificacin por hardware
caractersticas bioantropomtricas (huellas dactilares, voz, retina del ojo, ...)
conocimientos, aptitudes y hbitos del usuario
informacin predefinida
Adems, el administrador deber especificar los privilegios que un usuario tiene sobre los
objetos:
utilizar una BD
consultar ciertos datos
actualizar datos, ...

Para facilitar la administracin los SGBD suelen incorporar el concepto el concepto de
perfil, rol o grupo de usuarios que agrupa una serie de privilegios por lo que el usuario que
se asigna a un grupo hereda todos los privilegios del grupo. El mecanismo de control de
acceso se encarga de denegar o conceder el acceso a los usuarios. En un SGBD pueden
existir diferentes tipos de autorizacin.

Una primera distincin puede hacerse entre:

Autorizacin explcita. Normalmente usada en los sistemas tradicionales. Consiste
en almacenar que sujetos pueden acceder a ciertos objetos con determinados
privilegios para lo que suele utilizarse una matriz de control de accesos

Autorizacin implcita. Consiste en que una autorizacin definida sobre un objeto
puede deducirse a partir de otras (por ejemplo si se puede acceder a una clase en
un SGBO se puede tambin acceder a todas las instancias de esa clase)

Tambin se puede distinguir entre:
Autorizacin fuerte. Las autorizaciones deducidas a partir de la misma no puedan
ser invalidadas
Autorizacin dbil. Se permiten excepciones sobre las autorizaciones implcitas

Por ltimo:
Autorizacin positiva. Su presencia indica la existencia de autorizacin
Autorizacin negativa. Es la denegacin explcita de una autorizacin

Disponibilidad:
Los sistemas de bases de datos deben asegurar la disponibilidad de los datos a aquellos
usuario que tienen derecho a ello por lo que proporcionan mecanismos que permiten
recuperar la base de datos contra fallos lgicos o fsicos que destruyan los datos en todo o
en parte. Aunque slo nos centraremos en utilidades propias del SGBD, sera conveniente
adems, contar con facilidades ajenas al SGBD como, por ejemplo, mquinas tolerantes a
fallos, sistemas de alimentacin ininterrumpida. El principio bsico en el que se apoya la
recuperacin de la base de datos ante cualquier fallo es la redundancia fsica.

En lo que se refiere al SGBD existen dos tipos importante de fallos:

Los que provocan la perdida de memoria voltil, debidos a interrupcin del
suministro elctrico o por funcionamiento anormal del hardware
Los que provocan la prdida del contenido de memoria secundaria

Lo importante ante cualquier tipo de fallo es asegurar que, despus de una actualizacin,
la base de datos se queda en un estado consistente.

Para conseguir esto se crean unidades de ejecucin denominadas transacciones que
pueden definirse como secuencias de operaciones que han de ejecutarse de forma
atmica, es decir, o bien se realizan todas las operaciones que comprenden la transaccin
globalmente o bien no se realiza ninguna.

Por definicin, la base de datos se encuentra en un estado consistente antes de que se
empiece a ejecutar una transaccin y tambin lo deber estas cuando la transaccin
termine de ejecutarse.

Las transacciones son unidades de la ejecucin (ACID):

Las propiedades principales que debe poseer una transaccin son las siguientes:

Atomic (Atomicidad) Si una transaccin completa exitosamente, sus efectos son
durables, en caso contrario la transaccin aborta y sus efectos se deshacen
(rollback). Por ejemplo, cuando actualizamos un registro, el registro cambia de
valor y el antiguo valor se anula (cuando termina exitosamente), o no
cambia nada (cuando aborte).

Consistency (Consistencia) Una transaccin es una transformacin correcta del
estado del sistema. Una transaccin producir siempre los mismos resultados si se
aplican ms de una vez(es decir, deben ser consistentes y reproducibles). Por
ejemplo, cuando agregando un elemento a una lista doblemente enlazada, los
cuatro indicadores (dos delanteros y los dos dirigidos hacia atrs) son puestos al
da.
Isolation (Aislamiento).Se aslan transacciones concurrentes de las actualizaciones
de otras transacciones incompletas. Estas actualizaciones no constituyen un estado
consistente, los datos deben protegerse de cambios hasta haber completado la
transaccin a travs de todos los nodos. Esta propiedad es llamada a menudo
seriabilidad. Por ejemplo, una segunda transaccin, cruzando la lista doblemente
enlazada mencionada en el ejemplo de consistencia, ver la lista antes o despus
de la insercin, pero solo ver cambios completos.
Durability (Durabilidad) Una vez una transaccin completa exitosamente, sus
efectos persistirn aun cuando hay fracasos del sistema. Por ejemplo, despus de
la actualizacin en el ejemplo de atomicidad, el registro tendr el nuevo valor aun
cuando el sistema falla y cuando el sistema se inicie nuevamente se corrigen
despus de haber completado la transaccin bases de datos (Oracle, Infomix,
Sysbase), a fin de satisfacer las necesidades emergentes de comprometa completa.
Hoy esta tecnologa muestra sus lmites y los grandes vendedores de negocio,
hacen posible otro adelanto tecnolgico en la gestin de bases de datos. Este
enfoque relativamente nuevo usualmente se conoce bajo trminos como:
Almacenaje de Datos, Repeticin, DSS-R (Sistemas de apoyo de Decisin-
Repeticin).
Una transaccin pude terminar de dos formas diferentes:

Con xito, en cuyo caso las actualizaciones de que consta la transaccin se graban
(commit)
Con fracaso, en cuyo caso debe ser restaurado el estado inicial en el que se
encontrada la base de datos antes de que empezara a ejecutarse la transaccin.
Las actualizaciones de que consta la transaccin debern, por tanto, deshacerse
(rollback)

Integridad:
El objetivo en cuanto a la integridad es proteger la base de datos contra operaciones que
introduzcan inconsistencias en los datos, por eso hablamos de integridad en el sentido
de correccin, validez o precisin de los datos de la base. El subsistema de integridad de
un SGBD debe, por tanto, detectar y corregir, en la medida de lo posible, las operaciones
incorrectas. Existen dos tipos de operaciones que pueden atentar contra la integridad de
los datos que son las operaciones semnticamente inconsistentes y las interferencias
debidas a accesos concurrentes.

Integridad semntica:
Existen operaciones que pueden violar restricciones definidas al disear la base de datos,
como pueden ser restricciones sobre los dominios o sobre los atributos. Estas
restricciones pueden ser estticas (tambin llamadas de estado o situacin) o dinmicas
(denominadas de transicin).
Los SGBD tienen que ofrecer en su lenguaje de definicin facilidades que permitan
describir las restricciones, con una sintaxis adecuada y gran flexibilidad.
Un aspecto muy importante de estas reglas de integridad, es que se almacenan en
el diccionario, como parte integrante de la descripcin de los datos (control centralizado
de la semntica) con lo que se consiguen las siguientes ventajas: Son ms sencillas de
entender y de cambiar, facilitando su mantenimiento

Se detectan mejor las inconsistencias
Se protege mejor la integridad, ya que ningn usuario podr escribir un programa
que las viole llevando la base de datos a estados inconsistentes

El subsistema de integridad del SGBD debe realizar las siguientes funciones:
Comprobar la coherencia de las reglas que se definen
Controlar las distintas transacciones y detectar las violaciones de integridad
Cuando se produce una violacin, ejecutar las acciones pertinentes

Integridad operacional:
En sistemas multiusuario es imprescindible, adems, un mecanismo de control de
concurrencia para conservar la integridad de la base de datos, ya que se pueden producir
importantes inconsistencias derivadas del acceso concurrente.
A continuacin presentaremos las tcnicas de control de concurrencia ms tradicionales:
Bloqueo
Marcas de tiempo
Marcas de tiempo multiversin
Tcnicas optimistas

Para, posteriormente, resumir las principales tcnicas avanzadas:
Transacciones anidadas
Transacciones largas
Transacciones de coordinacin

Disparadores (Trigger):
Un "trigger" (disparador o desencadenador) es un tipo de procedimiento almacenado que
se ejecuta cuando se intenta modificar los datos de una tabla (o vista). Se definen para
una tabla (o vista) especfica. Se crean para conservar la integridad referencial y la
coherencia entre los datos entre distintas tablas.
Si se intenta modificar (agregar, actualizar o eliminar) datos de una tabla en la que se
defini un disparador para alguna de estas acciones (insercin, actualizacin y
eliminacin), el disparador se ejecuta (se dispara) en forma automtica.
Un trigger se asocia a un evento (insercin, actualizacin o borrado) sobre una tabla.
La diferencia con los procedimientos almacenados del sistema es que los triggers:

no pueden ser invocados directamente; al intentar modificar los datos de una tabla
para la que se ha definido un disparador, el disparador se ejecuta
automticamente.
no reciben y retornan parmetros.
son apropiados para mantener la integridad de los datos, no para obtener
resultados de consultas.
Tambin podemos especificar el momento de disparo del trigger. El momento de disparo
indica que las acciones (sentencias) del trigger se ejecuten luego de la accin (insert,
delete o update) que dispara el trigger o en lugar de la accin.

La sintaxis para ello es:

create triggre NOMBREDISPARADOR
on NOMBRETABLA o VISTA
MOMENTODEDISPARO-- after o instead of
ACCION-- insert, update o delete
as
SENTENCIAS

Entonces, el momento de disparo especifica cuando deben ejecutarse las acciones
(sentencias) que realiza el trigger. Puede ser "despus" (after) o "en lugar" (instead of) del
evento que lo dispara.

Si no especificamos el momento de disparo en la creacin del trigger, por defecto se
establece como "after", es decir, las acciones que el disparador realiza se ejecutan luego
del suceso disparador. Hasta el momento, todos los disparadores que creamos han sido
"after".

Los disparadores "instead of" se ejecutan en lugar de la accin desencadenante, es decir,
cancelan la accin desencadenante (suceso que dispar el trigger) reemplazndola por
otras acciones.

Veamos un ejemplo. Una empresa almacena los datos de sus empleados en una tabla
"empleados" y en otra tabla "clientes" los datos de sus clientes. Se crea una vista que
muestra los datos de ambas tablas:

create view vista_empleados_clientes
as
select documento,nombre, domicilio, 'empleado' as condicion from empleados
union
select documento,nombre, domicilio,'cliente' from clientes;
Creamos un disparador sobre la vista "vista_empleados_clientes" para insercin, que
redirija las inserciones a la tabla correspondiente:

create trigger DIS_empleadosclientes_insertar
on vista_empleados_clientes
instead of insert
as
insert into empleados
select documento,nombre,domicilio
from inserted where condicion='empleado'

insert into clientes
select documento,nombre,domicilio
from inserted where condicion='cliente';

El disparador anterior especifica que cada vez que se ingresen registros en la vista
"vista_empleados_clientes", en vez de (instead of) realizar la accin (insertar en la vista),
se ejecuten las sentencias del trigger, es decir, se ingresen los registros en las tablas
correspondientes.

Entonces, las opciones de disparo pueden ser:

"after": el trigger se dispara cuando las acciones especificadas (insert, delete y/o
update) son ejecutadas; todas las acciones en cascada de una restriccin "foreign
key" y las comprobaciones de restricciones "check" deben realizarse con xito
antes de ejecutarse el trigger. Es la opcin por defecto si solamente colocamos
"for" (equivalente a "after").

La sintaxis es:
create triggre NOMBREDISPARADOR
on NOMBRETABLA
after | for-- son equivalentes
ACCION-- insert, update o delete
as
SENTENCIAS

"instead of": sobreescribe la accin desencadenadora del trigger. Se puede definir
solamente un disparador de este tipo para cada accin (insert, delete o update)
sobre una tabla o vista.

Sintaxis:
create triggre NOMBREDISPARADOR
on NOMBRETABLA o VISTA
instead of
ACCION-- insert, update o delete
as
SENTENCIAS

Consideraciones:

Se pueden crear disparadores "instead of" en vistas y tablas.
No se puede crear un disparador "instead of" en vistas definidas "with check
option".
No se puede crear un disparador "instead of delete" y "instead of update" sobre
tablas que tengan una "foreign key" que especifique una accin "on delete
cascade" y "on update cascade" respectivamente.
Los disparadores "after" no pueden definirse sobre vistas.
No pueden crearse disparadores "after" en vistas ni en tablas temporales; pero
pueden referenciar vistas y tablas temporales.
Si existen restricciones en la tabla del disparador, se comprueban DESPUES de la
ejecucin del disparador "instead of" y ANTES del disparador "after". Si se
infringen las restricciones, se revierten las acciones del disparador "instead of"; en
el caso del disparador "after", no se ejecuta.