Bases de Datos Distribuidas

I
Bases de Datos Distribuidas

Introduccin

A lo largo de los aos la informacin se ha convertido en una herramienta
indispensable en la toma de decisiones, y el hecho de almacenar y administrar
esta informacin a tomado mayor importancia da con da.
En los aos 70's, cuando las computadoras comenzaron a ser usadas no solo
para realizar clculos, sino tambin para almacenar informacin, naci una nueva
rea dentro de la informtica, el diseo e implementacin de sistemas de bases de
datos.

Estas bases de datos en sus inicios funcionaban en una sola computadora,
donde se realizaban todos los procesos de almacenamiento, consulta y
actualizacin de la informacin. Con el surgimiento de las redes de rea local el
procesamiento de la informacin fue ms fcil y rpido, aun cuando se tenia un
nuevo problema, cada vez era mayor el volumen de la informacin que se tenia
que almacenar en el nico servidor central.

Con el crecimiento econmico mundial, aparecieron las grandes empresas
transnacionales, con plantas y oficinas en diferentes ciudades y pases, por tanto,
con diferentes redes de rea local en cada una de las reas geogrficas de la
empresa. Es asi como aparece un nuevo concepto en el rea de las bases de
datos, las bases de datos distribuidas.

Las bases de datos distribuidas surgen a partir de la necesidad de poder
almacenar y administrar informacin en cada rea geogrfica, tener una red de
computo en cada una de ellas, y poder compartir dicha informacin de manera
transparente a todos y cada uno de los usuarios de las redes, formando a si una
gigantesca base de datos distribuida.

II


Objetivo

Este trabajo es realizado con la intencin de proveer al alumno de un
documento de consulta basado en el plan de estudio de la materia, lo que
permitir un fcil acceso a la informacin requerida de una manera rpida y
concisa, logrando as una fcil comprensin de los temas tratados en clase. Esto
sin intentar sustituir a los libros existentes de bases de datos centralizadas y bases
de datos distribuidas.

III

Bases de datos distribuidas

Contenido

Capitulo 1 Fundamentos de las bases de datos distribuidas
1.1 Diferencias entre las bases de datos distribuidas y las bases de datos
centralizadas ....................................................................... .............1

1.2 Ventajas de las bases de datos distribuidas contra las bases de
datos centralizadas................................................................. .............4

1.3 Los doce objetivos de una base de datos distribuidas...........................6

1.4 Arquitectura cliente/servidor.................................................................11
1.4.1 Paradigma cliente/servidor.................................................................11
1.4.2 Procesamiento cliente/servidor...........................................................11
1.4.3 Ventajas de la arquitectura cliente/servidor........................................11
1.4.4 Desventajas de la arquitectura cliente/servidor..................................12
1.4.5 Caractersticas del cliente...................................................................12
1.4.6 Funciones del cliente..........................................................................13
1.4.7 Interfaz grafica de usuario estndar....................................................13
1.4.8 Caractersticas de[ servido.........................r.......................................14
1.4.9 Funciones del servidor........................................................................15
1.4.10 El sistema X Windows.......................................................................18

1.5 Problemas de los sistemas distribuidos.................................................19

1.6 Soporte para bases de datos distribuidas..............................................23

1.7 Resumen del capitulo.............................................................................24
1.8 Preguntas de repaso..............................................................................31
Bibliografa...................................................................................................32

Capitulo II Bases de datos en mltiples servidores
2.1 Consideraciones para distribuir bases de datos....................................34
2.1.1 Objetivo del diseo de los datos distribuidos .....................................35

2.2 Diseo de bases de datos distribuidas ................................................36
2.2.1 Tcnicas de diseo Top-Down y Bottom-Up de bases de datos
distribuidas ................................................................................... 36
2.2.2 Diseo de los fragmentos de la base de datos...................................37
2.2.3 Correctez de la fragmentacin ........................................................... 37
2.2.4 Fragmentacin Horizontal...................................................................38
2.2.5 Fragmentacin Horizontal derivada. .................................... .............40

IV

2.2.6 Fragmentacin Vertical ........................................................ .............42
2.2.7 Fragmentacin Mixta ........................................................... .............46
2.2.8 Distribucin de los fragmentos............................................. .............48
2.2.9 Criterios generales para la distribucin de los fragmentos.................48

2.3 Procesamiento de consultas distribuidas..............................................49
2.3.1 rbol de operadores de una consulta................................................49
2.3.2 Ejemplos de consultas distribuidas....................................................50
2.4. Resumen del capitulo...........................................................................57
2.5. Preguntas de repaso............................................................................60
2.6. Ejercicios..............................................................................................60
Bibliografa..................................................................................................62

Capitulo III Optimizacin de estrategias de acceso
3.1 Importancia de la optimizacin de consultas........................................63

3.2 Transformaciones equivalentes................. ..................................... ..65
3.2.1 Transformaciones equivalentes por lgebra relacional .................. .66
3.2.2 Determinacin de subexpresiones comunes .................................. 68

3.3 Mtodos de ejecucin de JOIN..........................................................70
3.3.1 Iteracin simple ............................................................................... 71
3.3.2 Iteracin orientada a bloques.......................................................... 72
3.3.3 Merge - Join ................................................................................ 73
3.3.4 Uso de ndices ................................................................................ 75
3.3.5 Hash Join ................................................................................ 76
3.3.6 Tree - way join ................................................................................ 78
3.3.7 Estrategias para procesamiento paralelo ...................... ................ 80
3.3.8 Join paralelo ............................................................... ................ 80
3.3.9 Pipeline multiway join .................................................... ................ 82

3.4. Principios de optmizacin. .............................................. ................ 84

3.5. Resumen del capitulo. ..................................................... ................ 88

3.6. Preguntas de repaso. ...................................................... ................ 93
3.7. Ejercicios............................................................................................94
Bibliografa................................................................................................94

V

CapitulolV Procesamiento de transacciones en bases de datos distribuidas
4.1 Control de concurrencia......................................................................95
4.1.1 Seriabilidad en bases de datos centralizadas..................................95
4.1.2 Seriabilidad en bases de datos distribuidas. ...................................98
4.1.3 Control de concurrencia basado en bloqueos centralizados .........100
4.1.4 Control de concurrencia basado en bloqueos distribuidos ............101
4.1.5 Bloqueo de 2 fases como un mtodo de control de
concurrencia...................................................................................104
4.1.6 Etiquetas de tiempo en una base de datos distribuida...................106
4.1.7 Deadloks distribuidos.....................................................................109

4.2 Recuperacin. .................................................................................. 111
4.2.1 Transacciones. .............................................................................. 112
4.2.2 Manejo de mensajes ..................................................................... 113
4.2.3 estructura general de los registros de bitcora .............................. 114
4.2.4 Tipos de fallas ............................................................................... 116
4.2-5 Fallas de transaccin .................................................................... 117
4.2.6 Bitcora en lnea ........................................................................... 118
4.2.7 Transacciones grandes ................................................................. 118
4.2.8 Compresin de bitcora ................................................................ 119
4.2.9 Fallas del sistema .......................................................................... 120
4.2.10 Fallas en el medio de almacenamiento ....................................... 123

4.3 Integridad ..........................................................................................125
4.3.1 Reglas de integridad de dominio ................................................... 126
4.3.2 Reglas de integridad de relacin ................................................... 127

4.4 Seguridad. .......................................................................................131
4.4.1 Identificacin y autentificacin ....................................................... 133
4.4.2 Reglas de autorizacin...................................................................133
4.4.3 Encriptacin de datos. .. ................................................................ 134
4.4.4 Encriptacin por sustitucin, .......................................................... 135
4.4.5 Encriptacin de llave publica ......................................................... 136
4.5. Resumen del capitulo.......................................................................139
4.6. Preguntas de repaso. .......................................... ............................151

4.7. Ejercicios ......................................................................................... 152
Bibliografa..............................................................................................153
Respuestas a preguntas de repaso y ejercicios.....................................154

1
Fundamentos de las Bases de Datos Distribuidas

Objetivo
El alumno conocer las caractersticas de las bases de datos distribuidas, el
paradigma cliente / servidor, y los aspectos que se deben considerar al disear una
base de datos distribuida.

Introduccin
En este captulo se tratan las diferencias entre las bases de datos centralizadas
y distribuidas, las cuales proporcionan ventajas y desventajas que debern ser
tomadas en cuenta al disear bases de datos distribuidas, as mismo, se tratan los
objetivos a cumplir por dichas bases de datos. Se discutir tambin, una pequea
descripcin del paradigma cliente / servidor, ya que las bases de datos no
centralizadas hacen un uso extenso de ste.

1.1 Diferencias entre las bases de datos distribuidas y las bases de
datos centralizadas
Las bases de datos distribuidas no son simples implementaciones distribuidas de
bases de datos centralizadas, aun cuando presentan algunas caractersticas
semejantes, los sistemas distribuidos no podran ser diseados con las tcnicas de
diseo de los sistemas centralizados tradicionales. Sin embargo es posible comparar
los sistemas tradicionales de bases de datos con los sistemas de bases de datos
distribuidas en base a dichas caractersticas, las cuales son: control centralizado,
independencia de datos, reduccin de redundancia, estructuras fsicas complejas para
un acceso eficiente y seguridad.
Captulo I
Fundamentos de las bases de datos
distribuidas

2

Control centralizado
La posibilidad de proveer control centralizado sobre los recursos de informacin
puede ser considerada como una de las razones ms atractivas para introducir bases
de datos; esto es considerado como la evolucin de los sistemas de informacin, en los
cuales cada aplicacin tiene sus archivos privados. En las bases de datos distribuidas,
la idea de un control centralizado tiene poco nfasis.
En las bases de datos distribuidas es posible identificar una estructura de control
jerrquico basado en un Administrador global de bases de datos, el cual tiene la
principal responsabilidad de la totalidad de la base de datos, y el Administrador local de
bases de datos, quien tiene la responsabilidad de su respectiva base de datos local.
Esto nos da como resultado una caracterstica llamada Autonoma de sitio. Las bases
de datos distribuidas tienen diferentes grados de autonoma de sitio: desde la ms
completa autonoma sin ningn administrador centralizado hasta el ms completo
control centralizado.

Independencia de datos.
La independencia de datos quiere decir, que la organizacin actual de los datos es
transparente a las aplicaciones. Los programas son escritos teniendo una vista
conceptual de los datos, llamada esquema conceptual. La ventaja principal de la
independencia de datos es que los programas no son afectados por los cambios en la
organizacin fsica de los datos.
En las bases de datos, la independencia de los datos es tan importante como en las
bases de datos tradicionales; sin embargo, una nueva caracterstica se agrega a la
definicin de la independencia de datos, esta es la transparencia de distribucin.
Gracias a la transparencia de distribucin es que se pueden escribir programas como
si la base de datos no estuviera distribuida.
La independencia de datos fue introducida en las bases de datos tradicionales por
la arquitectura multinivel que tiene diferentes descripciones de los datos y mapeos
entre ellos. Las definiciones de esquema conceptual, esquema externo y esquema
interno fueron desarrolladas para esta arquitectura. De manera similar, la
transparencia de distribucin es obtenida en las bases de datos distribuidas por la
introduccin de nuevos niveles y esquemas.

3
Reduccin de la redundancia.
En las bases de datos tradicionales, la redundancia fue reducida en lo posible, por
dos razones: primera, la inconsistencia entre varias copias de los datos es evitada
automticamente teniendo solo una copia de los datos; la segunda razn, la
recuperacin de espacio de almacenamiento al eliminar la redundancia. La
redundancia se reduce compartiendo los datos, permitiendo que varias aplicaciones
accesen los mismos archivos.
En las bases de datos distribuidas, se tienen varias razones para considerar la
redundancia de los datos como una caracterstica necesaria: primero, las aplicaciones
pueden verse favorecidas si los datos son replicados en todos los sitios donde la
aplicacin las necesita, y segundo, la razn de disponibilidad del sistema puede
incrementarse por este medio, debido a que si el sitio en el que se encuentran los
datos fallara, la ejecucin de la aplicacin no se detiene porque existe una copia en
algn otro sitio.

Estructuras complejas y acceso eficiente,
Las estructuras de acceso complejas, como ndices secundarios y enlaces entre
archivos, son aspectos comunes de las bases de datos tradicionales. El soporte para
estas estructuras es una de las partes ms importantes del DBMS (Database Manager
System, Sistema manejador de base de datos). El objetivo de estas estructuras es el
de obtener un acceso eficiente a los datos.
Escribir un acceso distribuido es muy parecido al hacerlo en un sistema
centralizado, en el sentido de que el programador especifica de qu modo ser
accesada la base de datos. De cualquier forma, el proceso es local a cada uno de los
sitios donde se encuentran los grupos de datos.
Es conveniente tomar en cuenta dos cuestiones muy importantes en el momento de
accesar una base de datos distribuida, la optimizacin local y la optimizacin global de
los accesos. La optimizacin global consiste en determinar qu datos sern accesados
en qu sitios y qu archivos de datos sern transmitidos entre sitios. La optimizacin
local consiste en decidir como llevar acabo el acceso a la base de datos local en cada
sitio.

4
Seguridad.
En las bases de datos tradicionales, el administrador de la base de datos, tiene el
control centralizado, puede asegurarse que nicamente se tenga el acceso a los datos
autorizados.
En las bases de datos distribuidas, el administrador local enfrenta el mismo
problema que el administrador de bases de datos tradicionales. Sin embargo, vale la
pena mencionar dos aspectos peculiares de las bases de datos distribuidas: en una
base de datos distribuida con un alto nivel de autonoma, los dueos de los datos
locales pueden proteger de diferentes maneras su informacin, esto dependiendo del
DBMS local; y segundo, los problemas de seguridad son intrnsecos en los sistemas de
bases de datos en general, esto debido a que las comunicaciones en las redes es su
punto dbil con respecto a la proteccin.

1.2 Ventajas de las bases de datos distribuidas sobre las bases de
datos centralizadas

Razones organizacionales
La mayor parte de las organizaciones estn descentralizadas, y las bases de datos
distribuidas se acercan ms a las necesidades de la estructura de la organizacin
distribuida.

Interconexin de las bases de datos existentes.
Las bases de datos distribuidas son la solucin natural cuando se tienen varias
bases de datos existentes en la organizacin. En este caso, las bases de datos
distribuidas son creadas utilizando una estrategia de diseo tipo bottom-up a partir de
las bases de datos locales existentes. Este proceso requiere cierto grado de
reestructuracin local; de cualquier forma, el esfuerzo requerido para esto es mucho
menor que el necesario para la creacin de una base de datos local completamente
nueva.

5
Desarrollo incremental.
Si una organizacin agrega una nueva unidad, relativamente autnoma, entonces
las bases de datos distribuidas soportaran este crecimiento con el menor grado de
impacto a las unidades ya existentes. En un sistema centralizado cualquier cambio en
las dimensiones del sistema tendra un impacto mayor, no solo en las nuevas
aplicaciones, sino tambin en las ya existentes.

Reduccin en la sobrecarga de la comunicacin.
En una base de datos distribuida geogrficamente, el factor que las aplicaciones
locales veran claramente reducido es la sobrecarga de las comunicaciones, en
relacin con bases de datos centralizadas. Por eso, en el mximo de que las
aplicaciones sean locales es uno de los objetivos primarios en el diseo de las bases
de datos distribuidas.

Consideraciones en el desempeo.
La existencia de varios procesadores autnomos dan como resultado un incremento
en el desempeo por medio de un alto grado de paralelismo. Esta consideracin
puede ser aplicada a un sistema multiprocesador y no nicamente a los sistemas de
bases de datos distribuidas. Las bases de datos distribuidas tienen la ventaja en que
la descomposicin de los datos permite maximizar el desempeo de las aplicaciones
locales; de esta forma es minimizada la mutua interferencia entre diferentes
procesadores.

Confiabilidad y disponibilidad.
Las bases de datos distribuidas obtienen, por medio de la replica de datos, un alto
grado de confiabilidad y disponibilidad. Sin embargo, el lograr esta meta no es tan
fcil, pues requiere del uso de ciertas tcnicas, las cuales son difciles de comprender.
La capacidad de procesamiento autnomo en los diferentes sitios no es, por s misma,
garanta de que exista una completa confiabilidad en el sistema, pero esto generara
una fcil degradacin del sistema; en otras palabras, las fallas en una base de datos
distribuida pueden ser ms frecuentes que en las centralizadas, debido al gran nmero
de componentes, pero el efecto de cada falla es considerado por cada aplicacin que
usa los datos en sitio que fall, y por lo tanto es raro que el sistema en su totalidad
falle.

6

1.3 Los doce objetivos de una base de datos distribuidas.

La siguiente expresin se podra considerar como el principio fundamental de los
sistemas distribuidos en general, y por tanto es aplicable a las bases de datos
distribuidas:

Desde el punto de vista del usuario, un sistema
distribuido deber ser idntico a un sistema no
distribuido.

Esto quiere decir que, los usuarios de un sistema distribuido debern comportarse
exactamente como si el sistema no estuviera distribuido.
Al principio fundamental antes mencionado se le conoce como el "objetivo o regla
cero" de los sistemas distribuidos. Existen doce reglas u objetivos ms, las cuales
norman la existencia de un sistema distribuido y en este caso, de una base de datos
distribuida. Dichos sistemas debern apegarse a ellas, en la medida, en que el diseo
y la tecnologa lo permitan, tales reglas son:

Autonoma local.
Los sitios de un sistema distribuido debern ser autnomos. La autonoma local
significa que todas las operaciones en un sitio se controlan en ese sitio; ningn sitio
deber depender de algn otro sitio para su buen funcionamiento. La autonoma local
implica tambin un propietario y una administracin local de los datos, con
responsabilidad local: todos los datos pertenecen a una base de datos local, aunque -
sean accesibles para algn sitio remoto. Por tanto, la seguridad, integridad y
representacin en almacenamiento de los datos locales permanecen bajo el control del
sitio local.

7
No dependencia de un sitio central.
La autonoma local implica que todos los sitios deben tratarse igual; no debe haber
dependencia de un sitio central maestro para obtener un servicio central. La no
dependencia de un sitio central es deseable por s misma, an si no se logra la
autonoma local completa.
La dependencia de un sitio central seria indeseable al menos por dos razones:
primero, el sitio central podra ser un cuello de botella; en segundo lugar, el sistema
sera vulnerable; si el sitio central sufriera un desperfecto, todo el sistema dejara de
funcionar.

Operacin continua.
En un sistema distribuido como en uno no distribuido, lo ideal seria que nunca
hubiera la necesidad de apagar el sistema a propsito. Es decir, el sistema nunca
deber necesitar apagarse para que se pueda realizar alguna funcin, como actualizar
el DBMS de un sitio existente o aadir un nuevo sitio.

Dependencia (o Transparencia) con respecto a la localizacin.
La idea bsica de la independencia con respecto a la localizacin es simple; no
debe ser necesario que los usuarios sepan donde estn almacenados fsicamente los
datos, sino que ms bien deben comportarse (al menos desde el punto de vista lgico)
como si todos los datos estuvieran almacenados en su propio sitio local. La
independencia con respecto a la localizacin hace posible la migracin de datos de un
sitio a otro sin anular la validez de ningn programa o actividad. Esta posibilidad de
migracin es deseable porque permite modificar la distribucin de los datos dentro de
la red en respuesta a cambios en las necesidades del desempeo.

Independencia con respecto a la fragmentacin.
Un sistema maneja fragmentacin de los datos si es posible dividir una relacin en
partes o fragmentos para propsitos de almacenamiento fsico. La fragmentacin es
deseable por razones de desempeo: los datos pueden almacenarse en la localidad
donde se utilizan con mayor frecuencia, de manera que la mayor parte de las
operaciones sean locales y se reduzca el trfico de la red.
Existen en esencia dos clases de fragmentacin, horizontal y vertical,

8
Un fragmento puede ser cualquier subrelacin arbitraria que pueda generarse de la
relacin original mediante ciertas operaciones.
Un sistema que maneja la fragmentacin de los datos deber ofrecer tambin una
independencia con respecto a la fragmentacin (transparencia de fragmentacin); es
decir, las bases de datos distribuidas debern poder comportarse (desde el punto de
vista lgico) como si los datos no estuvieran fragmentados en realidad.

Independencia de rplica.
Un sistema maneja rplica de datos si una relacin dada (o, un fragmento dado de
una relacin) se puede representar en el nivel fsico mediante varias copias
almacenadas o rplicas, en muchos sitios distintos.
La rplica es deseable al menos por dos razones: primero, puede producir un mejor
desempeo (las aplicaciones pueden operar sobre copias locales en vez de tener que
comunicarse con sitios remotos); En segundo lugar, tambin puede significar una mejor
disponibilidad. La desventaja principal de las replicas es la actualizacin, ya que
cuando se actualiza un objeto copiado, deben de ser actualizadas todas las replicas de
este objeto: Esto es, el problema de la propagacin de actualizaciones.
La rplica, como la fragmentacin, debe ser transparente al usuario. En otras
palabras, la base de datos deber comportarse como si solo existiera una sola copia
de los datos.

Procesamiento distribuido de las consultas.
La optimizacin es todava ms importante en un sistema distribuido que en uno
centralizado. Lo esencial es que, en una consulta, donde estn implicados varios
sitios, habr muchas maneras de trasladar los datos en la red para satisfacer la
solicitud y es crucial encontrar una estrategia eficiente. Por ejemplo, una solicitud de
unin de una relacin Rx almacenada en el sitio X y una relacin Ry almacenada en un
sitio Y podra llevarse a cabo trasladando Rx a Y o trasladando Ry a X, o trasladando
las dos a un tercer sitio Z. As, la importancia crucial de la optimizacin es obvia, y esto
a su vez puede verse como otra razn ms por la cul los sistemas distribuidos
siempre son relacinales (pues las solicitudes relacinales son optimizables).

9
Manejo distribuido de transacciones.
El manejo de transacciones tiene dos aspectos principales, el control de
recuperacin y el control de concurrencia. En un sistema distribuido, una sola
transaccin puede implicar la ejecucin de cdigo en vados sitios. Por tanto, se dice
que cada transaccin est compuesta de varios agentes, donde un agente es el
proceso ejecutado en nombre de una transaccin dada en un sitio determinado. Y el
sistema requiere saber cundo dos agentes son parte de la misma transaccin; por
ejemplo, es obvio que no puede permitirse un bloqueo mutuo entre dos agentes que
sean de la misma transaccin.
Para asegurar que una transaccin dada sea atmica en el ambiente distribuido, el
sistema debe asegurarse de que todos los agentes correspondientes a esa transaccin
se comprometan al unsono o retrocedan al unsono, Este efecto puede lograrse
mediante el protocolo de compromiso de dos fases.
En cuanto al control de concurrencia, esta funcin en un ambiente distribuido est
basada con toda seguridad en el bloqueo, como sucede en los sistemas no distribuidos
(se han estudiado otras estrategias para el control de concurrencia, pero en la prctica,
el bloqueo parece seguir siendo la tcnica preferida).

Independencia con respecto al equipo.
Las instalaciones de cmputo en el mundo real por lo regular incluyen varias
mquinas diferentes y existe una verdadera necesidad de poder integrar los datos en
todos esos sistemas y presentar al usuario una sola imagen del sistema.

Independencia con respecto al sistema operativo.
Este objetivo es en parte un corolario del anterior. Resulta obvia la consecuencia no
slo de poder ejecutar el mismo DBMS en diferentes equipos, sino tambin de poder
ejecutarlo en diferentes sistemas operativos (aun en diferentes sistemas operativos del
mismo equipo).

Independencia con respecto a la red.
Si el sistema ha de poder manejar mltiples sitios diferentes, con equipo distinto y
diferentes sistemas operativos, resulta obvia la conveniencia de poder manejar tambin
varias redes de comunicacin distinta.

10
Independencia con respecto al sistema manejador de base de datos (DBMS).
En realidad no se requiere sino que los DBMS en los diferentes sitios manejen
todos la misma interfaz; no necesitan ser por fuerza copias del mismo sistema. Por
ejemplo, si tanto INGRES como ORACLE manejaran nicamente el estndar de SQL
(ambos lo manejan pero cada uno tiene caractersticas propias que los hacen
prcticamente incompatibles), podra ser posible lograr una comunicacin entre los dos
en el contexto de un sistema distribuido. Dicho de otro modo, el sistema distribuido
podra ser heterogneo, al menos en cierto grado.
Una vez ms, en la realidad las instalaciones de cmputo no solo suelen emplear
mquinas distintas, varios sistemas operativos diferentes, sino tambin ejecutan
diferentes DBMS; y seria agradable que todos esos DBMS distintos pudieran participar
de alguna manera en un sistema distribuido.

1.4 Arquitectura Cliente/Servidor

1.4.1 Paradigma Cliente/Servidor.
El paradigma que dispone que una aplicacin espere pasivamente a que otra inicie
la comunicacin permea una parte tan grande del cmputo distribuido que tiene un
nombre: paradigma de interaccin cliente/servidor.

1.4.2 Procesamiento Cliente/Servidor.
El modelo de procesamiento cliente/servidor surgi como un concepto de alto nivel
de procesamiento compartido de dispositivos, tpico en las redes de rea local. En el
procesamiento de dispositivos compartidos en la red de rea local (LAN), las
computadoras personales estn enlazadas a un sistema de dispositivos que permite a
las computadoras personales (PCs) compartir recursos. En la terminologa LAN, tales
dispositivos son llamados servidores (un servidor de archivos y un servidor de
impresin seran un ejemplo). El nombre de servidor es apropiado, puesto que estos
dispositivos compartidos son usados para recibir solicitudes de servicio de las
computadoras personales (PCs).
Al mismo tiempo, el rol de las estaciones de trabajo fue cambiando hasta
convertirse en clientes de los servidores. Esto es, los clientes realizan solicitudes de
servicios a los servidores.

11
El modelo de procesamiento cliente/servidor es una extensin natural del
procesamiento de dispositivos compartidos. En este modelo, el procesamiento de
aplicaciones esta dividido entre el cliente y el servidor. El procesamiento es inicializado
y parcialmente controlado por el solicitante del servicio (cliente) pero no es un
funcionamiento maestro-esclavo,

1.4.3 Ventajas de la arquitectura cliente/servidor.
- Permite a las corporaciones obtener cada vez mejores tecnologas de computo.
En la actualidad las estaciones de trabajo tienen un rendimiento y una potencia,
la cual solo se obtena con mainframes, que eran muy costosas.
- Permite que el procesamiento de los datos se realice en el lugar en el que se
encuentran. (La arquitectura cliente/servidor es una forma especial de
procesamiento distribuido y cooperativo) Por lo tanto, el trfico en la red se ve
reducido significativamente, y por consiguiente las necesidades de una red de
banda ancha y el costo se ven reducido.
- Facilita el uso de interfaces de usuario grficas (GUI) disponibles en estaciones
de trabajo. Estas nuevas interfaces pueden ser usadas por una gran variedad
de clientes y cuentan con diferentes tcnicas para mostrar la informacin,
logrando con esto una fcil navegacin.
- Permite el uso de sistemas abiertos. Esto es, el cliente y el servidor pueden
correr en diferentes plataformas de software y hardware permitiendo a los
usuarios finales decidir libremente que arquitectura utilizar o poder utilizar la ya
existente.

1.4.4 Desventajas de la arquitectura cliente/servidor.
- Si una parte significativa de la aplicacin lgica es movida al servidor, el
servidor puede convertirse en cuello de botella. Los recursos del servidor
pueden verse disminuidos por el incremento de demanda debido al aumento de
usuarios.
- Las aplicaciones distribuidas, especialmente las que son diseadas para el
proceso cooperativo, son ms complicadas que las no distribuidas. Esto es
verdad para las aplicaciones de desarrollo, ambientes run-time y herramientas
usadas para el mantenimiento de este ambiente distribuido.

12
1.4.5 Caractersticas del cliente
- Es un programa de aplicacin arbitrario que se vuelve cliente temporalmente
cuando necesita acceso remoto, pero tambin lleva a cabo otro computo local.
- Lo llama directamente el usuario y se ejecuta solo durante la sesin.
- Se ejecuta localmente en la computadora personal del usuario.
- Inicia el contacto con el servidor.
- Puede acceder a varios servicios, segn se necesite, pero contacta activamente
con un servidor remoto a la vez.
- No necesita hardware poderoso y un sistema operativo complicado.

1.4.6 Funciones del cliente
La Funcin ms importante que desempea un sistema cliente en un ambiente
cliente/servidor es la presentacin y algunas funciones lgicas. El usuario final
interacta con una aplicacin desarrollada para la presentacin lgica del sistema.
Las funciones tradicionales de presentacin basadas en caracteres, en donde el
procesador desplegaba los caracteres recibidos secuencialmente desde una aplicacin
en pantalla con caracteres de tamao fijo. La continua evolucin de las funciones de
presentacin ha sido estrechamente ligada con el alto desempeo de las estaciones de
trabajo que ofrecan caractersticas grficas.
Las caractersticas grficas permiten al procesador controlar de manera individual
los pxeles en la pantalla, por tanto, no esta limitado a un tipo de carcter o al nmero
de columnas de la pantalla. Estas caractersticas permiten el desarrollo de interfaces
grficas de usuario (GUI) capaces de manejar grficos, imgenes, y audio-video.

1.4.7 Interfaz Grfica de Usuario estndar
Una interfaz consistente entre el usuario y la aplicacin representa un parte
importante en los sistemas abiertos. Las interfaces de presentacin entre el usuario y
la aplicacin son llamadas interfaces Grficas de Usuario (GUI), y son diseadas para
presentar la informacin a los usuarios de forma grfica.
Existe una gran variedad de interfaces, pero cada nueva interfaz requiere que los
usuarios y los desarrolladores tengan una nueva capacitacin en sus usos, y las
aplicaciones sean modificadas. Una nueva interfaz de usuario requiere que las
aplicaciones sean reescritas para esta nueva plataforma. Las aplicaciones escritas

13
para una GUI especifica no son portabas a otro ambiente GUI. Un ejemplo de
interfaces incompatibles es Linux, Windows y Unix.
Aun cuando la industria del hardware y software, aunada a asociaciones de
usuarios prefieren una GUI en particular, Se tiene una GUI estndar, la cual debe de
cumplir los siguientes requisitos:

Portabilidad.- Las aplicaciones deben de ser portabas a travs de varias
plataformas de sistema abiertos. Una GUI estndar debe de proporcionar un API
estable en cualquier plataforma, de esta manera permitira una fcil y rpida manera de
migrar de una plataforma a otra.

Flexibilidad.- Una GUI estndar debe de ser flexible y extensible, permitiendo
ajustarse a nuevos tipos de monitores y a otros dispositivos de entrada salida, que
podran estar disponibles en un futuro.

Herramientas de desarrollo: Cualquier GUI que sea considerada un estndar debe
proporcionar un conjunto de herramientas para el desarrollo.

Internacionalizacin: En la actualidad, la internacionalizacin es otra de la
forma de lograr una portabilidad. Esto incluye otros lenguajes, nmeros, unidades
monetarias, formatos de fecha y hora, y smbolos especiales, as como mensajes
relacionados con la cultura de esos pases.

Independencia de plataforma: Para ser un verdadero sistema abierto y un estndar,
una GUI deber ser diseado para operar independientemente del sistema operativo o
la plataforma de hardware, en el que se esta ejecutando.

1.4.8 Caractersticas del servidor
- Es un programa privilegiado de propsito especial dedicado a ofrecer un
servicio, pero puede manejar varios clientes remotos a la vez.
- Se inicia automticamente al arranque del sistema y continua ejecutndose en
varias sesiones.
- Espera pasivamente el contacto de los clientes remotos.
- Acepta el contacto de varios clientes, pero ofrece un solo servicio.

14
- Necesita hardware poderoso y un sistema operativo complejo.

1.4.9 Funciones de los servidores
El mejor ejemplo de servidores especializados con respecto a la funcionalidad y
diseo son los servidores de bases de datos, Bsicamente, los servidores de bases de
datos nos permiten un rpido almacenamiento en disco, un signif icativo poder de
procesamiento, y la capacidad de interactuar con varia aplicaciones (clientes) de
manera simultnea.

Un servidor es un proceso lgico que provee servicios a solicitudes de
procesamiento. En la computacin cliente/servidor, un cliente inicia la interaccin
cliente/servidor para enviar las solicitudes a los servidores. La funcin que un servidor
debe llevar a cabo es determinada, en gran parte, por el tipo de solicitud que los
clientes puedan enviar al servidor. Si un servidor es incapaz de llevar a cabo la
solicitud de un cliente, entonces el servidor no puede participar en una interaccin
cooperativa cliente/servidor. Idealmente. Un cliente no enva una solicitud que no sea
soportada por un servidor.

En general, sin embargo, una vez que un cliente y un servidor se han
interconectado a travs de una red, alguna de las siguientes funciones pueden ser
solicitadas al servidor por el usuario:

- Compartir archivos. En un ambiente de grupo de trabajo, los clientes tal vez
necesiten compartir los mismos archivos de datos. Estos archivos se colocan
en procesadores de archivos compartidos (Servidores de archivos) y los
clientes envan a estos sus solicitudes de 110.

- Impresin compartida. En un ambiente de grupo de trabajo, una impresora de
alto desempeo puede reemplazar a todas las impresoras individuales de los
clientes. Entonces todos los clientes pueden enviar sus solicitudes de
impresin a los servidores de impresin. Un servidor de impresin mantiene
todos los archivos a ser impresos en una cola, a la cual se envan todos los
archivos de los usuarios, y en su tumo, cada una de ellos sern impresos.

15
- Servicios de comunicacin. En un ambiente de grupo de trabajo que se
encuentra conectado a un host remoto, todas las comunicaciones de software y
hardware se concentran en un dispositivo especial conocido como servidor de
comunicaciones, al cual los clientes envan sus solicitudes para ser procesadas.

- Servicios de Fax Esto requiere usualmente software y equipo especial,
conocido como servidor de fax. Los clientes envan y reciben documentos de
fax por medio de una apropiada solicitud del servicio al servidor de fax.

- Acceso a las bases de datos. En un ambiente cliente/servidor, el
procesamiento esta dividido en el sistema cliente y el sistema servidor, El
servidor puede ejecutar una parte de la lgica de la base de datos. Algo similar
al servidor de archivos, el servidor de bases de datos provee al cliente de los
datos que residen en el servidor por medio de una solicitud, Sin embargo, el
sistema manejador de bases de datos (DBMS), es ms sofisticado que los
mtodos de acceso bsicos. El DBMS de un acceso a los datos por medio de
varios niveles de bloqueo y de integridad de datos. El DBMS elimina la
redundancia permitiendo una transparencia de distribucin de datos. Los
clientes requieren acceder ciertos datos (a diferencia de un servidor de archivos
en el cual se tiene acceso al archivo completo), y toda la manipulacin
necesaria para dar respuesta a la solicitud se realiza en el servidor de bases de
datos.

Otras funciones solicitadas por los clientes pueden ser de correo electrnico, de
red, manejo de configuracin y manejo de recursos, para los cuales se deber de tener
los servidores apropiados.

Un nodo servidor dentro del modelo cliente/servidor puede ser especializado para
realizar cierta funcin. De cualquier forma, los servidores deben cumplir con los
siguientes requerimientos generales:

- Soporte multiusuario. Aun en un pequeo grupo de trabajo, un servidor debe
de ser capaz de proporcionar servicio a mltiples usuarios concurrentes. Los

16
clientes ejecutan mltiples tareas esperando que el servidor sea capaz de
soportar un procesamiento multitarea.

- Escalabilidad. Un servidor debe de ser capaz de satisfacer la creciente
demanda de los recursos, as como de las aplicaciones. Escalabilidad no
significa que usuarios deben comprar un sistema de servidor de mayor
capacidad de procesamiento lo cual implicara un costo extra. Por el contrario,
el sistema debe de satisfacer los requerimientos actuales y, al mismo tiempo,
debe de permitir una fcil expansin.

- Desempeo. Un sistema servidor debe proveer niveles de desempeo
satisfactorios necesarios para la empresa y los requerimientos de los usuarios
en un ambiente multiusuario cliente/servidor.

- Almacenamiento. Como el nmero de aplicaciones ejecutndose y de usuarios
aumentan, y los avances de la tecnologa de dispositivos de almacenamiento
han hecho que los costos bajen, la demanda de almacenamiento de rpido
acceso se ha convertido en un requisito esencial en un sistema servidor.

- Gestin de redes. La comunicacin cliente/servidor requiere de una
comunicacin de red. Ambos, cliente y servidor deben de contar con
capacidades de red. Sin una red el cliente y el servidor no podran interactuar.

- Multimedia. Las nuevas aplicaciones y las nuevas tecnologas cuentan con
capacidades multimedia, es necesario dar soporte al almacenamiento y
reproduccin de imagen, vdeo y sonido.

1.4.1 0 El sistema X Window

El sistema X Window permite un manejo transparente de la interfaz grfica en
estaciones de trabajo. Conocido tambin como X, fue desarrollado conjuntamente por
el Instituto Tecnolgico de Massachussets, IBM, y DEC en un proyecto conocido como
Athena. La arquitectura X est basada en el modelo cliente/servidor. X proporciona:

17
- Un Protocolo de comunicacin transparente entre una aplicacin y su
presentacin lgica, la cual puede residir en una estacin de trabajo
remota.
- Alto desempeo en la independencia de dispositivos grficos.

En la tecnologa cliente/servidor, el nodo que despliega y recibe informacin, e
interacta con el usuario, es el nodo cliente.
Los X clients contienen la aplicacin lgica funcional escrita por el desarrollador,
aunque esta residira en un sistema servidor en la red cliente/servidor. El X Client es
enlazado con las libreras X Window y las libreras de las herramientas basadas en X
usadas para crear una aplicacin. Aun cuando la designacin de X Client y X Server
pueden parecer contradictorias a la definicin de cliente y servidor del modelo
cliente/servidor. De hecho:

- En el sistema X Window, el X cliente inicia la interaccin con su servidor, el X
Server.
- El X Client solicita un X Server para las funciones de despliegue en pantalla.
- Un X Server puede dar servicio a mltiples X clients.
- X Client y X Server pueden estar en la misma mquina.

1.5 Problemas de los sistemas distribuidos

El mayor problema en las redes de rea amplia es que son lentas. Por ejemplo
algunas redes tienen una velocidad de transferencia de 1250 bytes por segundo,
mientras que un disco duro representativo tiene un factor de transferencia de al
rededor de 1 a 2 millones de bytes por segundo. Por lo tanto, un objetivo principal de
los sistemas distribuidos es reducir el nmero y volumen de los mensajes. Este
objetivo a su vez da pie a problemas en varias reas secundarias, entre ellas las
siguientes:

Procesamiento de consultas.
El objetivo de reducir al mnimo el trfico en la red implica que el proceso mismo
de optimizacin de consultas debe ser distribuido, adems del proceso de ejecucin de

18
las consultas. En otras palabras, un proceso representativo consistir en un paso de
optimizacin global, seguido de pasos de optimizacin local en cada uno de los sitios.
Por ejemplo se requiere una consulta C en el sitio X, y que C implica una reunin de
una relacin Ry de cien tuplas en el sitio Y con una relacin Rz de un milln de tuplas
en el sitio Z. El optimizador ubicado en el sitio X escoger la estrategia global para
ejecutar C; y resulta evidente la importancia de que decida trasladar Ry a Z y no Rz a Y
(y ciertamente no Ry y Rz a X). Despus, una vez que haya decidido trasladar Ry a Z,
el optimizador local en Z ser el que decida cul debe ser la estrategia para realizar la
unin en este sitio.

Administracin del catlogo.
En un sistema distribuido, el catlogo del sistema incluir no solo la informacin
usual acerca de las relaciones, ndices, usuarios, etctera; sino tambin toda la
informacin de control necesaria para que el sistema pueda ofrecer la independencia
deseada con respecto a la localizacin, la fragmentacin y la rplica. Existen varias
tcnicas para el almacenamiento de los catlogos:
1. Centralizado: El catlogo total se almacena una sola vez, en un sitio central.
2. Replicas completas: El catlogo total se almacena por completo en todos los
sitios.
3. Dividido: Cada sitio mantiene su propio catlogo para los objetos almacenados
en ese sitio. El catlogo total es la unin de todos los catlogos locales no
traslapados.
4. Combinacin de 1 y 3: Cada sitio mantiene su propio catlogo local, como en el
punto 3; adems, un sitio central nico mantiene una copia unificada de todos los
catlogos locales, como en el punto 1.

Todos estos enfoques tienen algn problema. Es obvio que el enfoque 1 viola el
objetivo de "no depender de un sitio central": el enfoque 2 adolece de una grave falta
de autonoma, pues toda actualizacin del catalogo deber de ser propagada a cada
uno de los sitios. El enfoque 3 hace muy costosas todas las operaciones no locales
(no encontrar un objeto remoto requerir obtener acceso a la mitad de los sitios en
promedio). El enfoque 4 es ms eficiente que el 3 (encontrar un objeto remoto requiere
slo el acceso a su catlogo remoto), pero viola una vez ms el objetivo de "no

19
depender de un sitio central". Por lo tanto, los sistemas en la practica casi nunca
usan ninguno de estos cuatro enfoques.

Propagacin de actualizaciones.
El problema bsico con la rplica de datos, como se seal es la necesidad de
propagar cualquier modificacin de un objeto lgico dado a todas las copias
almacenadas de ese objeto, Un problema que surge es algn sitio donde se mantiene
una copia del objeto podra no estar disponible en el momento de la actualizacin. As,
la estrategia de propagar las actualizaciones de inmediato a todas las copias podra ser
inaceptable, porque implica que la modificacin ( y la transaccin) fracasara si
cualquiera de estas copias no esta disponible en el momento.
Un mtodo para manejar este problema es el llamado mtodo de "copia primaria", el
cual funciona de la siguiente manera:

- Una de las copias del objeto se designa como copia primaria. Las dems sern
copias secundarias.
- Las copias primarias de los diferentes objetos estn en sitios diferentes (de
modo que, una vez ms, este mtodo es distribuido).
- Las operaciones de actualizacin se consideran completas tan pronto como se
ha modificado la copia primaria. El sitio donde se encuentra esa copia se
encarga entonces de propagar la actualizacin a las copias secundarias en un
momento posterior.

Este mtodo representa un problema, una violacin al objetivo de autonoma local,
porque ahora una transaccin podra fallar cuando una copia (primaria) remota de
algn objeto no estuviera disponible, aun cuando se dispusiera de una copia local.

Control de recuperacin.

20
El control de recuperacin en los sistemas distribuidos se basa por lo regular en el
protocolo de dos fases. El compromiso de dos fases es obligatorio en cualquier
ambiente en el cual una sola transaccin puede interactuar con vados manejadores de
recursos autnomos, pero tiene especial importancia en un sistema distribuido porque
los manejadores de recursos en cuestin (DBMS locales) operan en sitios remotos
distintos y por tanto son muy autnomos.
De acuerdo a lo anterior surgen los siguientes puntos:

1. El objetivo de "no dependencia de un sitio central' dicta que la funcin de
coordinador no debe asignarse a un sitio especifico de la red, sino que deben
realizara diferentes sitios para diferentes transacciones. Por lo general se
encarga de ella el sitio en el cual se inicia la transaccin en cuestin.

2. El proceso de compromiso en dos fases requiere una comunicacin entre el
coordinador y todos los sitios participantes, lo cual implica ms mensajes y
mayor costo.

3. El sitio Y acta como participante en un compromiso de dos fases coordinado
por el sitio X, el sitio Y deber hacer lo ordenado por el sitio X (compromiso o
retroceso), lo cual implica otra prdida de autonoma local.

4. En condiciones ideales el proceso de compromiso en dos fases funcionar
an en caso de presentarse fallas de sitios o de la red en cualquier punto.
Idealmente, el proceso debera ser capaz de soportar cualquier tipo
concebible de falla.

Control de concurrencia.
Como en mayor parte de los sistemas distribuidos el control de concurrencia se
basa en el bloqueo, tal como sucede en casi todos los sistemas no distribuidos. Pero
en un sistema distribuido, las solicitudes de prueba, establecimiento y liberacin de
bloqueo se convierten en mensajes (suponiendo que el objeto en cuestin es un sitio
remoto), y los mensajes implican costos adicionales. Por ejemplo, se considerara una
transaccin T que necesita poner al da un objeto del cual existen rplicas en n sitios
remotos. Si cada sitio se encarga de los bloqueos sobre los objetos almacenados en

21
ese sitio (como suceder si se cumple la suposicin de autonoma local), la puesta en
practica directa requerir por lo menos de 5 mensajes por cada sitio:
- solicitud de bloqueo
- concesiones de bloqueo
- mensajes de actualizacin
- verificaciones
- solicitudes de liberacin de bloqueo

As pues, el tiempo total invertido en la actualizacin podra con facilidad ser mayor
que en un sistema centralizado.
Otro problema con el bloqueo en un sistema distribuido es que puede conducir a un
bloqueo mutuo, en el cual se veran implicados varios sitios.
El problema con un bloqueo como ste es que ninguno de los sitios puede
detectarlo empleando slo informacin interna de este sitio. Dicho de otro modo, no
existen ciclos en las grficas de espera locales, aunque aparecer un ciclo si se
combinan esas dos grficas locales para formar una grfica de espera global. En
consecuencia, la deteccin de bloqueos mutuos globales implica mayores costos
adicionales de comunicacin, pues requiere juntar de alguna manera las grficas
locales individuales.

1.6 Soporte para bases de datos distribuidas
Existen diversos Sistemas Manejadores de Bases de Datos (DBMS) comerciales,
los cuales en sus inicios fueron diseados para el manejo de bases de datos
centralizadas, logrando un hito en el manejo de datos puesto que permitieron el diseo
de sistemas abiertos. Esto gracias al sublenguaje de datos con que trabajaban en la
realizacin de consultas (por lo general SQL), los programadores de aplicaciones solo
se preocupaban por generar las consultas en SQL y no por generar consultas para uno
u otro DBMS en particular.
Al aumentar la cantidad de datos y la necesidad de informacin, y de la misma
manera al evolucionar las bases de datos centralizadas a distribuidas, los DBMS
tambin tuvieron que evolucionar a lo que actualmente se conoce como Sistemas
Manejadores de Bases de Datos Distribuidas (DDBMS). Estos DDBMS, adems de
contar con el sublenguaje de datos deben tener nuevas caractersticas propias de las
bases de datos distribuidas como son el soporte de fragmentacin, replicacin, y el

22
procesamiento de consultas distribuidas. Sin dejar a un lado que un DDBMS debe de
ser un sistema abierto, esto debido a que el DDBMS se debe de comunicar con otro
sito en el cual tal vez no cuente con el mismo DDBMS.
Algunos de los DDBMS comerciales con los que se cuenta son INFORMIX, DB2 y
ORACLE. A continuacin se presenta una tabla en la cual se muestran algunas de las
caractersticas de dichos DDBMS:

DDBMS DSL REPLICA
INFORMIX VS.07 SQL Soportada
DB2 V5 SQL Integrada
ORACLE V8 SQL Integrada

Existen muchos ms DDBMS con diferentes caractersticas, por ejemplo, Sybase
ofrece las primitivas pero- las aplicaciones deben de implementar las transacciones
distribuidas por si mismas, sin embargo, es posible disear de manera optima una
base de datos distribuida con las herramientas que estos DDBMS comerciales
proporcionan.

1.7 Resumen
Las caractersticas que deben de tener los sistemas de bases de datos son:

23

Control centralizado: Un Administrador de base de datos (DBA) tiene la funcin de
garantizar la seguridad de los datos, el administrador local tiene la responsabilidad de
su respectiva base de datos, mientras que el administrador global tiene la principal
responsabilidad de la totalidad de los datos de la base de datos.

Independencia de datos: quiere decir que, la organizacin actual de los datos es
transparente a las aplicaciones y en el caso de una base de datos distribuida se refiere
tambin a la transparencia de distribucin.

Reduccin de redundancia: la redundancia debe de ser reducida, por dos razones:
evitar la inconsistencia entre varias copias de los datos, y recuperar espacio de
almacenamiento en el sistema, an cuando en una base de datos distribuida, las
aplicaciones podran verse favorecidas con la redundancia, ya que, debido a esta, la
razn de disponibilidad puede aumentar.

Estructuras fsicas complejas y acceso eficiente: El uso de estructuras de acceso
podra ser una herramienta para el acceso eficiente a la base de datos, es conveniente
tomar en cuenta la optimizacin local, el acceso a las bases de datos locales, y la
optimizacin global, el acceso a los sitos que conforman la base de datos, de las
consultas.

Seguridad: En las bases de datos tradicionales, el administrador de la base de
datos, tiene el control centralizado. En las bases de datos distribuidas, se tienen,
adems, que considerar dos aspectos, el grado de autonoma y la seguridad en los
accesos de los usuarios.

Las bases de datos distribuidas tienen algunas ventajas sobre las no distribuidas,
estas son:

Razones organizacionales: La mayor parte de las organizaciones estn ya
descentralizadas.

24
Interconexin de las bases de datos existentes: Las bases de datos distribuidas son
la solucin cuando se tiene varias bases de datos en la organizacin.

Desarrollo incrementar: Es posible agregar una nueva unidad en una base de datos
distribuida si afectar a las ya existentes.

Reduccin de la sobrecarga de la comunicacin: En una base de datos distribuida
geogrficamente, se vera reducida la sobrecarga de las comunicaciones en
comparacin con una base de datos no distribuida.

Consideraciones en el desempeo: La existencia de varios procesadores
autnomos da como resultado un alto grado de procesamiento en paralelo.

Confiabilidad y disponibilidad: Por medio de la repica de datos, se logra un alto
grado de contabilidad y disponibilidad.

Existe un principio fundamental en los sistemas distribuidos, el cual es aplicable a
las bases de datos distribuidas:

Desde el punto de vista del usuario, un sistema distribuido deber ser idntico a un
sistema no distribuido.

Hay adems de este, 12 reglas para los sistemas distribuidos:

Autonoma local: Significa que todas las operaciones en un sitio se controlan en ese
sitio.

No dependencia de un sitio central: Todos los sitios son iguales y no dependen de
ningn otro sitio.

Operacin continua: Un sistema distribuido siempre esta disponible.

Independencia con respecto a la localizacin: Los usuarios nunca sabrn la
localizacin real de los datos.

25

Independencia con respecto a la fragmentacin: Un sistema distribuido deber dar
la apariencia de que se encuentra en una sola pieza.

Independencia de replica: Un sistema deber comportarse como si solo e)dstiera
una sola copia de los datos.

Procesamiento distribuido de consulta: En una consulta, la cual involucro a ms de
un sitio, siempre habr varias maneras de trasladar en la informacin para satisfacer la
peticin y encontrar la estrategia ms eficiente.

Manejo distribuido de transacciones: Deber poder procesar una transaccin a
travs de varios sitios.

Independencia con respecto al equipo: Deber poder procesar una transaccin a
travs de diferentes plataformas de hardware y aparentar ante el usuario como si fuera
uno solo.

Independencia con respecto al sistema operativo: Deber de ser capaz de trabajar
en cualquier sistema operativo.

Independencia con respecto a la red: Deber de ser capaz de trabajar en diferentes
redes.

Independencia con respecto al DBMS: Varios DBMS debern trabajar en conjunto y
procesar las transacciones.

El paradigma que dispone que una aplicacin debe esperar pasivamente a que otra
aplicacin inicie la comunicacin, tiene el nombre de interaccin cliente/servidor.

El modelo de procesamiento cliente/servidor surgi del concepto de procesamiento
compartido de las redes de rea local. As, las computadoras personales conectadas a
un sistema pueden compartir recursos, la computadora que solicita el recurso pasa a

26
ser un cliente, mientras que aquella que comparte el recurso y recibe la peticin se
convierte en servidor.

Esta arquitectura provee ciertas ventajas:

- Permite integrar mejores tecnologas al sistema.
- Permite que el procesamiento de los datos se realice en el lugar en el que
estos residen
- Facilita el uso de interfaces grficas de usuario.
- Permite el uso de sistemas abiertos.

A pesar de todo esto, tambin cuenta con algunas desventajas:

- El servidor puede convertirse en cuello de botella, al verse disminuidos los
recursos del servidor.
- El desarrollo de aplicaciones distribuidas es ms complicado que el de las no
distribuidas.

Tanto el cliente como el servidor, deben de cumplir con ciertas caractersticas para
ser considerados como tales:

Cliente
- Es un programa de aplicacin arbitrario que se vuelve cliente temporalmente
cuando necesita acceso remoto, pero tambin lleva a cabo otro computo local.
- Lo llama directamente el usuario y se ejecuta solo durante la sesin.
- Se ejecuta localmente en la computadora personal del usuario.
- Inicia el contacto con el servidor.
- Puede acceder a varios servicios, segn se necesite, pero contacta activamente
con un servidor remoto a la vez.
- No necesita hardware poderoso y un sistema operativo complicado.

Servidor

27

- Es un programa privilegiado de propsito especial dedicado a ofrecer un
servicio, pero puede manejar varios clientes remotos a la vez.
- Se inicia automticamente al arranque del sistema y continua ejecutndose
en varias sesiones.
- Opera en una computadora compartida (es decir, no en una computadora
personal).
- Espera pasivamente el contacto de los clientes remotos.
- Acepta el contacto de varios clientes, pero ofrece un solo servicio.
- Necesita hardware poderoso y un sistema operativo complejo.

El cliente debe de cumplir con la funcin de presentar la informacin al usuario,
as como de realizar algunas funciones lgicas en el procesamiento de dicha
informacin. Por su parte el servidor debe de proveer servicios a solicitudes de
procesamiento, el cliente inicia la interaccin cliente/servidor enviando solicitudes a los
servidores, la funcin de un servidor debe llevar a cabo una determinada accin, de
acuerdo a la solicitud enviada por el cliente. Algunas funciones que un servidor pudra
realizar seria:
- Compartir archivos.
- Compartir impresoras.
- Servicios de comunicacin.
- Servicios de fax.
- Accesos a las bases de datos.

Un servidor deber, tambin, cumplir con ciertos requerimientos generales:
- Soporte multiusuario: Debe de ser capaz de proporcionar servicio a mltiples
clientes.
- Escalabilidad: Debe de ser capaz de satisfacer la creciente demanda de los
recursos y las aplicaciones.
- Desempeo: Un servidor debe proveer niveles de desempeo satisfactorios.
- Almacenamiento: Debe de ser capaz de almacenar tanto aplicaciones, como los
archivos generados por estas y los usuarios.

28
- Gestin de red: Tanto el servidor como el cliente deben de contar con
capacidades de red.
- Multimedia: En la actualidad la necesidad de que un servidor soporte datos,
vdeo y sonido son esenciales.

Debido a que un sistema distribuido involucro el procesamiento cooperativo entre
vados servidores y clientes, se presentan algunos problemas que se deben de tomar
en cuenta para ser solucionados:

Procesamiento de consultas: El proceso deber de ser distribuido, por lo tanto, un
proceso representativo consistir en una actualizacin global seguida de
optimizaciones locales en cada sitio.

Administracin del catalogo: En un sistema distribuido, el catalogo del sistema incluir
la informacin a cerca de las relaciones, los ndices, los usuarios, y la localizacin de
fragmentos y replicas de los datos.

Propagacin de las actualizaciones: Es necesario propagar cualquier actualizacin de
un objeto dado, en todas las copias existentes de ese objeto en el sistema.

Control de recuperacin: Es necesario que un sistema distribuido cuente con un
mtodo de recuperacin, esto, en caso de cadas del sistema. El control de
recuperacin en los sistemas distribuidos se basa por lo regular en el protocolo de dos
fases. El compromiso de dos fases es obligatorio en cualquier ambiente en el cual una
sola transaccin puede interactuar con varios manejadores de recursos autnomos.

Control de concurrencia: el control de concurrencia se basa en el bloqueo, las
solicitudes de prueba, establecimiento y liberacin de bloqueo, los cuales se convierten
en mensajes, y por lo tanto implica costos adicionales. La puesta en practica directa
requerir por lo menos de 5 mensajes por cada sitio involucrado en la transaccin:
solicitud de bloqueo, concesiones de bloqueo, mensajes de actualizacin,
verificaciones, solicitudes de liberacin de bloqueo.

29
Al aumentar la cantidad de datos y la necesidad de informacin, y de la misma
manera al evolucionar las bases de datos centralizadas a distribuidas, los DBMS
tambin tuvieron que evolucionar a lo que actualmente se conoce como Sistemas
Manejadores de Bases de Datos Distribuidas (DDBMS). Estos DDBMS debern contar
con: el sublenguaje de consultas, el soporte de fragmentacin, replicacin, y el
procesamiento de consultas distribuidas. Sin dejar a un lado que un DDBMS debe de
ser un sistema abierto capaz de interactuar con otros DDBMS.

1.8 Preguntas de repaso

1.-Cuales son las caractersticas sobre las cuales, es posible hacer una
comparacin entre bases de datos centralizadas y bases de datos distribuidas?
2.-Cuales son las ventajas que tienen las bases de datos distribuidas sobre las
centralizadas?
3.-Cul es la regla cero de los sistemas distribuidos?
4.-Por qu la regla cero de los sistemas distribuidos es considerada el
principio de las bases de datos distribuidas?
5.-A que se refiere la autonoma en el enfoque de las bases de datos distribuidas?
6.-Que significa transparencia dentro del entorno de las bases de datos
distribuidas?
7.-Cmo describe la arquitectura cliente - servidor?
8.-Cuales deben ser las caractersticas de un cliente?
9.-Cules deben ser las caracteristic as de un servidop
10.-Que requerimientos son necesarios para un servidor?
11.- Cuales son los principales problemas a los que se enfrentan los diseadores de
bases de datos distribuidas?

30
Bibliografa

[1] Date, C.J.; "An lntroduction to Databases Systems"; Volume 1-1 Fifth Edition;
Addison-Wesley Publishing Company; U.S.A.; Reprinted July, 1990

[2] Date, C.J-; "An Introduction to Databases Systems"; Volume li; Addison-Wesley
Publishing Company; U.S.A.; Reprinted July, 1995

[3] Korth, Henry F. Silberschatz, Abraham; "Database System Concepts"; Second
Edition; McGraw-Hill; U.S.A-; Internacional Edition 1991

[4] Berson, Alex - "Client/ServerArchitecture'; McGraw-Hill; U.S.A.-, 1992

[5] Renuad, Paul E.; "Introduction to Client/Server Systems A practicar guide for
systems professionals"; Wiley Professional Computing; U.S.A.; 1993

31

Objetivo
El alumno comprender las tcnicas de diseo de bases de datos distribuidas, as
como cada uno de los tipos de fragmentacin existentes y las operaciones necesarias
para realizarla.

Introduccin
En este captulo se tratarn las consideraciones que se debern tener al disear la
distribucin de la base de datos, as como los tipos de fragmentaciones que existen y
como se obtienen. Tambin se expondr la forma en como se debern llevar a cabo el
procesamiento de las consultas en un sistema con datos distribuidos y los costos de
dicho procesamiento,
A continuacin se presenta una tabla con las operaciones del lgebra relaciona que se
utilizarn a lo largo del captulo:

Operacin Abreviacin Smbolo
Select SL o
Projecion Pi H
Join JN
Semi-join si
Union UN
Producto cartesiano CP X
Natural Join NJN
Natural Semi-join NSJ
Diferencia DF

Captulo II

Bases de Datos en mltiples servidores

32
2.1 Consideraciones en la distribucin de bases de datos

Desde la primera etapa de las bases de datos distribuidas a la actualidad, se han
desarrollado varias tcnicas para su diseo. De cualquier forma esta claro que el
diseo de bases de datos distribuidas no es fcil, ya que por si mismas, las tcnicas y
organizacin, en el diseo de un sitio sencillo son complicadas, stas se vuelven ms
complicadas en el diseo de un sistema multisitio. Desde el punto de vista tcnico, los
nuevos problemas que se presentan son la interconexin entre los sitios por medio de
la red, y la distribucin optima de los datos y aplicaciones en los sitios para lograr un
desempeo optimo del sistema. Desde el punto de vista organizacional, la
descentralizacin es crucial, puesto que se sustituir por un sistema distribuido al tpico
y extenso sistema centralizado, y en el caso de la distribucin de una aplicacin tendra
un gran impacto en la organizacin.
El diseo de una base de datos centralizada consiste en:

1. Disear el "esquema conceptual", el cual describe la base de datos-
2. Disear el 'esquema fsico", mapeando el esquema conceptual con las reas de
almacenamiento y determinando los mtodos de acceso.

En las bases de datos distribuidas estos dos puntos son utilizados para disear el
esquema global y disear las bases de datos locales en cada sitio. La distribucin de
las bases de datos requiere agregar dos nuevos puntos:

3. Disear la fragmentacin de los datos, determinando como las relaciones
globales sern divididas, horizontalmente, verticalmente o en fragmentos
mixtos.
4. Disear la distribucin de los fragmentos, determinando como se mapearn los
fragmentos, con las imgenes fsicas. En este punto son determinadas las
replicas de los fragmentos.

Estos dos puntos son caractersticos en el diseo de datos distribuidos.

33
2.1.1 Objetivos del diseo de los datos distribuidos
En el diseo de los datos distribuidos, los siguientes objetivos debern ser tomados
en cuenta:

Procesamiento local.
La distribucin de los datos aumenta el procesamiento local, esto correspondiendo a
un principio bsico de que los datos son colocados lo ms cercano a las aplicaciones
que los utilizan. Una manera simple de ejemplificar el procesamiento local, es
considerar dos tipos de referencias a los datos: referencias "locales" y referencias
"remotas". Claramente, una vez que los sitios de origen de las aplicaciones conocen la
localizacin local y remota de los datos, la referencia depende nicamente de la
distribucin de los mismos.
Se deber, tambin, tomar en cuenta cuando una aplicacin tiene un procesamiento
local completo, es decir la aplicacin se ejecuta completamente en el lugar de origen.
La ventaja del procesamiento local completo no solamente reduce los accesos
remotos, sino que adems, incremento la simplicidad en el control de la ejecucin de la
aplicacin.

Disponibilidad y confiabilidad de los datos distribuidos.
El almacenamiento de mltiples copias de la informacin permite lograr un alto
grado de disponibilidad para las aplicaciones que solo leen o muestran los datos; el
sistema puede conmutar a una copia alternativa, cuando la copia que comnmente era
accesada no se encuentra disponible.
La Confiabilidad se logra por medio del almacenamiento de mltiples copias de la
informacin permitiendo recuperarla, de cadas del sistema o de daos fsicos en
alguna de las copias, usando cualquier otra copia disponible.

Distribucin de la carga del trabajo.
La distribucin de la carga del trabajo en los sitios es una caracterstica importante
de los sistemas distribuidos. La distribucin de la carga del trabajo es hecha en
relacin con el poder de cmputo y utilizacin del equipo de cada sitio, y para

34
maximizar el grado de paralelismo en la ejecucin de las aplicaciones. La distribucin
de la carga del trabajo puede provocar un efecto negativo en la ejecucin local.

Disponibilidad y costo del almacenamiento.
La distribucin de las bases de datos se refleja en el costo y disponibilidad del
medio de almacenamiento en los diferentes sitios. Esto es posible teniendo sitios
especializados en la red para el almacenamiento de datos. Por lo general, el costo del
almacenamiento de los datos nos es tan relevante, comparado con el costo de CPU,
I/O, y el costo de la transmisin de las aplicaciones.

2.2 Diseo de bases de datos distribuidas

2.2.1 Tcnicas de diseo Top-Down y Bottom-Up de bases de datos
distribuidas
Se tiene dos alternativas en el diseo de las bases de datos distribuidas, las
tcnicas Top-Down y Bottom-Up.
En la tcnica top-down, se comienza diseando el esquema global, y se procede
con el diseo de la fragmentacin de los datos, despus se distribuyen los fragmentos
en los sitios, creando las imgenes fsicas. Esta tcnica es complementada con la
construccin, en cada sitio, del "diseo fsico" de los datos que estarn almacenados
ah.
Cuando la base de datos distribuida es desarrollada como un complemento de una
base de datos existente, no es tan fcil lograr esto con la tcnica top-down- De hecho,
en este caso el esquema global est, por lo general, comprometido con los datos
existentes.
Cuando una nueva base de datos va a ser agregada a una ya existente, la tcnica
de diseo bottom-up puede ser utilizada. Esta tcnica consiste en la integracin de
esquemas existentes en un solo esquema global. Para la integracin, se deber de
unir definiciones de datos comunes y resolver conflictos entre diferentes
representaciones del mismo dato.
En resumen, la tcnica bottom-up requiere:

35

1. La seleccin de un modelo de base de datos comn para disear el esquema
global de la base de datos.
2. La traduccin de cada esquema local al modelo de datos comn.
3. La integracin de los esquemas locales en el esquema global comn.

2.2.2 Diseo de los fragmentos de la base de datos
El diseo de los fragmentos es la primera parte dentro de la tcnica top-down. El
propsito de la fragmentacin es determinar fragmentos no traslapados, los cuales
sern unidades lgicas de distribucin.
Se podr ver que, las tuplas y atributos de la relacin no podrn ser considerados
como "unidades individuales de distribucin'. El diseo de fragmentos consiste en
agrupar tuplas (en el caso de la fragmentacin horizontal) o atributos (en el caso de la
fragmentacin vertical), las cuales tienen las "mismas propiedades" desde el punto de
vista de la distribucin. Cada grupo de tuplas o atributos que tienen las "mismas
propiedades" puede constituir un fragmento. La idea bsica es que si dos elementos
cualquiera de un mismo fragmento tiene las mismas propiedades" desde el punto de
\Asta de la distribucin, cualquier mtodo usado para localizar un dato puede entonces
localizar a cualquiera.

2.2.3 Correctez de la fragmentacin
Para que una fragmentacin sea correcta, esta deber de cumplir con las siguientes
caractersticas:
Completez
La descomposicin de una relacin R en fragmentos RI,R2, ... ,Rn, es completa si y
solo si cada elemento de datos en R puede ser encontrado en algn Ri

Reconstruccin
Si la relacin R es descompuesta en fragmentos Rl,R2, ... , Rn, debiera existir un
operador relacional V tal que: R V Ri
Exclyete

36
Si la relacin R es descompuesta, en fragmentos Rl,R2, .... Rn, y datos de]
elemento di estn en Rj entonces di no debiera estar en algn otro fragmento Rk = k).

2.2.4 Fragmentacin horizontal
La fragmentacin horizontal consiste en particionar las tuplas o registros de una
Tabla global en subconjuntos de tuplas o registros; esto es muy utilizado en las bases
de datos distribuidas, donde cada subconjunto pueden contener datos con propiedades
geogrficamente comunes.
Es importante, dentro de la fragmentacin horizontal, considerar las siguientes
definiciones:

Predicado simple
Dado R[A
l
,A
2
, ... A.], un predicado simple pj es:
pj: Ai u Valor
donde u e {=, =, >, , <, >}, Valor e Di y Di es el dominio de A.
Se tendr entonces R[pl,P2,P3,---,PMI

Predicados minitermino
Dado Ri y Pti = {p
1
,p
2
, ... pj definir M = {mi
1
, mi
2
, ... miz} como:
Mi = {mij l mij = ^pik e pri pik*}, 1 k m, 1 j z donde pi*= pi o pi* = ~pi

selectividad de miniterminos sel(mj)
Nmero de tuplas de la relacin que sera accesada por una consulta de usuario la
cual es especificada acorde a un predicado minitermino mj dado.

frecuencias de acceso: acc(qj)
Frecuencia con la cual la aplicacin qj accesa datos.
La frecuencia de acceso por una predicado minitermino puede tambin ser definida.

Considrese la siguiente relacin global:
Proveedor(pclave, nombre, cveciudad)

37
pClave Nombre cveciudad
P01 John Smith SF
P02 Jos Sanchz LA
P03 Juan Prez LA
P04 Steven Freeman SF
P05 Alex SD
P06 Tere SD

Para la cual se tiene la siguiente aplicacin:
q: Obtener la clave y el nombre de los proveedores de cada ciudad.

Se tendrn los siguientes predicados simples:
P
1
= {cveciudad = "SF" }
P
2
= { cveciudad = "LA" }
P
3
= { cveciudad = "SD" }

Dando como resultado los siguientes predicados miniterminos, los cuales se
obtienen de las combinaciones de los predicados simples:

m
1
= {SF ^ LA ^ SD} contradictorio
m
2
= {SF ^ ~LA ^ SD} contradictorio
m
3
= {SF ^ ~LA ^ ~SD}
..
M
6
= {~SF ^ ~LA ^ ~SD} contradictorio
..
M
7
= {~SF ^ LA ^ ~SD}
M
8
= {~SF ^ ~LA ^ SD}

Eliminando los miniterminos contradictorios se obtiene el siguiente resultado, donde
cada uno de estos miniterminos representa un fragmento de la relacin global:
M
3
= {SF ^ ~LA ^ ~SD}
M
7
= {~SF ^ LA ^ ~SD}
M
8
= {~SF ^ ~LA ^ SD}

38

Entonces la fragmentacin horizontal estara dada de la siguiente forma:
Proveedor
1
= SL
cveciudad = SF
Proveedor

Select pclave, nombre, cveCiudad into Proveedor1
from Proveedor Where cveCiudad = SF
Pclave Nombre Cveciudad
P01 John Smith SF
P04 Steven Freeman SF

Proveedor
2
= SL
cveciudad = LA
Proveedor

from Proveedor Where cveCiudad = LA
P02 Jos Sanchz LA
P03 Juan Prez LA

Proveedor
3
= SL
cveciudad = SD
Proveedor

from Proveedor Where cveCiudad = SD
P05 Alex SD
P06 Tere SD

Las condiciones anteriores cumpliran con la definicin de fragmentacin, si los
nicos valores posibles para el atributo Cveciudad fueran "SF", "LA" y SD; de otro
modo no se sabra a que fragmento corresponden las tuplas que contengan otro valor.

39
La reconstruccin de la Tabla global Proveedor se logra fcilmente, por medio de la
siguiente condicin:

Proveedor = Proveedor
1
UN Proveedor
2
UN Proveedor
3

Create View ReconstruccionProveedor
As
Select * from Proveedor1
Union All
Union All

La reconstruccin de la relacin global siempre se lleva a cabo, por medio de la
operacin de unin.

2.2.5 Fragmentacin horizontal derivada
En algunas ocasiones, la fragmentacin horizontal de una tabla no se puede basar
en alguna propiedad de sus propios atributos, pero se deriva de la fragmentacin
horizontal de otra tabla. Considrese el siguiente ejemplo:

Pedido(pclave, cveProducto, cant)
Pclave cveProducto Cant
P01 2325 123
P01 2547 21
P02 3298 98
P03 7895 87
P04 741 0 53
P04 2589 10

Donde pclave es la clave del proveedor. Esto es significativo para la particin
de esta relacin ya que un fragmento contiene las tuplas para los proveedores con los
cuales se obtiene la cveciudad. No obstante que cveciudad no es un atributo de la

40
tabla Pedido, sino que es un atributo de la tabla Proveedor. Por lo tanto, se necesita
una operacin de semi-join para determinar las tuplas de Pedido que corresponden con
los proveedores en cierta cveciudad. Esto se logra de la siguiente manera:

Pedido
1
= Pedido SJ
pclave = pclave
Proveedor
1
Select A.* into Pedido1 From Pedido A Inner Join Proveedor1 B on (A.pclave=B.pclave)

Pclave Pnum Depto Cant
P01 2325 Compras 123
P01 2547 Compras 21
P04 7410 Ventas 53
P04 2589 Sistemas 10

Pedido
2
= Pedido SJ
pclave = pclave
Proveedor
2

Pclave Pnum Depto Cant
P02 3298 Ventas 98
P03 7895 Finanzas 87

Pedido
3
= Pedido SJ
pclave = pclave
Proveedor
3

El efecto de la operacin semi-join nos permite seleccionar de Pedido las tuplas que
satisfacen la condicin de unin entre Proveedor1, o Proveedor2, o Proveedor3 y
Pedido, de esta manera se determinaran aqullas tuplas de la Table Pedido que hacen
referencia a proveedores en San Francisco, Los ngeles o San Diego,
respectivamente.
La reconstruccin de la Table global Pedido puede lograrse por medio de una
operacin de unin como en el caso de la table Proveedor.
La integridad de un fragmento requiere que no existan claves de proveedores en la
Table Pedido, los cuales no estn dentro de la tabla Proveedor. Esto es una
restriccin tpica dentro de las bases de datos conocida como integridad referencial.

41

2.2.6 Fragmentacin vertical
La fragmentacin vertical de una tabla global es la subdivisin de sus atributos en
grupos, los fragmentos son obtenidos al proyectar la tabla global sobre cada grupo.
La fragmentacin es correcta si cada atributo es mapeado por lo menos con un atributo
de los dems fragmentos; por otra parte, es posible reconstruir la tabla original por
medio de uniones de todos los fragmentos a la vez. Considrese el siguiente ejemplo:

Emp(Cvemp, Nom, Sal, lmp, Depto)

Cvemp Nom Sal Imp Depto
E12 Juan Prez 4500 15 15
E56 Jos Hernndez 756 15 9
E78 Luis Prez 9254 15 17
E98 Maria Sols- 2345 25 22
E32 John Smith 5489 2-5 22
Egl Rocio Snchez 4600 15 8
E73 Carmen Campos 753 15 15

Considrese las siguientes aplicaciones:
q
1
: Obtener el nombre y departamento de todos los empleados
q
2
: Obtener el clave, salado y tasa de impuestos por departamento
q
3
: Obtener la clave, nombre y departamento de los empleados con salado mayor a
10,000
Se tiene la siguiente matriz de accesos:
Total de
S1 S2 S3 accesos
q
1
2 3 2 7
q
2
2 1 2 5
q
3
1 2 1 4

42

Las aplicaciones se traduciran de la manera siguiente:

q
1
= Select nom, depto
From empleados
q
2
= Select cvemp, sal, imp
From empleados
Where depto = X
q
3
= Select cvemp, nom, depto
From empleados
Where sal > 10000

Con esto se podr obtener la matriz de uso, en la cual se colocara, de acuerdo con
los atributos accesados en cada una de las aplicaciones, colocando en cada casilla un
1 si el atributo A es reverenciado en la aplicacin q
j
.

A
1
(cvemp) A
2
(nom) A
3
(sal) A
4
(imp) A
5
(depto)
q
1
0 1 0 0 1
q
2
1 0 1 1 1
q
3
1 1 1 0 1

Ahora se construir la matriz de afinidad, la cual se obtiene por medio de la siguiente
formula

aff(Ai,Aj) = E todas las consultas que accesan A y Aj (accesos en consultas) accesos
en consulta = E todos los sitios frecuencia de accesos de una consulta

aff(A
1
, A
1
)= (2+1+2)(1) + (1+2+1)(1) = 9
aff(A
1
, A
2
)= (1+2+1)(1) = 4
aff(A
1
, A
3
)= (2+1+2)(1) + (1+2+1)(1) = 9
aff(A
1
, A
4
)= (2 +1+2)(1) = 5
aff(A
1
, A
5
)= (2+1+2)(1) + (1+2+1)(1) = 9
aff(A
2
, A
1
)= (1 +2+ 1)(1) = 4
aff(A
2
, A
2
)= (2+3+2)(1) + (1+2+ 1)(1) = 11

43
aff(A
2
, A
3
)= (1+2+1)(1) = 4
aff(A
2
, A
4
)= 0
aff(A
2
, A
5
)= (2+3+2)(1) + (1 +2+ 1)(1) = 11

A
1
A
2
A
3
A
4
A
5

A
l
9 4 9 5 9
A
2
4 11 4 0 11
A
3
9 4 9 5 9
A
4
5 0 5 5 5
A
5
9 11 9 5 16

En la diagonal debern aparecer los valores ms altos de cada columna, de no ser
as, ser necesario reordenar dichas columnas para logrado.

El paso restante ser seleccionar los campos necesarios para cada fragmento, esto,
de acuerdo al orden en que las columnas se encuentran en la tabla.

Emp= {A
1
, A
2
, A
3
, A
4
, A
5
}

Emp
1
{ A
1
, A
2
), Emp
2
= { A
1
, A
3
, A
4
, A
5
)
Emp
1
= PJ
cvemp, Nom
, Emp
Emp
2
= PJ
Cemp, Sal, Imp, Depto
Emp

Emp
1
(Cvemp, Nom)
Emp
2
(Cvemp, Sal, lmp, Depto)

o en otro caso

Emp
1
= { A
1
, A
2
, A
3
} Emp
2
= { A
1
, A
4
, A
5
}

44
Emp
1
= PJ
cvemp, Nom, Depto
Emp
Emp
2
= PJ
Cemp, Sal, Imp
Emp

Emp
1
(Cvemp, Nom, Sal)
Emp
2
(Cvemp, Imp, Depto)

El atributo A
1
aparece en ambos fragmentos debido a que es la llave primaria de la
relacin global. La manera de seleccionar que atributos iran en cada fragmento
depende de las necesidades del sistema.

La reconstruccin de la relacin Emp se puede obtener por medio de:

Emp = Emp
1
JN
cvemp = cvemp
Emp
2

Esto dado que Cvemp es la llave de la relacin global Emp. En general, la inclusin
de la llave de la relacin en cada uno de los fragmentos es lo que hace posible la
reconstruccin por medio de la operacin de join.

2.2.7 Fragmentacin mixta
Los fragmentos son obtenidos por medio de las operaciones de fragmentacin, que
pueden relacionarse precedentemente, es posible aplicar la operacin de
fragmentacin (vertical y horizontal) de manera recursiva, dando como resultado las
condiciones necesarias para la fragmentacin. La reconstruccin se logra aplicando
las reglas de reconstruccin en orden inverso de acuerdo a la fragmentacin.

45
Para realizar la fragmentacin mixta se deber considerar la necesidad de
informacin de cada uno de los sitios dentro de la base de datos distribuida, esto es
considrese la siguiente tabla:

Emp(Cvemp, Nom, Sal, lmp, Depto)

Se tiene un sitio en el departamento fiscal el cual se encarga del clculo de los
impuestos, y tres sitios ms, uno por cada uno de los tres departamentos restantes
dentro de la empresa. Para el departamento fiscal, el nombre y el departamento del
trabajador no son relevantes, necesitando nicamente los campos de clave del
empleado, salario y tasa de impuesto. Por tanto, es conveniente realizar una
fragmentacin vertical para obtener un fragmento con los campos necesarios (cvemp,
sal y imp) para este departamento. El resto de la tabla global podra fragmentarse
horizontalmente de acuerdo a cada departamento, obteniendo tres tablas, las cuales se
situaran en cada uno de los tres sitios restantes dentro del sistema distribuido.

Por medio de las siguientes operaciones se realizar una fragmentacin mixta,
donde se aplica la fragmentacin vertical, seguida por una fragmentacin horizontal por
Depto:
Vertical
Emp
1
= PJ
cvemp, Sal. Imp
Emp
Select cvemp, Sal, Imp Into Emp1 From Emp
Horizontal
Depto10 = SL
depto=10
PJ
Cvemp, Nom, Depto
Emp
Select cvemp, nom, depto Into Depto10 from Emp Where depto=10

Depto20 = SL
depto=20
PJ
Cvemp, Nom, Depto
Emp

Depto30 = SL
depto=30
PJ
Cvemp, Nom, Depto
Emp

La reconstruccin de la tabla Emp se define de la siguiente forma:

46

Emp = UN(Depto10, Depto20, Depto30) JN
Cvemp = Cvemp
PJ
Cvemp, Sal, Imp
Emp
1

Reconstruccion Horizontal
Create View ReconstruccionHorizontal
As
Select * from Depto10
Union All
Select * from Depto20
Union All
Select * From Depto30

Reconstruccion Vertical
Create View ReconstruccionVertical
as
Select A.cvemp, nom, imp, depto
From ReconstruccionHorizontal A inner join Emp1 B On
(A.cvemp=B.cvemp)

La fragmentacin mixta se representa generalmente por medio de un rbol de
fragmentacin. En el rbol de fragmentacin, la raz corresponde a la tabla global, las
hojas corresponden a los fragmentos, y los nodos intermedios corresponden a los
fragmentos intermedios, resultantes de las operaciones. A continuacin se presenta el
rbol de distribucin del ejemplo anterior:

Emp

Emp1

Depto10 Depto20 Depto30

H
V

47

Es importante tomar en cuenta que el orden en el cual se realiza la fragmentacin
horizontal y vertical afecta a la fragmentacin final.

fragmentacin vertical seguida de fragmentacin horizontal

fragmentacin horizontal seguida de fragmentacin vertical

2.2.8 Distribucin de los fragmentos
La manera ms fcil para realizar la distribucin de los fragmentos es considerar
cada fragmento como un archivo separado; sin embargo, este enfoque no es
conveniente, por las siguientes razones:
1 . Los fragmentos no son modelados propiamente como archivos individuales, ya
que de esta manera no se podra tomar en cuenta el hecho, de que tienen la
misma estructura.
2. Hay muchos ms fragmentos que relaciones globales, y muchos modelos
analticos no pueden procesar la solucin de problemas que involucran
demasiadas variables.
3. El modelado del comportamiento de las aplicaciones en sistema de archivos es
muy simple (tpicamente, las aplicaciones hacen un "acceso remoto a
archivos"), mientras que en aplicaciones de bases de datos distribuidas pueden
hacer un uso ms complejo de los datos.

Algunos de estos problemas no tienen una solucin satisfactoria; por ejemplo el
punto 3 es particularmente difcil, puesto que el correcto enfoque permitira evaluar la
distribucin de los datos mediante cmo las aplicaciones pueden optimizar el acceso.

48

2.2.9 Criterios generales para la distribucin de fragmentos.
En la distribucin de los fragmentos, es importante distinguir entre si se va a
disear una distribucin redundante o no redundante.

La replicacin introduce una amplia complejidad en el diseo, porque:

1. El grado de replicacin de cada fragmento llega a ser una variable del problema.

1. El diseo de los mdulos de lectura en las aplicaciones es complicado por el hecho
que las aplicaciones deben de seleccionar entre varios sitios alternativos, en cual
accesarn el mismo fragmento replicado en estos sitios.

Para determinar la redundancia en la distribucin de fragmentos, cualquiera de los
dos mtodos siguientes puede ser utilizado:

1 . Determinar el conjunto de todos los sitios donde el beneficio de colocar una
copia del fragmento es mayor que el costo, y colocar un fragmento en cada uno
de los sitios de este conjunto; este mtodo selecciona "todos los sitios
benficos'.
2. Determinar primero la solucin del problema sin rplica, y posteriormente
introducir rplicas iniciando por las ms benficas; el proceso termina cuando
una 'rplica adicional' no es benfica.

Ambos mtodos tienen algunas desventajas. En el caso del mtodo de "los sitios
benficos, el hecho de cuantificar el costo y el beneficio para cada fragmento es ms
crtico que en el caso no redundante. El mtodo de "la rplica adicional' es un tpico
enfoque heurstica; con este mtodo, es posible tomar en cuenta que el incremento en
el grado de redundancia es cada vez menos benfico. La disponibilidad y la
confiabilidad del sistema se ve incrementado si se tienen dos o tres copias de un
fragmento.

49
2.3 Procesamiento de consultas distribuidas

2.3.1 rbol de operadores de una consulta

Una manera de representar la secuencia en que se realizarn las operaciones de
una consulta, es un rbol de operadores. Considrese la siguiente consulta:

PJ
SNUM
SL
rea = Norte
(Prevee JN
Numdepto = Numdepto
Depto

Un ejemplo de un rbol de operadores para la consulta sera el que aparece en la
figura siguiente. Obsrvese que las hojas del rbol son relaciones globales y cada
nodo representa una operacin binaria o unitaria. Un rbol define un orden parcial en
como las operaciones deben ser aplicadas para obtener el resultado deseado en la
consulta, esto es, de abajo hacia arriba. Un orden diferente de operaciones -
correspondera un rbol tambin diferente, obteniendo una transformacin equivalente.

PJ
SNUM

SL
AREA="Norte"

JN
Numdepto=Numdepto

PROVEE DEPTO

El rbol de operadores de una expresin de lgebra relaciona] puede verse como
un rbol gramatical, asumiendo la siguiente forma:

R -> identificador
R -> ( R )
R -> op_uni R

50
R -> R op_bin R
op_uni -> SL
F
| PJ
A

op_bin CP | UN | DF | JN
F
| NJN
F
| SJ
F
| NSJ
F

2.3.2 Ejemplos de consultas distribuidas

Supngase una universidad, que cuenta con las carreras de derecho, contadura y
administracin- Dicha universidad tiene una base de datos distribuida con fragmentos
en cada uno de los departamentos concernientes a cada carrera de la manera
siguiente:
Tabla global

Alumnos(no-control, nombre, domicilio, ciudad, edad, especialidad)

No-control nombre Domicilio ciudad edad especialidad
D12 Pedro H. Hidalgo 100 Celaya 1-9 derecho
A32 Jos L. Morelos 23-4 Salamanca 20 Administracin
C54 Juan J. Revolucin 987 Irapuato 21 Contadura
C78 Mario V. A. L. Mateos 2345 Celaya 21 contadura
A29 Adolfo A Jurez 199 Celaya 21 administracin
D90 Adriana A Guerrero 987 Irapuato 21 derecho
D73 Sandra F. Revolucin 200 Salamanca 20 derecho
A99 Carmen G. A. 1. Mateos 234 Celaya 19 administracin
C34 Rocio S. Guerrero 987 Celaya 20 contadura

Debido a que cada departamento requiere tener la informacin de sus alumnos, se
realizara una fragmentacin horizontal utilizando la siguiente aplicacin:

51
Q: Seleccionar el nmero de control, nombre, domicilio, ciudad, edad, especialidad
para los alumnos de cada rea.

Esto dara como resultado los siguientes tres fragmentos horizontales:

Alumnos
1
= SL
especialidad = derecho
Alumnos

No-control nombre domicilio ciudad Edad Especialidad
D12 Pedro H. Hidalgo 100 Celaya 19 Derecho
D90 Adriana A. Guerrero 987 Irapuato 21 Derecho
D73 Sandra F. Revolucin Salamanca 20 Derecho

Alumnos
1
= SL
especialidad = contadura
Alumnos

No-control Nombre domicilio ciudad edad especialidad
C54 Juan J. Revolucin 987 Irapuato 21 contadura
C78 Mario V. A. L. Mateos 2345 Celaya 2-1 contadura
C34 Roci S. Guerrero 987 Celaya 2-0 contadura

Alumnos
1
= SL
especialidad = administracin
Alumnos

No-control Nombre domicilio ciudad edad especialidad
A32 Jos L. Morelos 234 Salamanca 20 administracin
A29 Adolfo A Jurez 199 Celaya 21 administracin
A99 Carmen G. A. L. Mateos 234 Celaya 19 administracin

52
Como se puede observar cada departamento es un sitio dentro de nuestra base de
datos distribuida, conteniendo un fragmento horizonte de la tabla global de acuerdo a
la especialidad.

Considrese, que se requiere una consulta en el departamento de administracin en
la cual se deben de obtener el nombre y domicilio de los alumnos de la carrera de
administracin que viven en la ciudad de Celaya, dicha consulta no tendra mayor
complicacin para el sistema de bases de datos, dado que el proceso se realizara de
manera local en el sitio de administracin.
Por lo tanto el DBMS local deber detectar que el procesamiento de la consulta se
debe de realizar sobre los datos locales y, que no hay necesidad de efectuar consultas
en otros sitios, esto seria como sigue:

PJ
nombre, domicilio
SL
especialidad = administracin
AND
ciudad = "Celaya
Alumnos

La cual sea traducida por el DBMS local, en el departamento de administracin a:

PJ
nombre, domicilio
SL
ciudad = "Celaya
Alumnos
3

nombre Domicilio
Adolfo A. Jurez 199
Carmen G. A. L. Mateos 234

Ahora supngase el caso de que el departamento de contabilidad requiere el nombre,
nmero de control y especialidad de los alumnos que tienen 21 aos o ms. Esta
consulta involucro a todos los fragmentos que se encuentran distribuidos en el sistema.
La consulta global sera de la siguiente manera:

PJ
no-control, nombre, especialidad
SL
edad>=21
Alumnos

La cual se traducira en el sistema distribuido de la siguiente manera:

53

PJ
no-control, nombre, especialidad
SL
edad>=21
(Alumnos
1
UN Alumnos
2
UN Alumnos
3
)

no control nombre especialidad
C54 Juan J. contadura
C78 Mario V. contadura
A29 dolfo A. administracin
D90 Adriana A. derecho

En la consulta es necesario realizar una unin entre los tres fragmentos existentes para
reconstruir la relacin global y as poder ejecutar la seleccin sobre totalidad de las
tuplas existentes en al base de datos.

El rbol de operaciones quedara de esta manera:

PJ
NO CONTROL, NOMBRE. ESPECIALIDAD

SL
EDAD >= 21

UN

ALUMNOS
1
ALUMNOS
2
ALUMNOS
3

En este punto se debe de considerar un aspecto muy importante en el
procesamiento de las consultas, sta no es la nica forma de realizar la consulta.
Existen varias formas de realizar la misma consulta, esto es, se podra variar el orden
de ejecucin de las operaciones o reemplazarlas por un conjunto de operaciones
equivalentes. Por ejemplo el siguiente rbol arroja el mismo resultado que el anterior:

54

PJ
NO CONTROL, NOMBRE. ESPECIALIDAD

UN

SL
EDAD >= 21
SL
EDAD >= 21
SL
EDAD >= 21

ALUMNOS
1
ALUMNOS
2
ALUMNOS
3

La diferencia que existe entre este rbol y el anterior no radica en el resultado de
las operaciones, sino en el costo de la ejecucin de las mismas. Es decir en el rbol
anterior los fragmentos eran transmitidos ntegramente a un sitio, por lo general es el
sitio que lanz la consulta, y en l se realizan todas las operaciones.
En este punto se debe de consideras el costo de la transmisin de los fragmentos y
el costa en la ejecucin de cada una de las operaciones dentro del sitio.
En el caso del segundo rbol, el costo de transmisin se reduce considerablemente
al transmitir nicamente los datos del fragmento que cumplen con la condicin del
select, y el costo de la ejecucin de las operaciones se distribuye en cada uno de los
sitios de la base de datos distribuida, ya que el select se realizara de manera local en
cada uno de los sitios, y la proyeccin, as como la unin, se realizaran en el sitio que
lanz la consulta.
Considrese ahora otro rbol de operaciones, en el cual se puede observar que la
mayor parte del proceso se realiza en los sitios y se deja al sitio que lanz la consulta
nicamente el trabajo de buscar en su fragmento y unir todos los datos que le sean
enviados por cada uno de los otros sitios. Obsrvese tambin que el costo de
transmisin se reduce considerablemente ya que no solo se envan nicamente los
dato que cumplen con la condicin del select, sino que tambin se reduce el nmero de
atributos de la relacin que se envan ( no se estaran enviando los atributos de
domicilio, ciudad y edad).

55

UN

PJ
no_CONTROL,
PJ
no_CONTROL,
PJ
no_CONTROL,
NOMBRE, ESPECIALIDAD



SL
EDAD >= 21
SL
EDAD >= 21
SL
EDAD >= 21

ALUMNOS
1
ALUMNOS
2
ALUMNOS
3

An cuando se tienen menos operaciones que realizar en el sitio que lanz la consulta,
se debe de considerar que se est generando una carga de trabajo para los dems
sitios, los cuales, posiblemente estn ejecutando sus propias consultas.
Por lo tanto, en el diseo de consultas se debe de considerar los costos en la
ejecucin de las operaciones, tanto locales como las que se ejecutarn en otros sitios,
esto quiere decir que, si existen sitios con mucha mayor potencia de computo que el
sitio en el cual se gener la consulta, y existe poca carga de trabajo en estos sitios,
convendr ms, que la mayor parte de las operaciones se realicen en dichos sitios y no
en el que gener la consulta-
Tambin se debe considerar el que posiblemente sea el costo ms importante en
una base de datos distribuida, el costo de la transmisin de los datos entre sitios, esto
dado que, los costos de transmisin son mucho mayores al transmitir dentro de una red
WAN, en la que tal vez se involucren transmisiones va telefnica o va satlite, que
entre sitios de una red LAN, la cual involucro transmisiones por medio de cables que
interconectan directamente los sitios.

56

2.4 Resumen
El diseo de una base de datos distribuida requiere de una planeacin de las
tcnicas y de la organizacin de dicha base de datos, esto, en cuanto al diseo de los
mltiples sitios. Los problemas principales seran la intercone)in de [os diferentes
sitios, as como la distribucin de los datos en dichos sitios.

El diseo de una base de datos distribuida consiste en:
1. Disear el esquema conceptual.
2. Disear el esquema fsico.
3. Disear la fragmentacin de los datos.
4. Disear la distribucin de los fragmentos.

Existen varios objetivos que una base de datos distribuida deber de lograr:

Procesamiento local: Debido a que los datos son colocados donde se necesitan, el
procesamiento local aumenta.

57
Disponibilidad y confiabilidad de los datos distribuidos: El almacenamiento de
mltiples copias en el sistema permite que las aplicaciones utilicen a cualquier otra
copia cuando la copia que era accesada normalmente no est disponible.
Distribucin de la carga de trabajo: La distribucin de la carga de trabajo se da a la
par de la distribucin de los datos y esto permite que exista un alto grado de
paralelismo en la ejecucin de las aplicaciones.
Disponibilidad y casto del almacenamiento: la distribucin de las bases de datos
refleja una reduccin en el costo del almacenamiento en los sitios.

Existen dos tcnicas de diseo de bases de datos distribuidas: La tcnica topdown y
la tcnica bottom-up. En la tcnica top-down se inicia diseando el esquema global y
la fragmentacin de los datos, continuando con la distribucin de los fragmentos en los
diferentes sitios, esta tcnica es utilizada cuando no e)dste base de datos alguna.

Cuando una base de datos distribuida se va a agregar a una base de datos ya
existente, la tcnica que se utiliza es bottom-top. Esta tcnica consiste en:

1. La seleccin del modelo de datos, para el diseo del esquema global de la base
de datos.
2. La traduccin de cada esquema local a un modelo de datos comn.
3. La integracin de los esquemas locales en el esquema global comn.

La fragmentacin permite determinar cuales sern las unidades lgicas de
distribucin. Las tuplas y atributos de la relacin por si mismos, no podrn ser
considerados como unidades lgicas de distribucin. El diseo de los fragmentos
consiste en agrupar tuplas y atributos que tengan las mismas propiedades lgicas.
Existen dos tipos bsicos de fragmentacin, la horizontal y la vertical, existe un
tercer mtodo de fragmentacin, el cual es la combinacin de los dos anteriores.
La fragmentacin horizontal consiste en dividir las tuplas de la relacin global en
subconjuntos de tuplas, donde cada subconjunto puede contener datos con
propiedades geogrficamente comunes. La fragmentacin se realiza, por lo general
por medios de una operacin select, mientras que la reconstruccin de la relacin
global siempre se llevara a cabo por medio de una operacin de union. Existe un
subtipo de fragmentacin horizontal conocida como fragmentacin horizontal derivada,

58
esta consiste en la fragmentacin de una relacin que no se puede basar en sus
propios atributos, pero se deriva de la fragmentacin de otra relacin.
La fragmentacin vertical de una relacin global es la subdivisin de sus atributos
en grupos; la fragmentacin se obtiene al proyectar la relacin global sobre cada
grupo. La reconstruccin de la relacin global se obtiene por medio de la operacin
join.
El tercer tipo de fragmentacin es la mixta, esta es obtenida por medio de
operaciones de fragmentacin realizadas de manera recursiva, y la reconstruccin se
realizara aplicando las operaciones respectivas en orden inverso de acuerdo a la
fragmentacin.

Despus de que se a realizado la fragmentacin de los datos, es necesario analizar
la forma en como se distribuirn dichos fragmentos, la manera ms fcil de realizar
esta operacin seria considerar cada fragmento como archivos separados, pero este
enfoque no es conveniente, por las siguientes razones:

1. Los fragmentos no son modelados propiamente como archivos individuales.
2. Habra ms fragmentos que relaciones globales, y seria difcil procesar la
solucin del problema al involucrar demasiadas variables.
3. El modelado del comportamiento de las aplicaciones en sistemas de archivos
difiere en demasa con relacin a las aplicaciones de bases de datos.

En la distribucin de los fragmentos es importante decidir si se va disear una
distribucin redundante o no redundante. La replicacin introduce una amplia
complejidad en el diseo, porque:
1. El grado de replicacin de cada fragmento llega a ser una variable del
problema.
2. El diseo de los mdulos de lectura de las aplicaciones es complicado por el
hecho de que las aplicaciones deben de seleccionar entre varios sitios para el
acceso del mismo fragmento.

Existen dos mtodos para determinar la redundancia en la distribucin de
fragmentos:

59
Determinar el conjunto de todos los sitios donde el beneficio de colocar una copia
del fragmento es mayor que el costo, y colocar un fragmento en cada uno de los
sitios de este conjunto.
Determinar primero la solucin sin replica del problema, y posteriormente introducir
replicas iniciando por las ms benficas; este proceso termina cuando una replica
no es benfica.

En el anlisis del procesamiento de consultas distribuidas, existe una herramienta
muy til llamada rbol de operadores, este rbol representa la secuencia en que se
realizan las operaciones de una consulta, en este rbol, las hojas son las relaciones
globales y cada nodo representa una operacin binaria o unitaria. Un rbol define un
orden parcial en como las operaciones se deben de aplicar para obtener el resultado
deseado en la consulta, esto es de abajo hacia arriba.


1.- Cuales son los cuatro pasos en el diseo de una base de datos distribuida?
2.- Mencione y describa los objetivos del diseo de datos distribuidos.
3.- Cundo es conveniente utilizar la tcnica bottom-up para disear una base
de datos distribuida?
4.- Explique brevemente en que consiste cada uno de los tipos de fragmentacin
que existen.
5.- Que representa y que partes conforman a un rbol de operadores?

2.6 Ejercicios

1.- Usando la tabla de clientes, realizar una fragmentacin horizontal, si las
aplicaciones son las siguientes:

q
1
: Obtener los nombres de todos los clientes.
q
2
: Obtener el nmero del cliente por estado.
q
3
: Obtener el nombre del cliente por empresa.

No_cli Nom_cli Empresa Estado
C01 Jurez Gamesa Gto
C02 Vidal Lara Qro
C03 vila Gamesa Jal

60
C04 Meja Lara Jal
C05 Herrera Lara Gto
C06 Cervantes Gamesa Qro

2.- Fragmentar horizontalmente la siguiente base de datos.
Clientes Productos
No_cli Nom_cli Edo No_p Nom_p Precio
C01 vila Gto P1 Lpiz 1.20
C02 Soria Gto P2 Libreta 3.50
C03 Avalos Qro P3 Lapicero 3.20
C04 Medina Mich P4 Borrador 1.50
C05 Trajo P5 Escuadra 3.10
C06 vila Qro P6 Plumones 15.20

Compras
No_cli Nom_cli Cant
C02 Pl 2
C01 P3 1
C02 P4 2
C01 P5 2
C03 P1 2
C03 P5 3

q1: Obtener el nmero del cliente por estado.
q2: Obtener el nmero y nombre de los clientes del estado de Jalisco.
q3: Obtener el estado de los clientes cuyo nombre sea vila,

3.- Usando la tabla de dientes, realizar una fragmentacin vertical, si las
aplicaciones son las siguientes:
q1: Obtener los nombres de todos los clientes.
q2: Obtener el nmero y nombre de los clientes por estado.
q3: Obtener el nombre de los clientes por empresa.

Matriz de accesos
S1 S2
q1 3 2
q2 2 1
q3 1 1

4.- Fragmentar verticalmente la siguiente tabla
A1 A2 A3 A4 A5 A6 A7 A8
No_al Nom_al Edad Dir Ciudad Sem Esp Prom
AL1 Aguilar 19 Rev. 115 Celaya 3 Qumica 85.7

61
AL2 Jimnez 18 Hgo. 120 Irapuato 1 Electrnica 83.2
AL3 Trejo 18 Rev. 315 Celaya 1 Sistemas 75.2
AL4 Soria 20 Hgo. 422 Len 4 Qumica 89.7

q1: Obtener el nmero de alumno por especialidad.
q2: Obtener nmero y nombre del alumno por ciudad.
q3: Obtener el nombre y edad por promedio.
q4: Obtener el nmero y semestre del alumno por direccin.

Matriz de accesos.
S1 S2 S3
q1 3 1 1
q2 2 0 1
q3 2 1 2
q4 3 5 1

Bibliografa

[1] Ceri, Stefano. Pelaggati, Giuseppe; 'Distributed Databases Principles and
systems'; lntemational Edition; MeGraw-Hill; U.S.A.; 1985

[2] Date, C,J.; "An Introduction to Databases Systems"; Volume 1; Fifth Edition;

[3] Date, C.J.; "An lntroduction to Databases Systems"; Volume li; Addison-Wesley

62

Objetivo
El alumno comprender el concepto optimizacin de consultas distribuidas y
entender las tcnicas para la ejecucin de la operacin join.

Introduccin
En este captulo se analizar el hecho de que an cuando se cuente con una buena
estrategia de fragmentacin o un buen procesamiento de consultas, no implica que se
tenga un funcionamiento correcto del sistema. Adems se tratara el concepto de
Captulo III

Optimizacin de estrategias de accesos

63
optimizacin de consultas, lo cual implica reducidas a una forma equivalente ms
pequea y fcil de manejar para el sistema, esto es, a su forma cannica. Tambin se
analizaran los diferentes mtodos de ejecucin de la operacin Join.

3.1 Importancia de la optimizacin de consultas

El trmino optimizacin es algo inapropiado, puesto que las' tcnicas para
optimizar la ejecucin de una consulta generalmente no lo logran y nicamente se
obtienen estrategias para un "buen acceso. Por eso, al referirse a este hecho como
optimizacin se debe de ser muy cuidadoso.
El desarrollo de una estrategia "buena" en el procesamiento de una consulta es
necesaria en un ambiente distribuido, pero tambin pueden existir estrategias para el
procesamiento de consultas "muy malas', las cuales se deben evitar. De esta manera,
la eficiencia del sistema final depende en mucho de la calidad del optimizador de
consultas, de la ausencia de un optimizador, y en la habilidad del programador de las
aplicaciones.

La seleccin de estrategias alternativas para la ejecucin de las consultas, tanto en
ambientes centralizados como distribuidos, es hecha de acuerdo al desempeo
requerido. Las medidas tpicas asumidas en un sistema centralizado de bases de
datos son el nmero de operaciones I/O y el tiempo de uso del CPU requerido para
realizar las consultas. En bases de datos distribuidas de debe considerar adems, el
costo de la transmisin de datos entre los sitios participantes de la consulta. No
obstante, no existe ningn convenio en la importancia relativa del costo de transmisin
contra I/O local. A pesar de esto, se deber de encontrar la sentencia que minimice el
costo de transmisin, lo cual es nuestra meta ms importante.

La seleccin de una estrategia de procesamiento de consultas involucro:

1 . Determinar las copias fsicas de los fragmentos sobre los cuales se ejecutar la
consulta, obteniendo una expresin de consulta sobre fragmentos..

64
2. Seleccionar el orden de ejecucin de las operaciones; como se puede ver, esto
involucro la determinacin de una buena secuencia de operaciones join, semi-
join y unin.
3. Seleccionar el mtodo para la ejecucin de cada operacin; esto involucro el
cambio de ejecucin de algunas operaciones algebraicas.

Los problemas anteriores no son independientes, por ejemplo, la eleccin de la
mejor materializacin para una consulta depende del orden en el cual son ejecutadas
las operaciones; por lo tanto, utilizar procedimientos para resolverlos de manera
independiente producira errores. No obstante, una manera fcil de obtener mtodos
de optimizacin consiste exactamente en considerar estos problemas como
independientes; de esta manera:

1. Una consulta dada se ejecuta sobre una sola copia no redundante de la base de
datos distribuida.
2. El orden de ejecucin de las operaciones es optima.
3. Las operaciones son agrupadas en los programas locales.

En la prctica, el primer problema no es tomado en cuenta, el tercer problema es
despreciable; por lo tanto solo se hace nfasis en el segundo problema.

3.2 Transformaciones equivalentes

Una consulta relacional puede expresarse utilizando diferentes lenguajes, para fines
de estudio, se utilizar lgebra relacionar y SQL, esto debido a que es posible
transformar una consulta SQL en expresiones equivalentes de lgebra relacional y
viceversa. Adems, no solo se pude interpretar una expresin de lgebra relacional
por sus especificaciones semnticas de una consulta, sino que adems se deber de
tomar en cuanta la secuencia de las operaciones. Desde este punto de vista, dos
expresiones con la misma semntica pueden describirse por medio de dos secuencias
de operaciones diferentes. Por ejemplo, considrese la siguiente relacin:

Emp(Cvemp, Nom, Sal, Imp, Depto)

65

Cvemp Nom Sal Imp Depto
E12 Juan Prez 4500 15 15
E56 Jos Hernndez 8756 15 9
E78 Luis Prez 9254 15 17
E98 Maria Sols 12345 25 22
E32 John Smith 25489 25 22
E91 Roci Snchez 4600 15 8
E73 Carmen Campos 8753 15 15

Se tiene las siguientes consultas:

PJ
Nom, depto
SL
depto=15
Emp

Nom Depto
Juan Prez 15
Carmen Campos 15

y

SL
depto = 15
PJ
Nom, depto
Emp

Nom Depto
Juan Prez 15
Carmen Campos 15

Son dos expresiones equivalentes, las cuales arrojan el mismo resultado, pero
definidas por dos secuencias de operadores diferentes.

Transformaciones equivalentes por lgebra relacional

66
Dos relaciones son equivalentes cuando sus tuplas representan el mismo mapeo
de los atributos a los valores, incluso si el orden de los atributos es diferente.

Considrense dos expresiones E
1
y E
2
de lgebra relacional, la equivalencia de dos
expresiones se representa E
1
E
2
.
Se podrn obtener transformaciones equivalentes sistemticamente ms pequeas,
es decir expresiones de dos o tres operadores relacionases. Estas transformaciones
son clasificadas en categoras de acuerdo a las operaciones que involucro. Sean U y
B operaciones unitaria y binaria respectivamente, R y S relaciones, entonces se tienen
las siguientes propiedades:

- Conmutatividad de operaciones unitarias:

U
1
U
2
R U
2
U
1
R

- Conmutatividad de operaciones binarias:

R B S S B R

- Asociatividad de operaciones binarias:

R B (S B T) (R B S) B T

- Idempotencia de operaciones unitarias:

U R U
1
U
2
R

- Distributividad de operaciones unitarias con respecto a operaciones binarias:

U ( R B S) U ( R ) B U (S)

- Factorizacin de operaciones unitarias:

U(R)BU(S) U(RBS)

67

Las siguientes son propiedades que tambin pueden ser aplicadas dentro de la
transformacin de expresiones:

R NJN R R
R UN R R
R DF R 0

R NJN SL
F
R SL
F
R
R UN SL
F
R R
R DF SL
F
R SL
NOT F
R

(SL
F1
R) NJN (SL
F2
R) SL
F1 AND F2
R
(SL
F1
R) UN (SL
F2
R) SL
F1 OR F2
R
(SLF, R) DF (SLF2 R) <-> SL
F1 AND NOT P2
R

3.2.2 Determinacin de subexpresiones comunes
Una parte importante en la transformacin de expresiones equivalentes es el
descubrir las subexpresiones comunes; las cuales aparecen en ms de una vez en la
consulta, esto es importante, ya que de esta manera solo se evaluara una sola vez
dicha expresin. Una forma de reconocer la existencia de dichas expresiones, consiste
en transformar la consulta en su correspondiente rbol de operadores. De esta
manera es posible localizar las subexpresines iguales, las cuales utilizan las mismas
operaciones y operandos, enseguida se unen tanto los nodos y las hojas en una sola
hoja o nodo.

En el siguiente ejemplo se ilustrara este mtodo. Considrese las siguientes tablas
de una base de datos:

68
EMP(id-emp, nom, sal, deptnum, edad)
DEPT(deptnum, descr, gtenum)

Se requieren los nombres de los empleados que trabajan en cierto departamento y
cuyo gerente tiene el nmero de 373 pero que no ganan ms de $35,000. Una
expresin para dicha consulta seria:

PJ
EMP.Nom
((EMP JN
DEPTNUM = DEPTNUM
SL
GTENUM=373
DEPT) DF
(SL
SAL>35000
EMP JN
DEPTNUM=DEPTNUM
SL
GTENUM=373
DEPT))

A simple villa se puede deducir que existe una subexpresin repetida en la
consulta, esta es:

EMP JN
DEPTNUM=DEPTNUM
SL
GTENUM=373
DEPT

Pero vase el rbol de operadores:
PJ
EMP_NOM

DF

JN
DEPTNUM=DEPTNUM
JN
DEPTNUM=DEPTNUM

EMP SL
GETNUM=373
SL
SAL>35000
SL
GETNUM=373

DEPT EMP DEPT

Se comienza factorizando el select sobre SAL con respecto al join (al hacer esto, el
select es desplazado hacia arriba).

69

PJ
EMP_NOM

DF

JN
DEPTNUM=DEPTNUM
SL
SAL>35000

EMP SL
GETNUM=373
JN
DEPTNUM=DEPTNUM

DEPT EMP SL
GETNUM=373

DEPT

A continuacin se unen los nodos correspondientes al select sobre GTENUM, el
nodo correspondiente al join y finalmente, uniendo las hojas correspondientes a las
relaciones de EMP y DEPT. El resultado de esto seria un rbol de operadores
simplificado como se muestra a continuacin:
PJ
EMP-NOM

EMP SL
GTENUM=373

DEPT

SL
SAL>35000

JN
DEPTNUM=DEPTNUM

DF

70

3.3 Mtodos de ejecucin de JOIN

En la ejecucin de una operacin join, se debe de considerar el costo de
procesamiento. En este punto influyen varios factores que se deben de tomar en
cuenta, para lograr la eleccin de la estrategia correcta, dichos factores son:
- El orden fsico de las tuplas en la relacin.
- La presencia de ndices y el tipo de estos.
- El costo de creacin de un ndice temporal para el procesamiento de una
consulta

Para el resto de la seccin se considerar la siguiente expresin:

deposito JN cliente

Y se asumir que la relacin deposito cuenta con 10,000 tuplas y clientes consta de
200 clientes.

3.3.1 Iteracin simple
Supngase que no se cuentan con ndices, y que es necesario examinar todos los
pares posibles de tuplas td en depositas y tc en cliente. De esta manera, se
examinarla 10000 * 200 = 2000000 pares de tuplas.
Si se ejecutar esta consulta de una manera ms optima, se reducira
significativamente el nmero de bloques accesados ( considrese un bloque como un
conjunto fsico de tuplas ). Supngase que se utiliza el siguiente procedimiento para
procesar el join. En l se lee cada tupla de la relacin deposito, esto requerira accesar
10000 bloques de almacenamiento fsico bajo el peor de los casos, considerando que
cada una de las tuplas de la relacin deposito se encuentran en bloques diferentes. Si
se consideran que 20 tuplas de la relacin deposito se encuentran almacenadas en un
bloque, entonces se tendrn 10000120 = 500 bloques distintos accesados.

71

for each tupla d in deposito do
begin
for each tupla c in cliente do
begin
compara el par (d, c) para ver si alguna tupla es agregada
al resultado final
end
end

Si se compara cada tupla de clientes con cada una de las tuplas de la relacin
deposito, esto llevar a hacer 10,000 referencias a cada tupla de clientes. El nmero
exacto de accesos a disco depende del tamao del buffer y de otros factores. En el
peor de los casos cada consulta requerir de un acceso a disco. Puesto que se tienen
200 tuplas en la relacin de clientes, se tendrn que hacer 2,000,000 lecturas a la
relacin de clientes. Si se asume que 20 tuplas de la relacin clientes son
almacenadas en un bloque, entonces se requieren de 10 accesos para leer la relacin
completa, Por lo tanto, solo se requieren 10 accesos en lugar de 200. Esto implica que
se accesarn 100,000 bloques de la tupla clientes para procesar la consulta.
El costo de esta tcnica es de 500 accesos a depsitos ms 100,000 accesos a
clientes para un total de 100,500 bloques accesados.

3.3.2 Iteracin orientada a bloques

Se obtiene un mayor ahorro en el acceso si se procesa la relacin en base a un
proceso por bloques en vez de un proceso basado en tuplas. Nuevamente, se asume
que las tuplas de la relacin depsitos y de la relacin clientes son almacenadas de
manera continua tambin, Se usar el procedimiento siguiente para procesar depsitos
JN clientes.

For each bloque Bd of deposito do
begin
for each bloque Be of dientes do

72
begin
for each tupla d in Bd do
begin
for cach tupla e in Be do begin
compara el par (d,c) para ver s una tupla
puede ser tomada para el resultado
end
end
end
end.

Este procedimiento desarrolla el join considerando un bloque entero de tuplas de la
relacin deposito en vez de una tupla individual- An, se leer completa la relacin
deposito a un costo de 500 accesos. Sin embargo, en lugar de realizar una lectura a la
relacin cliente por cada tupla de la relacin deposito, se leer la relacin cliente por
cada bloque de la relacin deposito. Entonces, se tienen 500 bloques- de la relacin
deposito y 10 bloques de la relacin diente, requieren 10*500= 5000 bloques
accesados. De esta manera, el costo en trminos de bloques accesados es de 5500
accesos (5000 accesos a clientes ms 500 accesos a dep>sitos). Claramente se
puede ver un significativo ahorro en el nmero de accesos necesarios en comparacin
con la tcnica anterior.

3.3.3 Merge - Join
En aquellos casos en los cuales ninguna relacin se encuentra en la memoria
principal, es posible realizar un join eficientemente si ambas relaciones se encuentran
almacenadas en orden de acuerdo a un atributo por medio de[ cual se realizara el join.

Supngase que ambas relaciones, clientes y depsitos, estn ordenados por
nombre-cliente. Se podr entonces realizar una operacin merge-join.

Para ejecutar un merge-join, se requiere de un punto de asociacin en cada
relacin, Estos puntos son direccionados a la primera tupla de cada relacin. Los

73
punteros son movidos a lo largo de la relacin y si un grupo de tuplas de la relacin
contiene el mismo valor que el atributo del join, se leen dichas tuplas, puesto que las
tuplas estn ordenadas, el conjunto de tuplas con el mismo valor estarn consecutivas.
Esto permite leer cada tupla una sola vez y en el caso de que las tuplas estn
almacenadas de manera ordenada, entonces se leer cada bloque exactamente una
vez.

A continuacin se muestra el esquema del merge-join aplicado al ejemplo de
deposito JN cliente.

Pd := direccin de la primera tupla de deposito;
Pc:= direccin de la primera tupla de clientes;
while (pc nuil) do
begin
tc:= tupla ala cual pc apunta;
sc {tc}
mueve pc a la siguiente tupla en cliente;
done := falso;
while (not done and pc nuil ) do
begin
tc' := tupla a la cual pc apunta;
if tc[nombre-Cliente] = tc'[nombre-Cliente]
then begin si := se u {tc'};
mover pc a la siguiente tupla de cliente;
end
else done:= verdad;
end
td := tupla a la cual pd apunta;
mueve pd a la siguiente tupla;
while ( td[nombre-Cliente] < tc[nombre-Cliente]) do
begin
td := tupla a la cual pd apunta;
mueve pd a la siguiente tupla de deposito;

74
end
while (td[nombre-Clientel = tc[nombre-Cliente]) do
begin
for each t in sc do
begin
ejecuta t JN td y agrega esto al resultado final;
end
mueve pd a la siguiente tupla de deposito;
td := tupla a la cual pd apunta; end
end.

Una desventaja de este mtodo es que ambas relaciones deben de estar ordenadas
fsicamente, es decir en el medio de almacenamientos.

3.3.4 Uso de ndices
Las tres estrategias que se han considerando dependen de la tcnica usada para
almacenar fsicamente las relaciones. El merge-join requiere de un almacenamiento
en orden. La iteracin orientada a bloques requiere que las tuplas de cada relacin
estn ordenadas fsicamente. nicamente la iteracin simple, puede ser aplicada sin
importar la forma en como estn almacenadas las tuplas de las relaciones. El costo de
la iteracin simple para el ejemplo deposito JN diente es de 2 millones de accesos a
bloques. Cuando se utiliza un ndice, sin importar la manera en como fueron
almacenadas fsicamente las tuplas de las relaciones, el join puede ser ejecutado con
una reduccin de accesos significativa.
Frecuentemente los atributos del join forman parte de la llave del ndice de una
relacin. En estos casos se puede considerar una estrategia de join que utiliza estos
ndices. La iteracin simple puede ser ms eficiente si e>iste un ndice en la relacin
cliente para el atributo nombre ~ cliente. Cuando se tiene una tupla d de la relacin
deposito no es necesario recorrer la relacin clientes completa. El ndice es usado
para buscar las tuplas en clientes para los cuales el nombre-cliente sea igual a
d[nombre-clientel.
Se requieren 10000 accesos para leer la relacin deposito. Si se asume que la
relacin clientes tiene 200 tuplas, y que se almacenan 20 apuntadores por bloque,

75
entonces, se requieren en promedio 2 accesos a bloques ms un bloque accesado
para leer la relacin cliente. Con esto, son necesarios 3 accesos a bloques en la
relacin deposito en lugar de 200. Entonces, si por cada tupla de la relacin deposito
son necesarios 3 accesos a bloques dara como resultado un total de 30000 accesos,
ms los 10000 de la relacin deposito.
Aunque un costo de 40000 accesos pareciera alto, se debe tomar en cuenta que se
obtendra un mejor resultado solo si las tuplas estn ordenadas fsicamente, Tambin
se debe recordar que inicialmente, esta estrategia, tiene un costo de 2 millones de
accesos a bloques.
Entonces el hecho de obtener un ahorro tan alto de accesos es suficiente para
justificar la creacin de ndices.

3.3.5 Hash join
La construccin de un ndice para la ejecucin de un join, convendra, si este ndice
es un rbol B+. Dicho ndice sera usado una sola vez para la ejecucin de un simple
join.
Una funcin hash h es usada sobre las tuplas de ambas relaciones sobre los
atributos bsicos del join. Si d es una tupla de la relacin deposito y en c es una tupla
de la relacin clientes entonces d y c sern comparados solo si h(c) = h(d). Si h( c )
h( d ) , entonces d y c tendrn valores diferentes para nombre-cliente. Sin embargo es
posible que d y c tengan valores diferentes para nombre-cliente a pesar de que sus
valores en la funcin hash sean iguales.
A continuacin se muestra el algoritmo usado para el hash join que se aplicara en el
ejemplo deposito JN cliente.

for each tupla c in cliente do
begin
i := h(c[nombre-Cliente]);
Hci := Hci u {apuntador a c},
end

76
for each tupla d in deposito do
begin
i := h(d[nombre-cliente]);
Hdi := Hdi @ {apuntador a d};
end
for i := 0 to max do
begin
rc:= 0;
rd:= 0;
for each apuntador pc in Hci do
begin
c:= tupla a la cual apunta pc;
rc:= rc u {c ;
end
for each apuntador pd in Hdi do
begin
d:= tupla a la cual apunta pd;
rd := rd u {d};
end
for each tupla d in rd do
begin
for each tupla c in rc do
begin
compara el par (d,c) para ver si una tupla puede ser agregada al resultado
end
end

77
end

En el algoritmo anterior, se asume que:

- h es una funcin hash que mapea valores de nombre-cliente con {0,1,2,...,max)

- H
c0
, H
c1
, ... , H
cmax
denotan el contenedor del apuntador a las tuplas de la
relacin diente, cada uno vaco al inicio.

- H
d0
, H
d1
, ... , H
dmax
denotan el contenedor del apuntador a las tuplas de la
relacin deposito, cada uno vaco al inicio.

Se usarn estas propiedades para estimar el costo del desempeo de un hash join.

La asignacin de apuntadores a los contenedores hash en los primeros dos ciclos
for del algoritmo generan una lectura completa de ambas relaciones.

El costo de esta operacin es de 510 accesos a bloques si las tuplas de ambas
relaciones, clientes y deposito, son almacenadas de forma continua fsicamente.
Desde el momento en que los contenedores almacenan solo apuntadores se asumir
que se encuentran en la memoria principal, y por lo tanto no es necesario ningn
acceso a disco para leer dichos contenedores.
En la parte final del algoritmo se itera sobre el rango de h. Donde i es un valor del
rango de h. El ciclo for final ejecuta:

rd JN rc

Donde el conjunto rd es el conjunto de las tuplas de la relacin deposito en el
contenedor i y rc es el conjunto de tuplas de la relacin clientes localizadas en el
contenedor i. Este join es procesado utilizando una iteracin simple, ya que rd y rc son
lo suficientemente pequeos, ambos pueden estar en la memoria principal. Desde el

78
momento que se aplico una funcin hash a una tupla y esta se coloco en un
contenedor, cada tupla es leda una sola vez por el for final en el algoritmo.

Cabe hacer notar que lo anterior requiere 510 accesos a bloques inicialmente. As,
el costo total estimado de un hash join es de 1020 accesos, se requiere una lectura
para la funcin hash, y una segunda lectura dentro de los contenedores. Es necesario
elegir una funcin hash cuyo rango sea lo suficientemente extenso para que cada
contenedor almacene la menor cantidad de apuntadores posible.

3.3.6 Tree - way join
Ahora supngase que un join envuelve tres relaciones:

sucursal JN deposito JN cliente

Se asume que ndd. = 10000, n,ii,,t, = 200 y n....., = 50. No solo se tiene que
considerar la estrategia para procesar el join; sino que ahora se debe ver cual se
realizara primero- Hay varias estrategias posibles a utilizar.

Estrategia 1: Se procesa el join deposito JN cliente usando alguna de las
tcnicas antes mencionadas. Considerando que nombre - cliente es la
llave para la relacin clientes. Es posible saber que el resultado de este
join, tiene a lo ms 10000 tuplas ( nmero de tuplas en la relacin
deposito). Si es posible construir un ndice para sucursal sobre el atributo
nombre-sucursal, se podra procesar lo siguiente:

sucursal JN (deposito JN cliente)

Considerando que nombre - sucursal es la llave para sucursal es posible
saber que se examinarn nicamente una tupla de la relacin sucursal

79
para cada una de las 10000 tuplas de la operacin deposito JN cliente. El
nmero exacto de bloques accesados en esta estrategia depende de la
manera en que la operacin deposito JN cliente es ejecutada, y la forma
en que la relacin sucursal es almacenada fsicamente.

Estrategia 2: Es posible ejecutar el join con las tres relaciones sin utilizar ndices. Esto
requerir el acceso de 50 * 10000 * 200 posibilidades, es decir un total de
10000000.

Estrategia 3: En lugar de procesar dos joins, es posible hacer el proceso de un par de
joins en uno solo. La tcnica primero requiere la construccin de dos
ndices:

- En sucursal con nombre-sucursal.
- En cliente con nombre-cliente.

A continuacin se considera para cada tupla t en la relacin deposito,
las correspondientes tuplas dentro de las relaciones clientes y sucursal.

As, se examinar por cada tupla en deposito - una sola en las otras
dos relaciones.

La estrategia 3 presenta una forma de realizar una operacin que no tiene una
correspondencia directa dentro del lgebra relacionar. En cambio, combina 2
operaciones dentro de una operacin especial. El costo relativo depende de la forma
en como las relaciones son almacenadas fsicamente.

3.3.7 Estrategias para procesamiento paralelo
Las estrategias antes consideradas asumen que un solo procesador esta disponible
para procesar un join. Ahora se vera el caso donde varios procesadores estn
disponibles para el procesamiento paralelo de un join.

80

Antes que nada se debe considerar que:

- Todos los procesadores tienen acceso a todos los discos.
- Todos los procesadores comparten la memoria principal.

Las tcnicas que se presentarn a continuacin pueden ser adaptadas en otras
arquitecturas en las cuales cada procesador tiene su propia memoria privada.

3.3.8 Join paralelo
En las tcnicas antes mencionadas para el procesamiento de un join en un
procesador solo, la eficiencia se logra reduciendo el nmero de pares de tuplas que
son comparadas. La meta de un algoritmo de join paralelo es dividir los pares de
tuplas entre varios procesadores. Cada procesador entonces ejecuta una parte del
join. En un paso final, el resultado individual de cada procesador es recolectado para
producir el resultado final.
Idealmente, el trabajo global para procesar el join es dividido equivalente sobre
todos los procesadores. Esto sin que ningn procesador caiga en un overhead. Un
join paralelo que utiliza N procesadores, tomar 1/N del tiempo que se tardara en
ejecutar el mismo join en un solo procesador. En la practica la velocidad es ms
dramtica por varias razones:
- Un overhead ocurre en la particin del trabajo entre procesadores.
- Un overhead ocurre en la recoleccin de los resultados arrojados por cada uno
de los procesadores, para producir el resultado final.
- El esfuerzo hecho para dividir el trabajo equitativamente es una aproximacin,
ya que algunos procesadores, tienen ms trabajo que otros. El resultado final
obtenido hasta que el ltimo procesador haya terminado.
- El procesador tal vez tenga que competir por recursos compartidos del sistema.
El resultado se retrasa debido a que un procesador espera a que otro
procesador libere los recursos.

81
Considerando nuevamente el ejemplo deposito JN cliente, se asume que se tiene N
procesadores P
1
, P
2
, ..., P
N
. Se divide la relacin de deposito en N partes de igual
tamao; deposito
1
, deposito
2
, ..., deposito
N
Se supone, por facilidad, que el tamao de
la relacin deposito es mltiplo de N, entonces cada procesador P
i
procesa deposito
i

JN cliente en paralelo. En el paso final, se realizara la unin de los resultados
parciales obtenidos por cada procesador.

El costo de esta estrategia depende de vados factores:

- La seleccin del algoritmo usado para cada procesador.
- El costo de la construccin del resultado final.
- El retraso generado por la retencin de recursos. Aunque cada procesador
accesa su propia particin de la relacin deposito, todos los procesadores
accesan a la relacin cliente. Si la memoria principal no es suficientemente
grande para almacenar la relacin cliente, el procesador necesita sincronizar
sus accesos a la relacin cliente con otros procesadores para reducir el nmero
de accesos a disco.

Se sugiere que se utilice alguna tcnica para realizar la divisin del trabajo entre
procesadores para reducir el espacio utilizado de memoria. Una tcnica simple es la
de utilizar una versin de hash-join para trabajar en paralelo. En donde se escoger
una funcin hash cuyo rango sea { 1, 2, ..., N }. Esto dara como resultado, que cada
procesados trabaje con exactamente un contenedor hash.

3.3.9 Pipeline multiway join
Existe la posibilidad del procesamiento de varios joins en paralelo. Esto es un uso
importante en algunos queries que se realizan en el mundo real, particularmente
cuando se tienen vistas, que involucran a varias relaciones.
Considere el siguiente join entre cuatro relaciones:

r
1
JN r
2
JN r
3
JN r
4

82
Es posible ejecutar t
1
(r
1
JN r
2
) en paralelo con t
2
(r
3
JN r
4
) y cuando este proceso
termine se ejecutar:

t
1
JN t
2

Se puede lograr un alto grado de paralelismo si se tiene un "pipeline" que permita a
los tres join ejecutarse en paralelo. Se asigna al procesador P
1
la ejecucin de r
1
JN r
2

y al procesador P
2
se asigna r
3
JN r
4
.
Como las tuplas resultantes del proceso de P
1
estn disponibles para P
3
, as como
las tuplas resultantes del procesador P
2
, entonces P
3
podr comenzar el proceso ( r
1

JN r
2
) JN (r
3
JN r
4
) antes de que r
1
JN r
2
y r
3
JN r
4
hallan terminado.

A continuacin se muestra el algoritmo utilizado por el procesador P
3
para procesar
el join. Las tuplas resultantes de P
1
y P
2
son colocadas en una cola para ser
procesados por P
3
, P
1
y P
2
pueden haber utilizado cualquier tcnica para el
procesamiento del join. La nica modificacin sera que cuando una tupla t es
adicionada al resultado, debe de colocarse como disponible para P
3
en la cola. Se
deber considerar tambin, entradas especiales en la cola que consisten ENDP1 y
ENDP2, que indican la finalizacin del procesamiento del join en los procesadores P
1
y
r
1

r
2

r
3

r
4

P
1

P
3

P
2

83
P
2
respectivamente. Para ejemplo se utilizo un 4-way join pero pude extenderse para
procesar N-way join.

done1:= falso;
done2:= falso;
from1:= 0;
from2:= 0;
result := 0 ;
while not donel or not done2 do
begin
if la cola esta vaca then esperar hasta que no este vaca;
t:= primer elemento de la cola;
if t = ENDP1 then donel := verdadero
else if t = ENDP2 then done2:= verdadero
else if t proviene de Pl then
begin
from1:= from1 {t};
result:= result ({t} JN from2);
end
else /* t proviene de P2 */
begin
from2 := from2 {t};
result := result (from1 JN {t});
end
end

3.4 Principios de optimizacin
Se pueden identificar cuatro pasos generales para el proceso de optimizacin de
una consulta.

84

1.- Convertir la consulta en alguna representacin interna.
El primer paso en el proceso de una consulta es convertirla en alguna
representacin interna que sea ms apropiada para la manipulacin de la
computadora, eliminando as, las consideraciones del nivel externo (tales como los
rasgos concretos de la sintaxis de un lenguaje de consulta), preparando as el
camino para los subsecuentes pasos de la optimizacin.
Se deber hacer una eleccin de manera que se represente a la consulta por
medio del lenguaje que pueda manejar el sistema de manera que los pasos
subsecuentes no se vean afectados. Por ejemplo, se tiene la consulta "obtener los
nombre de los proveedores que surten la pieza P2', es posible representar esto en
un rbol de operadores:

PJ
Pnombre

SL
provee.p#=P2

JN

Proveedor Provee

Esto da como resultado una expresin, dentro del lgebra relacional que se puede
manejar ms fcilmente por el sistema:

PJ ( SL ( Proveedor JN Provee )
provee.p#=P2
)
nombre

2.- Convertir a forma cannica.

85
La definicin de forma cannica es el punto central en muchas reas de las
matemticas y disciplinas relacionadas. Es posible definirla como sigue: Se tiene un
conjunto Q de objetos (Queries) y la definicin de equivalencia entre ellos (dos queries
son equivalentes, si y solo si, producen el mismo resultado), se tiene tambin un
subconjunto C de Q, el cual se llama conjunto de formas cannicas de Q ( bajo la
definicin de equivalencia ), si y solo si, algn objeto q en Q es equivalente a solo un
objeto c en C. El objeto c es llamado la forma cannica de q. Todas las propiedades
que se aplican a q se aplican a la forma cannica c; As, es suficiente realizar el
estudio del pequeo conjunto de formas cannicas, y no del gran conjunto de Q.
Durante este paso, el optimizador ejecuta un nmero de transformaciones que son
"garantizadas para ser correctas', en relacin con los datos actuales y las rutas de
acceso que existen en la base de datos. El punto es que la mayora de los lenguajes
de consulta permiten que hasta la ms simple consulta pueda ser expresada en una
variedad de formas distintas. Tan solo en SQL, la consulta de la seccin anterior tiene
ocho posibles representaciones.
La obtencin de expresiones equivalentes se logra por medio de reglas de
transformacin bien definidas y permitidas dentro del lgebra relacionar.

3.- Elegir el procedimiento de bajo nivel.
Habiendo convertido la representacin interna de la consulta en alguna forma ms
deseable (forma cannica), se debe decidir como se evaluar la consulta, representada
por su forma cannica.
En este paso se debe considerar la existencia de ndices, rutas de acceso,
distribucin de los datos almacenados, almacenamiento fsico de los registros, etc.
La estrategia bsica es considerar la consulta como una serie de operaciones de
"bajo nivel" join, select, project, etc.), con cierta interdependencia entre ellos. Para
cada operacin de bajo nivel, se tendr un conjunto de procedimientos predefinidos;
Por ejemplo, un conjunto de procedimientos para la seleccin sera, un procedimiento
para cuando los campos estn indexados, y otro para cuando no lo estn, pero estn
almacenados fsicamente en orden, etc. Cada procedimiento tiene asociado un costo.

86
4.- Seleccionar el procedimiento ms econmico.
El paso final del proceso de optimizacin involucro la construccin de un conjunto
de planes de ejecucin de consultas candidatas seguido de la eleccin del mejor (ms
econmico) de estos planes.
Cada plan es construido con la implementacin de los procedimientos necesarios
para ejecutar la consulta. Ser necesario un procedimiento por cada operacin de bajo
nivel en la consulta. No es necesario construir todos los planes posibles, basta con
generar una cantidad razonable de procedimientos y realizar combinaciones entre ellos
y seleccionar el conjunto ms econmico para la ejecucin de la consulta. La
asignacin del costo a algn plan involucrar el nmero de accesos a disco, la
utilizacin del CPU, etc.
Dentro del costo de una consulta tambin deber tomar en cuenta la transmisin de
los datos dentro del sistema en el cual se lleva a cabo dicha consulta. Es importante
recordar que dentro de un sistema de bases de datos distribuidas, la informacin se
encuentra dispersa dentro de varios servidores y es utilizada por muchos clientes, los
cuales pueden estar a corta distancia de los servidores o muy alejados de estos.
Cuando una consulta es lanzada en un sistema de bases de datos distribuidos, en ese
momento es posible saber que informacin se requiere y en que sitio se encuentra.
Entonces se debe decidir la forma en que se realizar el proceso de recoleccin de
datos. Es decir, la tabla es enviada ntegramente al sitio que lanzo la consulta o solo
los registros que cumplen con la condicin, tal vez es necesario que otro sitio realice el
proceso de recoleccin de resultados parciales y solo se reciba el resultado final o si el
sitio que lanzo la consulta, realice el proceso integro, etc.
En un sistema distribuido de bases de datos, el costo ms alto es el de la
comunicacin, por ello es necesario utilizar estrategias para reducirlo. Como se vio en
el captulo anterior (Ejemplos de consultas distribuidas), es necesario considerar, de
cierta forma, la capacidad de procesamiento de los equipos para decidir que equipo o
equipos realizaran los procesos ms demandantes.

87

3.5 Resumen

El desarrollo de una buena estrategia en el procesamiento de una consulta es
necesario en un ambiente distribuido, la eficiencia del sistema final depende mucho de
la calidad del optimizador de consultas. La seleccin de estrategias alternativas para la
ejecucin de las consultas, tanto en ambientes centralizados como distribuidos, es
hecha de acuerdo al desempeo requerido. Las medidas tpicas asumidas en un
sistema centralizado de bases de datos son el nmero de operaciones I/O y el tiempo
de uso del CPU requerido para realizar las consultas. En bases de datos distribuidas
de debe considerar adems, el costo de la transmisin de datos entre los sitios
participantes de la consulta.

88

La seleccin de una estrategia de procesamiento de consultas involucro:
1. Determinar el nmero de copias de los fragmentos sobre los cuales se
ejecutara la consulta, obteniendo una expresin de consulta sobre
fragmentos.
2. Seleccionar el orden de ejecucin de las operaciones.
3. Seleccionar el mtodo para la ejecucin de cada operacin.

Una expresin de lgebra relacional no solo se expresa por medio de sus
especificaciones semnticas, sino tambin por medio de una secuencia de operadores,
y desde este punto de vista dos expresiones con la misma semntica se pueden
expresar por medio de dos secuencias de operadores diferente, esto conlleva a decir
que estas dos expresiones son equivalentes. Dos expresiones son equivalentes
cuando sus tuplas representan el mismo mapeo de los atributos a los valores, aun
cuando el orden de los atributos no sea el mismo. La equivalencia de dos expresiones
se representa por El E2.
Es posible obtener expresiones equivalentes pequeas aplicando ciertas
propiedades de operadores y conjuntos de operadores. Sea U y B operaciones
unitaria y binaria respectivamente, R y S relaciones. Se tienen las siguientes
propiedades:

- Conmutatividad de operaciones unitarias:
U
1
U
2
R U
2
U
1
R

- Conmutatividad de operaciones binarias:
R B S S B R

- Asociatividad de operaciones binarias:
R B (S B T) (R B S) B T

- Idempotencia de operaciones unitarias:
U R U
1
U
2
R

89

- Distributividad de operaciones unitarias con respecto a operaciones binarias:
U(RBS) U(R)BU(S)

- Factorizacin de operaciones unitarias:
U ( R ) B U ( S U R B S

Las siguientes son propiedades que tambin pueden ser aplicadas dentro de la
transformacin de expresiones:

R NJN R R
R UN R R
R DF R 0

R NJN SL
F
R SL
F
R
R UN SL
F
R R
R DF SL
F
R SL
NOT F
R

(SL
F1
R) NJN (SL
F2
R) SL
F1 AND F2
R
(SL
F1
R) UN (SL
F2
R) SL
F1 OR F2
R
(SLF, R) DF (SLF2 R) <-> SL
F1 AND NOT P2
R

Una parte importante en la transformacin de expresiones equivalentes es el
descubrir subexpresiones comunes, las cuales podran aparecer ms de una vez en la
consulta, esto es importante, dado que, solo se tendran que evaluar una sola vez,
ahorrando as, tiempo. Una manera de reconocer la existencia de dichas expresiones,
consiste en transformar la consulta en su correspondiente rbol de operadores, de esta
manera es posible localizar las subexpresiones iguales, que en este caso seran ramas
similares, las cuales se convertirn en una sola rama.
Algo que tambin se debe de considerar es el costo de procesamiento de las
operaciones join. En esta parte influyen varios factores, los cuales se debern tomar
en cuenta:

- El orden fsico de las tuplas en la relacin.

90
- La presencia de ndices y el tipo de los mismos.
- El costo de procesamiento de un ndice temporal para el procesamiento de una
consulta.

Dentro de las tcnicas de ejecucin de join se tiene las siguientes:

Iteracin simple: Cada una de las tuplas de una relacin es comparada con todas las
tuplas de la otra relacin.

Iteracin orientada a bloques: Se asume que las tuplas de la relacin estn
almacenadas en orden y de manera continua. Esta tcnica leer un bloque de tuplas
en lugar de una tupla individual, as se compara un bloque de una relacin contra los
bloques de la otra relacin.

Merge-join: Esta tcnica requiere que las tuplas estn almacenadas de forma ordenada
de acuerdo al atributo por el cual se va a realizar el join. Cada relacin tendr un
puntero que indica la posicin de lectura para el join, al ir leyendo, dichos punteros
avanzarn. Al encontrarse la tupla que tiene el mismo valor que la tupla con la que se
esta ejecutando el join, el recorrido sobre la relacin se detiene y el puntero se coloca
de nuevo en la primera posicin, esto debido a que las tuplas estn ordenadas y no
debe existir otro valor ms all de la posicin del puntero. Se repetir este proceso
hasta que se recorran todas las tuplas de la primera relacin.
Hash-join: Una funcin hash h es usada sobre las tuplas de ambas relaciones
sobre los atributos bsicos del join. Si d es una tupla de la relacin deposito y en c es
una tupla de la relacin clientes entonces d y c sern comparados solo s h(c) = h(d). Si
h(c) h(d), entonces d y c tendrn valores diferentes para los atributos bsicos del
join. Sin embargo es posible que d y c tendrn valores diferentes para los atributos
bsicos del join a pesar de que sus valores en la funcin hash sean iguales.

Tree-way join: Si se tiene que un join envuelve tres relaciones, se podran utilizar
algunas de las siguientes estrategias:

91
1 . Se procesa el join con cualquier tcnica, si es posible se deber construir un
ndice sobre los atributos bsicos del join, se procesarn primero un par de
relaciones y el resultado de este join se procesara con la tercer relacin,
obteniendo as el resultado final.
2. Es posible ejecutar el join con las tres relaciones sin utilizar ndices.
3. En lugar de procesar dos joins, es posible hacer el proceso de un par de joins
en uno solo. Esto requerir la utilizacin de ndices.

Join paralelo: La meta de un algoritmo de join paralelo es la de dividir los pares de
tuplas entre varios procesadores. Cada procesador ejecutar una parte del join. En un
paso final, el resultado individual de cada procesador es recolectado para producir el
resultado final. El trabajo global para procesar el join ser dividido lo ms
equitativamente posible, tratando de que ningn procesador caiga en un overhead.

Pipeline multiway join: Existe la posibilidad de procesar varios joins en paralelo.
Considrese el siguiente join entre cuatro relaciones:

r
1
JN r
2
JN r
3
JN r
4

Es posible ejecutar t
1
(r
1
JN r
2
) en paralelo con t
2
(r
3
JN r
4
) y cuando este proceso
termine se ejecutar:
t
1
JN t
2

Se puede lograr un alto grado de paralelismo si se tiene un "pipeline" que permita a
los tres join ejecutarse en paralelo. Se asigna al procesador P
1
la ejecucin de r
1
JN r
2

y al procesador P
2
se asigna r
3
JN r
4
.

92
Como las tuplas resultantes del proceso de P
1
estn disponibles para P
3
, as como
las tuplas resultantes del procesador P
2
, entonces P
3
podr comenzar el proceso (r
1

JN r
2
) JN (r
3
JN r
4
) antes de que r
1
JN r
2
y r
3
JN r
4
hallan terminado. Las tuplas
resultantes de P
1
Y P
2
son colocadas en una cola para ser procesadas por P
3
, para
obtener el resultado final.

Se tienen cuatro pasos generales en el proceso de optimizacin de una consulta:
1. Convertir la consulta en alguna representacin interna: El primer paso en el
proceso de una consulta es convertirla en una representacin interna que sea
ms apropiada para la manipulacin de la informacin, esto de manera que los
pasos subsecuentes no se vean afectados.

2. Convertir a una forma cannica: Se tiene un conjunto Q de objetos (Queries)
y la definicin de equivalencia entre ellos (dos queries son equivalentes, si y
solo si, producen el mismo resultado), se tiene tambin un subconjunto C de
Q, el cual se llama conjunto de formas cannicas de Q (bajo la definicin de
equivalencia), si y solo si, algn objeto q en Q es equivalente a solo un
objeto c en C. El objeto c es llamado la forma cannica de q. Lo importante
en este punto, es que, la mayora de los lenguajes de consulta permiten
representar una consulta en varias formas distintas. As, la obtencin de
expresiones equivalentes se logra por medio de reglas de transformacin
definidas y permitidas dentro del lgebra relacional.
3. Elegir el procedimiento de bajo nivel: Se deber decidir como se evaluara la
consulta, representada por su forma cannica, aqu, la estrategia bsica es
considerar la consulta como una serie de operaciones de bajo nivel, para
cada operacin se tendr un conjunto de procedimientos predefinidos.
4. Seleccionar el procedimiento ms econmico: El paso final es la contraccin
de un conjunto de planes de ejecucin de consultas candidatas seguidas de
la eleccin del mejor de los planes. Dentro del costo de una consulta
tambin deber tomarse en cuenta la transmisin de los datos dentro del
sistema en el cual se llevara a cabo la consulta. Cuando una consulta es
lanzada dentro de un sistema de bases de datos distribuidas, es posible
saber que informacin se requiere y en que sitio se encuentra. Entonces se
deber de disear una estrategia de recoleccin de datos. Es necesario

93
recodar que dentro de un sistema de bases de datos distribuidas el costo
ms alto es el de la comunicacin, por lo tanto de deben de utilizar las
estrategias que minimicen este costo en lo posible.


1.- Cuales son los tres puntos que se deben tomar en cuanta en la optimizacin
de una consulta?
2.- Mencione que se debe de considerar para seleccionar una estrategia de
procesamiento de consultas?
3.- Que condicin deben cumplir dos expresiones para que sean consideradas
equivalentes?
4.- Que es una subexpresin comn?
5.- Que puntos se deber tomar en cuenta para seleccionar una buena
estrategia de ejecucin de join?
6.- Que mtodos de ejecucin de join existen?
7.- Explique brevemente el funcionamiento de la estrategia de join paralelo.
8.- Explique brevemente los pasos para el proceso de optimizacin de una
consulta.
3.7 Ejercicios

Para los siguientes ejercicios, se utilizaran las tablas EMP y DEPT del ejemplo de la
seccin 3.2.2 y la siguiente consulta:

Obtngase el nombre de los empleados mayores de 40 aos del departamento X
con sueldo mayor a $11,000.

l.- Dibuje el rbol de operadores de la consulta.

94

2.- Obtenga las subexpresiones comunes que contenga la consulta.

3.- Dibuje el rbol de operadores optimizado de la consulta.

4.- Considrese que las tablas de EMP y DEPT se encuentran en diferentes
sitios, y que el sitio en el cual se encuentra la tabla EMP tiene una capacidad de
procesamiento muy reducida. Dibuje el rbol de operadores ms recomendable para
este caso.

Bibliografia

[1] Ceri, Stefano. Pelaggati, Giuseppe; "Distributed Databases Principies and
systems'; Internacional Edition; McGraw-Hill; U.S.A.; 1985

[2) Date, C.J.; "An Introduction lo Databases Systems"; Volume 1; Fifth Edition;
Addison-Wesley Publishing Company; U.S.A.; Repnted Juiy, 1990

[3] Date, C.J.; "An lntroduction lo Databases Systems"; Volume li; Addison-Wesley
Publishing Company-, U.S.A.; Reprinted July, 1995

Captulo IV
Procesamiento de transacciones en bases de
datos distribuidas

95
Objetivo
El alumno comprender y manejara los conceptos de control de concurrencia,
seguridad y recuperacin dentro del mbito de las bases de datos distribuidas

Introduccin
Este captulo trata el aspecto del control de concurrencia, de cmo con etiquetas de
tiempo o bloqueos de registros, es posible mantener la integridad de la base de datos
en un ambiente multiusuario. Tambin se habla a cerca de los mtodos de
recuperacin del sistema en base a bitcoras, check-points y respaldos. Por ultimo, el
captulo expone algunas tcnicas para garantizar la seguridad del sistema, por medio
de matrices de autorizacin, evitando as el acceso a usuarios no autorizados.

4.1 Control de concurrencia

4.1.1 Seriabilidad en bases de datos centralizadas

Una transaccin accesa la base de datos usando primitivas de lectura y escritura.
Sean R
j
(x) y W
i
(x) las operaciones de lectura y escritura respectivamente, usadas en la
transaccin Ti para el elemento de datos X. X puede ser una tupla o un fragmento
completo. El conjunto de elementos de lectura de datos para T
i
es llamado conjunto
lector y el conjunto de elementos de escritura de datos para T
i
es llamado conjunto
escritor. El conjunto lector y el conjunto escritor de una transaccin no estn
separados sino por el contrario, trabajan en conjunto.
Una entrada de bitcora es una secuencia de operaciones hechas por una
transaccin. Por ejemplo, la siguiente serie de operaciones sera una planificacin:

S1: R
j
(x) R
j
(x) W
i
(y) R
k
(X) W
j
(X)

Dos transacciones Ti y Tj se ejecutan en sede dentro de una planificacin S, si la
ultima operacin de Ti precede a la primera operacin de Tj en S o viceversa); En otro
caso las transacciones se ejecutaran concurrentemente.

96
Una planificacin es serial si las transacciones no se ejecutan concurrentemente, es
decir, una detrs de otra. Por ejemplo, la siguiente planificacin S2 es serial:

S2: R
i
(x) W
i
(y) R
i
(y) R
j
(x) W
j
(y) R
k
(y) W
k
(X)

Ti Tj Tk
R(x)
W(y)
R(y)
R(x)
W(y)
R(y)
W(x)

Esto sera

S2: T
i
T
j
T
k

En una planificacin, si la operacin O
i
precede a la operacin O
j
, se indica como
O
i
< O
j
, es decir O
i
se ejecuta primero que O
j
, entonces en S2 T
i
< T
j
y T
j
< T
k
.

La ejecucin serial de una transaccin puede ser descrita por una planificacin
seal (denominada por Serial (S1) ). De cualquier forma no es posible forzar a las
transacciones a ejecutarse serialmente. Algo ideal sera que las transacciones se
ejecutaran lo ms concurrentemente posible, cuidando que esta ejecucin sea
corrector. La definicin ms aceptada de correcto en una planificacin es basada en la
seriabilidad:

97
Una planificacin es correcta si esta es seriabilizable, esto es, que el
resultado obtenido por esta sea equivalente al resultado de una
planificacin serial.

Teniendo el concepto de seriabilidad, es posible decir que un mecanismo de control
de concurrencia es correcto si permite a las transacciones ejecutarse en una secuencia
tal que solo una bitcora serializable podra producir. Un mecanismo de control de
concurrencia restringe las posibles secuencias de operacin ejecutados por una
transaccin que fuerza a otra transaccin a esperar mientras la primera termina de
realizar sus operaciones. Un ejemplo es el bloqueo de registros, ya que fuerza a otras
transacciones a esperar hasta que esta termine de realizar las operaciones sobre los
datos.

Las siguientes dos condiciones son suficientes para decir que dos planificaciones
son equivalentes:

1. Cada operacin de lectura lee los mismos valores que fueron producidos por
las mismas operaciones de escritura en ambas planificaciones.
2. La operacin de escritura final es igual en ambas planificaciones.

Estas dos condiciones son suficientes ya que ambas transacciones leen y escriben
los mismos datos. Es importante tambin considerar el hecho de que dos operaciones
pueden llegar a caer en conflicto:

Dos operaciones estn en conflicto si, ellas procesan el mismo dato y al
menos una de estas operaciones es una operacin de escritura, y estas
operaciones pertenecen a diferentes transacciones.
Por ejemplo, [ R
j
(x), W
j
(x) ] y [ W
i
(X), W
j
(X) ] son pares de operaciones en conflicto
mientras que [ R
i
(x), R
j
(x) W
i
(x), W
j
(y) ], y [ W
i
(x), R
j
(y) ] son pares que no se
encuentran en conflicto.

Usando este concepto es posible obtener una definicin de planificacin equivalente
de otra manera:

98
Dos planificaciones S1 y S2 son equivalentes si por cada par de
operaciones en conflicto O
i
y O
j
, donde O
i
< O
j
en S1, entonces O
i
deber preceder a O
j
en S2.

Por ejemplo, la estructura S3 es equivalente a la planificacin S4:

S3: R
i
(x) R
i
(x) W
j
(y) W
i
(x)
S4: R
j
(x) W
j
(y) R
i
(x) W
i
(x)

S3 S4
Ti Tj Ti Tj
R(x) R(x)
R(x) W(y)
W(x) R(x)
W(x) W(x)

4.1.2 Seriabilidad en una base de datos distribuida
En una base de datos distribuida, cada transaccin ejecuta operaciones en varios
sitios. La secuencia de operaciones procesada por las transacciones en un sitio es
una planificacin local. Una ejecucin de n transacciones distribuidas T
1
, T
2
, .... T
n
en
m sitios es modelado por un conjunto de entradas de bitcora Sl, S2, .... Sm.

Si se aplica en cada sitio un mecanismo de control de concurrencia se asegurara que
todas las planificaciones locales son serializables. Sin embargo, la seriabilidad local no
es suficiente para asegurar la exactitud de la ejecucin de un conjunto de
transacciones distribuidas. Considere los siguientes ejemplos:

S1 (Sitio 1): R
i
(x) W
j
(x) R
i
(x) W
i
(x)
S2 (Sitio 2): R
j
(y) W
i
(y) R
i
(y) W
j
(y)

99

S1 S2
Ti Tj Ti Tj
R(x) R(y)
W(x) W(y)
R(x) R(y)
W(x) W(y)

Ambas planificaciones son seriales, sin embargo, no hay una secuencia seal global
de ejecucin de ambas transacciones porque Ti < Tj en Serial(S1) y Tj < Ti en
Serial(S2). Para generalizar, la seriabilidad de transacciones distribuidas, es necesaria
una condicin ms fuerte que la seabilidad local.

La ejecucin de las transacciones T
1
, ..., T
n
es correcta si:

1. Cada entrada local S
k
es serializable.
2. Existe un orden total de T
1
, ..., T
n
tal que, si Ti < Tj en el orden total, entonces
hay una planificacin serial S
k
tal que, S
k
es equivalente a S
k
y T
i
< T
j
en el
Serial(S
k
), para cada sitio k donde ambas transacciones tienen algn proceso en
ejecucin.

La anterior definicin puede ser explicada usando la definicin de conflicto:

Sea T
1
, ..., T
n
un conjunto de transacciones, y sea E una ejecucin
de estas transacciones, modelado por el conjunto de planificaciones
S1, ..., Sm E es correcto (serializable) si existe un orden total de las
transacciones, y adems para cada par de operaciones en conflicto Oi y
Oj de las transacciones Ti y Tj respectivamente, Oi precede a Oj en
cualquier entrada S1, ..., Sn si y solo si Ti precede Ti en el orden total.

100
Esta condicin determina si una ejecucin de una transaccin distribuida es
correcta. Un mecanismo de control de concurrencia es correcto si permite solo la
ejecucin de transacciones distribuidas.

4.1.3 Control de concurrencia basado en bloqueos centralizados
La idea bsica del bloqueo (lock) es que cuando una transaccin requiera accesar
un registro, esta bloquee dicho registro antes de intentar el acceso, y cuando una
transaccin intente bloquear un registro que anteriormente ya fue bloqueado por otra
transaccin, la primera deber esperar a que la otra transaccin libere dicho bloqueo
(unlock).

De hecho, los mecanismos tpicos de bloqueo son ms complejos, debido al
concepto de modo de bloqueo: una transaccin puede bloquear un registro en modo
compartido (shared) si nicamente se desea leerlo y en modo exclusivo (exclusiva) si
se va a escribir en l. Una transaccin siempre deber bloquear un registro de forma
compartida antes de leer el contenido, y bloquear de modo exclusivo antes de escribir.

Existen dos reglas de compatibilidad entre los modos de bloqueo:

1. Una transaccin puede bloquear un registro, si este no esta bloqueado o si lo
esta de manera compartida.
2. Una transaccin puede bloquear de manera exclusiva, solo si el registro no esta
bloqueado.

Otro aspecto importante en el bloqueo es la granularidad. Esto se refiere al tamao
del "objeto" que se bloquea con una operacin simple, esto es, se puede bloquear un
registro o un archivo con una sola instruccin.
Otra condicin que se deber de tener en cuenta es que, una transaccin no debe
de requerir de un nuevo bloque despus de que se libere algn registro, esto quiere

101
decir que la transaccin debe de tener un bloqueo de dos fases (2PL), esto porque la
primera fase sera el bloqueo de todos los registros necesarios para realizar la
transaccin, y la segunda fase es en la cual se hace la liberacin de todos los registros
antes bloqueados.
Teniendo en cuenta lo anterior, se podra asumir que las transacciones estn
estructuradas de la siguiente forma:

- Inicia transaccin
- Se realizan todos los bloqueos para escritura o lectura
- Se hace todo el proceso de la transaccin (Commit)
- Se liberan todos los bloqueos

Un problema que se puede presentar al usar los mecanismos de bloqueo es el
deadlock. Un deadlock entre dos transacciones surge cuando cada una de las
transacciones tiene bloqueado un registro y estn esperando para bloquear el registro
que la otra transaccin ya tiene bloqueado. Ambas transacciones pueden quedar
esperando a la otra para siempre. El sistema debe de ser capaz de detectar el
deadlock y forzar a alguna de las dos transacciones a liberar el registro que se tenia
bloqueado y a que se reinice posteriormente, permitiendo que la otra transaccin
termine correctamente.

4.14 Control de concurrencia basado en bloqueos distribuidos
Se asume que, el manejador local de transacciones (LTM, Local Transaction
Manager) permite al agente local realizar los bloqueos y liberaciones de registros
locales, y el proceso de la transaccin se lleva acabo de acuerdo con la siguiente
figura:

ROOT
AGENT

AGENT

AGENT

DTM-
AGENT

DTM-
AGENT

DTM-
AGENT
Mensaje Mensaje
2 2 2
Transaccin
Distribuida

102

Interface 1': Bloqueo local compartido, Bloqueo local exclusivo, desbloqueo local
Interface 2': Bloqueo compartido, Bloqueo exclusivo. desbloqueo

Entonces, los LTMs interpretan las primitivas locales de bloqueo (bloqueo local
compartido, bloqueo local exclusivo y, liberacin local), mientras que los agentes de la
transaccin procesan las primitivas globales (bloqueo compartido, bloqueo exclusivo, y
liberacin). Entender los aspectos peculiares del control distribuido de concurrencia es
equivalente a comprender lo que el manejador distribuido de transacciones (DTM,
Distributed Transaction Manager) tiene que hacer para garantizar que la transaccin
global tenga las caractersticas de seriabilidad y aislamiento.

Un problema principal que se presenta es la administracin de mltiples copias de
datos, el cual, el DTM debe resolver.

Los mecanismos de bloqueo fueron desarrollados para bases de datos
centralizadas con la suposicin implcita de que solo existe una copia nica de los
datos; de esta manera, una transaccin se da cuenta de que otra transaccin est
trabajando con un registro al momento de intentar accesarla. En las bases de datos
distribuidas, la redundancia que existe entre los datos es almacenada en diferentes
sitios puede generar un conflicto de bloqueo entre dos transacciones, al accesar dos
copias del mismo dato almacenados en diferentes sitios, para los cuales la existencia
mutua es inadvertida para dichas transacciones.

LTM
en
sitio k

LTM
en
sitio j

LTM
en
sitio i
Mensaje Mensaje
1 1 1
Manejador
distribuido de
transacciones
Manejadores de
transacciones
locales

103
Una manera de evitar este problema seria que el DTM tiene que traducir la primitiva
de bloqueo emitida por un agente en un registro de tal manera que sea imposible que
un bloqueo pase inadvertido por una transaccin. Esta es una manera sencilla de
hacer que de manera local, los LTMS, realicen todos los bloqueos en cada uno de los
sitios en donde se encuentran almacenadas las copias de los datos; de esta manera,
una primitiva de bloqueo es traducida en varias primitivas de bloqueo, tantas como
copias de datos se deseen bloquear. Este enfoque trabajara, porque dos
transacciones en conflicto de bloqueo podran darse cuenta de esto en todos los sitios
donde se encuentren copias de los mismos datos.

Existen esquemas alternativos para lograr evitar conflictos en los bloqueos:

1. Write-locks-all, read-locks-one. En este esquema los bloqueos exclusivos son
adquiridos en todas las copias, mientras que los bloqueos compartidos son
adquiridos nicamente en alguna copia arbitrada. Un conflicto es siempre
detectado, porque un bloqueo compartido - exclusivo es detectado en el sitio
donde este se encuentra o es requerido el bloqueo compartido, y un bloqueo
exclusivo - exclusivo es detectado en todos los sitios.
2. Mayora de bloqueos. En ambos bloqueos compartido y exclusivo son
requeridos en una mayora de las copias de los registros (el nmero de copias
que se bloquean son estrictamente ms grande que el nmero de copias que
no se bloquean); de esta manera si dos transacciones requieren bloquear el
mismo registro, hay por lo menos una copia de l en donde se descubrira el
conflicto.
3. Bloque de copia primaria. Una de las copias de cada dato es privilegiada
(llamada copia primaria); todos los bloqueos son solicitados a esta copia, y as
es descubierto el conflicto en el sitio en donde se encuentra esta copia.

4.1.5 Bloqueo de 2 fases como un mtodo de control de concurrencia
Considrese primero que, si todas las transacciones logran un bloqueo de 2 fases,
entonces todas las entradas de bitcora son serializables. Considrese tambin un sitio
donde una transaccin ejecuta alguna operacin, la cual es nicamente una parte de]

104
conjunto total de operaciones ejecutadas por la transaccin distribuida, entonces se
tendr que, si una transaccin distribuida logra un bloqueo de dos fases entonces
todas las subtransacciones en los diferentes sitios, lograrn separadamente un
bloqueo de dos fases. En el momento que el bloqueo de 2 fases es un mtodo
correcto para el control de concurrencia para una base de datos centralizada, la
ejecucin de las subtransacciones es serializable.
Considrese ahora que, las transacciones T
1
, T
2
, ..., T
n
requieren de un bloqueo de
dos fases, esto tal vez no llegue a ocurrir. Considere el estado intermedio en el
conjunto T
1
tiene bloqueado a X, T
2
tiene bloqueado Y, ..., T
n-1
tiene bloqueado V y T
n

tiene bloqueado Z. Cada una de estas transacciones requieren de bloquear un dato el
cual, ya esta bloqueado por otra transaccin; por lo tanto cada una de ellas tendr que
esperar hasta que otra transaccin libere el bloqueo. Sin embargo, desde el momento
en que las transacciones utilizan el bloqueo de dos fases, estas no pueden liberar el
bloqueo, sino hasta que se logran todos los bloqueos requeridos por dicha transaccin.
Por lo tanto n transacciones alcanzarn un estado de deadlock, y pueden estar
esperando por siempre. Entonces, una de estas transacciones deber ser abortada
por algn algoritmo de solucin de deadlock. En cualquier caso, el conjunto de
transacciones no podr ocurrir.
Lo anterior es independiente del nmero de transacciones y de la secuencia de
ejecucin, pero s depende nicamente del orden de los pares de operaciones en
conflicto. Por tanto, un algoritmo de deteccin y resolucin de deadlock es necesario
en un bloqueo de dos fases.
Considrense dos transacciones T
i
y T
j
, las cuales transfieren fondos de una cuenta
x localizada en el sitio 1 a una cuenta localizada en el sitio 2. Dichas transacciones
pueden ser descritas por la siguiente secuencia de operaciones:

T
i
: R
i1
(x) W
i1
(x) R
i2
(Y) W
i2
(Y)
T
j
: R
j1
(x) W
j1
(x) R
j2
(Y) W
j2
(Y)

Ti Ti
Ri(x) Ri(x)
Wi(x) Wi(x)

105
R2(Y) R2(Y)
W2(Y) W2(Y)

Se asume que cada transaccin lee X, decrementa su valor, escribe el nuevo valor,
lee Y, incremento su valor, y escribe su nuevo valor.
Supngase que ambas transacciones son activadas de manera simultnea. Un
bloqueo de 2 fases asegura la ejecucin serializable de estas transacciones, y habra
un orden total en el que Ti < Tj o Tj < Ti; esto significara que W
i1
(x) < R
j1
(x) y
W
i2
(y) < R
j2
(y) o que W
j1
(x) < R
i1
(x) y W
j2
(y) < R
i2
(y)- Dado que existe una simetra, se
podr considerar cualquiera de los dos casos. Para ejemplo considrese T
i
< T
j
.
Para lograr un anlisis del grado de concurrencia que es permitido por el algoritmo
de control de concurrencia, es necesario incluir en el modelo de ejecucin la nocin de
"operaciones concurrentes" en diferentes sitios. Se representarn dos operaciones
concurrentes colocndolas una sobre otra, en la ejecucin concurrente de
transacciones. Por ejemplo:

Sl: Ri(x) Wi(x) Ri(y) Wi(y)
S2: Rj(x) Wj(x) Rj(y) Wi(y)

S1 S2
Ri(x)
Wi(X)
Ri(y) Rj(x)
Wi(Y) Wi(X)
Rj(y)
Wi(Y)

En esta representacin de la ejecucin, el hecho de que la operacin Ri(y) aparezca
abajo de Rj(x) significa que estas dos operaciones inician al mismo tiempo. Por lo
tanto, Tj inicia leyendo x, e inmediatamente Tj tiene que escribir x, aunque Ti no

106
termine aun. Esta ejecucin de E es serializable y permite el m)dmo grado de
concurrencia.

4.1.6 Etiquetas de tiempo en una base de datos distribuida
En un sistema distribuido, es necesario, algunas veces, conocer si un evento A en
algn sitio ocurri antes o despus que un evento B en un sitio diferente. Determinar el
orden de los eventos es sencillo en un sistema centralizado, ya que es posible utilizar
el mismo reloj para determinar el tiempo en que cada uno ocurre. En un sistema
distribuido, en cambio, no es prctico asumir que los relojes disponibles en todos los
sitios estn perfectamente sincronizados.
Varios mtodos de control de concurrencia y algoritmos de prevencin de deadlock
requieren determinar el orden en que se realizarn los eventos. La determinacin de
un orden de eventos consiste en asumir que a cada evento A, el cual ocurre en un
sistema distribuido, se asigna una etiqueta de tiempo TS(A) (timestamp) con las
siguientes propiedades:

1. TS(A) identifica de manera Unica a A (diferentes eventos tienen diferentes
etiquetas de tiempo).
2. Para dos eventos cualquiera A y B, si A ocurre antes que B, entonces TS(A) <
TS(B).

El principal inconveniente de la definicin anterior es que el manejo de la relacin
"ocurre antes" no est definida, de manera precisa, si dos eventos A y B ocurren en
dos diferentes sitios, esto, debido a que no se tiene un "reloj global" para medir el
tiempo exacto de ocurrencia de todos los eventos en el sistema distribuido.
Una definicin precisa de la relacin "ocurre antes" en un sistema distribuido es la
siguiente. Se asume que se conoce el significado de la declaracin " el evento A
ocurri antes que el evento B en el sitio i", La relacin "ocurre antes", denotada por
puede ser generalizada en un sistema distribuido por medio de las siguientes reglas:

1. Si A y B son dos eventos en el mismo sito y A ocurre antes que B, entonces
A B.
2. Si el evento A consiste en enviar un mensaje y el evento B consiste en recibir el
mensaje de A, entonces A B.

107
3. Si A B y B C, entonces A C.

La relacin es parcialmente ordenada. Se puede llamar a dos eventos A y B
pseudosimultneos debido a que en ocasiones no es posible saber cual de los casos
ocurre realmente A B o B A. Considrese el siguiente ejemplo, Los eventos A y
D, B y E, B y F, C y E, C y F son pseudosimultneos. La relacin de tiempo entre dos
eventos pseudosimultneos no puede ser determinada.
La segunda propiedad de la definicin de estampa del tiempo se puede ver de una
manera precisa como sigue:
Ntese que, si Ay B son pseudosimultneos, es posible que TS(A) < TS(B) o

que TS(B) < TS(A). De cualquier forma, Cuando se tienen asignadas las etiquetas a
los eventos, el orden es definido entre ellos, aun si algunos son pseudosimultneos.

Considrese ahora la generacin de las etiquetas de tiempo. El primer requisito,
que sean nicas, se puede satisfacer de manera sencilla en un sistema distribuido. Es
suficiente con que cada sitio agregue a cada etiqueta de tiempo local nica, el
identificador de] sitio en el cual fue generada, en la posicin menos significativa. Lo
Sitio 1 Sitio 2
B
A
C
F
E
D
Mensaje M2
Tiempo
Local
Tiempo
Local
Mensaje M1

108
anterior es necesario para evitar que las etiquetas generadas por un sitio sean
consideradas como mayores a las generadas en otros sitios.

El segundo requerimiento es el ms complicado de satisfacer. Primero, es
necesario utilizar en cada sitio un contador, el cual ser incrementado cada vez que se
genere una nueva etiqueta, esto con el fin de mantener un orden de estas dentro de un
mismo sitio. Sin embargo, la sincronizacin entre los contadores de diferentes sitios
podra llegar a ser difcil. Es posible que el sitio 1 genere ms etiquetas que el sitio 2, y
por lo tanto el contador del sitio 1 se incrementara ms rpido.

Los contadores de dos sitios se pueden mantener aproximadamente alineados, esto
se logra, aadiendo a cada mensaje el valor del contador del sitio que lo enva. Si un
sitio recibe un mensaje con una etiqueta con valor TS mayor al actual en este sitio,
este incremento su contador a TS + 1. De esta manera los contadores de sitios
cooperativos se mantendrn aproximadamente sincronizados; en el caso de que los
dos sitios no sean sitios cooperativos, no es muy importante la sincronizacin de sus
contadores.

Considrese el ejemplo anterior, se asume que el contador en el sitio 1 tiene un
valor inicial de 0 y el sitio 2 tiene un valor inicial de 10 en su contador. (x,y) representa
al sitio y, el cual tiene un contador con valor x. Por lo tanto, inicialmente se tiene que
TS(A)=(0,1) y TS(B)=(10,2). A y B son seudo simultneas con un orden arbitrario.
Cuando el mensaje M2 llega al sitio 1, este genera la etiqueta de tiempo B; Ahora el
contador local 1 es incrementado 4y pasa a ser TS(A)=(1 1, l). Cuando el mensaje Ml
llega al sitio 2, y dado que la etiqueta de tiempo es menor en este sitio, el contador es
simplemente incrementado y pasara a ser TS(B)=(1 1,2). Ntese que TS(A) y TS(B)
difieren nicamente en el identificador del sitio en donde se generaron.

Finalmente, se vera que se tendrn que usar siempre contadores y no relojes, en la
implementacin de etiquetas de tiempo. Sin embargo, en algunas implementaciones
ser conveniente usar relojes en lugar de contadores. De esta manera se reflejar de
manera ms real la secuencia en la ocurrencia de eventos.

109

4.1.7 Deadlocks distribuidos
La deteccin y solucin de deadlocks constituye una actividad importante de un
sistema manejador de bases de datos. La deteccin de deadlocks es ms difcil en un
sistema distribuido que un centralizado, esto, debido a un ciclo de espera involucro
varios sitios.
En la siguiente figura se muestra una grfica wait-for distribuido (Distributed Wait-for
Graphics, DWFG) el cual contiene un ciclo y este corresponde a un deadlock. La
notacin TAj hace referencia al agente A de la transaccin Ti.

En la figura, hay dos sitios y dos transacciones Ti y T2, cada una consiste de dos
agentes. Por simplicidad, se asumir que cada transaccin tiene solo un agente en
cada sitio donde esta se ejecuta. Una flecha directa de] agente TAj a un agente TA,
significa que TAj es bloqueado y espera al agente T
r
A
s
. Hay dos razones por las cuales
un agente esperara a otro:

1. El agente TAj espera que el agente TAj libere un recurso que l
necesita; en este caso, Ti es una transaccin diferente de T
r
, y los dos agentes
estn en el mismo sitio, porque los agentes requieren nicamente recursos
locales. En la figura de ejemplo, TIA, espera que T2A, libere recursos en el sitio
1. Este tipo de espera se representa por una flecha continua en la grfica.
2. El agente TiAj espera por el agente TiA, para realizar alguna solicitud de
funcin; En este caso, los dos agentes pertenecen a la misma transaccin, y el
agente TAj requiere que el agente TjA, ejecute alguna funcin en un sitio
T
1
A
1

T
2
A
1

Sitio 1
T
1
A
2

T
2
A
2

Sitio 2
T
1
A
1

T
2
A
1

Sitio 1
T
1
A
2

T
2
A
2

110
diferente. Este tipo de espera es representado por una flecha discontinuo en la
grfica.

La porcin de una DWFG que contiene nicamente los nodos y flechas
concernientes a un solo sitio se llama grfica wait-for local (Local Wait-For Graphics,
LWFG). Dichas LWFG se extienden con flechas, desde y hacia los nodos los cuales
representan a agentes que tienen conexin con el nodo local. En el ejemplo, la
segunda figura representa una LWFG, los nodos cuadrados son llamados puertos de
entrada si tienen una flecha hacia dentro de la grfica, y puertos de salida si las flechas
salen.

Un deadlock es local si es causado por un ciclo en una LWFG o distribuido si es
causado por un ciclo en una DWFG el cual no esta contenido en una LWFG. La
deteccin de un deadlock distribuido es una tarea que requiere el intercambio de
informacin entre los diferentes sitios del sistema.
La solucin a un deadlock involucro la seleccin de una o ms transacciones que
pueden se abortadas y reiniciadas. Cuando la transaccin es abortada, esta libera los
recursos, para que otras transacciones puedan ser procesadas. Un criterio para
seleccionar que transaccin ser abortada, pudiera ser el que se aborte la transaccin
que implique el menor costo en dicha operacin (l abortar una transaccin requiere de
operaciones de deshacer). Otros criterios podran ser, el abortar la transaccin ms
joven; abortar la transaccin que tiene la menor cantidad de recursos; o abortar la
transaccin que requiere ms tiempo para terminar.
La redundancia incremento la posibilidad de un deadlock. Considrense, por
ejemplo, dos transacciones Ti y T2, ambas bloquean de manera exclusiva el mismo
dato X. Si X no esta replicada, entonces una transaccin obtendra el bloqueo y se
ejecutara mientras que la otra tendra que esperar. En el otro caso, X esta replicado,
se tiene dos copias X, Y X2 en los sitios 1 y 2 y ambas transacciones utilizan la
estrategia write-locks-all, entonces, la siguiente secuencia de eventos en los sitios 1 y 2
determina un deadlock:

Sitio 1: T
1
bloquea X
1
; T
2
espera
Sitio2 : T
2
bloquea X
2
; T
1
espera

111
En este punto la DWFG contiene un ciclo, y por lo tanto un deadlock.

4.2 Recuperacin
Nada trabaja perfectamente el 100% de las veces. Esta simple observacin al
parecer trivial, tiene grandes consecuencias en el diseo de sistemas para
computadoras, en general, y para sistemas de bases de datos, en particular. Tales
sistemas deben incorporar, no solamente una variedad de verificaciones y controles
para reducir la posibilidad de una falla, sino adems y de manera ms significativa un
conjunto exacto de procedimientos para recuperacin de las fallas que,
inevitablemente, ocurren a pesar de estas verificaciones y controles.
La recuperacin en un sistema de bases de datos, significa, primero que nada
recuperar la propia base de datos, esto es, restaurar la base de datos a un estado que
se sabe es correcto, despus de que una falla la ha llevado a un estado incorrecto o al
menos incierto. Existen muchas causas de falla, por ejemplo, errores en la
programacin en una aplicacin, en el sistema operativo de apoyo, en el propio
manejador de bases de datos, errores en el hardware en un dispositivo, virus, ete.
El principio en el cual se basa la recuperacin se puede resumir en una sol a
palabra, redundancia. Esto es la forma de proteger la base de datos y asegurarla de
manera de que cualquier parte de la informacin almacenada en ella pueda ser
reconstruida de alguna otra informacin almacenada redundantemente en alguna parte
del sistema, aunque, el hecho de incluir algn mtodo de procesamiento o
almacenamiento en espejo, no nos garantiza que no ocurra alguna falla, por lo que de
cualquier manera se debe incluir algn procedimiento de recuperacin, el cual puede
consistir en forma general de lo siguiente:

1. Peridicamente, tal vez diario, hacer una copia de respaldo de la base de datos
completa.
2. Cada vez que se haga un cambio en la base de datos, se escribe un registro
que contiene los valores anteriores y los nuevos del registro modificado en un
conjunto de datos especial llamado bitcora.
3. Si ocurre una falla hay dos posibilidades:

112
a) Que la base de datos no se halla daado pero su contenido es incierto (por
ejemplo, la terminacin anormal de un programa en medio de una
secuencia de actualizaciones lgicamente relacionadas) en este caso la
base de datos se restaura a un estado correcto utilizando la bitcora para
deshacer todas las actualizaciones "INCIERTAS' que hayan sido realizadas
en ese programa.

b) La base de datos se daa fsicamente (por ejemplo, debido a algn
problema de hardware) la solucin en este caso, consiste en recuperar la
base de datos utilizndola copia de respaldo ms reciente, y despus
aplicndole la bitcora para hacer los cambio hechos desde el momento en
que se hizo el respaldo hasta el momento en el que ocurri la falla.

4.2.1 Transacciones
El propsito fundamental de un sistema de bases de datos es realizar
transacciones. Una transaccin es una unidad de trabajo, que consiste de la ejecucin
de una secuencia de operaciones lgicamente relacionadas de una aplicacin
especifica que inicia con el operador especial "BEGIN TRANSACTION y termina con
la operacin COMMIT o ROLLBACK. El commit se usa para indicar una
terminacin exitosa (la unidad de trabajo ha terminado con xito), el rollback se utiliza
para indicar una terminacin no exitosa, es decir, la unidad de trabajo no puede ser
terminada completamente debido a que ha ocurrido una condicin excepcional. La
ejecucin de un programa puede corresponder a una secuencia de vanas
transacciones, una detrs de otra.

Las transacciones no se pueden anidar, esto es el begin transaction puede ser
ejecutado solamente cuando la aplicacin no tiene una transaccin en progreso, por
otro lado el commit y el rollback se pueden ejecutar solamente cuando se esta
ejecutando una transaccin. Todas las acciones recuperables deben ser ejecutadas
dentro de los limites de una transaccin, una operacin recuperable es una operacin
que puede ser deshecha o rehecha en el caso de alguna falla, es decir son las

113
operaciones que se deben registrar en la bitcora. Las actualizaciones en la base de
datos y los mensajes de entrada-salida son operaciones recuperables.

Las transacciones son proposiciones de todo o nada, se debe garantizar al usuario
que cada transaccin es ejecutada completamente o no se ejecuta en lo absoluto. El
requerimiento es que el sistema considerado como procesador de transacciones
deber ser confiable, las transacciones no se debern perder o ser hechas
parcialmente o hechas ms de una vez. Al aceptar el mensaje de entrada deber
garantizar que una transaccin se ejecute una vez que cualquier actualizacin sobre la
base de datos producida por la transaccin sea aplicada una vez y que cualquier
mensaje de salida producido por la transaccin sea transmitido al usuario solamente
una vez, el manejador de recuperacin es el responsable de proveer esa confiabilidad.

4.2.2 Manejo de mensajes
La recuperacin tiene varias aplicaciones tanto con el manejo de mensajes como
de la base de datos, considerando el aspecto del manejo de mensajes de una
transaccin, esta no solo actualiza la base de datos sino que adems enva mensajes
al usuario final, si la transaccin llega a su terminacin planeada (commit o rollback
explcito) se debe enviar un mensaje al usuario. Si la transaccin falla, es decir, no
llega a su terminacin planeada a causa de un error, entonces el sistema debe
deshacerla automticamente, el efecto en este caso ser como si la transaccin nunca
se hubiera iniciado, sus actualizaciones en la base de datos debern ser deshechas y
ningn mensaje generado por la transaccin deber ser mostrado. Los mensajes de
salida debern ser transmitidos al usuario hasta que ocurra una terminacin planeada
en la transaccin. El componente responsable del manejo de los mensajes es el
manejador de comunicaciones de datos (DC manager), este manejador recibe el
mensaje de entrada inicial dado por el usuario y al recibir el mensaje escribe un
registro de bitcora que contiene el texto del mensaje. La transaccin utiliza una
operacin get para obtener una copia del mensaje de una cola de entrada y una
operacin put para colocar un mensaje de salida en una cola de mensajes de salida.
Las operaciones commit y rollback explcitos, es decir planeados, provocan que el DC
Manager escriba un registro en la bitcora. Para los mensajes contenidos en la cola de
salida, realiza la transmisin de estos mensajes al usuario y remueve el mensaje de

114
entrada de la cola de correspondiente. Si la transaccin falla, el sistema
automticamente genera un rollback (implcito) y esto provoca que el DC Manager
descarte los mensajes de la cola de salida.

4.2.3 Estructura general de los registros de bitcora

- Registro de control
Identificadores (id, transaccin, fecha y hora, usuario, id. equipo, etc.)
Comandos (Begin transaction, Commit, Rollback)

- Mensajes
ldentificadores
Tipo de mensaje (entrada o salida)
Texto de mensaje

- Operaciones
identificadores
Id. del registro
Valores anteriores
Valores actuales

Considrese la siguiente tabla y transacciones para ejemplo:

T1 Transferir 400 pesos de la cuenta Cl a C4
T2 Depositar a la cuenta C5, 3000 pesos
T3 Dar de alta la cuenta C7 con 5000 pesos
T4 Transferir 1000 pesos de la cuenta Cl a C3

Id cuenta Saldo
C1 1000
C2 500
C3 3200

115
C4 8000
C5 1532
C6 4553

En la bitcora se almacenan los mensajes de entrada y salida, las operaciones de
alta, baja, deposito y retiro, as como los registros de control para cada una de las
transacciones:
T1 usr23 Begin transaction
T1 usr23 ME Transferencia C1 C4 400
T1 usr23 R C1 1000 C1 600
T1 usr23 D C4 8000 C4 8400
T1 usr23 ms Transferencia Completada
T1 usr23 Commit
T2 usrO2 Begin Transaction
T2 usrO2 ME Deposito C5 3000
T2 usrO2 D C5 1532 C5 4532
T2 usrO2 MS Deposito Completado
T2 usr02 Commit
T3 usr45 Begin Transaction
T3 usr45 ME Alta C7 5000
T3 usr45 A C7 5000
T3 usr45 ms Registro Completado
T3 usr45 Commit
T4 usr87 Begin Transaction
T4 usr87 ME Transferencia C1 C3 1000
T4 usr87 R C1 600 C1 -400
T4 usr87 MS Fondos Insuficientes
T4 usr87 Rollback

Dando como resultado siguiente la tabla:

116
Id cuenta Saldo
C1 600
C2 500
C3 3200
C4 8400
C5 4532
C6 4553
C7 5000

4.2.4 Tipos de fallas
Una operacin rollback permite asegurarse de que una falla no corrompa la base de
datos, en el caso de que la transaccin por si misma descubra la condicin de la falla,
desafortunadamente la mayor parte de las fallas no se pueden anticipar fcilmente y no
se puede dejar al programador de la aplicacin el manejadas de esta manera. Los
tipos de fallas que pueden ocurrir, caen en las siguientes categoras:

1. Fallas locales de la transaccin, que son detectadas por el cdigo de la
aplicacin (Por ejemplo, una condicin de fondos insuficientes en una
transaccin bancaria).
2. Fallas locales de transaccin, que no son explcitamente manejadas por el
cdigo de la misma, por ejemplo un overflow aritmtico, una divisin entre cero,
una violacin de seguridad, etc.
3. Fallas del sistema que afectan a todas las transacciones que se encuentran en
ejecucin, pero que no daan la base de datos (por ejemplo, una falla en el
CPU).
4. Fallas en el medio que daan la base de datos o alguna porcin de esta y
afectan a todas las transacciones que estn utilizando esta parte (Por ejemplo,
un aterrizaje de las cabezas de un disco duro).

4.2.5 Fallas de transaccin

117
Este trmino se usa para indicar una falla causada por una terminacin no planeada
y anormal de un programa. Las condiciones que pueden causar esta terminacin no
planeada, incluyen overflow aritmtico, divisin entre cero, Colaciones de seguridad, lo
que ocurre cuando se da una condicin de este tipo, por regla general es lo siguiente:

1. Cuando se presenta una condicin de error, el sistema enciende una condicin
para ese tipo de error en particular por ejemplo, divisin entre cero. El
programador tiene la opcin de incluir explcitamente el cdigo correspondiente
para manejar esta condicin, si no se incluye este cdigo, el sistema realiza la
siguiente accin.
2. El sistema enciende una condicin de error generalizada, de nuevo el
programador tiene la opcin de incluir el cdigo correspondiente para manejar
esta condicin o permitir que el sistema tome la siguiente accin.
3. En este punto el sistema provoca la terminacin anormal del programa y enva
el mensaje correspondiente al usuario, y es solamente en este punto que se
dice que a ocurrido una falla de transaccin.

En general se dice que una falla de transaccin ocurre si y solo si el programa
termina de manera no planeada, es decir, si ocurre un error para el cual no hay un
cdigo incluido en la aplicacin que maneje explcitamente ese error. La ejecucin de
un rollback explcito no esta considerado como una falla de transaccin, sino como una
terminacin anormal planeada de la transaccin, no del programa.

Una falla de transaccin significa que la transaccin no ha llegado a su terminacin
planeada, por lo que es necesario que el sistema force un rollback, esto es, que
deshaga cualquier cambio que haya hecho la transaccin en la base de datos y que
cancele cualquier mensaje de salida que se haya producido para hacer como si nunca
se hubiera iniciado. Deshacer los cambios involucro el trabajar hacia atrs en la
bitcora leyendo todos aquellos registros de bitcora generados por la transaccin
hasta que se encuentre un registro de inicio de transaccin (begin transaction) para
cada registro localizado en la base de datos. El cambio que representa un registro de
bitcora se deshace reemplazando los nuevos valores en la base de datos por los
valores antiguos registrados en la bitcora.

118
4.2.6 Bitcora en lnea
De la descripcin del procedimiento para deshacer una transaccin dada
anteriormente se puede observar que el manejador de recuperacin necesita tener la
posibilidad de accesar los registros de bitcora de una manera selectiva en lugar de
una manera secuencias, por lo tanto, es conveniente que la bitcora se pueda guardar
en un dispositivo de acceso directo, sin embargo, un sistema de base de datos grande
puede generar al orden de varios gigabites de bitcora al da, por lo que es claramente
inconveniente el mantener la bitcora completa en lnea. Una posible solucin podra
ser lo siguiente:

La bitcora activa es mantenida en el dispositivo de acceso directo. Cuando el
archivo de bitcora se llena, el administrador de la bitcora, activa otro archivo de
bitcora, donde se almacenaran los siguientes registros de bitcora, mientras que el
otro archivo se respalda en algn medio. Si una transaccin es muy larga y en dado
momento el archivo de bitcora se llena y esta transaccin aun no termina, el sistema
provoca un rollback y todas las operaciones realizadas por esta se deshacen, y es
reiniciada posteriormente, cuando el nuevo archivo de bitcora este activo.

4.2.7 Transacciones grandes
Una transaccin es tanto una unidad de recuperacin como una unidad de trabajo,
esto sugiere que, una transaccin debe de ser corta con el fin de reducir la cantidad de
trabajo que se tiene que deshacer y quizs, posteriormente rehacer en el caso de una
falla, esta, adems reduce la posibilidad de que una transaccin falle debido a un
overflow en la bitcora. Si una aplicacin es muy grande, lo ms adecuado es
subdividirla en varia transacciones sin afectar el concepto de transaccin.
4.2.8 Compresin de bitcora
Al momento de hacer el respaldo de la bitcora se puede eliminar parte de la
informacin contenida en la misma. Con el fin de ocupar menor cantidad de espacio
de almacenamiento posible, sin perjudicar el proceso de recuperacin, este proceso se
puede realizar de la siguiente manera:

119
1. Debido a que la bitcora en cinta (respaldo) solo se utiliza para rehacer
transacciones en el caso de que ocurra una falla en el medio, se pueden
eliminar los registros de las transacciones que terminaron con rollback.
2. Se pueden eliminar tanto los mensajes de entrada como los de salida.
3. Se pueden eliminar los registros de control, debido a que no es necesario hacer
la recuperacin, transaccin por transaccin, pues se hace un barrido y se
rehacen todas.
4. Se puede eliminar el identificador de la transaccin, el del usuario, fecha, hora,
etc. (identificador de transaccin no es lo mismo que tipo de transaccin).
5. Se puede eliminar la parte UNDO de cada registro que representa una
actualizacin sobre la base de datos.
6. Se eliminan los apuntadores al registro anterior y registro siguiente.
7. Se eliminan los registros de la bitcora que modifican el mismo registro de la
base de datos quedando registrado nicamente la ultima actualizacin.

Considerando la bitcora de la seccin 4, 2, 3, la cual despus de la compresin,
quedara como sigue:

T1 R C1 600
T1 D C4 8400
T2 D C5 4532
T3 A C7 5'000

Con el fin de optimizar el proceso de recuperacin se puede ordenar los registros de
la bitcora de acuerdo con el orden fsico que tienen los registros en la base de datos,
cuya actualizacin representan los registros de la bitcora.

4.2.9 Fallas del sistema
"Fallas del sistema significa que algn evento caus que el sistema se detuviera y
esto requerir un subsecuente reinicio del sistema: El contenido del almacenamiento
primario, en particular el contenido de todo los buffers de entrada/salida (I/O), se
pierde, pero la base de datos no sufre dao alguno. As, las transacciones que en el

120
momento de la falla se estuvieran ejecutando, se debern de deshacer, esto, si es que
estas no haban terminado. Pero, como podra el manejador de recuperacin saber al
momento del restablecimiento, que transacciones deshacer.

Esto se puede resolver buscando en la bitcora desde el principio, identificando
aquellas transacciones para las cuales hay un registro de inicio de transaccin (BT),
pero no un registro de terminacin (commit o rollback). Sin embargo, tal bsqueda
podra consumir demasiado tiempo. Se puede reducir fuertemente la cantidad de
bsqueda, introduciendo el principio de punto de verificacin (Checkpoint).

El principio de check-point es muy simple:

A cierto intervalos preestablecidos, por ejemplo, cada cierto tiempo o nmero de
entradas de bitcora, el sistema realiza un check-point que consiste en los siguientes
pasos:

1. Forza el contenido de los buffers de bitcora hacia la bitcora fsica. Esto obliga
la escritura de cualquier registro de bitcora que aun permanezca en la memoria
principal.
2. Forza la escritura de un registro de check-point en la bitcora.
3. Forza la escritura del contenido de los buffers de la base de datos, en la base de
datos almacenada fsicamente. Esto obligar la escritura de cualquier
actualizacin que aun se encuentre en la memoria principal.
4. Escribe la direccin del registro de check-point incluido en la bitcora en un
archivo de restablecimiento.

El registro de check-point contiene la siguiente informacin:

1. Una lista de todas las transacciones activas al momento del check-point.

121
2. La direccin del registro de bitcora ms reciente de cada una de estas
transacciones.

Al momento del restablecimiento, el manejador de recuperacin obtiene la direccin
del registro de check-point ms reciente del archivo de restablecimiento, localiza este
registro de bitcora y procede a buscar adelante en la bitcora, desde este punto hasta
el final.

Como resultado de este proceso el manejador de recuperacin tiene la posibilidad
de determinar, tanto las transacciones que tiene que deshacer, como las transacciones
que tienen que ser rehechas, con el fin de llevar la base de datos a un estado correcto.
Para el propsito del restablecimiento, las transacciones pueden ser clasificadas en 5
categoras:

Tipo Descripcin
T1 Terminan antes del check-point
T2 Inician antes del check-point y terminan despus de este
T3 Inician antes del check-point, sin embargo no han terminado al
momento de la falla.
T4 Inician despus del check-point y terminan antes de que ocurra la falla
T5 Inician despus del check-point, pero no termina porque se presenta la
falla.

T1

T2

T3

122

T4

T5

Check Point Momento
de la falla

Al momento del restablecimiento, las transacciones del tipo T3 y T5 se deben
deshacer y las del tipo T2 y T4 debern ser rehechas, ya aunque las transacciones se
realizaron completas, no hay garanta de que sus actualizaciones hayan sido escritas
en la base de datos. Las transacciones del tipo Tl no se consideran en al proceso de
recuperacin, ya que al realizar el paso 3 del check-point sus actualizaciones se
escribieron en la base de datos.
Para la recuperacin se procede a deshacer todos los cambios hechos por las
transacciones que estn en la lista UNDO de la siguiente manera:
1. Se lee hacia atrs, secuencialmente la bitcora desde el final hasta el registro de
check-point, s el registro recuperado pertenece a una transaccin de la lista
UNDO, se deshace el movimiento que este representa.
2. A partir del registro de check-point se hace una lectura selectiva de las
transacciones que estn tanto listadas en el registro de check-point como en la
lista de UNDO, hasta localizar el begin transaction de cada una de ellas.
3. Para rehacer las transacciones del tipo T2 y T4, es necesario iniciar una lectura
secuencia de la bitcora a partir del registro de check-point y rehacer el cambio
que representa cada registro de la bitcora que pertenezca a las transacciones
de la lista REDO.

4.2.10 Fallas en el medio de almacenamiento
Este tipo de falla en el que se daa el medio de almacenamiento, daa parte o toda
la base de datos, y las transacciones que estaban usando esa parte se ven afectadas,

123
en este caso, los respaldos realizados peridicamente, juegan un papel fundamental, el
proceso de recuperacin consiste en lo siguiente:

Una vez detectada la falla se procede a reemplazar el medio de almacenamiento y
se restaura la base de datos a partir del ultimo respaldo, y enseguida se le aplican los
movimientos registrados en la bitcora de las transacciones que terminaron con
commit. La bitcora debe contener todos los movimientos efectuados desde que se
hizo el ultimo respaldo hasta el momento de la falla. La bitcora implica todos los
movimientos que se encuentran en la parte activa, como las partes que se respaldaron.

Considrese la tabla de la seccin 4.2.3. La tabla cuentas fue respaldada antes de
que se realizaran las transacciones Tl, T2, T3 y T4, dichas transacciones fueron
registradas en la bitcora, la cual fue sometida a un proceso de compactacin y
respaldo. Supngase que el disco duro en el cual estaba almacenada la tabla de
cuentas se daa, y es necesario recuperarla a partir del respaldo en el disco duro
nuevo, siguiendo el proceso de recuperacin.

1.- Se restaura la base de datos del medio de respaldo.

Cuentas
Id_cuenta Saldo
C1 1000
C2 500
C3 3200'
C4 8000
C5 1532
C6 4553

2.- Se aplican los movimientos almacenados en la bitcora, substituyendo directamente
el valor almacenado en la tabla por el valor obtenido de la bitcora.

Bitcora
T1 R C1 600

124
T1 D C4 8400
T2 D C5 4532
T3 A C7 5000
Id_cuenta Saldo
C1 600
C2 500
C3 3200
C4 8400
C5 1532
C6 4553

Id_cuenta Saldo
C1 600
C2 50
C3 3200
C4 8400
C5 4532
C6 4553

Id_cuenta Saldo
C1 600
Id_cuenta Saldo
C1 600
C2 500
C3 3200
C4 8000
C5 1532
C6 4553

125
C2 500
C3 3200
C4 8400
C5 4532
C6 4553
C7 5000

La tabla que resulta de la operacin de recuperacin es ahora idntica a la tabla que
se tena antes de la falla del disco duro.

4.3 Integridad
El trmino integridad se usa en el contexto de la base de datos con el significado de
correctez o validez, el problema de la integridad es el asegurarse que la base de datos
sea correcta, esto es, proteger la base de datos de transacciones invalidas que pueden
ser provocadas por errores al introducir los datos, por errores por parte del operador o
del programador de la aplicacin, por fallas del sistema, y aun por falsificacin
deliberada. El ultimo caso, sin embargo, no tiene que ver con la integridad, sino con la
seguridad- El proteger la base de datos de operaciones que son legales es
responsabilidad del subsistema de seguridad, por lo tanto, se asume que el usuario
esta autorizado para la actualizacin en cuestin y que la actualizacin es valida.

Se asume la existencia de un subsistema de integridad con las siguientes
responsabilidades:

126
1. Monitorear las transacciones especialmente, operaciones de actualizacin y
deteccin de violaciones a la integridad de la base de datos.
2. En el caso de una violacin, tomar la accin apropiada, por ejemplo,
rechazando la operacin, reportando la violacin o corrigiendo el error.

Con el fin de ejecutar estas acciones, se le debe de proveer al subsistema de
integridad, un conjunto de reglas que define que errores debe verificar y que hacer si
se detecta el error.
La estructura general de una regla de integridad es la siguiente:

Etiqueta: [condicin de activacin]
Restriccin
[ELSE respuesta en caso de violacin]

La condicin de activacin define el momento en el que se verifica que se cumpla la
regla.

Una restriccin indica las acciones que se deben de realizar para que la base de
datos cumpla con la regia, y la respuesta en caso de violacin, corresponde a un
conjunto de instrucciones que se van a ejecutar en el caso de que no se cumpla con la
restriccin. Las reglas de integridad se expresan en lenguajes de alto nivel, por
ejemplo SQL, y son compilada y almacenadas en el diccionario de datos de la base de
datos. La mayor ventaja de esto es que las validaciones son manejadas por el DBMS,
en lugar de las aplicaciones individuales. Otra de las ventajas es que las reglas se
concentran en el diccionario de datos en lugar de estar distribuidas en los programas
de aplicacin, por lo que es ms fcil entenderlas en su totalidad, y por lo tanto
modificarlas en caso de ser necesario. Se tiene, adems, mayor oportunidad de
detectar contradicciones y redundancias en ellas, as como tambin conseguir que el
proceso de validacin se ejecute ms eficientemente.
Debido a que las reglas son almacenadas en el diccionario de datos, es posible
utilizar el lenguaje de consulta normal del sistema para hacer preguntas con respecto a
las mismas.

Las reglas de integridad se pueden dividir en dos categoras:

127
- Reglas de integridad de dominio.
- Reglas de integridad de relacin.

Las reglas de integridad de dominio conciernen a la admisibilidad de un valor
determinado como valor candidato para un atributo determinado, considerado de
manera aislada, esto es, independientemente de su relacin con otros valores en la
base de datos. Las reglas de integridad de relacin conciernen a la admisibilidad de
una tupla determinada como candidato para la insercin en una relacin determinada o
la asociacin entre tuplas de una relacin con otra.

4.3.1 Reglas de integridad de dominio
Cada atributo de cada relacin esta definido sobre un dominio identificado en la
definicin de la relacin, para el atributo A de la relacin R que se define sobre el
dominio D, cualquier valor dado como candidato del atributo A debe pertenecer a D. La
definicin del dominio D entonces constituye una importante regla de integridad, la cual
deber verificar en todas las operaciones de insercin y actualizacin que involucran
cualquier atributo definido sobre D. La regla de integridad de dominio, no es otra que,
la definicin de ese dominio. Las violaciones a las reglas de integridad de dominio
ocurren lo suficientemente seguido como para justificar algunas utileras especiales
para facilitar su manejo-
Cada dominio es un subconjunto de un dominio base y hereda por lo tanto, las
caractersticas de ese dominio base (los dominios base son el conjunto de todas las
cadenas de caracteres, el conjunto de todos los nmeros enteros, el conjunto de todos
los nmeros reales, etc.).
La sintaxis de una definicin de dominio puede ser la siguiente:

DLC nombre del dominio [PRIMARY] DOMAIN
Tipo de datos [PREDICADO]
[ELSE respuesta en caso de violacin]

128
4.3.2 Reglas de integridad de relacin
La sintaxis de una regla de integridad de relacin puede ser la siguiente:

Etiqueta: [Condicin de activacin]
restriccin
[ELSE respuesta en caso de violacin de la regia]

Condicin de activacin:

- WHEN COMMITING
- BEFORE INSERTING nombre-del-registro [FROM estructura]
- BEFORE UPDATING nombre-del_registro [FROM estructura]
- BEFORE UPDATING nombre-de-columna [FROM nombre-de-campol
- BEFORE DELETING nombre del registro
- AFTER INSERTING nombre-del-registro
- AFTER UPDATING nombre-del-registro
- AFTER UPDATING nombre-de-columna
- AFTER DELETING nombre-del-registro

Las siguientes notas explican la sintaxis de las reglas de integridad:

1. La condicin de activacin, si se especifica, consiste de una sola clusula when
commiting o de una lista de clusulas Before y/o After separadas por comas,
en el caso de que no se especifique una condicin de activacin, se asume por
default las siguientes condiciones de activacin:

AFTER INSERTING tabla
AFTER UPDATING tabla

2. Todos los parmetros mencionados en una condicin de activacin deben tener
el mismo cursor, ya sea explcito o implcito, en esta regla se asegura que
todas las clusulas Before y/o After incluidas en una regla de integridad
determinada se refiere al mismo registro, por lo que cualquier referencia al

129
registro por sus campos en la restriccin o en la respuesta en caso de violacin
no es ambigua.
3. Si se especifica la clusula FROM en una sentencia BEFORE se asume que la
estructura destinada, tiene la misma estructura interna que el registro a que se
esta haciendo referencia, esto permite hacer referencia a los campos de la
estructura indicada en el FROM de la restriccin y/o la respuesta en caso de
violacin.
4. Si se especifican mltiples clusulas FROM en la condicin de activacin
determinada, entonces todas estas clusulas deben incluir un nombre de
estructura como si se indicaran de forma aislada y esos nombre de estructura
deben ser la misma.
5. Un cursor es un objeto cuyo valor es la direccin de algn registro especifico de
la base de datos, es decir, es un apuntador la un registro especfico, la
expresin C R se refiere a una instancia especfica de un registro tipo R que
el cursor C se encuentra apuntando. Cada cursor esta restringido a apuntar a
registros de un tipo en particular y cada tipo de registro tiene un cursor de
default que se llama de la misma manera que el tipo de registro.

6. La restriccin puede incluir referencias a parmetros, esto es referencias a
cursores que estn en la lista de condiciones de activacin, as como tambin
referencias a las variables o estructuras indicadas en la clusula, as como
tambin pueden hacer referencia a registros y campos de las tablas implcitas
en la regla.
7. La regla de integridad

i: BEFORE cambio
restriccin
ELSE respuesta en caso de violacin;
Es lgicamente equivalente a:
i : si se va a realizar el cambio entonces sino (restriccin)
entonces ejecuta respuesta en caso de violacin fin_si
fin_si

130
Si se ejecuta la respuesta en caso de violacin y este incluye la operacin
REJECT entonces el cambio se realiza, de otra manera se realiza y regresa a la
aplicacin.

8. La regla de integridad
i: AFTER cambio
restriccin
ELSE respuesta en caso de violacin;
Es lgicamente equivalente a:
i : ejecuta el cambio
entonces sino (restriccin)
entonces ejecuta respuesta en caso de violacin
fin_si

Si respuesta en caso de violacin y este incluye la operacin REJECT entonces el
cambio se deshace
9. Las reglas de integridad de relacin pueden involucrar a ms de una
relacin, por esta razn, se especifica generalmente en forma separada en
lugar de incluirse como parte de la definicin de una relacin.

En el ejemplo de la seccin 4.2.3, se tiene que la transaccin 4 fue desecha debido
a que no se contaba con el saldo suficiente para realizar la operacin, esta validacin
puede ser hecha por medio de reglas de integridad, por ejemplo:

After Updating cuentas
cuentas.saldo >= 0
Else
Set return code to "Saldo insuficiente
Reject;

Esta regla verifica que el saldo sea igual o mayor a cero, despus de que se realizo
la actualizacin, en caso de ser negativo la operacin es forzada a deshacerse y se
enva el mensaje de "Saldo insuficiente".

131

Otro ejemplo, sera una regla que revisara la base de datos antes de dar de alta una
nueva cuenta, para evitar que, por error, se asigne un id que ya exista en la tabla de
cuentas:

Before inserting cuentas from variable-de-programa
Not exist (cuentas. Id-cuenta = variable-de-Programa. ld_cuenta)
Else
Set return code lo El Id de la cuenta ya existe"
Reject,

Supngase que se tiene una tabla en la cual se almacenan los movimientos
mensuales de las cuentas (retiros, depsitos). En el momento en el que se desea
borrar una cuenta de la tabla de cuentas, todos los movimientos de la cuenta debern
de ser borrados para mantener la integridad de la base de datos. Esto se puede lograr
por medio de una regla de integridad, definida como sigue:

After deleting cuentas from variable-de-Programa
Not exist (Movimientos where movimiento. Id-cuenta
variable-de_programa.ld-cuenta)

Else Delete from movimientos
where movimientos.ld-cuenta = variable_de_programa.ld-cuenta;

De esta manera se realizara un borrado en cascada de todos los movimientos de la
cuenta eliminada.

4.4 Seguridad
Se utiliza el trmino de seguridad en un contexto de bases de datos para indicar la
proteccin de la base de datos, acerca del acceso, alteracin o destruccin no
autorizada. Existen numerosos aspectos del problema de seguridad, entre ellos los
siguientes:

132

1. Aspectos legales, sociales y ticos. Por ejemplo, la persona que hace la
solicitud, tal vez un usuario de crdito, tiene acceso legal a la informacin
solicitada.
2. Controles fsicos. Considera si el cuarto de la computadora o las terminales
debern estar cerrados o protegidos de alguna otra manera.
3. Polticas de acceso. Por ejemplo, como decide la empresa quien deber tener
acceso a que datos.
4. Problemas de operacin. Por ejemplo, si se utiliza un esquema de control de
acceso por password, como se mantiene estos en secreto.
5. Controles de hardware. Por ejemplo, provee el procesador central de alguna
caracterstica de seguridad, tales como llaves de proteccin de almacenamiento,
o un modo de operacin privilegiada.
6. Seguridad del sistema operativo. Por ejemplo, cual es el esquema de
proteccin.
7. Situaciones que conciernen especficamente al propio manejador de la base de
datos. Por ejemplo, puede un usuario tener acceso al campo A y no tener
acceso al campo B, si tanto A como B pertenecen al mismo registro.

Algunos ejemplos de lo que podra verificar el subsistema de seguridad de una base
de datos son los siguientes.

Considerando la relacin empleados (num - emp, nombre, direccin, departamento,
sueldo, evaluacin-desempeo), los niveles de acceso a esta relacin que podran ser
otorgados a algn usuario en particular son:

1. El usuario tiene acceso sin restricciones a la relacin completa para cualquier
tipo de operacin.
2. El usuario no tiene acceso a la relacin para ningn tipo de operacin.
3. El usuario puede consultar cualquier parte de la relacin pero no modificarla.
4. Puede ver exactamente un registro en la relacin (del cual es propietario) pero
no cambiarlo.
5. Puede ver exactamente un registro (del cual es propietario) y dentro del registro
puede alterar nicamente el nombre y la direccin.

133
6. Puede ver nicamente el nmero de empleado, el nombre, la direccin y el
departamento de cualquier registro de la relacin y puede modificar solamente
los valores del nombre, direccin y departamento.
7. Puede ver los campos del nmero de empleado, sueldo y puede modificar el
sueldo pero solamente entre las 9 y 17 horas, y en una terminal localizada en la
oficina de personal.
8. Puede ver los nmeros de empleado y sueldo, y puede alterar el valor del sueldo
pero solo si el valor actual de este es menor de 5000.
9. El usuario puede aplicar operadores estadsticos al campo de sueldo, pero no
leer o alterar valores individuales.
10. El usuario puede ver los campos de nmero de empleado, nombre y la
evaluacin del desempeo, y puede alterar la evaluacin al desempeo si y solo
si es el gerente del departamento.

4.4.1 Identificacin y autentificacin
De la definicin de seguridad se deduce que el sistema no debe permitir que se
ejecute cualquier operacin sobre la base de datos a menos que el usuario este
autorizado para realizada.
En los sistemas multiusuario, el sistema operativo requiere de un nombre de usuario
(Login Name) y de una contrasea (Password) para permitir al usuario el acceso al
sistema. Existen algunos DBMS, tales como DB2 UDB de IBM, los cuales confan el
control de acceso al sistema operativo, esto es, si el usuario logro ingresar al sistema
operativo es un usuario valido para el DBMS y puede acceder a los datos.

Existen, tambin, otros DBMS en los que el sistema mantiene un registro en el que
se especifican los objetos que el usuario esta autorizado para accesar y las
operaciones que tiene autorizado ejecutar sobre los objetos.
Antes de accesar la base de datos, los usuarios se tendrn que identificar, esto es,
decir quienes son. Este paso direcciona el sistema al registro del usuario (USER
PROFILE) apropiado.

Normalmente los usuarios necesitan autentificar su identidad a travs de password.

134
El proceso de identificacin puede involucrar el que se provea al usuario con una
cuenta que el puede teclear directamente en su termina] o a travs de algn otro medio
(voz, huellas digitales o tarjetas).
El proceso de autentificacin involucro el proporcionar informacin solamente
conocida por el usuario propietario de la cuenta.

4.4.2 Reglas de autorizacin
El sistema debe permitir la definicin de reglas que debern ser expresadas en
algn lenguaje de alto nivel, por ejemplo SQL utiliza el comando GRANT, GRANT
SELECT ON empleado TO Jones, esta instruccin especifica que el usuario Jones esta
autorizado para ejecutar operaciones de seleccin sobre la relacin empleados, esta
informacin se almacena en el USER PROFILE de Jones. Las reglas de autorizacin
sern compiladas y almacenadas en el diccionario de datos y una vez incluidas en
este, el DBMS forzar que se cumplan.
Es conveniente considerar al conjunto de todos los USER PROFILES como una
matriz de autorizacin en la cual, los renglones corresponden a los usuarios y las
columnas a los objetos de datos, de tal forma que A[I,J] representa al conjunto de
reglas de integridad que se aplican al usuario I con respecto al objeto J.

La granularidad de los objetos para los cuales pueden existir columnas en la matriz
de autorizaciones es una medida de lo sofisticado del sistema; por ejemplo algunos
sistemas soportan solamente a nivel de relaciones completas, mientras que otras
permitirn la autorizacin a nivel de campos individuales. Sin embargo una medida
significativa esta dada por el rango de caractersticas que se permite incluir en el
cuerpo de la matriz.

4.4.3 Encriptacin de datos
Se ha asumido que los usuarios intentaran acceder la base de datos por los medios
normales de acceso, esto es, accesado a la red por medio de un usuario y contrasea,
a si mismo, que existe dentro del DBMS existe una matriz de accesos para este
usuario en la cual se han especificado reglas de autorizacin para este. Considrese

135
ahora el caso en que un "usuario" intenta acceder a la informacin rompiendo o
eludiendo los mtodos de seguridad establecidos, por ejemplo, robando parte de la
informacin almacenada en algn medio de respaldo, o corriendo algn programa que
logre romper la seguridad del sistema operativo y del DBMS, o interceptando las lneas
de comunicacin, es importante recordar que la mayor parte de la comunicacin dentro
de una base de datos distribuida es hacia y desde fuera de la red de rea local.
Una forma efectiva de prevenir que estos "usuarios puedan ver la informacin
contenida en la base de datos, es la encriptacin de datos, esto es, almacenar y
transmitir todos los datos, mensajes, contraseas en una forma encriptada.
En el concepto de la encriptacin, los datos originales son llamados texto plano. El
texto plano es encriptado por algn algoritmo de encriptacin, el cual requiere del texto
plano y de una llave de encriptacin, obteniendo as, la forma encriptada del texto
plano, conocida como texto cifrado.

4.4.4 Encriptacin por sustitucin
El mtodo de sustitucin es uno de los mtodos ms sencillos de encriptacin de
datos, es necesario tener una llave para determinar los caracteres de texto cifrado los
cuales sustituirn a los caracteres del texto plano. A continuacin se presenta un
ejemplo:
Teniendo como llave de encriptacin la palabra ELIOT, se encriptar el siguiente
texto:
AS KINGFISHERS CATCH FIRE

1.- Dividir el texto plano en grupos de caracteres de la misma longitud de la
llave:
AS_KI NGFIS HERS_ CATCH _FIRE

2.- Remplazar cada carcter del texto plano por un entero en el rango de 0-26,
usando_= 00, A=01, B=02, ..., Z=26:

0119001109 1407060919 0805181900 0301200308 0006091805

136
3.- Repetir el paso 2 para la llave de encdptacin:

0512091520

4.- Para cada grupo del texto plano, remplazar cada carcter por la suma,
mdulo 27, de su cdigo y el cdigo de la llave de encriptacin:

0119001109 1407060919 0805181900 0301200308 0006091805
0512091520 0512091520 0512091520 0512091520 0512091520
064092602 1919152412 1317000720 0813021801 0518180625

5.- Remplazar cada cdigo por su correspondiente carcter, de acuerdo al
cdigo del paso 2:

FDIZB SSOXL MQ_GT HMBRA ERRFY

El problema que se podra presentar en este mtodo es, como dificultarle a un
posible "usuario infiltrado el hecho de determinar la llave de encriptacin. Es posible
tambin combinar con este mtodo, el mtodo de permutacin, el cual consiste en
reordenar los caracteres resultantes de a cuerdo a alguna secuencia, previamente
definida.

4.4.5 Encriptacin de llave publica
En este esquema de encriptacin, la llave de encriptacin es conocida por todos, y
cualquier persona puede convertir texto plano a texto cifrado. Pero la llave de
desencriptacin es mantenida en secreto ( este esquema involucro dos llaves, una
para encriptar y otra para desencriptar). La llave de desencriptacin no puede ser
deducida a partir de la llave de encriptacin; de esta manera la persona que ejecuta la
encriptacin no podr ejecutar la desencriptacin si no esta autorizada para hacerlo.

Este mtodo de encriptacin se basa en los siguientes hechos:

137
1.- Existe un algoritmo rpido para determinar si cualquier nmero grande es
primo.
2.- No hay un algoritmo rpido para determinar los factores primos de un nmero
grande.

Este mtodo funciona de la siguiente manera:

1.- Se eligen, de forma aleatoria, dos numero primos largos distintos p y q, para
mayor seguridad deben de ser superiores a 80 dgitos.
Obtngase el producto r = p * q

2.- Se elige, aleatoriamente, un entero grande e que es primo con respecto a (p -1)
* (q - l); y que el mayor comn divisor entre e y (p -1) * (q - 1) es 1. Entonces e es la
llave de encriptacin.

3.- Se calcula la llave de desencriptacin, d, la cual corresponde al nico inverso
multiplicativo de e, mdulo (p -1) * (q - l); esto es:

(d * e) mdulo (p -1) * (q - 1) = 1

4.- Se dan a conocer e y r, pero no d, la cual es la llave de desencriptacin.

5.- Para encriptar una parte del texto plano P ( se asume por simplicidad que es un
entero menor a r ), y se reemplaza por el te)do cifrado C, obtenido de la siguiente
manera:

C = P
e
mdulo r

6.- Para desencriptar una parte del texto cifrado, este es reemplazado por P, que
se obtiene de la siguiente manera:

P = C
d
mdulo r

138
A continuacin se presenta un ejemplo, por razones de facilidad se utilizaran
nmeros pequeos:

Dados p = 3, q = 5, P = 13

r = 3 *5 = 15
(p 1) * (q - 1) = (3 -1) * (5 - 1) = 8

se tiene e = 11 (es un numero primo mayor a p y q)

ahora se calcula d

(d * 3) mdulo 8 = 1

La funcin mdulo obtiene nicamente el residuo de la divisin y se tiene que d = 3
cumple con esta condicin

Ahora se encripta P de la manera siguiente:

C = P
e
mdulo r
C = 13
11
mdulo 15
= 1792160394037 mdulo 15
= 7 (este es el residuo de la divisin entera de 1792160394037 entre 15)

Para desencriptar C se realiza el siguiente proceso:

p = C
d
mdulo r
P = 73 mdulo 15
= 343 mdulo 15
= 13 este es el residuo de la divisin entera de 343 entre 15)

139

4.5 Resumen
Una transaccin accesa la base de datos usando primitivas de lectura y escritura.
El conjunto de elementos de lectura de datos para una transaccin es llamado conjunto
lector y el conjunto de elementos de escritura de datos para una transaccin es
llamado conjunto escritor. Dos transacciones Ti y Tj se ejecutan serialmente en una
planificacin S, si la ultima operacin de Ti precede a la primera operacin de Tj en S.
En otro caso las transacciones se ejecutaran concurrentemente.
En una planificacin, si la operacin O precede a la operacin O, se indica como
O < Oj, es decir 01 se ejecuta primero que O.

Las transacciones se ejecutarn lo ms concurrentemente posible, cuidando que
esta ejecucin sea correcta. La definicin ms aceptada de correcto en una bitcora es
basada en la seriabilidad:

Una planificacin es correcta si esta es seriabilizable, esto es, que sea
equivalente a una planificacin serial.

140
Un mecanismo de control de concurrencia es correcto si permite a las transacciones
ejecutarse en una secuencia tal que solo una planificacin sealizaba podra producir.
Un mecanismo de control de concurrencia restringe las posibles secuencias de
operacin ejecutados por una transaccin que fuerza a otra transaccin a esperar
mientras la primera termina de realizar sus operaciones.

Las siguientes dos condiciones son suficientes para decir que dos planificaciones
son equivalentes:

1. Cada operacin de lectura lee los mismos valores que fueron producidos por
las mismas operaciones de escritura en ambas planificaciones.
2. La operacin de escritura final es igual en ambas planificaciones.

Es importante tambin considerar el hecho de que dos operaciones pueden llegar a
caer en conflicto:
Dos operaciones estn en conflicto si, ellas procesan el mismo dato y
al menos una de estas operaciones es una operacin de escritura, y
estas operaciones pertenecen a diferentes transacciones.

Usando este concepto es posible obtener una definicin de planificacin equivalente
de otra manera:

Dos planificaciones S1 y S2 son equivalentes si por cada par de
operaciones en conflicto O y Oj, donde O < Oj en S1, entonces O
deber preceder a Oj en S2.

En una base de datos distribuida, cada transaccin ejecuta operaciones en vanos
sitios. La secuencia de operaciones procesada por las transacciones en un sitio es
una planificacin local.
Si se aplica en cada sitio un mecanismo de control de concurrencia se asegurara
que todas las planificaciones locales son serializables. Sin embargo, la seriabilidad
local no es suficiente para asegurar la exactitud de la ejecucin de un conjunto de
transacciones distribuidas.

141
La ejecucin de las transacciones T
1
, ..., T
n
es correcta s:

1. Cada entrada local S
k
es serializable.
2. Existe un orden total de T
1
, ..., T
n
tal que, si Ti < Ti en el orden total, entonces
hay una entrada serial S
k
tal que, S
k
es equivalente a S
k
' y Ti < Tj en el
Seal(S
k
'), para cada sitio k donde ambas transacciones tienen algn proceso
en ejecucin.

La anterior definicin puede ser explicada usando la definicin de conflicto:

Sea T
1
, ..., T
n
un conjunto de transacciones, y sea E una ejecucin de
estas transacciones, modelado por el conjunto de entradas de bitcora
Sl,... Sm. E es correcto (serializable) si existe un orden total de las
transacciones, y adems para cada par de operaciones en conflicto O y
Oj de las transacciones Ti y Ti respectivamente, O precede a O en
cualquier entrada Sl,.. Sn, si y solo si Ti precede Tj en el orden total.

La idea bsica del bloqueo (lock) es que cuando una transaccin requiera accesar
un registro, esta bloquee dicho registro antes de intentar el acceso, y cuando una
transaccin intente bloquear un registro que anteriormente ya fue bloqueado por otra
transaccin, la primera deber esperar a que la otra transaccin libere dicho bloqueo
(unlock).
Una transaccin siempre deber bloquear un registro de forma compartida antes de
leer el contenido, y bloquear de modo exclusivo antes de escribir.

Existen dos reglas de compatibilidad entre los modos de bloqueo:

1. Una transaccin puede bloquear un registro, s este no esta bloqueado o s lo
esta de manera compartida.
2. Una transaccin puede bloquear de manera exclusiva, solo si el registro no esta
bloqueado.

Otra condicin que se deber de tener en cuenta es que, una transaccin no debe
de requerir de un nuevo bloque despus de que se libere algn registro, esto quiere

142
decir que la transaccin debe de tener un bloqueo de dos fases (2PL), esto porque la
primera fase sera el bloqueo de todos los registros necesarios para realizar la
transaccin, y la segunda fase es en la cual se hace la liberacin de todos los registros
antes bloqueados.
Los manejadores de transacciones locales interpretan las primitivas locales de
bloqueo (bloqueo local compartido, bloqueo local exclusivo y, liberacin local), mientras
que los agentes de la transaccin procesan las primitivas globales (bloqueo
compartido, bloqueo exclusivo, y liberacin). Entender los aspectos peculiares del
control distribuido de concurrencia es equivalente a comprender lo que el manejador
distribuido de transacciones tiene que hacer para garantizar que la transaccin global
tenga las caractersticas de sociabilidad y aislamiento.

El manejador de transacciones distribuidas tiene que traducir la primitiva de bloqueo
emitida por un agente en un registro de tal manera que sea imposible que un bloqueo
pase inadvertido por una transaccin. De esta manera, una primitiva de bloqueo es
traducida en varias primitivas de bloqueo, tantas como copias de datos se deseen
bloquear.

Existen esquemas alternativos para lograr evitar conflictos en los bloqueos:

1. Write-locks-all, read-locks-one. En este esquema los bloqueos exclusivos son
adquiridos en todas las copias, mientras que los bloqueos compartidos son
adquiridos nicamente en alguna copia arbitraria.
2. Mayora de bloqueos. En ambos bloqueos compartido y exclusivo son
requeridos en una mayora de las copias de los registros (el nmero de copias
que se bloquean son estrictamente ms grande que el nmero de copias que no
se bloquean).
3. Bloque de copia primaria. Una de las copias de cada dato es privilegiada
(llamada copia primaria) y todos los bloqueos se hacen sobre esta copia.

Considrese primero que si todas las transacciones logran un bloqueo de 2 fases,
entonces todas las entradas de bitcora son serializables. Si una transaccin
distribuida logra un bloqueo de dos fases entonces todas las subtransacciones en los
diferentes sitios, lograrn separadamente un bloqueo de dos fases.

143

Considrese ahora que, las transacciones T
1
, T
2
, ..., T
n
requieren de un bloqueo de
dos fases, cada una de estas transacciones requieren de bloquear un dato el cual, ya
esta bloqueado por otra transaccin. Por lo tanto cada una de ellas tendr que esperar
hasta que otra transaccin libere el bloqueo. Sin embargo, desde el momento en que
las transacciones utilizan el bloqueo de dos fases, estas no pueden liberar el bloqueo,
sino hasta que se logran todos los bloqueos requeridos por dicha transaccin. Por lo
tanto n transacciones alcanzarn un estado de deadlock, y pueden estar esperando
por siempre. Entonces, una de estas transacciones deber ser abortada por algn
algoritmo de solucin de deadlock. En cualquier caso, el conjunto de transacciones no
podr ocurrir.
Para lograr un anlisis del grado de concurrencia que es permitido por el algoritmo
de control de concurrencia, es necesario incluir en el modelo de ejecucin la nocin de
"operaciones concurrentes" en diferentes sitios. Se representan dos operaciones
concurrentes colocndolas una sobre otra, en la ejecucin concurrente de
transacciones.

En un sistema distribuido, es necesario, algunas veces, conocer si un evento A en
algn sitio ocurri antes o despus que un evento B en un sitio diferente.

Varios mtodos de control de concurrencia y algoritmos de prevencin de deadlock
requieren determinar el orden en que se realizarn los eventos. La determinacin de
un orden de eventos consiste en asumir que a cada evento A, el cual ocurre en un
sistema distribuido, se asigna una etiqueta de tiempo TS(A) (timestamp) con las
siguientes propiedades:

1. TS(A) identifica de manera nica a A (diferentes eventos tienen diferentes
etiquetas de tiempo).
2. Para dos eventos cualquiera A y B, si A ocurre antes que B, entonces TS(A) <
TS(B).

La relacin ocurre antes, denotada por puede ser generalizada en un sistema
distribuido por medio de las siguientes reglas:

144
1. Si A y B son dos eventos en el mismo sito y A ocurre antes que B, entonces
AS.
2. Si el evento A consiste en enviar un mensaje y el evento B consiste en recibir
el mensaje de A, entonces AB.
3. Si AB y BC, entonces AC.

La deteccin y solucin de deadlocks constituye una actividad importante de un
sistema manejador de bases de datos. La deteccin de deadlocks es ms difcil en un
sistema distribuido que un centralizado, esto, debido a un ciclo de espera involucro
varios sitios.

La figura se muestra una grfica wait-for distribuido (DWFG):

Hay dos razones por las cuales un agente esperara a otro:

1. T
1
A
1
espera que T
2
A
1
libere recursos en el sitio 1. Este tipo de espera se
representa por una flecha continua en la grfica.
2. El agente T
i
A
j
requiere que el agente T
i
A
s
ejecute alguna funcin en un sitio
diferente. Este tipo de espera es representado por una flecha discontinuo en la
grfica.
T
1
A
1

T
2
A
1

Sitio 1
T
1
A
2

T
2
A
2

Sitio 2
T
1
A
1

T
2
A
1

Sitio 1
T
1
A
2

T
2
A
2

145

La porcin de una DWFG que contiene nicamente los nodos y flechas
concernientes a un solo sitio se llama grfica wait-for local. Dichas LWFG se extienden
con flechas, desde y hacia los nodos los cuales representan a agentes que tienen
conexin con el nodo local. Los nodos cuadrados son llamados puertos de entrada si
tienen una flecha hacia dentro de la grfica, y puertos de salida si las flechas salen.
Un deadlock es local si es causado por un ciclo en una LWFG o distribuido si es
causado por un ciclo en una DWFG el cual no esta contenido en una LWFG.
La solucin a un deadlock involucro la seleccin de una o ms transacciones que
pueden se abortadas y reiniciadas. Un criterio para seleccionar que transaccin ser
abortada, pudiera ser el que se aborte la transaccin que implique el menor costo en
dicha operacin. Otros criterios podran ser, el abortar la transaccin ms joven;
abortar la transaccin que tiene la menor cantidad de recursos; o abortar la transaccin
que requiere ms tiempo para terminar.
Algo que se debe de tener en cuenta es que, la redundancia incremento la
posibilidad de un deadlock.

La recuperacin en un sistema de bases de datos, significa, primero que nada
recuperar la propia base de datos, esto es, restaurar la base de datos a un estado que
se sabe es correcto, despus de que una falla la ha llevado a un estado incorrecto o al
menos incierto. El principio en el cual se basa la recuperacin es la redundancia. Esto
es la forma de proteger la base de datos y asegurarla de manera de que cualquier
parte de la informacin almacenada en ella pueda ser reconstruida de alguna otra
informacin almacenada redundantemente en alguna parte del sistema. Se debe
incluir algn procedimiento de recuperacin, el cual puede consistir en forma general
de lo siguiente:

1. Peridicamente, tal vez diario, hacer una copia de respaldo de la base de datos
completa.
2. Cada vez que se haga un cambio en la base de datos, se escribe un registro en
un conjunto de datos especial llamado bitcora.
3. Si ocurre una falla hay dos posibilidades:

146
a) Que la base de datos no se halla daado pero su contenido es incierto en
este caso la base de datos se restaura a un estado correcto utilizando la
bitcora.
b) La base de datos se daa fsicamente, la solucin en este caso consiste en
recuperar la base de datos utilizndola copia de respaldo ms reciente.

El propsito fundamental de un sistema de bases de datos es realizar
transacciones. Una transaccin es una unidad de trabajo que inicia con el operador
especial "BEGIN TRANSACTION" y termina con la operacin 'COMMIT' o
"ROLLBACK". El commit se usa para indicar una terminacin exitosa, el rollback se
utiliza para indicar una terminacin no exitosa.

Todas las acciones recuperables deben ser ejecutadas dentro de los limites de una
transaccin, una operacin recuperable es una operacin que puede ser deshecha o
rehecha en el caso de alguna falla, que se deben registrar en la bitcora.

Las transacciones son proposiciones de todo o nada, se debe garantizar al usuario
que cada transaccin es ejecutada completamente o no se ejecuta en lo absoluto.

Una operacin rollback permite asegurarse de que una falla no corrompa la base de
datos, en el caso de que la transaccin por si misma descubra la condicin de la falla.

Los tipos de fallas que pueden ocurrir, caen en las siguientes categoras:

1. Fallas locales de la transaccin, que son detectadas por el cdigo de la
aplicacin.
2. Fallas locales de transaccin, que no son explcitamente manejadas por el
cdigo de la misma.
3. Fallas del sistema que afectan a todas las transacciones que se encuentran en
ejecucin, pero que no daan la base de datos.
4. Fallas en el medio que daan la base de datos o alguna porcin de esta y
afectan a todas las transacciones que estn utilizando esta parte.

147
El trmino fallas de transaccin se usa para indicar una falla causada por una
terminacin no planeada y anormal de un programa. Lo que ocurre cuando se da una
condicin de este tipo, por regla general es lo siguiente:

1. Cuando se presenta una condicin de error, el sistema enciende una condicin
para ese tipo de error en particular. El programador tiene la opcin de incluir
explcitamente el cdigo correspondiente para manejar esta condicin.
2. El sistema enciende una condicin de error generalizada, de nuevo el
programador tiene la opcin de incluir el cdigo correspondiente para manejar
esta condicin.
3. En este punto el sistema provoca la terminacin anormal del programa y enva
el mensaje correspondiente al usuario, y es solamente en este punto que se
dice que a ocurrido una falla de transaccin.

La ejecucin de un rollback explcito no esta considerado como una falla de
transaccin, sino como una terminacin anormal planeada de la transaccin, no del
programa.

Una falla de transaccin significa que la transaccin no ha llegado a su terminacin
planeada, por lo que es necesario que el sistema force un rollback.

El trmino faltas del sistema significa que algn evento causo que el sistema se
detuviera y esto requerir un subsecuente reinicio del sistema: El contenido del
almacenamiento primario, se pierde, pero la base de datos no sufre dao alguno. As,
las transacciones que en el momento de la falla se estuvieran ejecutando, se debern
de deshacer, esto si es que estas no haban terminado.

Esto se puede resolver buscando en la bitcora desde el principio, identificando
aquellas transacciones para las cuales hay un registro de inicio de transaccin (BT),
pero no un registro de terminacin (commit o rollback).

El principio de check-point es muy simple:

148
A cierto intervalos preestablecidos, por ejemplo, cada cierto tiempo o nmero de
entradas de bitcora, el sistema realiza un check-point que consiste en los siguientes
pasos:

1. Forza el contenido de los buffers de bitcora hacia la bitcora fsica.
2. Forza la escritura de un registro de check-point en la bitcora.
3. Forza la escritura del contenido de los buffers de la base de datos, en la base
de datos almacenada fsicamente.
4. Escribe la direccin del registro de check-point incluido en la bitcora en un
archivo de restablecimiento.

El registro de check-point contiene la siguiente informacin:

1. Una lista de todas las transacciones activas al momento del check-point.
2. La direccin del registro de bitcora ms reciente de cada una de estas
transacciones.

Al momento del restablecimiento, el manejador de recuperacin obtiene la direccin
del registro de check-point ms reciente del archivo de restablecimiento, localiza este
registro de bitcora y procede a buscar adelante en la bitcora, desde este punto hasta
el final.
Para el propsito del restablecimiento, las transacciones pueden ser clasificadas en
5 categoras:

Tipo Descripcin
T1 Terminan antes del check-point
T2 Inician antes del check-point y terminan despus de este
T3 Inician antes del check-point, sin embargo no han terminado al momento
de la falla.
T4 Inician despus del check-point y terminan antes de que ocurra la falla
T5 Inician despus del check-point, pero no termina porque se presenta la
falla.

149
Las transacciones del tipo T3 y T5 se deben deshacer y las del tipo T2 y T4 debern
ser rehechas. Las transacciones del tipo T1 no se consideran en al proceso de
recuperacin, ya que al realizar el paso 3 del check-point sus actualizaciones se
escribieron en la base de datos.

El trmino integridad se usa en el contexto de la base de datos con el significado de
correctez o validez, el problema de la integridad es el asegurarse que la base de datos
sea correcta.

Se asume la existencia de un subsistema de integridad con las siguientes
responsabilidades:

1. Monitorear las transacciones especialmente, operaciones de actualizacin y
deteccin de violaciones a la integridad de la base de datos.
2. En el caso de una violacin, tomar la accin apropiada, por ejemplo,
rechazando la operacin, reportando la violacin o corrigiendo el error.

Con el fin de ejecutar estas acciones, se le debe de proveer al subsistema de
integridad, un conjunto de reglas que define que errores debe verificar y que hacer si
se detecta el error.

Las reglas de integridad se expresan en lenguajes de alto nivel, por ejemplo SQL, y
son compilada y almacenadas en el diccionario de datos de la base de datos. La
mayor ventaja de esto es que las validaciones son manejadas por el DBMS, en lugar
de las aplicaciones individuales. Otra de las ventajas es que las reglas se concentran
en el diccionario de datos en lugar de estar distribuidas en los programas de aplicacin

Las reglas de integridad se pueden dividir en dos categoras:

- Reglas de integridad de dominio.
- Reglas de integridad de relacin.

150
Se utiliza el trmino de seguridad en un contexto de bases de datos para indicar la
proteccin de la base de datos, acerca del acceso, alteracin o destruccin no
autorizada. Existen numerosos aspectos del problema de seguridad, entre ellos los
siguientes:

1. Aspectos legales, sociales y ticos.
2. Controles fsicos.
3. Polticas de acceso.
4. Problemas de operacin.
5. Controles de hardware.
6. Seguridad del sistema operativo.
7. Situaciones que conciernen especficamente al propio manejador de la base
de datos.

De la definicin de seguridad se deduce que el sistema no debe permitir que se
ejecute cualquier operacin sobre la base de datos a menos que el usuario este
autorizado para realizarla, por lo que para cada usuario, el sistema debe mantener un
registro, especificar los objetos que el usuario esta autorizado para accesar y las
operaciones que tiene autorizados ejecutar sobre los objetos.

Este paso se direcciona el sistema al registro del usuario (USER PROFILE)
apropiado.
El sistema debe permitir la definicin de reglas que debern ser expresadas en
algn lenguaje de alto nivel, por ejemplo SQL utiliza el comando GRANT, GRANT
SELECT, esta instruccin especifica que el usuario esta autorizado para ejecutar
operaciones de seleccin sobre una relacin, esta informacin se almacena en el
USER PROFILE. Las reglas de autorizacin sern compiladas y almacenadas en el
diccionario de datos y una vez incluidas en este, el DBMS forzar que se cumplan.

Es conveniente considerar al conjunto de todos los USER PROFILES como una
matriz de autorizacin en la cual, los renglones corresponden a los usuarios y las
columnas a los objetos de datos, de tal forma que A[I,J] representa al conjunto de
reglas de integridad que se aplican al usuario 1 con respecto al objeto J.

151

Se ha asumido que los usuarios intentaran acceder la base de datos por los medios
normales de acceso, esto es, accesado a la red por medio de un usuario y contrasea,
a si mismo, que existe dentro del DBMS existe una matriz de accesos para este
usuario en la cual se han especificado reglas de autorizacin para este.
Una forma efectiva de prevenir que "usuarios" no autorizados puedan ver la
informacin contenida en la base de datos, es la encriptacin de datos, esto es,
almacenar y transmitir todos los datos, mensajes, contraseas en una forma
encriptada.
En el concepto de la encriptacin, los datos originales son llamados texto plano. El
texto plano es encriptado por algn algoritmo de encriptacin, el cual requiere del texto
plano y de una llave de encriptacin, obteniendo as, la forma encriptada del texto
plano, conocida como texto cifrado.
El mtodo de sustitucin es uno de los ms sencillos mtodos de eneriptacin de
datos, es necesario tener una llave para determinar los caracteres de texto cifrado
los cuales sustituirn a los caracteres del texto plano. Es posible tambin combinar
con este mtodo, el mtodo de permutacin, el cual consiste en reordenar los
caracteres resultantes de a cuerdo a alguna secuencia, previamente definida.
En el esquema de encriptacin de llave publica, la llave de encriptacin es conocida
por todos, y cualquier persona puede convertir texto plano a texto cifrado. Pero la llave
de desencriptacin es mantenida en secreto (este esquema involucro dos llaves, una
para encriptar y otra para desencriptar). La llave de desencriptacin no puede ser
deducida a partir de la llave de encriptacin; de sta manera la persona que ejecuta la
encriptacin no podr ejecutar la desencriptacin si no esta autorizada para hacerlo.

1.- Cul es la condicin para que dos transacciones sean serializables?
2.- Cundo dos transacciones son concurrentes?
3.- Cules son las dos condiciones que deben cumplir dos planificaciones para
que sean equivalentes?
4.- Por qu dos operaciones pueden caer en conflicto?

152
5.- Cmo funciona el control de concurrencia basado en bloqueos distribuidos?
6.- Mencione y describa los esquemas o mtodos que existen para evitar los
conflictos entre bloqueos.
7.- Explique brevemente en que consiste el bloqueo de 2 fases.
8.- En que consisten las etiquetas de tiempo?
9.- Que se entiende por deadlocks distribuidos?
10.- Que es la recuperacin?
11.- De que manera garantizamos que en dado momento, una base de datos
pueda ser recuperada?
12.- Adems de la replicacin de la base de datos, qu es recomendable hacer?
13.- Que tipos de fallas pueden darse en un sistema de base de datos?
14.- Que se entiende por integridad en un sistema de bases de datos?
15.- Cuales son las responsabilidades de un subsistema de integridad?
16.- Explique la regla de integridad de dominio?
17.- A que se refiere la palabra seguridad dentro del mbito de las bases de datos?
18.- Mencione 5 aspectos que se deben tomar en cuenta dentro de la seguridad de
las bases de datos?
19.- Que son las reglas de autorizacin?
20.- Que es la encriptacin de datos?

4.7 Ejercicios

1.- Para las siguiente tabla defina las reglas de integridad para el retiro de
fondos, creacin de una cuenta, transferencia de fondo y para la cancelacin de una
cuenta (considerando que existe una tabla de movimientos).

Cuentas

153
Id_cuenta Saldo
C12 458
C23 8541
C54 2369
C78 500

2.- Tomando en cuenta la tabla y regla de integridad anteriores, realice las
siguientes transacciones y regstrelas en una bitcora,

T1: Transferencia de la cuenta C23 a C12 por 1500.
T2: Deposito de 1234 a la cuenta C78.
T3: Retiro de 2000 de la cuenta C12.
T4: Transferencia de [a cuenta C12 a C78 por 1960.
T5: Cancelacin de la cuenta C54.

3.- Utilizando el mtodo de encriptacin de llave publica, y teniendo encuentra
que p = 5 y q = 7, realice la encriptacin y desencriptacin de los siguientes
nmeros: 8, 9.

Bibliografa

[1] Date, C.J.; "An lntroduction to Databases Systems"; Volume 1; Fifth Edition;

[2] Date, C.J.; "An lntroduction to Databases Systems"; Volume 11; Addison-Wesley

[3] Korth, Henry F. Silberschatz, Abraham; @Database System Concepts"; Second
Edition McGraw-Hili; U.S.A.; lnternational Edition 1991

154

Respuestas a preguntas y ejercicios de repaso

Captulo I
Preguntas de repaso
2.-
- La mayor parte de las organizaciones ya estn distribuidas.
- Permiten interconexin de las bases de datos existentes.
- Es posible realizar un desarrollo incrementar.
- Permite reducir la carga de las lneas de comunicacin.
- Existe un incremento en el desempeo del sistema.
- Son ms confiables.
- La mayor parte del tiempo se encuentra disponible la informacin.

155
4.-
Porque describe la forma en como deber de funcionar una base de datos
distribuida. Vista desde el exterior la distribucin ser completamente transparente,

6.-
Significa que el usuario nunca vera la base de datos como un conjunto de
fragmentos situados en diferentes sitios, sino por el contrario, para l, la base de datos
se encuentra ntegramente en su estacin de trabajo o sitio de trabajo.

8.-
- Es llamado por el usuario y se ejecuta durante la sesin.
- Se ejecuta de modo local.
- Tiene capacidad de iniciar la comunicacin con el servidor.

10.-
- Deber ser capaz de soportar mltiples usuarios.
- Deber ser capaz de satisfacer las demandas de los clientes.
- Deber de proveer altos niveles de desempeo-
- Deber de contar con capacidad de red.
Captulo II
Preguntas de repaso

2.-
- Procesamiento local: Los datos son colocados en el sitio o cerca del sitio
donde residen las aplicaciones que los utilizan.
- Disponibilidad y confiabilidad de los datos distribuidos: Debido a que e>dsten
vanas copias de la informacin, es posible conmutar a una copia altema
cuando la copia que era accesada comnmente no se encuentre disponible.
- Distribucin de la carga de trabajo: La carga de trabajo es distribuida en
relacin con la capacidad de cmputo de cada uno de los sitios participantes,
permitiendo un grado ms alto de paralelismo-
- Costo de almacenamiento: Los costos del almacenamiento son reducidos al
fragmentar la base de datos global en diferentes sitios, y esto garantiza

156
espacio disponible en algn sitio para el almacenamiento de nueva
informacin.

4.-
- Fragmentacin horizontal primaria: Consiste en particionar las tuplas de una
relacin global en subconjuntos de tuplas, donde cada uno de estos tiene
propiedades geogrficas comunes. La reconstruccin de la relacin global se
lleva a cabo por medio de la operacin unin.
- Fragmentacin horizontal derivada: Esta genera cuando una relacin no puede
ser fragmentada en base a alguna propiedad de sus atributos, entonces, su
fragmentacin se deriva de la fragmentacin horizontal de otra relacin.
- Fragmentacin vertical: se obtiene por la subdivisin de sus atributos en
grupos. Los fragmentos son obtenidos por medio de proyecciones sobre la
relacin global. La reconstruccin de la relacin global se da por medio de una
operacin join.
- Fragmentacin mixta: Los fragmentos son obtenidos a partir de la aplicacin de
fragmentaciones iterativas sobre la relacin global. La reconstruccin de la
relacin se logra al aplicar las operaciones en orden inverso a la fragmentacin.

Ejercicios de repaso

1.-
q2: Obtener los nmeros de cliente (no_cli) por estado.
q3: Obtener los nombres de los clientes (nom_cli) por empresa.

C02 Vidal Lara Qro
C03 vila Gamesa Jal
C04 Meja Lara Jal

157

q2= { Estado = Gto, Estado = Qro, Estado = Jal
q3= { Empresa = Gamesa, Empresa = Lara}

P1={Ciudad = Gto}, P2={Ciudad = Oro}, P3={Ciudad = Jal}
P4={Empresa = Gamesa}, P5={Empresa = Lara}

M1 = Gto ^ ~Qro ^ ~Jal ^ ~Gamesa ^ Lara si
m2 = Gto ^ ~Qro ^ ~Jal ^ Gamesa ^ ~Lara si
m3 = ~Gto ^ Qro ^ ~Jal ^ ~Gamesa ^ Lara si
m4 = ~Gto ^ Oro ^ ~Jal ^ Gamesa ^ ~Lara si
m5 = ~Gto ^ ~Qro A Jal ^ ~Gamesa ^ Lara si
m6 = ~Gto ^ ~Qro ^ Jal ^ Gamesa ^ ~Lara si

m7 = ~Gto ^ ~Oro ^ ~Jal ^ ~ Gamesa ^ ~Lara no
m8 = Gto ^ Oro ^ Jal ^ Gamesa ^ Lara no
m9 = Gto ^ Oro ^ Jal ^ Gamesa ^ ~Lara no
m10 = Gto ^ Oro ^ Jal ^ ~Gamesa ^ Lara no
m11 = Gto ^ Oro ^ Jal ^ ~ Gamesa ^ ~-Lara no
m12 = Gto ^ Qro ^ ~ Jal ^ Gamesa ^ Lara no
.
. no
.

m1 = Gto ^ Lara
m2 = Gto ^ Gamesa
m3 = Oro ^ Lara
m4 = Oro ^ Gamesa
m5 = Jal ^ Lara

158
m6 = Jal ^ Gamesa

m1

m2

m3
C02 Vidal Lara Qro

m4

m5
C04 Meja Lara Jal

m6
C03 vila Gamesa Jal

159
3.-

q2: Obtener los nmeros y nombres de los clientes por estado.
q3: Obtener los nombres de los clientes por empresa.

Matriz de accesos
S1 S2
Ql 3 2
q2 2 1
q3 1 1

q1= Select Nom_cli
From clients

q2= Select no_cli, Nom_cli
From clients
Where Estado
q3= Select Nom-cli
From clientes
Where Empresa = y

A1 no_cli A2 nom_cli A3 Empresa A4 Estado Tot de accesos
q1 0 1 0 0 5
q2 1 1 0 1 3
q3 0 1 1 0 2

160

Al A2 A3 A4
Al 3 3 0 3
A2 3 10 2 3
A3 0 2 2 0
A4 3 3 0 3

F1={No_cli, Nom_cli}
F2={No_cli, Empresa, Estado}

O

F1={ No_cli, Nom_cli, Empresa}
F2={ No el, Estado}

Captulo III
Preguntas de repaso
2.-
- Es necesario definir el nmero de copias fsicas de cada uno de los fragmentos
que existen en el sistema, y obtener una expresin de consulta sobre cada uno
de los fragmentos.
- Se deber seleccionar el orden de ejecucin del conjunto de consultas sobre
cada uno de los sitios.
- Seleccionar el mtodo optimo para la ejecucin de cada operacin.

4.-
Son expresiones que aparecen ms de una vez dentro de una misma consulta y
que solo deber ser ejecutada una sola vez para optimizar la ejecucin de la consulta.

6.-

161
- Iteracin simple.
- Iteracin orientada a bloques.
- Merge - join.
- Hash - join.
- Tree - way join.
- Join paralelo
- Pipeline muitiway join.

8.-
- Convertir la consulta a alguna expresin apropiada par el sistema administrador
de la base de datos, para que de esta manera pueda ser ejecutada
adecuadamente, eliminando las caractersticas de la sintaxis del lenguaje de
nivel externo con el cual fue hecha la consulta.
- Convertir la consulta a su forma cannica, es decir, llevar a la expresin hasta
su forma ms simple posible, eliminando expresiones comunes y repetidas, y
reduciendo su costo de procesamiento.
- Elegir el procedimiento para evaluar la consulta, sta, expresada en su forma
cannica, generando, generando subprocedimientos para la ejecucin de las
operaciones de bajo nivel, tales como join, select, etc.
- Por ultimo, se construyen un conjunto de planes de ejecucin de la consulta y
se elige el ms econmico de ellos. Donde econmico se refiere a la ejecucin
de menor costo en el sistema.

1.-
PJ
EMP:NOM

DF

JN
DEPTNUM=DEPTNUM
JN
DEPTNUM=DEPTNUM

EMP SL
DESC=X
SL
SAL<=11000
SL
DESC=x

162

DEPT EMP DEPT

3.
PJ
EMP:NOM

EMP SL
DESC=X

DEPT
Captulo IV-

Preguntas de repaso

2.-
Dos transacciones son concurrentes si no cumplen la condicin de seriabilidad.

4.-
Dos operaciones estn en conflicto, cuando procesan el mismo dato y al menos una
de ellas es una operacin de escritura, y dichas operaciones pertenecen a diferentes
transacciones.

6.-
- Write - lock - all, read - lock - one : Los bloqueos exclusivos se hacen en
todas las copias que existen del fragmento, mientras que los bloqueos
compartidos se hacen solo en una de las copias.
- Mayora de bloqueos: Tanto los bloqueos exclusivos como los
compartidos son hechos en la mayora de las copias existentes,
SL
SAL>35000

JN
DEPTNUM=DEPTNUM

DF

163
tomando en cuenta que el nmero de copias bloqueadas sea mayor que
el nmero de las no bloqueadas.
- Bloqueo de copia primaria: Todos los bloqueo son hechos en una sola
copia del fragmento, llamada copia primaria.

8.-
Una etiqueta de tiempo, es un identificador nico asignado a cada transaccin
lanzada en el sistema. Esta etiqueta es utilizada para saber en que orden fueron
lanzadas cada una de las transacciones y en dado momento, poder decidir cual podra
ser abortada en caso de presentarse un interbloqueo.

10.-
La recuperacin de un sistema de bases de datos consiste en llevarla a un estado
correcto despus de que ha ocurrido una falla y la base de datos se encuentra en un
estado incorrecto o incierto.

12.-
Junto con la replicacin, es necesario llevar una bitcora de todos y cada uno de las
actualizaciones hechas a la base de datos, esto para que en caso de una falla, se
realicen un recorrido secuencias a la bitcora y se rehagan todas stas actualizaciones
despus de haber recuperado la base de datos a partir de la copia, esto para que las
perdidas de informacin sean mnimas o casi nulas.

14.-
Una base de datos es integra cuando todos los datos almacenados en ella son
correctos o validos en el contexto de la definicin de la base de datos.

16.-
Cada atributo de la relacin esta definido sobre un dominio, identificado en la
definicin de la relacin y todo valor de este atributo debe estar definido dentro del
domino.

164

18.-
- La existencia de controles de seguridad fsicos.
- Las polticas de acceso.
- Los controles de acceso por medio de hardware.
- La seguridad del sistema operativo.
- Las situaciones concernientes al DBMS.

19.-
La encriptacin de datos es el hecho de almacenar o transmitir la informacin de
manera que no seria entendible para cualquier persona que intentara accesaria.

1.
Para una transferencia o retiro

After Updati ng cuentas
cuentas.saldo >= 0
Else
Set retum code to "Saldo insuficiente
Reject;

Para alta de cuenta:

Before inserting cuentas from variable-de-programa
Not exist (cuentas.Id-cuenta = variable-de-Programa.ld-cuenta)
Else
Set retum code to " El Id de la cuenta ya existe
Reject;

165

Para el borrado de una cuenta:

After deleting cuentas from variable-de-programa
Not exist (Movimientos where movimiento.Id-cuenta =
variable-de-Programa.ld-cuenta)
Else Delete from movimientos
where movimientos.ld-cuenta variable-de-Programa.id_Cuenta;

3.

p = 5, q = 7

r = 5 * 7 = 35

(5 - 1) * (7 -1) = 24

e = 11

(d * 11) modulo 24 = 1

d=11

Encriptacin

C
1
= (8)
11
mdulo 35 = 22
C
2
= (9)
11
mdulo 35 = 4

Desencriptacin

166
P
1
= (22)
11
mdulo 35 = 8
P
2
= (4)
11
mdulo 359

Conclusiones

Durante la realizacin de este trabajo se trato de cubrir la mayor parte del programa
de estudio de la materia de base de datos distribuida, y se logro obtener un texto que
puede ser utilizado por el maestro como apoyo, y por el alumno como libro de texto,
permitiendo as una rpida asimilacin de los temas y conceptos que en esta obra se
tratan.

Es tambin, un texto que podra ser utilizado por personas autodidactas con
conocimientos de generales de computacin y de bases de datos, permitiendo un
entendimiento claro del concepto de lo que son las bases de datos distribuidas.

Bases de Datos Distribuidas

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bases de Datos Distribuidas

Uploaded by

Copyright:

Available Formats

I

Bases de Datos Distribuidas

You might also like