Bases de Datos Distribuidas Completo.doc

Bases de Datos Distribuidas

Introducción

A lo largo de los años la información se ha convertido en una herramienta

indispensable en la toma de decisiones, y el hecho de almacenar y administrar

esta información a tomado mayor importancia día con día.

En los años 70's, cuando las computadoras comenzaron a ser usadas no solo

para realizar cálculos, sino también para almacenar información, nació una nueva

área dentro de la informática, el diseño e implementación 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 actualización de la información. Con el surgimiento de las redes de

área local el procesamiento de la información fue más fácil y rápido, aun cuando

se tenia un nuevo problema, cada vez era mayor el volumen de la información que

se tenia que almacenar en el único servidor central.

Con el crecimiento económico mundial, aparecieron las grandes empresas

transnacionales, con plantas y oficinas en diferentes ciudades y países, por tanto,

con diferentes redes de área local en cada una de las áreas geográficas de la

empresa. Es así 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 información en cada área geográfica, tener una red de

computo en cada una de ellas, y poder compartir dicha información de manera

transparente a todos y cada uno de los usuarios de las redes, formando a si una

gigantesca base de datos distribuida.

I


Objetivo

Este trabajo es realizado con la intención de proveer al alumno de un

documento de consulta basado en el plan de estudio de la materia, lo que

permitirá un fácil acceso a la información requerida de una manera rápida y

concisa, logrando así una fácil comprensión de los temas tratados en clase. Esto

sin intentar sustituir a los libros existentes de bases de datos centralizadas y bases

de datos distribuidas.

II


Bases de datos distribuidas

Contenido

Capitulo 1 Fundamentos de las bases de datos distribuidas1.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 dedatos centralizadas................................................................. .............4

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

1.4 Arquitectura cliente/servidor.................................................................111.4.1 Paradigma cliente/servidor.................................................................111.4.2 Procesamiento cliente/servidor...........................................................111.4.3 Ventajas de la arquitectura cliente/servidor........................................111.4.4 Desventajas de la arquitectura cliente/servidor..................................121.4.5 Características del cliente...................................................................121.4.6 Funciones del cliente..........................................................................131.4.7 Interfaz grafica de usuario estándar....................................................131.4.8 Características de[ servido.........................r.......................................141.4.9 Funciones del servidor........................................................................151.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

Bibliografía...................................................................................................32

Capitulo II Bases de datos en múltiples servidores2.1 Consideraciones para distribuir bases de datos....................................342.1.1 Objetivo del diseño de los datos distribuidos .....................................35

2.2 Diseño de bases de datos distribuidas ................................................362.2.1 Técnicas de diseño Top-Down y Bottom-Up de bases de datos

distribuidas ................................................................................... 362.2.2 Diseño de los fragmentos de la base de datos...................................372.2.3 Correctez de la fragmentación...........................................................372.2.4 Fragmentación Horizontal...................................................................38

III


2.2.5 Fragmentación Horizontal derivada...................................................402.2.6 Fragmentación Vertical......................................................................422.2.7 Fragmentación Mixta.........................................................................462.2.8 Distribución de los fragmentos...........................................................482.2.9 Criterios generales para la distribución de los fragmentos.................

48

2.3 Procesamiento de consultas distribuidas..............................................492.3.1 Árbol de operadores de una consulta................................................492.3.2 Ejemplos de consultas distribuidas....................................................50

2.4. Resumen del capitulo...........................................................................57

2.5. Preguntas de repaso............................................................................60

2.6. Ejercicios..............................................................................................60

Bibliografía..................................................................................................62

Capitulo III Optimización de estrategias de acceso3.1 Importancia de la optimización de consultas........................................63

3.2 Transformaciones equivalentes.........................................................653.2.1 Transformaciones equivalentes por álgebra relacional....................663.2.2 Determinación de subexpresiones comunes...................................68

3.3 Métodos de ejecución de JOIN..........................................................703.3.1 Iteración simple...............................................................................713.3.2 Iteración orientada a bloques..........................................................723.3.3 Merge - Join .................................................................................733.3.4 Uso de índices................................................................................753.3.5 Hash Join .................................................................................763.3.6 Tree - way join................................................................................783.3.7 Estrategias para procesamiento paralelo........................................803.3.8 Join paralelo .................................................................................803.3.9 Pipeline multiway join......................................................................82

3.4. Principios de optímización.................................................................84

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

3.6. Preguntas de repaso.........................................................................93

3.7. Ejercicios............................................................................................94

Bibliografía................................................................................................94

IV


CapitulolV Procesamiento de transacciones en bases de datos distribuidas4.1 Control de concurrencia......................................................................954.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 método 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 Recuperación....................................................................................1114.2.1 Transacciones...............................................................................1124.2.2 Manejo de mensajes......................................................................1134.2.3 estructura general de los registros de bitácora..............................1144.2.4 Tipos de fallas................................................................................1164.2-5 Fallas de transacción.....................................................................1174.2.6 Bitácora en línea............................................................................1184.2.7 Transacciones grandes..................................................................1184.2.8 Compresión de bitácora.................................................................1194.2.9 Fallas del sistema..........................................................................1204.2.10 Fallas en el medio de almacenamiento.......................................123

4.3 Integridad ..........................................................................................1254.3.1 Reglas de integridad de dominio...................................................1264.3.2 Reglas de integridad de relación...................................................127

4.4 Seguridad. .......................................................................................1314.4.1 Identificación y autentificación.......................................................1334.4.2 Reglas de autorización...................................................................1334.4.3 Encriptación de datos. ..................................................................1344.4.4 Encriptación por sustitución,..........................................................1354.4.5 Encriptación de llave publica.........................................................136

4.5. Resumen del capitulo.......................................................................139

4.6. Preguntas de repaso........................................................................151

4.7. Ejercicios.........................................................................................152

Bibliografía..............................................................................................153

Respuestas a preguntas de repaso y ejercicios.....................................154

V

Bases de Datos Distribuidas VI

Objetivo

El alumno conocerá las características de las bases de datos distribuidas, el

paradigma cliente / servidor, y los aspectos que se deben considerar al diseñar una

base de datos distribuida.

Introducción

En este capítulo se tratan las diferencias entre las bases de datos centralizadas

y distribuidas, las cuales proporcionan ventajas y desventajas que deberán ser

tomadas en cuenta al diseñar bases de datos distribuidas, así mismo, se tratan los

objetivos a cumplir por dichas bases de datos. Se discutirá también, una pequeña

descripción 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 características

semejantes, los sistemas distribuidos no podrían ser diseñados con las técnicas de

diseño 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 características, las cuales son: control centralizado,

independencia de datos, reducción de redundancia, estructuras físicas complejas para

un acceso eficiente y seguridad.

1

Fundamentos de las Bases de Datos Distribuidas


Capítulo I

Fundamentos de las bases de datos distribuidas

Control centralizado

La posibilidad de proveer control centralizado sobre los recursos de información

puede ser considerada como una de las razones más atractivas para introducir bases

de datos; esto es considerado como la evolución de los sistemas de información, en los

cuales cada aplicación 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

jerárquico 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 característica llamada Autonomía de sitio. Las bases

de datos distribuidas tienen diferentes grados de autonomía de sitio: desde la más

completa autonomía sin ningún administrador centralizado hasta el más completo

control centralizado.

Independencia de datos.

La independencia de datos quiere decir, que la organización 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

organización física 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 característica se agrega a la

definición de la independencia de datos, esta es la transparencia de distribución.

Gracias a la transparencia de distribución 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 distribución es obtenida en las bases de datos distribuidas por la

introducción de nuevos niveles y esquemas.

2



Reducción 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

automáticamente teniendo solo una copia de los datos; la segunda razón, la

recuperación 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 característica necesaria: primero, las aplicaciones

pueden verse favorecidas si los datos son replicados en todos los sitios donde la

aplicación las necesita, y segundo, la razón de disponibilidad del sistema puede

incrementarse por este medio, debido a que si el sitio en el que se encuentran los

datos fallara, la ejecución de la aplicación no se detiene porque existe una copia en

algún 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 más 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 optimización local y la optimización global de

los accesos. La optimización global consiste en determinar qué datos serán accesados

en qué sitios y qué archivos de datos serán transmitidos entre sitios. La optimización

local consiste en decidir como llevar acabo el acceso a la base de datos local en cada

sitio.

3



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 autonomía, los dueños de los datos

locales pueden proteger de diferentes maneras su información, esto dependiendo del

DBMS local; y segundo, los problemas de seguridad son intrínsecos en los sistemas de

bases de datos en general, esto debido a que las comunicaciones en las redes es su

punto débil con respecto a la protección.

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

datos centralizadas

Razones organizacionales

La mayor parte de las organizaciones están descentralizadas, y las bases de datos

distribuidas se acercan más a las necesidades de la estructura de la organización

distribuida.

Interconexión de las bases de datos existentes.

Las bases de datos distribuidas son la solución natural cuando se tienen varias

bases de datos existentes en la organización. En este caso, las bases de datos

distribuidas son creadas utilizando una estrategia de diseño tipo bottom-up a partir de

las bases de datos locales existentes. Este proceso requiere cierto grado de

reestructuración local; de cualquier forma, el esfuerzo requerido para esto es mucho

menor que el necesario para la creación de una base de datos local completamente

nueva.

4



Desarrollo incremental.

Si una organización agrega una nueva unidad, relativamente autónoma, entonces

las bases de datos distribuidas soportarían este crecimiento con el menor grado de

impacto a las unidades ya existentes. En un sistema centralizado cualquier cambio en

las dimensiones del sistema tendría un impacto mayor, no solo en las nuevas

aplicaciones, sino también en las ya existentes.

Reducción en la sobrecarga de la comunicación.

En una base de datos distribuida geográficamente, el factor que las aplicaciones

locales verían claramente reducido es la sobrecarga de las comunicaciones, en

relación con bases de datos centralizadas. Por eso, en el máximo de que las

aplicaciones sean locales es uno de los objetivos primarios en el diseño de las bases

de datos distribuidas.

Consideraciones en el desempeño.

La existencia de varios procesadores autónomos dan como resultado un incremento

en el desempeño por medio de un alto grado de paralelismo. Esta consideración

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 descomposición de los datos permite maximizar el desempeño 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 fácil, pues requiere del uso de ciertas técnicas, las cuales son difíciles de comprender. La capacidad de procesamiento autónomo en los diferentes sitios no es, por sí misma, garantía de que exista una completa confiabilidad en el sistema, pero esto generaría una fácil degradación del sistema; en otras palabras, las fallas en una base de datos distribuida pueden ser más frecuentes que en las centralizadas, debido al gran número de componentes, pero el efecto de cada falla es considerado por cada aplicación que usa los datos en sitio que falló, y por lo tanto es raro que el sistema en su totalidad falle.

5



1.3 Los doce objetivos de una base de datos distribuidas.

La siguiente expresión se podría 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 idéntico a un sistema no

distribuido.

Esto quiere decir que, los usuarios de un sistema distribuido deberán 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 más, las cuales

norman la existencia de un sistema distribuido y en este caso, de una base de datos

distribuida. Dichos sistemas deberán apegarse a ellas, en la medida, en que el diseño

y la tecnología lo permitan, tales reglas son:

Autonomía local.

Los sitios de un sistema distribuido deberán ser autónomos. La autonomía local

significa que todas las operaciones en un sitio se controlan en ese sitio; ningún sitio

deberá depender de algún otro sitio para su buen funcionamiento. La autonomía local

implica también un propietario y una administración local de los datos, con

responsabilidad local: todos los datos pertenecen a una base de datos local, aunque -

sean accesibles para algún sitio remoto. Por tanto, la seguridad, integridad y

representación en almacenamiento de los datos locales permanecen bajo el control del

sitio local.

6



No dependencia de un sitio central.

La autonomía 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, aún si no se logra la

autonomía local completa.

La dependencia de un sitio central seria indeseable al menos por dos razones:

primero, el sitio central podría ser un cuello de botella; en segundo lugar, el sistema

sería vulnerable; si el sitio central sufriera un desperfecto, todo el sistema dejaría de

funcionar.

Operación continua.

En un sistema distribuido como en uno no distribuido, lo ideal seria que nunca

hubiera la necesidad de apagar el sistema a propósito. Es decir, el sistema nunca

deberá necesitar apagarse para que se pueda realizar alguna función, como actualizar

el DBMS de un sitio existente o añadir un nuevo sitio.

Dependencia (o Transparencia) con respecto a la localización.

La idea básica de la independencia con respecto a la localización es simple; no

debe ser necesario que los usuarios sepan donde están almacenados físicamente los

datos, sino que más bien deben comportarse (al menos desde el punto de vista lógico)

como si todos los datos estuvieran almacenados en su propio sitio local. La

independencia con respecto a la localización hace posible la migración de datos de un

sitio a otro sin anular la validez de ningún programa o actividad. Esta posibilidad de

migración es deseable porque permite modificar la distribución de los datos dentro de

la red en respuesta a cambios en las necesidades del desempeño.

Independencia con respecto a la fragmentación.

Un sistema maneja fragmentación de los datos si es posible dividir una relación en

partes o fragmentos para propósitos de almacenamiento físico. La fragmentación es

deseable por razones de desempeño: 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 tráfico de la red.

Existen en esencia dos clases de fragmentación, horizontal y vertical,

7



Un fragmento puede ser cualquier subrelación arbitraria que pueda generarse de la

relación original mediante ciertas operaciones.

Un sistema que maneja la fragmentación de los datos deberá ofrecer también una

independencia con respecto a la fragmentación (transparencia de fragmentación); es

decir, las bases de datos distribuidas deberán poder comportarse (desde el punto de

vista lógico) como si los datos no estuvieran fragmentados en realidad.

Independencia de réplica.

Un sistema maneja réplica de datos si una relación dada (o, un fragmento dado de

una relación) se puede representar en el nivel físico mediante varias copias

almacenadas o réplicas, en muchos sitios distintos.

La réplica es deseable al menos por dos razones: primero, puede producir un mejor

desempeño (las aplicaciones pueden operar sobre copias locales en vez de tener que

comunicarse con sitios remotos); En segundo lugar, también puede significar una mejor

disponibilidad. La desventaja principal de las replicas es la actualización, ya que

cuando se actualiza un objeto copiado, deben de ser actualizadas todas las replicas de

este objeto: Esto es, el problema de la propagación de actualizaciones.

La réplica, como la fragmentación, 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 optimización es todavía más importante en un sistema distribuido que en uno

centralizado. Lo esencial es que, en una consulta, donde están 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

unión de una relación Rx almacenada en el sitio X y una relación Ry almacenada en un

sitio Y podría 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 optimización es obvia, y esto

a su vez puede verse como otra razón más por la cuál los sistemas distribuidos

siempre son relaciónales (pues las solicitudes relaciónales son optimizables).

8



Manejo distribuido de transacciones.

El manejo de transacciones tiene dos aspectos principales, el control de

recuperación y el control de concurrencia. En un sistema distribuido, una sola

transacción puede implicar la ejecución de código en varios sitios. Por tanto, se dice

que cada transacción está compuesta de varios agentes, donde un agente es el

proceso ejecutado en nombre de una transacción dada en un sitio determinado. Y el

sistema requiere saber cuándo dos agentes son parte de la misma transacción; por

ejemplo, es obvio que no puede permitirse un bloqueo mutuo entre dos agentes que

sean de la misma transacción.

Para asegurar que una transacción dada sea atómica en el ambiente distribuido, el

sistema debe asegurarse de que todos los agentes correspondientes a esa transacción

se comprometan al unísono o retrocedan al unísono, Este efecto puede lograrse

mediante el protocolo de compromiso de dos fases.

En cuanto al control de concurrencia, esta función 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 práctica,

el bloqueo parece seguir siendo la técnica preferida).

Independencia con respecto al equipo.

Las instalaciones de cómputo en el mundo real por lo regular incluyen varias

máquinas 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

sólo de poder ejecutar el mismo DBMS en diferentes equipos, sino también 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 múltiples sitios diferentes, con equipo distinto y

diferentes sistemas operativos, resulta obvia la conveniencia de poder manejar también

varias redes de comunicación distinta.

9



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 estándar de SQL

(ambos lo manejan pero cada uno tiene características propias que los hacen

prácticamente incompatibles), podría ser posible lograr una comunicación entre los dos

en el contexto de un sistema distribuido. Dicho de otro modo, el sistema distribuido

podría ser heterogéneo, al menos en cierto grado.

Una vez más, en la realidad las instalaciones de cómputo no solo suelen emplear

máquinas distintas, varios sistemas operativos diferentes, sino también 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 aplicación espere pasivamente a que otra inicie

la comunicación permea una parte tan grande del cómputo distribuido que tiene un

nombre: paradigma de interacción 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, típico en las redes de área local. En el

procesamiento de dispositivos compartidos en la red de área local (LAN), las

computadoras personales están enlazadas a un sistema de dispositivos que permite a

las computadoras personales (PCs) compartir recursos. En la terminología LAN, tales

dispositivos son llamados servidores (un servidor de archivos y un servidor de

impresión serían 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.

10



El modelo de procesamiento cliente/servidor es una extensión 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 tecnologías de computo.

En la actualidad las estaciones de trabajo tienen un rendimiento y una potencia,

la cual solo se obtenía 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 tráfico 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 gráficas (GUI) disponibles en estaciones

de trabajo. Estas nuevas interfaces pueden ser usadas por una gran variedad

de clientes y cuentan con diferentes técnicas para mostrar la información,

logrando con esto una fácil navegación.

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 aplicación lógica 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 diseñadas para el

proceso cooperativo, son más 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.

11



1.4.5 Características del cliente

Es un programa de aplicación arbitrario que se vuelve cliente temporalmente

cuando necesita acceso remoto, pero también lleva a cabo otro computo local.

Lo llama directamente el usuario y se ejecuta solo durante la sesión.

Se ejecuta localmente en la computadora personal del usuario.

Inicia el contacto con el servidor.

Puede acceder a varios servicios, según 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 Función más importante que desempeña un sistema cliente en un ambiente

cliente/servidor es la presentación y algunas funciones lógicas. El usuario final

interactúa con una aplicación desarrollada para la presentación lógica del sistema.

Las funciones tradicionales de presentación basadas en caracteres, en donde el

procesador desplegaba los caracteres recibidos secuencialmente desde una aplicación

en pantalla con caracteres de tamaño fijo. La continua evolución de las funciones de

presentación ha sido estrechamente ligada con el alto desempeño de las estaciones de

trabajo que ofrecían características gráficas.

Las características gráficas permiten al procesador controlar de manera individual

los píxeles en la pantalla, por tanto, no esta limitado a un tipo de carácter o al número

de columnas de la pantalla. Estas características permiten el desarrollo de interfaces

gráficas de usuario (GUI) capaces de manejar gráficos, imágenes, y audio-video.

1.4.7 Interfaz Gráfica de Usuario estándar

Una interfaz consistente entre el usuario y la aplicación representa un parte

importante en los sistemas abiertos. Las interfaces de presentación entre el usuario y

la aplicación son llamadas interfaces Gráficas de Usuario (GUI), y son diseñadas para

presentar la información a los usuarios de forma gráfica.

Existe una gran variedad de interfaces, pero cada nueva interfaz requiere que los

usuarios y los desarrolladores tengan una nueva capacitación 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

12



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 estándar, la cual debe de

cumplir los siguientes requisitos:

Portabilidad.- Las aplicaciones deben de ser portabas a través de varias

plataformas de sistema abiertos. Una GUI estándar debe de proporcionar un API

estable en cualquier plataforma, de esta manera permitiría una fácil y rápida manera de

migrar de una plataforma a otra.

Flexibilidad.- Una GUI estándar debe de ser flexible y extensible, permitiendo

ajustarse a nuevos tipos de monitores y a otros dispositivos de entrada salida, que

podrían estar disponibles en un futuro.

Herramientas de desarrollo: Cualquier GUI que sea considerada un estándar debe

proporcionar un conjunto de herramientas para el desarrollo.

Internacionalización: En la actualidad, la internacionalización es otra de la

forma de lograr una portabilidad. Esto incluye otros lenguajes, números, unidades

monetarias, formatos de fecha y hora, y símbolos especiales, así como mensajes

relacionados con la cultura de esos países.

Independencia de plataforma: Para ser un verdadero sistema abierto y un estándar,

una GUI deberá ser diseñado para operar independientemente del sistema operativo o

la plataforma de hardware, en el que se esta ejecutando.

1.4.8 Características del servidor

Es un programa privilegiado de propósito especial dedicado a ofrecer un

servicio, pero puede manejar varios clientes remotos a la vez.

Se inicia automáticamente al arranque del sistema y continua ejecutándose en

varias sesiones.

Espera pasivamente el contacto de los clientes remotos.

Acepta el contacto de varios clientes, pero ofrece un solo servicio.

13



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

diseño son los servidores de bases de datos, Básicamente, los servidores de bases de

datos nos permiten un rápido almacenamiento en disco, un significativo poder de

procesamiento, y la capacidad de interactuar con varia aplicaciones (clientes) de

manera simultánea.

Un servidor es un proceso lógico que provee servicios a solicitudes de

procesamiento. En la computación cliente/servidor, un cliente inicia la interacción

cliente/servidor para enviar las solicitudes a los servidores. La función 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 interacción

cooperativa cliente/servidor. Idealmente. Un cliente no envía 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 través 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 envían a estos sus solicitudes de 110.

Impresión compartida. En un ambiente de grupo de trabajo, una impresora de

alto desempeño puede reemplazar a todas las impresoras individuales de los

clientes. Entonces todos los clientes pueden enviar sus solicitudes de

impresión a los servidores de impresión. Un servidor de impresión mantiene

todos los archivos a ser impresos en una cola, a la cual se envían todos los

archivos de los usuarios, y en su tumo, cada una de ellos serán impresos.

14



Servicios de comunicación. 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 envían sus solicitudes para ser procesadas.

Servicios de Fax Esto requiere usualmente software y equipo especial,

conocido como servidor de fax. Los clientes envían 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 lógica 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 más sofisticado que los

métodos de acceso básicos. 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 distribución 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 manipulación

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 electrónico, de

red, manejo de configuración 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 función. De cualquier forma, los servidores deben cumplir con los

siguientes requerimientos generales:

Soporte multiusuario. Aun en un pequeño grupo de trabajo, un servidor debe

de ser capaz de proporcionar servicio a múltiples usuarios concurrentes. Los

15



clientes ejecutan múltiples 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 implicaría un costo extra. Por el contrario,

el sistema debe de satisfacer los requerimientos actuales y, al mismo tiempo,

debe de permitir una fácil expansión.

Desempeño. Un sistema servidor debe proveer niveles de desempeño

satisfactorios necesarios para la empresa y los requerimientos de los usuarios

en un ambiente multiusuario cliente/servidor.

Almacenamiento. Como el número de aplicaciones ejecutándose y de usuarios

aumentan, y los avances de la tecnología de dispositivos de almacenamiento

han hecho que los costos bajen, la demanda de almacenamiento de rápido

acceso se ha convertido en un requisito esencial en un sistema servidor.

Gestión de redes. La comunicación cliente/servidor requiere de una

comunicación de red. Ambos, cliente y servidor deben de contar con

capacidades de red. Sin una red el cliente y el servidor no podrían interactuar.

Multimedia. Las nuevas aplicaciones y las nuevas tecnologías cuentan con

capacidades multimedia, es necesario dar soporte al almacenamiento y

reproducción de imagen, vídeo y sonido.

1.4.1 0 El sistema X Window

El sistema X Window permite un manejo transparente de la interfaz gráfica en

estaciones de trabajo. Conocido también como X, fue desarrollado conjuntamente por

el Instituto Tecnológico de Massachussets, IBM, y DEC en un proyecto conocido como

Athena. La arquitectura X está basada en el modelo cliente/servidor. X proporciona:

16



Un Protocolo de comunicación transparente entre una aplicación y su

presentación lógica, la cual puede residir en una estación de trabajo

remota.

Alto desempeño en la independencia de dispositivos gráficos.

En la tecnología cliente/servidor, el nodo que despliega y recibe información, e

interactúa con el usuario, es el nodo cliente.

Los X clients contienen la aplicación lógica funcional escrita por el desarrollador,

aunque esta residiría en un sistema “servidor” en la red cliente/servidor. El X Client es

enlazado con las librerías X Window y las librerías de las herramientas basadas en X

usadas para crear una aplicación. Aun cuando la designación de X Client y X Server

pueden parecer contradictorias a la definición de cliente y servidor del modelo

cliente/servidor. De hecho:

En el sistema X Window, el X cliente inicia la interacción 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 múltiples X clients.

X Client y X Server pueden estar en la misma máquina.

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 número 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 mínimo el tráfico en la red implica que el proceso mismo

de optimización de consultas debe ser distribuido, además del proceso de ejecución de

17



las consultas. En otras palabras, un proceso representativo consistirá en un paso de

optimización global, seguido de pasos de optimización local en cada uno de los sitios.

Por ejemplo se requiere una consulta C en el sitio X, y que C implica una reunión de

una relación Ry de cien tuplas en el sitio Y con una relación Rz de un millón 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). Después, una vez que haya decidido trasladar Ry a Z,

el optimizador local en Z será el que decida cuál debe ser la estrategia para realizar la

unión en este sitio.

Administración del catálogo.

En un sistema distribuido, el catálogo del sistema incluirá no solo la información

usual acerca de las relaciones, índices, usuarios, etcétera; sino también toda la

información de control necesaria para que el sistema pueda ofrecer la independencia

deseada con respecto a la localización, la fragmentación y la réplica. Existen varias

técnicas para el almacenamiento de los catálogos:

1. Centralizado: El catálogo total se almacena una sola vez, en un sitio central.

2. Replicas completas: El catálogo total se almacena por completo en todos los

sitios.

3. Dividido: Cada sitio mantiene su propio catálogo para los objetos almacenados

en ese sitio. El catálogo total es la unión de todos los catálogos locales no

traslapados.

4. Combinación de 1 y 3: Cada sitio mantiene su propio catálogo local, como en el

punto 3; además, un sitio central único mantiene una copia unificada de todos los

catálogos locales, como en el punto 1.

Todos estos enfoques tienen algún 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 autonomía, pues toda actualización 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 más eficiente que el 3 (encontrar un objeto remoto requiere

sólo el acceso a su catálogo remoto), pero viola una vez más el objetivo de "no

18



dependerá de un sitio central". Por lo tanto, los sistemas en la practica casi nunca

usan ninguno de estos cuatro enfoques.

Propagación de actualizaciones.

El problema básico con la réplica de datos, como se señaló es la necesidad de

propagar cualquier modificación de un objeto lógico dado a todas las copias

almacenadas de ese objeto, Un problema que surge es algún sitio donde se mantiene

una copia del objeto podría no estar disponible en el momento de la actualización. Así,

la estrategia de propagar las actualizaciones de inmediato a todas las copias podría ser

inaceptable, porque implica que la modificación ( y la transacción) fracasara si

cualquiera de estas copias no esta disponible en el momento.

Un método para manejar este problema es el llamado método de "copia primaria", el

cual funciona de la siguiente manera:

Una de las copias del objeto se designa como copia primaria. Las demás serán

copias secundarias.

Las copias primarias de los diferentes objetos están en sitios diferentes (de

modo que, una vez más, este método es distribuido).

Las operaciones de actualización 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 actualización a las copias secundarias en un

momento posterior.

Este método representa un problema, una violación al objetivo de autonomía local,

porque ahora una transacción podría fallar cuando una copia (primaria) remota de

algún objeto no estuviera disponible, aun cuando se dispusiera de una copia local.

19



Control de recuperación.

El control de recuperación 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 transacción puede interactuar con vados manejadores de

recursos autónomos, pero tiene especial importancia en un sistema distribuido porque

los manejadores de recursos en cuestión (DBMS locales) operan en sitios remotos

distintos y por tanto son muy autónomos.

De acuerdo a lo anterior surgen los siguientes puntos:

1. El objetivo de "no dependencia de un sitio central' dicta que la función de

coordinador no debe asignarse a un sitio especifico de la red, sino que deben

realizaría diferentes sitios para diferentes transacciones. Por lo general se

encarga de ella el sitio en el cual se inicia la transacción en cuestión.

2. El proceso de compromiso en dos fases requiere una comunicación entre el

coordinador y todos los sitios participantes, lo cual implica más mensajes y

mayor costo.

3. El sitio Y actúa 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 pérdida de autonomía local.

4. En condiciones ideales el proceso de compromiso en dos fases funcionará

aún en caso de presentarse fallas de sitios o de la red en cualquier punto.

Idealmente, el proceso debería 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 liberación de

bloqueo se convierten en mensajes (suponiendo que el objeto en cuestión es un sitio

20



remoto), y los mensajes implican costos adicionales. Por ejemplo, se considerara una

transacción T que necesita poner al día un objeto del cual existen réplicas en n sitios

remotos. Si cada sitio se encarga de los bloqueos sobre los objetos almacenados en

ese sitio (como sucederá si se cumple la suposición de autonomía local), la puesta en

practica directa requerirá por lo menos de 5 mensajes por cada sitio:

solicitud de bloqueo

concesiones de bloqueo

mensajes de actualización

verificaciones

solicitudes de liberación de bloqueo

Así pues, el tiempo total invertido en la actualización podría 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 verían implicados varios sitios.

El problema con un bloqueo como éste es que ninguno de los sitios puede

detectarlo empleando sólo información interna de este sitio. Dicho de otro modo, no

existen ciclos en las gráficas de espera locales, aunque aparecerá un ciclo si se

combinan esas dos gráficas locales para formar una gráfica de espera global. En

consecuencia, la detección de bloqueos mutuos globales implica mayores costos

adicionales de comunicación, pues requiere juntar de alguna manera las gráficas

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 diseñados para el manejo de bases de datos

centralizadas, logrando un hito en el manejo de datos puesto que permitieron el diseño

de sistemas abiertos. Esto gracias al sublenguaje de datos con que trabajaban en la

realización 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 información, y de la misma

manera al evolucionar las bases de datos centralizadas a distribuidas, los DBMS

también tuvieron que evolucionar a lo que actualmente se conoce como Sistemas

21



Manejadores de Bases de Datos Distribuidas (DDBMS). Estos DDBMS, además de

contar con el sublenguaje de datos deben tener nuevas características propias de las

bases de datos distribuidas como son el soporte de fragmentación, replicación, y el

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 continuación se presenta una tabla en la cual se muestran algunas de las

características de dichos DDBMS:

DDBMS DSL REPLICA

INFORMIX VS.07 SQL Soportada

DB2 V5 SQL Integrada

ORACLE V8 SQL Integrada

Existen muchos más DDBMS con diferentes características, por ejemplo, Sybase

ofrece las primitivas pero- las aplicaciones deben de implementar las transacciones

distribuidas por si mismas, sin embargo, es posible diseñar de manera optima una

base de datos distribuida con las herramientas que estos DDBMS comerciales

proporcionan.

22



1.7 Resumen

Las características que deben de tener los sistemas de bases de datos son:

Control centralizado: Un Administrador de base de datos (DBA) tiene la función 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 organización actual de los datos es

transparente a las aplicaciones y en el caso de una base de datos distribuida se refiere

también a la transparencia de distribución.

Reducción 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, aún cuando en una base de datos distribuida, las

aplicaciones podrían verse favorecidas con la redundancia, ya que, debido a esta, la

razón de disponibilidad puede aumentar.

Estructuras físicas complejas y acceso eficiente: El uso de estructuras de acceso

podría ser una herramienta para el acceso eficiente a la base de datos, es conveniente

tomar en cuenta la optimización local, el acceso a las bases de datos locales, y la

optimización 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,

además, que considerar dos aspectos, el grado de autonomía y la seguridad en los

accesos de los usuarios.

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

estas son:

23



Razones organizacionales: La mayor parte de las organizaciones están ya

descentralizadas.

Interconexión de las bases de datos existentes: Las bases de datos distribuidas son

la solución cuando se tiene varias bases de datos en la organización.

Desarrollo incrementar: Es posible agregar una nueva unidad en una base de datos

distribuida si afectar a las ya existentes.

Reducción de la sobrecarga de la comunicación: En una base de datos distribuida

geográficamente, se vería reducida la sobrecarga de las comunicaciones en

comparación con una base de datos no distribuida.

Consideraciones en el desempeño: La existencia de varios procesadores

autónomos 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 idéntico a un

sistema no distribuido.

Hay además de este, 12 reglas para los sistemas distribuidos:

1. Autonomía local: Significa que todas las operaciones en un sitio se controlan en

ese sitio.

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

de ningún otro sitio.

3. Operación continua: Un sistema distribuido siempre esta disponible.

24



4. Independencia con respecto a la localización: Los usuarios nunca sabrán la

localización real de los datos.

5. Independencia con respecto a la fragmentación: Un sistema distribuido deberá

dar la apariencia de que se encuentra en una sola pieza.

6. Independencia de replica: Un sistema deberá comportarse como si solo

e)dstiera una sola copia de los datos.

7. Procesamiento distribuido de consulta: En una consulta, la cual involucro a más

de un sitio, siempre habrá varias maneras de trasladar en la información para

satisfacer la petición y encontrar la estrategia más eficiente.

8. Manejo distribuido de transacciones: Deberá poder procesar una transacción a

través de varios sitios.

9. Independencia con respecto al equipo: Deberá poder procesar una transacción a

través de diferentes plataformas de hardware y aparentar ante el usuario como

si fuera uno solo.

10. Independencia con respecto al sistema operativo: Deberá de ser capaz de

trabajar en cualquier sistema operativo.

11. Independencia con respecto a la red: Deberá de ser capaz de trabajar en

diferentes redes.

12. Independencia con respecto al DBMS: Varios DBMS deberán trabajar en

conjunto y procesar las transacciones.

El paradigma que dispone que una aplicación debe esperar pasivamente a que otra

aplicación inicie la comunicación, tiene el nombre de interacción cliente/servidor.

25



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

ser un cliente, mientras que aquella que comparte el recurso y recibe la petición se

convierte en servidor.

Esta arquitectura provee ciertas ventajas:

Permite integrar mejores tecnologías al sistema.

Permite que el procesamiento de los datos se realice en el lugar en el que

estos residen

Facilita el uso de interfaces gráficas de usuario.

Permite el uso de sistemas abiertos.

A pesar de todo esto, también 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 más complicado que el de las no

distribuidas.

Tanto el cliente como el servidor, deben de cumplir con ciertas características para

ser considerados como tales:

Cliente

Es un programa de aplicación arbitrario que se vuelve cliente temporalmente

cuando necesita acceso remoto, pero también lleva a cabo otro computo local.

Lo llama directamente el usuario y se ejecuta solo durante la sesión.

Se ejecuta localmente en la computadora personal del usuario.

Inicia el contacto con el servidor.

Puede acceder a varios servicios, según se necesite, pero contacta activamente

con un servidor remoto a la vez.

No necesita hardware poderoso y un sistema operativo complicado.

26



Servidor

Es un programa privilegiado de propósito especial dedicado a ofrecer un

servicio, pero puede manejar varios clientes remotos a la vez.

Se inicia automáticamente al arranque del sistema y continua ejecutándose

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 función de presentar la información al usuario,

así como de realizar algunas funciones lógicas en el procesamiento de dicha

información. Por su parte el servidor debe de proveer servicios a solicitudes de

procesamiento, el cliente inicia la interacción cliente/servidor enviando solicitudes a los

servidores, la función de un servidor debe llevar a cabo una determinada acción, de

acuerdo a la solicitud enviada por el cliente. Algunas funciones que un servidor pudría

realizar seria:

Compartir archivos.

Compartir impresoras.

Servicios de comunicación.

Servicios de fax.

Accesos a las bases de datos.

Un servidor deberá, también, cumplir con ciertos requerimientos generales:

Soporte multiusuario: Debe de ser capaz de proporcionar servicio a múltiples

clientes.

Escalabilidad: Debe de ser capaz de satisfacer la creciente demanda de los

recursos y las aplicaciones.

Desempeño: Un servidor debe proveer niveles de desempeño satisfactorios.

Almacenamiento: Debe de ser capaz de almacenar tanto aplicaciones, como los

archivos generados por estas y los usuarios.

27



Gestión 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,

vídeo 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 actualización global seguida de

optimizaciones locales en cada sitio.

Administración del catalogo: En un sistema distribuido, el catalogo del sistema incluirá

la información a cerca de las relaciones, los índices, los usuarios, y la localización de

fragmentos y replicas de los datos.

Propagación de las actualizaciones: Es necesario propagar cualquier actualización de

un objeto dado, en todas las copias existentes de ese objeto en el sistema.

Control de recuperación: Es necesario que un sistema distribuido cuente con un

método de recuperación, esto, en caso de caídas del sistema. El control de

recuperación 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 transacción puede interactuar con varios manejadores de recursos autónomos.

Control de concurrencia: el control de concurrencia se basa en el bloqueo, las

solicitudes de prueba, establecimiento y liberación 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 transacción:

solicitud de bloqueo, concesiones de bloqueo, mensajes de actualización,

verificaciones, solicitudes de liberación de bloqueo.

28



Al aumentar la cantidad de datos y la necesidad de información, y de la misma

manera al evolucionar las bases de datos centralizadas a distribuidas, los DBMS

también tuvieron que evolucionar a lo que actualmente se conoce como Sistemas

Manejadores de Bases de Datos Distribuidas (DDBMS). Estos DDBMS deberán contar

con: el sublenguaje de consultas, el soporte de fragmentación, replicación, 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 características sobre las cuales, es posible hacer una

comparación 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.-¿Cuál 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 autonomía en el enfoque de las bases de datos distribuidas?

6.-¿Que significa transparencia dentro del entorno de las bases de datos

distribuidas?

7.-¿Cómo describe la arquitectura cliente - servidor?

8.- ¿Cuales deben ser las características de un cliente?

9.-¿Cuáles 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 diseñadores de

bases de datos distribuidas?

29



Bibliografía

[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

30



Objetivo

El alumno comprenderá las técnicas de diseño de bases de datos distribuidas, así

como cada uno de los tipos de fragmentación existentes y las operaciones necesarias

para realizarla.

Introducción

En este capítulo se tratarán las consideraciones que se deberán tener al diseñar la

distribución de la base de datos, así como los tipos de fragmentaciones que existen y

como se obtienen. También se expondrá la forma en como se deberán llevar a cabo el

procesamiento de las consultas en un sistema con datos distribuidos y los costos de

dicho procesamiento,

A continuación se presenta una tabla con las operaciones del álgebra relaciona¡ que se

utilizarán a lo largo del capítulo:

Operación Abreviación Símbolo

Select SL

Projecion Pi

Join JN

Semi-join Si

Union UN

Producto cartesiano CP X

Natural Join NJN

Natural Semi-join NSJ

Diferencia DF

31



Capítulo II

Bases de Datos en múltiples servidores

2.1 Consideraciones en la distribución de bases de datos

Desde la primera etapa de las bases de datos distribuidas a la actualidad, se han

desarrollado varias técnicas para su diseño. De cualquier forma esta claro que el

diseño de bases de datos distribuidas no es fácil, ya que por si mismas, las técnicas y

organización, en el diseño de un sitio sencillo son complicadas, éstas se vuelven más

complicadas en el diseño de un sistema multisitio. Desde el punto de vista técnico, los

nuevos problemas que se presentan son la interconexión entre los sitios por medio de

la red, y la distribución optima de los datos y aplicaciones en los sitios para lograr un

desempeño óptimo del sistema. Desde el punto de vista organizacional, la

descentralización es crucial, puesto que se sustituirá por un sistema distribuido al típico

y extenso sistema centralizado, y en el caso de la distribución de una aplicación tendría

un gran impacto en la organización.

El diseño de una base de datos centralizada consiste en:

1. Diseñar el "esquema conceptual", el cual describe la base de datos-

2. Diseñar el 'esquema físico", mapeando el esquema conceptual con las áreas de

almacenamiento y determinando los métodos de acceso.

En las bases de datos distribuidas estos dos puntos son utilizados para diseñar el

esquema global y diseñar las bases de datos locales en cada sitio. La distribución de

las bases de datos requiere agregar dos nuevos puntos:

3. Diseñar la fragmentación de los datos, determinando como las relaciones

globales serán divididas, horizontalmente, verticalmente o en fragmentos

mixtos.

4. Diseñar la distribución de los fragmentos, determinando como se mapearán los

fragmentos, con las imágenes físicas. En este punto son determinadas las

replicas de los fragmentos.

Estos dos puntos son característicos en el diseño de datos distribuidos.

32



2.1.1 Objetivos del diseño de los datos distribuidos

En el diseño de los datos distribuidos, los siguientes objetivos deberán ser tomados

en cuenta:

Procesamiento local.

La distribución de los datos aumenta el procesamiento local, esto correspondiendo a

un principio básico de que los datos son colocados lo más 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

localización local y remota de los datos, la referencia depende únicamente de la

distribución de los mismos.

Se deberá, también, tomar en cuenta cuando una aplicación tiene un procesamiento

local completo, es decir la aplicación se ejecuta completamente en el lugar de origen.

La ventaja del procesamiento local completo no solamente reduce los accesos

remotos, sino que además, incremento la simplicidad en el control de la ejecución de la

aplicación.

Disponibilidad y confiabilidad de los datos distribuidos.

El almacenamiento de múltiples copias de la información 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 comúnmente era

accesada no se encuentra disponible.

La Confiabilidad se logra por medio del almacenamiento de múltiples copias de la

información permitiendo recuperarla, de caídas del sistema o de daños físicos en

alguna de las copias, usando cualquier otra copia disponible.

Distribución de la carga del trabajo.

La distribución de la carga del trabajo en los sitios es una característica importante

de los sistemas distribuidos. La distribución de la carga del trabajo es hecha en

relación con el poder de cómputo y utilización del equipo de cada sitio, y para

33



maximizar el grado de paralelismo en la ejecución de las aplicaciones. La distribución

de la carga del trabajo puede provocar un efecto negativo en la ejecución local.

Disponibilidad y costo del almacenamiento.

La distribución 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 transmisión de las aplicaciones.

2.2 Diseño de bases de datos distribuidas

2.2.1 Técnicas de diseño Top-Down y Bottom-Up de bases de datos

distribuidas

Se tiene dos alternativas en el diseño de las bases de datos distribuidas, las

técnicas Top-Down y Bottom-Up.

En la técnica top-down, se comienza diseñando el esquema global, y se procede

con el diseño de la fragmentación de los datos, después se distribuyen los fragmentos

en los sitios, creando las imágenes físicas. Esta técnica es complementada con la

construcción, en cada sitio, del "diseño físico" de los datos que estarán almacenados

ahí.

Cuando la base de datos distribuida es desarrollada como un complemento de una

base de datos existente, no es tan fácil lograr esto con la técnica 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 técnica

de diseño bottom-up puede ser utilizada. Esta técnica consiste en la integración de

esquemas existentes en un solo esquema global. Para la integración, se deberá de

unir definiciones de datos comunes y resolver conflictos entre diferentes

representaciones del mismo dato.

En resumen, la técnica bottom-up requiere:

34



1. La selección de un modelo de base de datos común para diseñar el esquema

global de la base de datos.

2. La traducción de cada esquema local al modelo de datos común.

3. La integración de los esquemas locales en el esquema global común.

2.2.2 Diseño de los fragmentos de la base de datos

El diseño de los fragmentos es la primera parte dentro de la técnica top-down. El

propósito de la fragmentación es determinar fragmentos no traslapados, los cuales

serán “unidades lógicas de distribución”.

Se podrá ver que, las tuplas y atributos de la relación no podrán ser considerados

como "unidades individuales de distribución'. El diseño de fragmentos consiste en

agrupar tuplas (en el caso de la fragmentación horizontal) o atributos (en el caso de la

fragmentación vertical), las cuales tienen las "mismas propiedades" desde el punto de

vista de la distribución. Cada grupo de tuplas o atributos que tienen las "mismas

propiedades" puede constituir un fragmento. La idea básica es que si dos elementos

cualquiera de un mismo fragmento tiene las mismas propiedades" desde el punto de \

Asta de la distribución, cualquier método usado para localizar un dato puede entonces

localizar a cualquiera.

2.2.3 Correctez de la fragmentación

Para que una fragmentación sea correcta, esta deberá de cumplir con las siguientes

características:

Completez

La descomposición de una relación R en fragmentos RI,R2, ... ,Rn, es completa si y

solo si cada elemento de datos en R puede ser encontrado en algún Ri

Reconstrucción

Si la relación R es descompuesta en fragmentos Rl,R2, ... , Rn, debiera existir un

operador relacional tal que: R Ri

Exclúyete

35



Si la relación R es descompuesta, en fragmentos Rl,R2, .... Rn, y datos de]

elemento di están en Rj entonces di no debiera estar en algún otro fragmento Rk k).

2.2.4 Fragmentación horizontal

La fragmentación 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

geográficamente comunes.

Es importante, dentro de la fragmentación horizontal, considerar las siguientes

definiciones:

Predicado simple

Dado R[Al,A2, ... A.], un predicado simple pj es:

pj: Ai Valor

donde {, , , ≤, <, >}, Valor Di y Di es el dominio de A¡.

Se tendrá entonces R[pl,P2,P3,---,PMI

Predicados minitermino

Dado Ri y Pti = {p1,p2, ... pj definir M = {mi1, mi2, ... miz} como:

Mi = {mij l mij = ^pik pri pik*}, 1 ≤ k ≤ m, 1 ≤ j ≤ z donde pi*= pi o pi* = ~pi

selectividad de miniterminos sel(mj)

Número de tuplas de la relación que sería 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 aplicación qj accesa datos.

La frecuencia de acceso por una predicado minitermino puede también ser definida.

Considérese la siguiente relación global:

Proveedor(pclave, nombre, cveciudad)

36



pClave Nombre cveciudad

P01 John Smith SF

P02 José Sanchéz LA

P03 Juan Pérez LA

P04 Steven Freeman SF

P05 Alex SD

P06 Tere SD

Para la cual se tiene la siguiente aplicación:

q: Obtener la clave y el nombre de los proveedores de cada ciudad.

Se tendrán los siguientes predicados simples:

P1 = {cveciudad = "SF" }

P2 = { cveciudad = "LA" }

P3 = { cveciudad = "SD" }

Dando como resultado los siguientes predicados miniterminos, los cuales se

obtienen de las combinaciones de los predicados simples:

m1 = {SF ^ LA ^ SD} contradictorio

m2 = {SF ^ ~LA ^ SD} contradictorio

m3 = {SF ^ ~LA ^ ~SD}

..

M6 = {~SF ^ ~LA ^ ~SD} contradictorio

..

M7 = {~SF ^ LA ^ ~SD}

M8 = {~SF ^ ~LA ^ SD}

Eliminando los miniterminos contradictorios se obtiene el siguiente resultado, donde

cada uno de estos miniterminos representa un fragmento de la relación global:

M3 = {SF ^ ~LA ^ ~SD}

M7 = {~SF ^ LA ^ ~SD}

M8 = {~SF ^ ~LA ^ SD}

37



Entonces la fragmentación horizontal estaría dada de la siguiente forma:

Proveedor1 = 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

Proveedor2 = SL cveciudad = “LA” Proveedor


from Proveedor Where cveCiudad = ‘LA’


P02 José Sanchéz LA

P03 Juan Pérez LA

Proveedor3 = SL cveciudad = “SD” Proveedor


from Proveedor Where cveCiudad = ‘SD’


P05 Alex SD

P06 Tere SD

Las condiciones anteriores cumplirían con la definición de fragmentación, si los

únicos valores posibles para el atributo Cveciudad fueran "SF", "LA" y “SD”; de otro

modo no se sabría a que fragmento corresponden las tuplas que contengan otro valor.

38



La reconstrucción de la Tabla global Proveedor se logra fácilmente, por medio de la

siguiente condición:

Proveedor = Proveedor1 UN Proveedor2 UN Proveedor3

Create View ReconstruccionProveedorAs

Select * from Proveedor1Union AllSelect * from Proveedor2Union AllSelect * from Proveedor3

La reconstrucción de la relación global siempre se lleva a cabo, por medio de la

operación de unión.

2.2.5 Fragmentación horizontal derivada

En algunas ocasiones, la fragmentación horizontal de una tabla no se puede basar

en alguna propiedad de sus propios atributos, pero se deriva de la fragmentación

horizontal de otra tabla. Considérese 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 partición

de esta relación 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

39



tabla Pedido, sino que es un atributo de la tabla Proveedor. Por lo tanto, se necesita

una operación de semi-join para determinar las tuplas de Pedido que corresponden con

los proveedores en cierta cveciudad. Esto se logra de la siguiente manera:

Pedido1 = Pedido SJ pclave = pclave Proveedor1

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

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



Pclave Pnum Depto CantP02 3298 Ventas 98P03 7895 Finanzas 87



El efecto de la operación semi-join nos permite seleccionar de Pedido las tuplas que

satisfacen la condición de unión entre Proveedor1, o Proveedor2, o Proveedor3 y

Pedido, de esta manera se determinaran aquéllas tuplas de la Table Pedido que hacen

referencia a proveedores en San Francisco, Los Ángeles o San Diego,

respectivamente.

La reconstrucción de la Table global Pedido puede lograrse por medio de una

operación de unión 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 estén dentro de la tabla Proveedor. Esto es una

restricción típica dentro de las bases de datos conocida como integridad referencial.

40



2.2.6 Fragmentación vertical

La fragmentación vertical de una tabla global es la subdivisión de sus atributos en

grupos, los fragmentos son obtenidos al proyectar la tabla global sobre cada grupo.

La fragmentación es correcta si cada atributo es mapeado por lo menos con un atributo

de los demás fragmentos; por otra parte, es posible reconstruir la tabla original por

medio de uniones de todos los fragmentos a la vez. Considérese el siguiente ejemplo:

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

Cvemp Nom Sal Imp Depto

E12 Juan Pérez 4500 15 15

E56 José Hernández 756 15 9

E78 Luis Pérez 9254 15 17

E98 Maria Solís- 2345 25 22

E32 John Smith 5489 2-5 22

Egl Rocio Sánchez 4600 15 8

E73 Carmen Campos 753 15 15

Considérese las siguientes aplicaciones:

q1: Obtener el nombre y departamento de todos los empleados

q2: Obtener el clave, salado y tasa de impuestos por departamento

q3: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

q1 2 3 2 7

q2 2 1 2 5

q3 1 2 1 4

41



Las aplicaciones se traducirían de la manera siguiente:

q1= Select nom, depto

From empleados

q2= Select cvemp, sal, imp

From empleados

Where depto = X

q3= 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 aplicación qj.

A1 (cvemp) A2 (nom) A3 (sal) A4 (imp) A5 (depto)

q1 0 1 0 0 1

q2 1 0 1 1 1

q3 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) = todas las consultas que accesan A¡ y Aj (accesos en consultas) accesos

en consulta = todos los sitios frecuencia de accesos de una consulta

aff(A1, A1)= (2+1+2)(1) + (1+2+1)(1) = 9

aff(A1, A2)= (1+2+1)(1) = 4

aff(A1, A3)= (2+1+2)(1) + (1+2+1)(1) = 9

aff(A1, A4)= (2 +1+2)(1) = 5

aff(A1, A5)= (2+1+2)(1) + (1+2+1)(1) = 9

aff(A2, A1)= (1 +2+ 1)(1) = 4

aff(A2, A2)= (2+3+2)(1) + (1+2+ 1)(1) = 11

42



aff(A2, A3)= (1+2+1)(1) = 4

aff(A2, A4)= 0

aff(A2, A5)= (2+3+2)(1) + (1 +2+ 1)(1) = 11

A1 A2 A3 A4 A5

Al 9 4 9 5 9

A2 4 11 4 0 11

A3 9 4 9 5 9

A4 5 0 5 5 5

A5 9 11 9 5 16

En la diagonal deberán aparecer los valores más 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= {A1, A2, A3, A4, A5}

Emp1 { A1, A2), Emp2= { A1, A3, A4, A5)

Emp1 = PJcvemp, Nom, Emp

Emp2 = PJCemp, Sal, Imp, Depto Emp

Emp1(Cvemp, Nom)

Emp2(Cvemp, Sal, lmp, Depto)

o en otro caso

Emp1= { A1, A2, A3} Emp2= { A1, A4, A5}

43



Emp1 = PJcvemp, Nom, Depto Emp

Emp2 = PJCemp, Sal, Imp Emp

Emp1(Cvemp, Nom, Sal)

Emp2(Cvemp, Imp, Depto)

El atributo A1 aparece en ambos fragmentos debido a que es la llave primaria de la

relación global. La manera de seleccionar que atributos irían en cada fragmento

depende de las necesidades del sistema.

La reconstrucción de la relación Emp se puede obtener por medio de:

Emp = Emp1 JNcvemp = cvemp Emp2

Esto dado que Cvemp es la llave de la relación global Emp. En general, la inclusión

de la llave de la relación en cada uno de los fragmentos es lo que hace posible la

reconstrucción por medio de la operación de join.

2.2.7 Fragmentación mixta

Los fragmentos son obtenidos por medio de las operaciones de fragmentación, que

pueden relacionarse precedentemente, es posible aplicar la operación de

fragmentación (vertical y horizontal) de manera recursiva, dando como resultado las

condiciones necesarias para la fragmentación. La reconstrucción se logra aplicando

las reglas de reconstrucción en orden inverso de acuerdo a la fragmentación.

44



Para realizar la fragmentación mixta se deberá considerar la necesidad de

información de cada uno de los sitios dentro de la base de datos distribuida, esto es

considérese la siguiente tabla:

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

Se tiene un sitio en el departamento fiscal el cual se encarga del cálculo de los

impuestos, y tres sitios más, 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

fragmentación vertical para obtener un fragmento con los campos necesarios (cvemp,

sal y imp) para este departamento. El resto de la tabla global podría fragmentarse

horizontalmente de acuerdo a cada departamento, obteniendo tres tablas, las cuales se

situarían en cada uno de los tres sitios restantes dentro del sistema distribuido.

Por medio de las siguientes operaciones se realizará una fragmentación mixta,

donde se aplica la fragmentación vertical, seguida por una fragmentación horizontal por

Depto:

Vertical

Emp1 = PJcvemp, Sal. Imp Emp

Select cvemp, Sal, Imp Into Emp1 From Emp

Horizontal

Depto10 = SLdepto=10 PJ Cvemp, Nom, Depto Emp

Select cvemp, nom, depto Into Depto10 from Emp Where depto=10





La reconstrucción de la tabla Emp se define de la siguiente forma:

45



Emp = UN(Depto10, Depto20, Depto30) JNCvemp = Cvemp PJCvemp, Sal, Imp Emp1

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 fragmentación mixta se representa generalmente por medio de un árbol de

fragmentación. En el árbol de fragmentación, la raíz 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 continuación se presenta el

árbol de distribución del ejemplo anterior:

Emp

Emp1

Depto10 Depto20 Depto30

46



H

V

Es importante tomar en cuenta que el orden en el cual se realiza la fragmentación

horizontal y vertical afecta a la fragmentación final.

fragmentación vertical seguida de fragmentación horizontal

fragmentación horizontal seguida de fragmentación vertical

2.2.8 Distribución de los fragmentos

La manera más fácil para realizar la distribución 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 podría tomar en cuenta el hecho, de que tienen la

misma estructura.

2. Hay muchos más fragmentos que relaciones globales, y muchos modelos

analíticos no pueden procesar la solución de problemas que involucran

demasiadas variables.

3. El modelado del comportamiento de las aplicaciones en sistema de archivos es

muy simple (típicamente, las aplicaciones hacen un "acceso remoto a

archivos"), mientras que en aplicaciones de bases de datos distribuidas pueden

hacer un uso más complejo de los datos.

Algunos de estos problemas no tienen una solución satisfactoria; por ejemplo el

punto 3 es particularmente difícil, puesto que el correcto enfoque permitiría evaluar la

distribución de los datos mediante cómo las aplicaciones pueden optimizar el acceso.

47



2.2.9 Criterios generales para la distribución de fragmentos.

En la distribución de los fragmentos, es importante distinguir entre si se va a

diseñar una distribución redundante o no redundante.

La replicación introduce una amplia complejidad en el diseño, porque:

1. El grado de replicación de cada fragmento llega a ser una variable del problema.

1. El diseño de los módulos de lectura en las aplicaciones es complicado por el hecho

que las aplicaciones deben de seleccionar entre varios sitios alternativos, en cual

accesarán el mismo fragmento replicado en estos sitios.

Para determinar la redundancia en la distribución de fragmentos, cualquiera de los

dos métodos 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 método selecciona "todos los sitios

benéficos'.

2. Determinar primero la solución del problema sin réplica, y posteriormente

introducir réplicas iniciando por las más benéficas; el proceso termina cuando

una 'réplica adicional' no es benéfica.

Ambos métodos tienen algunas desventajas. En el caso del método de "los sitios

benéficos”, el hecho de cuantificar el costo y el beneficio para cada fragmento es más

crítico que en el caso no redundante. El método de "la réplica adicional' es un típico

enfoque heurística; con este método, es posible tomar en cuenta que el incremento en

el grado de redundancia es cada vez menos benéfico. La disponibilidad y la

confiabilidad del sistema se ve incrementado si se tienen dos o tres copias de un

fragmento.

48



2.3 Procesamiento de consultas distribuidas

2.3.1 Árbol de operadores de una consulta

Una manera de representar la secuencia en que se realizarán las operaciones de

una consulta, es un árbol de operadores. Considérese la siguiente consulta:

PJSNUM SL área = “Norte” (Prevee JNNumdepto = Numdepto Depto

Un ejemplo de un árbol de operadores para la consulta sería el que aparece en la

figura siguiente. Obsérvese que las hojas del árbol son relaciones globales y cada

nodo representa una operación 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 -

correspondería un árbol también diferente, obteniendo una transformación equivalente.

PJSNUM

SLAREA="Norte"

JNNumdepto=Numdepto

PROVEE DEPTO

El árbol de operadores de una expresión de álgebra relaciona] puede verse como

un árbol gramatical, asumiendo la siguiente forma:

R -> identificador

R -> ( R )

R -> op_uni R

R -> R op_bin R

49



op_uni -> SLF | PJA

op_bin CP | UN | DF | JNF | NJNF | SJF | NSJF

2.3.2 Ejemplos de consultas distribuidas

Supóngase una universidad, que cuenta con las carreras de derecho, contaduría y

administración- 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 Administración

C54 Juan J. Revolución 987 Irapuato 21 Contaduría

C78 Mario V. A. L. Mateos 2345 Celaya 21 contaduría

A29 Adolfo A Juárez 199 Celaya 21 administración

D90 Adriana A Guerrero 987 Irapuato 21 derecho

D73 Sandra F. Revolución 200 Salamanca 20 derecho

A99 Carmen G. A. 1. Mateos 234 Celaya 19 administración

C34 Rocio S. Guerrero 987 Celaya 20 contaduría

Debido a que cada departamento requiere tener la información de sus alumnos, se

realizaría una fragmentación horizontal utilizando la siguiente aplicación:

50



Q: Seleccionar el número de control, nombre, domicilio, ciudad, edad, especialidad

para los alumnos de cada área.

Esto daría como resultado los siguientes tres fragmentos horizontales:

Alumnos1 = SLespecialidad = “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. Revolución Salamanca 20 Derecho

Alumnos2 = SL especialidad = “contaduría” Alumnos

No-control Nombre domicilio ciudad edad especialidad

C54 Juan J. Revolución 987 Irapuato 21 contaduría

C78 Mario V. A. L. Mateos 2345 Celaya 2-1 contaduría

C34 Roció S. Guerrero 987 Celaya 2-0 contaduría

Alumnos3 = SL especialidad = “administración” Alumnos

No-control Nombre domicilio ciudad edad especialidad

A32 José L. Morelos 234 Salamanca 20 administración

A29 Adolfo A Juárez 199 Celaya 21 administración

A99 Carmen G. A. L. Mateos 234 Celaya 19 administración

51



Como se puede observar cada departamento es un sitio dentro de nuestra base de

datos distribuida, conteniendo un fragmento horizontal de la tabla global de acuerdo a

la especialidad.

Considérese, que se requiere una consulta en el departamento de administración en

la cual se deben de obtener el nombre y domicilio de los alumnos de la carrera de

administración que viven en la ciudad de Celaya, dicha consulta no tendría mayor

complicación para el sistema de bases de datos, dado que el proceso se realizaría de

manera local en el sitio de administración.

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 = “administración” AND ciudad = "Celaya” Alumnos

La cual seña traducida por el DBMS local, en el departamento de administración a:

PJ nombre, domicilio SL ciudad = "Celaya” Alumnos3

nombre Domicilio

Adolfo A. Juárez 199

Carmen G. A. L. Mateos 234

Ahora supóngase el caso de que el departamento de contabilidad requiere el nombre,

número de control y especialidad de los alumnos que tienen 21 años o más. Esta

consulta involucro a todos los fragmentos que se encuentran distribuidos en el sistema.

La consulta global sería de la siguiente manera:

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

La cual se traduciría en el sistema distribuido de la siguiente manera:

52



PJ no-control, nombre, especialidad SL edad>=21 (Alumnos1 UN Alumnos2 UN Alumnos3)

no control nombre especialidad

C54 Juan J. contaduría

C78 Mario V. contaduría

A29 Ádolfo A. administración

D90 Adriana A. derecho

En la consulta es necesario realizar una unión entre los tres fragmentos existentes para

reconstruir la relación global y así poder ejecutar la selección sobre totalidad de las

tuplas existentes en al base de datos.

El árbol de operaciones quedaría de esta manera:

PJNO CONTROL, NOMBRE. ESPECIALIDAD

SLEDAD >= ”21”

UN

ALUMNOS1 ALUMNOS2 ALUMNOS3

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 podría variar el orden

de ejecución de las operaciones o reemplazarlas por un conjunto de operaciones

equivalentes. Por ejemplo el siguiente árbol arroja el mismo resultado que el anterior:

53



PJNO CONTROL, NOMBRE. ESPECIALIDAD

UN

SLEDAD >= ”21” SLEDAD >= ”21” SLEDAD >= ”21”


La diferencia que existe entre este árbol y el anterior no radica en el resultado de

las operaciones, sino en el costo de la ejecución 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 transmisión de los fragmentos y

el costa en la ejecución de cada una de las operaciones dentro del sitio.

En el caso del segundo árbol, el costo de transmisión se reduce considerablemente

al transmitir únicamente los datos del fragmento que cumplen con la condición del

select, y el costo de la ejecución de las operaciones se distribuye en cada uno de los

sitios de la base de datos distribuida, ya que el select se realizaría de manera local en

cada uno de los sitios, y la proyección, así como la unión, se realizarían en el sitio que

lanzó la consulta.

Considérese 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. Obsérvese también que el costo de

transmisión se reduce considerablemente ya que no solo se envían únicamente los

dato que cumplen con la condición del select, sino que también se reduce el número de

atributos de la relación que se envían ( no se estarían enviando los atributos de

domicilio, ciudad y edad).

UN

54



PJno_CONTROL, PJno_CONTROL, PJno_CONTROL,

NOMBRE, ESPECIALIDAD NOMBRE, ESPECIALIDAD NOMBRE, ESPECIALIDAD

SLEDAD >= ”21” SLEDAD >= ”21” SLEDAD >= ”21”


Aún 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 demás

sitios, los cuales, posiblemente estén ejecutando sus propias consultas.

Por lo tanto, en el diseño de consultas se debe de considerar los costos en la

ejecución de las operaciones, tanto locales como las que se ejecutarán 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á más, que la mayor parte de las operaciones se realicen en dichos sitios y no

en el que generó la consulta-

También se debe considerar el que posiblemente sea el costo más importante en

una base de datos distribuida, el costo de la transmisión de los datos entre sitios, esto

dado que, los costos de transmisión son mucho mayores al transmitir dentro de una red

WAN, en la que tal vez se involucren transmisiones vía telefónica o vía satélite, que

entre sitios de una red LAN, la cual involucro transmisiones por medio de cables que

interconectan directamente los sitios.

55



2.4 Resumen

El diseño de una base de datos distribuida requiere de una planeación de las

técnicas y de la organización de dicha base de datos, esto, en cuanto al diseño de los

múltiples sitios. Los problemas principales serían la interconexión de los diferentes

sitios, así como la distribución de los datos en dichos sitios.

El diseño de una base de datos distribuida consiste en:

1. Diseñar el esquema conceptual.

2. Diseñar el esquema físico.

3. Diseñar la fragmentación de los datos.

4. Diseñar la distribución 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.

Disponibilidad y confiabilidad de los datos distribuidos: El almacenamiento de

múltiples copias en el sistema permite que las aplicaciones utilicen a cualquier otra

copia cuando la copia que era accesada normalmente no esté disponible.

56



Distribución de la carga de trabajo: La distribución de la carga de trabajo se da a la

par de la distribución de los datos y esto permite que exista un alto grado de

paralelismo en la ejecución de las aplicaciones.

Disponibilidad y costo del almacenamiento: la distribución de las bases de datos

refleja una reducción en el costo del almacenamiento en los sitios.

Existen dos técnicas de diseño de bases de datos distribuidas: La técnica topdown y

la técnica bottom-up. En la técnica top-down se inicia diseñando el esquema global y

la fragmentación de los datos, continuando con la distribución de los fragmentos en los

diferentes sitios, esta técnica es utilizada cuando no existe base de datos alguna.

Cuando una base de datos distribuida se va a agregar a una base de datos ya

existente, la técnica que se utiliza es bottom-top. Esta técnica consiste en:

1. La selección del modelo de datos, para el diseño del esquema global de la base

de datos.

2. La traducción de cada esquema local a un modelo de datos común.

3. La integración de los esquemas locales en el esquema global común.

La fragmentación permite determinar cuales serán las unidades lógicas de

distribución. Las tuplas y atributos de la relación por si mismos, no podrán ser

considerados como unidades lógicas de distribución. El diseño de los fragmentos

consiste en agrupar tuplas y atributos que tengan las mismas propiedades lógicas.

Existen dos tipos básicos de fragmentación, la horizontal y la vertical, existe un

tercer método de fragmentación, el cual es la combinación de los dos anteriores.

La fragmentación horizontal consiste en dividir las tuplas de la relación global en

subconjuntos de tuplas, donde cada subconjunto puede contener datos con

propiedades geográficamente comunes. La fragmentación se realiza, por lo general

por medios de una operación select, mientras que la reconstrucción de la relación

global siempre se llevara a cabo por medio de una operación de union. Existe un

subtipo de fragmentación horizontal conocida como fragmentación horizontal derivada,

esta consiste en la fragmentación de una relación que no se puede basar en sus

propios atributos, pero se deriva de la fragmentación de otra relación.

57



La fragmentación vertical de una relación global es la subdivisión de sus atributos

en grupos; la fragmentación se obtiene al proyectar la relación global sobre cada

grupo. La reconstrucción de la relación global se obtiene por medio de la operación

join.

El tercer tipo de fragmentación es la mixta, esta es obtenida por medio de

operaciones de fragmentación realizadas de manera recursiva, y la reconstrucción se

realizaría aplicando las operaciones respectivas en orden inverso de acuerdo a la

fragmentación.

Después de que se ha realizado la fragmentación de los datos, es necesario

analizar la forma en como se distribuirán dichos fragmentos, la manera más fácil de

realizar esta operación 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. Habría más fragmentos que relaciones globales, y seria difícil procesar la

solución del problema al involucrar demasiadas variables.

3. El modelado del comportamiento de las aplicaciones en sistemas de archivos

difiere en demasía con relación a las aplicaciones de bases de datos.

En la distribución de los fragmentos es importante decidir si se va diseñar una

distribución redundante o no redundante. La replicación introduce una amplia

complejidad en el diseño, porque:

1. El grado de replicación de cada fragmento llega a ser una variable del

problema.

2. El diseño de los módulos 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 métodos para determinar la redundancia en la distribución de

fragmentos:

58



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 solución sin replica del problema, y posteriormente

introducir replicas iniciando por las más benéficas; este proceso termina

cuando una replica no es benéfica.

En el análisis 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 operación 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 diseño de una base de datos distribuida?2.- Mencione y describa los objetivos del diseño de datos distribuidos.3.- ¿Cuándo es conveniente utilizar la técnica bottom-up para diseñar una base de

datos distribuida?4.- Explique brevemente en que consiste cada uno de los tipos de fragmentación

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 fragmentación horizontal, si las aplicaciones son las siguientes:

q1: Obtener los nombres de todos los clientes.q2: Obtener el número del cliente por estado.q3: Obtener el nombre del cliente por empresa.

No_cli Nom_cli Empresa EstadoC01 Juárez Gamesa GtoC02 Vidal Lara QroC03 Ávila Gamesa Jal

59



C04 Mejía Lara JalC05 Herrera Lara GtoC06 Cervantes Gamesa Qro

2.- Fragmentar horizontalmente la siguiente base de datos.Clientes Productos

No_cli Nom_cli Edo No_p Nom_p PrecioC01 Ávila Gto P1 Lápiz 1.20C02 Soria Gto P2 Libreta 3.50C03 Avalos Qro P3 Lapicero 3.20C04 Medina Mich P4 Borrador 1.50C05 Trajo P5 Escuadra 3.10C06 Ávila Qro P6 Plumones 15.20

Compras

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

q1: Obtener el número del cliente por estado.q2: Obtener el número 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 fragmentación vertical, si las aplicaciones son las siguientes:

q1: Obtener los nombres de todos los clientes.q2: Obtener el número 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 PromAL1 Aguilar 19 Rev. 115 Celaya 3 Química 85.7

60



AL2 Jiménez 18 Hgo. 120 Irapuato 1 Electrónica 83.2AL3 Trejo 18 Rev. 315 Celaya 1 Sistemas 75.2AL4 Soria 20 Hgo. 422 León 4 Química 89.7

q1: Obtener el número de alumno por especialidad.q2: Obtener número y nombre del alumno por ciudad.q3: Obtener el nombre y edad por promedio.q4: Obtener el número y semestre del alumno por dirección.

Matriz de accesos.

S1 S2 S3

q1 3 1 1

q2 2 0 1

q3 2 1 2

q4 3 5 1

Bibliografía

[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


61



Objetivo

El alumno comprenderá el concepto optimización de consultas distribuidas y

entenderá las técnicas para la ejecución de la operación join.

Introducción

En este capítulo se analizará el hecho de que aún cuando se cuente con una buena

estrategia de fragmentación o un buen procesamiento de consultas, no implica que se

tenga un funcionamiento correcto del sistema. Además se tratara el concepto de

62



Capítulo III

Optimización de estrategias de accesos

optimización de consultas, lo cual implica reducidas a una forma equivalente más

pequeña y fácil de manejar para el sistema, esto es, a su forma canónica. También se

analizaran los diferentes métodos de ejecución de la operación Join.

3.1 Importancia de la optimización de consultas

El término “optimización” es algo inapropiado, puesto que las' técnicas para

optimizar la ejecución de una consulta generalmente no lo logran y únicamente se

obtienen estrategias para un "buen” acceso. Por eso, al referirse a este hecho como

optimización 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 también 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.

Puntos para estrategia de consultas.

1. La selección de estrategias alternativas para la ejecución de las consultas, tanto

en ambientes centralizados como distribuidos, es hecha de acuerdo al

desempeño requerido.

2. Las medidas típicas asumidas en un sistema centralizado de bases de datos son

el número de operaciones I/O y el tiempo de uso del CPU requerido para realizar

las consultas.

3. En bases de datos distribuidas de debe considerar además, el costo de la

transmisión de datos entre los sitios participantes de la consulta. No obstante,

no existe ningún convenio en la importancia relativa del costo de transmisión

contra I/O local. A pesar de esto, se deberá de encontrar la sentencia que

minimice el costo de transmisión, lo cual es nuestra meta más importante.

La selección de una estrategia de procesamiento de consultas involucro:

1 . Determinar las copias físicas de los fragmentos sobre los cuales se ejecutará la

consulta, obteniendo una expresión de consulta sobre fragmentos..

63



2. Seleccionar el orden de ejecución de las operaciones; como se puede ver, esto

involucro la determinación de una buena secuencia de operaciones join, semi-

join y unión.

3. Seleccionar el método para la ejecución de cada operación; esto involucro el

cambio de ejecución de algunas operaciones algebraicas.

Los problemas anteriores no son independientes, por ejemplo, la elección de la

mejor materialización para una consulta depende del orden en el cual son ejecutadas

las operaciones; por lo tanto, utilizar procedimientos para resolverlos de manera

independiente produciría errores. No obstante, una manera fácil de obtener métodos

de optimización 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 ejecución de las operaciones es óptima.

3. Las operaciones son agrupadas en los programas locales.

En la práctica, 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. Además, no solo se pude interpretar una expresión de álgebra relacional

por sus especificaciones semánticas de una consulta, sino que además se deberá de

tomar en cuanta la secuencia de las operaciones. Desde este punto de vista, dos

expresiones con la misma semántica pueden describirse por medio de dos secuencias

de operaciones diferentes. Por ejemplo, considérese la siguiente relación:

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

64



Cvemp Nom Sal Imp Depto

E12 Juan Pérez 4500 15 15

E56 José Hernández 8756 15 9

E78 Luis Pérez 9254 15 17

E98 Maria Solís 12345 25 22

E32 John Smith 25489 25 22

E91 Roció Sánchez 4600 15 8

E73 Carmen Campos 8753 15 15

Se tiene las siguientes consultas:

Select Nom, Depto

From Emp

Where Depto = 15

PJ Nom, depto SL depto=15 Emp

Nom Depto

Juan Pérez 15

Carmen Campos 15

y

SL depto = 15 PJ Nom, depto Emp

Nom Depto

Juan Pérez 15

Carmen Campos 15

65



Son dos expresiones equivalentes, las cuales arrojan el mismo resultado, pero

definidas por dos secuencias de operadores diferentes.

Transformaciones equivalentes por álgebra relacional

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.

Considérense dos expresiones E1 y E2 de álgebra relacional, la equivalencia de dos

expresiones se representa E1 ↔ E2.

Se podrán obtener transformaciones equivalentes sistemáticamente más pequeñas,

es decir expresiones de dos o tres operadores relacionases. Estas transformaciones

son clasificadas en categorías de acuerdo a las operaciones que involucro. Sean U y

B operaciones unitarias y binaria respectivamente, R y S relaciones, entonces se

tienen las siguientes propiedades:

Conmutatividad de operaciones unitarias:

U1 U2 R ↔ U2 U1 R

Conmutatividad de operaciones binarias:

Una operación binaria es conmutativa cuando el resultado de la operación es el

mismo, cualquiera que sea el orden de los elementos con los que se opera.

R B S ↔ S B R

Asociatividad de operaciones binarias:

Propiedad asociatividad: para cualesquiera elementos del conjunto A no importa

el orden en que se operen las parejas de elementos, mientras no se cambie el

orden de los elementos siempre dará el mismo resultado

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

Idempotencia de operaciones unitarias:

66



http://es.wikipedia.org/wiki/Operaci%C3%B3n_binaria

El término idempotente se usa para describir una operación que produce los mismos resultados si se ejecuta una o varias veces. Ésta es una propiedad muy útil en numerosas situaciones, ya que su empleo hace que una operación pueda ser repetida tantas veces como sea necesario sin causar efectos involuntarios. Con operaciones no idempotentes, el algoritmo podría tener que mantener un registro de si la operación ya hubo sido realizada o no.

Estrictamente, una secuencia que nunca produce efectos secundarios puede ser considerada idempotente (siempre y cuando no haya operaciones concurrentes sobre el mismo conjunto de recursos)1

UN EJEMPLO DE IDEMPOTENCIA ES LA MULTIPLICACION DE 1*1 = 1 o de 0*0 = 0 ASI COMO TAMBIEN LA MULTIPLICACION DE 1*1*1*1*1*1*1*1*1 = 1

U R ↔U1 U2 R

Distributividad de operaciones unitarias con respecto a operaciones binarias:

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

Factorización de operaciones unitarias:

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

Las siguientes son propiedades que también pueden ser aplicadas dentro de la

transformación de expresiones:

R NJN R ↔ R

R UN R ↔ R

R DF R ↔ 0

R NJN SLF R ↔ SLF R

R UN SLF R ↔ R

R DF SLF R ↔ SLNOT F R

(SLF1 R) NJN (SLF2 R) ↔ SL F1 AND F2 R

(SLF1 R) UN (SLF2 R) ↔SL F1 OR F2 R

67



http://es.wikipedia.org/wiki/Idempotencia_(inform%C3%A1tica)#cite_note-0

(SLF1, R) DF (SLF2 R) <-> SL F1 AND NOT F2 R

3.2.2 Determinación de subexpresiones comunes

Una parte importante en la transformación de expresiones equivalentes es el

descubrir las subexpresiones comunes; las cuales aparecen en más de una vez en la

consulta, esto es importante, ya que de esta manera solo se evaluara una sola vez

dicha expresión. 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 subexpresiónes 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 método. Considérese las siguientes tablas

de una base de datos:

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 número de 373 pero que no ganan más de $35,000. Una

expresión para dicha consulta seria:

Select A.nom

From A EMP inner JOIN B DEPT in (A.deptnum = B.deptnum)

Where B.gtenum = ‘373’ < 35001

PJEMP.Nom((EMP JN DEPTNUM = DEPTNUM SL GTENUM=373 DEPT) DF

(SL SAL>35000 EMP JN DEPTNUM=DEPTNUM SL GTENUM=373 DEPT))

68



A simple vista se puede deducir que existe una subexpresión repetida en la

consulta, esta es:

EMP JN DEPTNUM=DEPTNUM SL GTENUM=373 DEPT

Pero véase el árbol de operadores:

PJ EMP_NOM

DF

JNDEPTNUM=DEPTNUM JN DEPTNUM=DEPTNUM

EMP SLGETNUM=373 SLSAL>35000 SLGETNUM=373

DEPT EMP DEPT

Se comienza factorizando el select sobre SAL con respecto al join (al hacer esto, el

select es desplazado hacia arriba).

PJ EMP_NOM

DF

JNDEPTNUM=DEPTNUM SL SAL>35000

EMP SLGETNUM=373 JNDEPTNUM=DEPTNUM

DEPT EMP SLGETNUM=373

DEPT

69



A continuación 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 continuación:

PJEMP-NOM

EMP SLGTENUM=373

DEPT

3.3 Métodos de ejecución de JOIN

En la ejecución de una operación 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 elección de la estrategia correcta, dichos factores son:

El orden físico de las tuplas en la relación.

La presencia de índices y el tipo de estos.

El costo de creación de un índice temporal para el procesamiento de una

consulta

Para el resto de la sección se considerará la siguiente expresión:

deposito JN cliente

Y se asumirá que la relación depósito cuenta con 10,000 tuplas y clientes consta de

200 clientes.

70



SLSAL>35000

DF

JNDEPTNUM=DEPTNUM

Métodos de ejecución del Join Existen diferentes algoritmos que pueden obtener transformaciones eficientes en el procesamiento de consultas. Join en bucles (ciclos) anidados Join en bucles anidados por bloques Join por mezcla Join por asociación. Join por asociación híbrida Join Complejos Outer Join (Join externos)

3.3.1 Iteración simple (Join en bucles (ciclos) anidados)

Supóngase 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 más optima, se reduciría

significativamente el número de bloques accesados ( considérese un bloque como un

conjunto físico de tuplas ). Supóngase que se utiliza el siguiente procedimiento para

procesar el join. En él se lee cada tupla de la relación deposito, esto requeriría accesar

10000 bloques de almacenamiento físico bajo el peor de los casos, considerando que

cada una de las tuplas de la relación deposito se encuentran en bloques diferentes. Si

se consideran que 20 tuplas de la relación deposito se encuentran almacenadas en un

bloque, entonces se tendrán 10000120 = 500 bloques distintos accesados.

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

71



Si se compara cada tupla de clientes con cada una de las tuplas de la relación

deposito, esto llevará a hacer 10,000 referencias a cada tupla de clientes. El número

exacto de accesos a disco depende del tamaño 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 relación de clientes, se tendrán que hacer 2,000,000 lecturas a la

relación de clientes. Si se asume que 20 tuplas de la relación clientes son

almacenadas en un bloque, entonces se requieren de 10 accesos para leer la relación

completa, Por lo tanto, solo se requieren 10 accesos en lugar de 200. Esto implica que

se accesarán 100,000 bloques de la tupla clientes para procesar la consulta.

El costo de esta técnica es de 500 accesos a depósitos más 100,000 accesos a

clientes para un total de 100,500 bloques accesados.

3.3.2 Iteración orientada a bloques

Se obtiene un mayor ahorro en el acceso si se procesa la relación en base a un

proceso por bloques en vez de un proceso basado en tuplas. Nuevamente, se asume

que las tuplas de la relación depósitos y de la relación clientes son almacenadas de

manera continua también, Se usará el procedimiento siguiente para procesar depósitos

JN clientes.

For each bloque Bd of deposito do

begin

for each bloque Be of dientes do

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.

72



Este procedimiento desarrolla el join considerando un bloque entero de tuplas de la

relación deposito en vez de una tupla individual- Aún, se leerá completa la relación

deposito a un costo de 500 accesos. Sin embargo, en lugar de realizar una lectura a la

relación cliente por cada tupla de la relación depósito, se leerá la relación cliente por

cada bloque de la relación depósito. Entonces, se tienen 500 bloques de la relación

deposito y 10 bloques de la relación diente, requieren 10*500= 5000 bloques

accesados. De esta manera, el costo en términos de bloques accesados es de 5500

accesos (5000 accesos a clientes más 500 accesos a depósitos). Claramente se

puede ver un significativo ahorro en el número de accesos necesarios en comparación

con la técnica anterior.

3.3.3 Merge - Join

En aquellos casos en los cuales ninguna relación 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 del cual se realizara el join.

Supóngase que ambas relaciones, clientes y depósitos, están ordenados por

nombre-cliente. Se podrá entonces realizar una operación merge-join.

Para ejecutar un merge-join, se requiere de un punto de asociación en cada

relación, Estos puntos son direccionados a la primera tupla de cada relación. Los

punteros son movidos a lo largo de la relación y si un grupo de tuplas de la relación

contiene el mismo valor que el atributo del join, se leen dichas tuplas, puesto que las

tuplas están ordenadas, el conjunto de tuplas con el mismo valor estarán consecutivas.

Esto permite leer cada tupla una sola vez y en el caso de que las tuplas estén

almacenadas de manera ordenada, entonces se leerá cada bloque exactamente una

vez.

A continuación se muestra el esquema del merge-join aplicado al ejemplo de

deposito JN cliente.

73



Pd := dirección de la primera tupla de deposito;

Pc:= dirección de la primera tupla de clientes;

while (pc ≠ null) do

begin

tc:= tupla a la 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;

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.

74



Una desventaja de este método es que ambas relaciones deben de estar ordenadas

físicamente, es decir en el medio de almacenamientos.

3.3.4 Uso de índices

Las tres estrategias que se han considerando dependen de la técnica usada para

almacenar físicamente las relaciones. El merge-join requiere de un almacenamiento

en orden. La iteración orientada a bloques requiere que las tuplas de cada relación

estén ordenadas físicamente. Únicamente la iteración simple, puede ser aplicada sin

importar la forma en como están almacenadas las tuplas de las relaciones. El costo de

la iteración 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 físicamente las tuplas de las relaciones, el join puede ser ejecutado con

una reducción de accesos significativa.

Frecuentemente los atributos del join forman parte de la llave del índice de una

relación. En estos casos se puede considerar una estrategia de join que utiliza estos

índices. La iteración simple puede ser más eficiente si existe un índice en la relación

cliente para el atributo nombre ~ cliente. Cuando se tiene una tupla d de la relación

deposito no es necesario recorrer la relación clientes completa. El índice es usado

para buscar las tuplas en clientes para los cuales el nombre-cliente sea igual a

d[nombre-cliente].

Se requieren 10000 accesos para leer la relación depósito. Si se asume que la

relación clientes tiene 200 tuplas, y que se almacenan 20 apuntadores por bloque,

entonces, se requieren en promedio 2 accesos a bloques más un bloque accesado

para leer la relación cliente. Con esto, son necesarios 3 accesos a bloques en la

relación deposito en lugar de 200. Entonces, si por cada tupla de la relación depósito

son necesarios 3 accesos a bloques darían como resultado un total de 30000 accesos,

más los 10000 de la relación depósito.

Aunque un costo de 40000 accesos pareciera alto, se debe tomar en cuenta que se

obtendría un mejor resultado solo si las tuplas están ordenadas físicamente, También

se debe recordar que inicialmente, esta estrategia, tiene un costo de 2 millones de

accesos a bloques.

75



Entonces el hecho de obtener un ahorro tan alto de accesos es suficiente para

justificar la creación de índices.

3.3.5 Hash join

La construcción de un índice para la ejecución de un join, convendría, si este índice

es un árbol B+. Dicho índice sera usado una sola vez para la ejecución de un simple

join.

Una función hash h es usada sobre las tuplas de ambas relaciones sobre los

atributos básicos del join. Si d es una tupla de la relación deposito y en c es una tupla

de la relación clientes entonces d y c serán comparados solo si h(c) = h(d). Si h( c ) ≠

h( d ) , entonces d y c tendrán 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 función hash sean iguales.

A continuación 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

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

76



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

end

En el algoritmo anterior, se asume que:

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

77



Hc0, Hc1, ... , Hcmax denotan el contenedor del apuntador a las tuplas de la

relación diente, cada uno vacío al inicio.

Hd0, Hd1, ... , Hdmax denotan el contenedor del apuntador a las tuplas de la

relación deposito, cada uno vacío al inicio.

Se usarán estas propiedades para estimar el costo del desempeño de un hash join.

La asignación 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 operación es de 510 accesos a bloques si las tuplas de ambas

relaciones, clientes y deposito, son almacenadas de forma continua físicamente.

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 ningún

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 relación deposito en el

contenedor i y rc es el conjunto de tuplas de la relación clientes localizadas en el

contenedor i. Este join es procesado utilizando una iteración simple, ya que rd y rc son

lo suficientemente pequeños, ambos pueden estar en la memoria principal. Desde el

momento que se aplico una función hash a una tupla y esta se coloco en un

contenedor, cada tupla es leída 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 función hash, y una segunda lectura dentro de los contenedores. Es necesario

78



elegir una función 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 supóngase 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

técnicas antes mencionadas. Considerando que nombre - cliente es la

llave para la relación clientes. Es posible saber que el resultado de este

join, tiene a lo más 10000 tuplas ( número de tuplas en la relación

deposito). Si es posible construir un índice para sucursal sobre el atributo

nombre-sucursal, se podría procesar lo siguiente:

sucursal JN (deposito JN cliente)

Considerando que nombre - sucursal es la llave para sucursal es posible

saber que se examinarán únicamente una tupla de la relación sucursal

para cada una de las 10000 tuplas de la operación deposito JN cliente. El

número exacto de bloques accesados en esta estrategia depende de la

manera en que la operación deposito JN cliente es ejecutada, y la forma

en que la relación sucursal es almacenada físicamente.

79



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 técnica primero requiere la construcción de dos

índices:

En sucursal con nombre-sucursal.

En cliente con nombre-cliente.

A continuación se considera para cada tupla t en la relación 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 operación que no tiene una

correspondencia directa dentro del álgebra relacionar. En cambio, combina 2

operaciones dentro de una operación especial. El costo relativo depende de la forma

en como las relaciones son almacenadas físicamente.

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 están

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 técnicas que se presentarán a continuación pueden ser adaptadas en otras

arquitecturas en las cuales cada procesador tiene su propia memoria privada.

3.3.8 Join paralelo

En las técnicas antes mencionadas para el procesamiento de un join en un

procesador solo, la eficiencia se logra reduciendo el número 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 ningún procesador caiga en un overhead. Un

join paralelo que utiliza N procesadores, tomará 1/N del tiempo que se tardaría en

ejecutar el mismo join en un solo procesador. En la practica la velocidad es más

dramática por varias razones:

Un overhead ocurre en la partición del trabajo entre procesadores.

Un overhead ocurre en la recolección 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 aproximación,

ya que algunos procesadores, tienen más 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.

Considerando nuevamente el ejemplo deposito JN cliente, se asume que se tiene N

procesadores P1, P2, ..., PN. Se divide la relación de deposito en N partes de igual

81



tamaño; deposito1, deposito2, ..., depositoN Se supone, por facilidad, que el tamaño de

la relación deposito es múltiplo de N, entonces cada procesador P i procesa depositoi

JN cliente en paralelo. En el paso final, se realizara la unión de los resultados

parciales obtenidos por cada procesador.

El costo de esta estrategia depende de vados factores:

La selección del algoritmo usado para cada procesador.

El costo de la construcción del resultado final.

El retraso generado por la retención de recursos. Aunque cada procesador

accesa su propia partición de la relación deposito, todos los procesadores

accesan a la relación cliente. Si la memoria principal no es suficientemente

grande para almacenar la relación cliente, el procesador necesita sincronizar

sus accesos a la relación cliente con otros procesadores para reducir el número

de accesos a disco.

Se sugiere que se utilice alguna técnica para realizar la división del trabajo entre

procesadores para reducir el espacio utilizado de memoria. Una técnica simple es la

de utilizar una versión de hash-join para trabajar en paralelo. En donde se escogerá

una función hash cuyo rango sea { 1, 2, ..., N }. Esto daría 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:

r1 JN r2 JN r3 JN r4

Es posible ejecutar t1 (r1 JN r2) en paralelo con t2 (r3 JN r4) y cuando este proceso

termine se ejecutará:

t1 JN t2

82



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 P1 la ejecución de r1 JN r2

y al procesador P2 se asigna r3 JN r4.

Como las tuplas resultantes del proceso de P1 están disponibles para P3 , así como

las tuplas resultantes del procesador P2 , entonces P3 podrá comenzar el proceso ( r1

JN r2) JN (r3 JN r4 ) antes de que r1 JN r2 y r3 JN r4 hallan terminado.

A continuación se muestra el algoritmo utilizado por el procesador P3 para procesar

el join. Las tuplas resultantes de P1 y P2 son colocadas en una cola para ser

procesados por P3, P1 y P2 pueden haber utilizado cualquier técnica para el

procesamiento del join. La única modificación sería que cuando una tupla t es

adicionada al resultado, debe de colocarse como disponible para P3 en la cola. Se

deberá considerar también, entradas especiales en la cola que consisten ENDP1 y

ENDP2, que indican la finalización del procesamiento del join en los procesadores P1 y

P2 respectivamente. Para ejemplo se utilizo un 4-way join pero pude extenderse para

procesar N-way join.

83



r1

r2

r3

r4

P1

P3

P2

done1:= falso;

done2:= falso;

from1:= 0;

from2:= 0;

result := 0 ;

while not donel or not done2 do

begin

if la cola esta vacía then esperar hasta que no este vacía;

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 optimización

Se pueden identificar cuatro pasos generales para el proceso de optimización de

una consulta.

84



1.- Convertir la consulta en alguna representación interna.

El primer paso en el proceso de una consulta es convertirla en alguna

representación interna que sea más apropiada para la manipulación 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 optimización.

Se deberá hacer una elección 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:

PJPnombre

SLprovee.prod=’P2’

JN

Proveedor Provee

Esto da como resultado una expresión, dentro del álgebra relacional que se puede

manejar más fácilmente por el sistema:

PJ ( SL ( Proveedor JN Provee ) provee.prod=’P2’ ) nombre

2.- Convertir a forma canónica.

La definición de forma canónica es el punto central en muchas áreas de las

matemáticas y disciplinas relacionadas. Es posible definirla como sigue: Se tiene un

conjunto Q de objetos (Queries) y la definición de equivalencia entre ellos (dos queries

85



son equivalentes, si y solo si, producen el mismo resultado), se tiene también un

subconjunto C de Q, el cual se llama conjunto de formas canónicas de Q ( bajo la

definición de equivalencia ), si y solo si, algún objeto q en Q es equivalente a solo un

objeto c en C. El objeto c es llamado la forma canónica de q. Todas las propiedades

que se aplican a q se aplican a la forma canónica c; Así, es suficiente realizar el

estudio del pequeño conjunto de formas canónicas, y no del gran conjunto de Q.

Durante este paso, el optimizador ejecuta un número de transformaciones que son

"garantizadas para ser correctas', en relación con los datos actuales y las rutas de

acceso que existen en la base de datos. El punto es que la mayoría de los lenguajes

de consulta permiten que hasta la más simple consulta pueda ser expresada en una

variedad de formas distintas. Tan solo en SQL, la consulta de la sección anterior tiene

ocho posibles representaciones.

La obtención de expresiones equivalentes se logra por medio de reglas de

transformación bien definidas y permitidas dentro del álgebra relacionar.

3.- Elegir el procedimiento de bajo nivel.

Habiendo convertido la representación interna de la consulta en alguna forma más

deseable (forma canónica), se debe decidir como se evaluará la consulta, representada

por su forma canónica.

En este paso se debe considerar la existencia de índices, rutas de acceso,

distribución de los datos almacenados, almacenamiento físico de los registros, etc.

La estrategia básica es considerar la consulta como una serie de operaciones de

"bajo nivel" join, select, project, etc.), con cierta interdependencia entre ellos. Para

cada operación de bajo nivel, se tendrá un conjunto de procedimientos predefinidos;

Por ejemplo, un conjunto de procedimientos para la selección sería, un procedimiento

para cuando los campos están indexados, y otro para cuando no lo están, pero están

almacenados físicamente en orden, etc. Cada procedimiento tiene asociado un costo.

4.- Seleccionar el procedimiento más económico.

86



El paso final del proceso de optimización involucro la construcción de un conjunto

de planes de ejecución de consultas candidatas seguido de la elección del mejor (más

económico) de estos planes.

Cada plan es construido con la implementación de los procedimientos necesarios

para ejecutar la consulta. Será necesario un procedimiento por cada operación 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 más económico para la ejecución de la consulta. La

asignación del costo a algún plan involucrará el número de accesos a disco, la

utilización del CPU, etc.

Dentro del costo de una consulta también deberá tomar en cuenta la transmisión 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 información 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 información se requiere y en que sitio se encuentra.

Entonces se debe decidir la forma en que se realizará el proceso de recolección de

datos. Es decir, la tabla es enviada íntegramente al sitio que lanzo la consulta o solo

los registros que cumplen con la condición, tal vez es necesario que otro sitio realice el

proceso de recolección 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 más alto es el de la

comunicación, por ello es necesario utilizar estrategias para reducirlo. Como se vio en

el capítulo 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 más demandantes.

El problema de optimización de consultas es minimizar una función de costo tal que función de costo total = costo deI/O + costo de CPU + costo de comunicación.

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 selección de estrategias alternativas para la

ejecución de las consultas, tanto en ambientes centralizados como distribuidos, es

hecha de acuerdo al desempeño requerido. Las medidas típicas asumidas en un

sistema centralizado de bases de datos son el número de operaciones I/O y el tiempo

de uso del CPU requerido para realizar las consultas. En bases de datos distribuidas

88



se debe considerar además, el costo de la transmisión de datos entre los sitios

participantes de la consulta.

La selección de una estrategia de procesamiento de consultas involucro:

1. Determinar el número de copias de los fragmentos sobre los cuales se

ejecutara la consulta, obteniendo una expresión de consulta sobre

fragmentos.

2. Seleccionar el orden de ejecución de las operaciones.

3. Seleccionar el método para la ejecución de cada operación.

Una expresión de álgebra relacional no solo se expresa por medio de sus

especificaciones semánticas, sino también por medio de una secuencia de operadores,

y desde este punto de vista dos expresiones con la misma semántica 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 E1 ↔ E2.

Es posible obtener expresiones equivalentes pequeñas 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:

U1 U2 R ↔ U2 U1 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

89



Idempotencia de operaciones unitarias:

U R ↔ U1 U2 R

Distributividad de operaciones unitarias con respecto a operaciones binarias:

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

Factorización de operaciones unitarias:

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

Las siguientes son propiedades que también pueden ser aplicadas dentro de la

transformación de expresiones:

R NJN R ↔ R

R UN R ↔ R

R DF R ↔ 0

R NJN SLF R ↔ SLF R

R UN SLF R ↔ R

R DF SLF R ↔ SLNOT F R

(SLF1 R) NJN (SLF2 R) ↔ SL F1 AND F2 R

(SLF1 R) UN (SLF2 R) ↔SL F1 OR F2 R

(SLF, R) DF (SLF2 R) <-> SL F1 AND NOT P2 R

Una parte importante en la transformación de expresiones equivalentes es el

descubrir subexpresiones comunes, las cuales podrían aparecer más de una vez en la

consulta, esto es importante, dado que, solo se tendrían 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 serían ramas

similares, las cuales se convertirán en una sola rama.

Algo que también se debe de considerar es el costo de procesamiento de las

operaciones join. En esta parte influyen varios factores, los cuales se deberán tomar

en cuenta:

90



El orden físico de las tuplas en la relación.

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 técnicas de ejecución de join se tiene las siguientes:

Iteración simple: Cada una de las tuplas de una relación es comparada con todas las

tuplas de la otra relación.

Iteración orientada a bloques: Se asume que las tuplas de la relación están

almacenadas en orden y de manera continua. Esta técnica leerá un bloque de tuplas

en lugar de una tupla individual, así se compara un bloque de una relación contra los

bloques de la otra relación.

Merge-join: Esta técnica requiere que las tuplas están almacenadas de forma ordenada

de acuerdo al atributo por el cual se va a realizar el join. Cada relación tendrá un

puntero que indica la posición de lectura para el join, al ir leyendo, dichos punteros

avanzarán. Al encontrarse la tupla que tiene el mismo valor que la tupla con la que se

esta ejecutando el join, el recorrido sobre la relación se detiene y el puntero se coloca

de nuevo en la primera posición, esto debido a que las tuplas están ordenadas y no

debe existir otro valor más allá de la posición del puntero. Se repetirá este proceso

hasta que se recorran todas las tuplas de la primera relación.

Hash-join: Una función hash h es usada sobre las tuplas de ambas relaciones

sobre los atributos básicos del join. Si d es una tupla de la relación deposito y en c es

una tupla de la relación clientes entonces d y c serán comparados solo sí h(c) = h(d). Si

h(c) ≠ h(d), entonces d y c tendrán valores diferentes para los atributos básicos del

join. Sin embargo es posible que d y c tengan valores diferentes para los atributos

básicos del join a pesar de que sus valores en la función hash sean iguales.

Three-way join: Si se tiene que un join envuelve tres relaciones, se podrían utilizar

algunas de las siguientes estrategias:

91



1 . Se procesa el join con cualquier técnica, si es posible se deberá construir un

índice sobre los atributos básicos del join, se procesarán primero un par de

relaciones y el resultado de este join se procesara con la tercer relación,

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.El resultado final será la combinación de los resultados de las

relaciones. Esto requerirá la utilización 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 más

equitativamente posible, tratando de que ningún procesador caiga en un overhead.

Pipeline multiway join: Existe la posibilidad de procesar varios joins en paralelo.

Considérese el siguiente join entre cuatro relaciones:

r1 JN r2 JN r3 JN r4

Es posible ejecutar t1 (r1 JN r2) en paralelo con t2 (r3 JN r4) y cuando este proceso

termine se ejecutará:

t1 JN t2

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 P1 la ejecución de r1 JN r2

y al procesador P2 se asigna r3 JN r4.

92



Como las tuplas resultantes del proceso de P1 están disponibles para P3 , así como

las tuplas resultantes del procesador P2 , entonces P3 podrá comenzar el proceso (r1 JN

r2 ) JN (r3 JN r4 ) antes de que r1 JN r2 y r3 JN r4 hallan terminado. Las tuplas

resultantes de P1 Y P2 son colocadas en una cola para ser procesadas por P3 , para

obtener el resultado final.

Se tienen cuatro pasos generales en el proceso de optimización de una consulta:

1. Convertir la consulta en alguna representación interna: El primer paso en el

proceso de una consulta es convertirla en una representación interna que sea

más apropiada para la manipulación de la información, esto de manera que los

pasos subsecuentes no se vean afectados.

2. Convertir a una forma canónica: Se tiene un conjunto Q de objetos (Queries) y

la definición de equivalencia entre ellos (dos queries son equivalentes, si y

solo si, producen el mismo resultado), se tiene también un subconjunto C de

Q, el cual se llama conjunto de formas canónicas de Q (bajo la definición de

equivalencia), si y solo si, algún objeto q en Q es equivalente a solo un

objeto c en C. El objeto c es llamado la forma canónica de q. Lo importante

en este punto, es que, la mayoría de los lenguajes de consulta permiten

representar una consulta en varias formas distintas. Así, la obtención de

expresiones equivalentes se logra por medio de reglas de transformación

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 canónica, aquí, la estrategia básica es

considerar la consulta como una serie de operaciones de bajo nivel, para

cada operación se tendrá un conjunto de procedimientos predefinidos.

4. Seleccionar el procedimiento más económico: El paso final es la contracción de

un conjunto de planes de ejecución de consultas candidatas seguidas de la

elección del mejor de los planes. Dentro del costo de una consulta también

deberá tomarse en cuenta la transmisión 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

información se requiere y en que sitio se encuentra. Entonces se deberá de

93



diseñar una estrategia de recolección de datos. Es necesario recodar que

dentro de un sistema de bases de datos distribuidas el costo más alto es el

de la comunicación, 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 cuenta en la optimización

de una consulta?

2.- ¿Mencione que se debe de considerar para seleccionar una estrategia de

procesamiento de consultas?

3.- ¿Que condición deben cumplir dos expresiones para que sean consideradas

equivalentes?

4.- ¿Que es una subexpresión común?

5.- ¿Que puntos se deberá tomar en cuenta para seleccionar una buena

estrategia de ejecución de join?

6.- ¿Que métodos de ejecución de join existen?

7.- Explique brevemente el funcionamiento de la estrategia de join paralelo.

8.- Explique brevemente los pasos para el proceso de optimización de una

consulta.

3.7 Ejercicios

Para los siguientes ejercicios, se utilizaran las tablas EMP y DEPT del ejemplo de la

sección 3.2.2 y la siguiente consulta:

EMP(id-emp, nom, sal, deptnum, edad)

DEPT(deptnum, descr, gtenum)

94



Obténgase el nombre de los empleados mayores de 40 años del departamento

sistemas con sueldo mayor a $11,000.

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

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

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

4.- Considérese 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 más 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.; Repñnted Juiy, 1990

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

Publishing Company-, U.S.A.; Reprinted July, 1995

95



Objetivo

El alumno comprenderá y manejara los conceptos de control de concurrencia,

seguridad y recuperación dentro del ámbito de las bases de datos distribuidas

Introducción

Este capítulo trata el aspecto del control de concurrencia, de cómo con etiquetas de

tiempo o bloqueos de registros, es posible mantener la integridad de la base de datos

en un ambiente multiusuario. También se habla a cerca de los métodos de

recuperación del sistema en base a bitácoras, check-points y respaldos. Por ultimo, el

capítulo expone algunas técnicas para garantizar la seguridad del sistema, por medio

de matrices de autorización, evitando así el acceso a usuarios no autorizados.

4.1 Control de concurrencia

4.1.1 Seriabilidad en bases de datos centralizadas

Una transacción accesa la base de datos usando primitivas de lectura y escritura.

Sean Rj(x) y Wi(x) las operaciones de lectura y escritura respectivamente, usadas en la

transacción 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 transacción no están

separados sino por el contrario, trabajan en conjunto.

96



Capítulo IV

Procesamiento de transacciones en bases de datos distribuidas

Una entrada de bitácora es una secuencia de operaciones hechas por una

transacción. Por ejemplo, la siguiente serie de operaciones sería una planificación:

S1: Rj (x) Rj (x) Wi (y) Rk (X) Wj (X)

Dos transacciones Ti y Tj se ejecutan en sede dentro de una planificación S, si la

ultima operación de Ti precede a la primera operación de Tj en S o viceversa); En otro

caso las transacciones se ejecutarían concurrentemente.

Una planificación es serial si las transacciones no se ejecutan concurrentemente, es

decir, una detrás de otra. Por ejemplo, la siguiente planificación S2 es serial:

S2: Ri (x) Wi (y) Ri (y) Rj (x) Wj (y) Rk (y) Wk (X)

Ti Tj Tk

R(x)

W(y)

R(y)

R(x)

W(y)

R(y)

W(x)

Esto sería

S2: Ti Tj Tk

En una planificación, si la operación Oi precede a la operación Oj, se indica como

Oi < Oj, es decir Oi se ejecuta primero que Oj, entonces en S2 Ti < Tj y Tj < Tk.

97



La ejecución serial de una transacción puede ser descrita por una planificación

señal (denominada por Serial (S1) ). De cualquier forma no es posible forzar a las

transacciones a ejecutarse serialmente. Algo ideal sería que las transacciones se

ejecutaran lo más concurrentemente posible, cuidando que esta ejecución sea

correcta. La definición más aceptada de correcto en una planificación es basada en la

seriabilidad:

Una planificación es correcta si esta es seriabilizable, esto es, que el

resultado obtenido por esta sea equivalente al resultado de una

planificación 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 bitácora serializable podría producir. Un mecanismo de control de

concurrencia restringe las posibles secuencias de operación ejecutados por una

transacción que fuerza a otra transacción 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 operación de lectura lee los mismos valores que fueron producidos por

las mismas operaciones de escritura en ambas planificaciones.

2. La operación 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 también considerar el hecho de que dos operaciones

pueden llegar a caer en conflicto:

Dos operaciones están en conflicto si, ellas procesan el mismo dato y al

menos una de estas operaciones es una operación de escritura, y estas

operaciones pertenecen a diferentes transacciones.

98



Por ejemplo, [ Rj (x), Wj (x) ] y [ Wi (X), Wj (X) ] son pares de operaciones en conflicto

mientras que [ Ri(x), Rj(x) Wi(x), Wj(y) ], y [ Wi(x), Rj(y) ] son pares que no se

encuentran en conflicto.

Usando este concepto es posible obtener una definición de planificación equivalente

de otra manera:

Dos planificaciones S1 y S2 son equivalentes si por cada par de

operaciones en conflicto Oi y Oj, donde Oi < Oj en S1, entonces Oi

deberá preceder a Oj en S2.

Por ejemplo, la estructura S3 es equivalente a la planificación S4:

S3: Ri(x) Ri(x) Wj(y) Wi(x)

S4: Rj(x) Wj(y) Ri(x) Wi(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 transacción ejecuta operaciones en varios

sitios. La secuencia de operaciones procesada por las transacciones en un sitio es

una planificación local. Una ejecución de n transacciones distribuidas T1, T2, .... Tn en

m sitios es modelado por un conjunto de entradas de bitácora Sl, S2, .... Sm.

99



Si se aplica en cada sitio un mecanismo de control de concurrencia se aseguraría que

todas las planificaciones locales son serializables. Sin embargo, la seriabilidad local no

es suficiente para asegurar la exactitud de la ejecución de un conjunto de

transacciones distribuidas. Considere los siguientes ejemplos:

S1 (Sitio 1): Ri(x) Wj(x) Ri(x) Wi(x)

S2 (Sitio 2): Rj(y) Wi(y) Ri(y) Wj(y)

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 señal global

de ejecución 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 condición más fuerte que la seriabilidad local.

La ejecución de las transacciones T1, ..., Tn es correcta si:

1. Cada entrada local Sk es serializable.

2. Existe un orden total de T1, ..., Tn tal que, si Ti < Tj en el orden total, entonces

hay una planificación serial Sk’ tal que, Sk es equivalente a Sk’ y Ti < Tj en el

Serial(Sk’), para cada sitio k donde ambas transacciones tienen algún proceso en

ejecución.

La anterior definición puede ser explicada usando la definición de conflicto:

Sea T1, ..., Tn un conjunto de transacciones, y sea E una ejecución

de estas transacciones, modelado por el conjunto de planificaciones

100



S1, ..., Sm E es correcto (serializable) si existe un orden total de las

transacciones, y además 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.

Esta condición determina si una ejecución de una transacción distribuida es

correcta. Un mecanismo de control de concurrencia es correcto si permite solo la

ejecución de transacciones distribuidas.

4.1.3 Control de concurrencia basado en bloqueos centralizados

La idea básica del bloqueo (lock) es que cuando una transacción requiera accesar

un registro, esta bloquee dicho registro antes de intentar el acceso, y cuando una

transacción intente bloquear un registro que anteriormente ya fue bloqueado por otra

transacción, la primera deberá esperar a que la otra transacción libere dicho bloqueo

(unlock).

De hecho, los mecanismos típicos de bloqueo son más complejos, debido al

concepto de modo de bloqueo: una transacción 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 transacción 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 transacción puede bloquear un registro, si este no esta bloqueado o si lo

esta de manera compartida.

2. Una transacción puede bloquear de manera exclusiva, solo si el registro no esta

bloqueado.

101



Otro aspecto importante en el bloqueo es la granularidad. Esto se refiere al tamaño

del "objeto" que se bloquea con una operación simple, esto es, se puede bloquear un

registro o un archivo con una sola instrucción.

Otra condición que se deberá de tener en cuenta es que, una transacción no debe

de requerir de un nuevo bloque después de que se libere algún registro, esto quiere

decir que la transacción debe de tener un bloqueo de dos fases (2PC), esto porque la

primera fase sería el bloqueo de todos los registros necesarios para realizar la

transacción, y la segunda fase es en la cual se hace la liberación de todos los registros

antes bloqueados.

Teniendo en cuenta lo anterior, se podría asumir que las transacciones están

estructuradas de la siguiente forma:

Inicia transacción

Se realizan todos los bloqueos para escritura o lectura

Se hace todo el proceso de la transacción (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 están esperando para bloquear el registro

que la otra transacción 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 transacción

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 transacción se lleva acabo de acuerdo con la siguiente

figura:

102



ROOTAGENT AGENT AGENT

Mensaje Mensaje Transacción Distribuida

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, liberación local), mientras que los agentes de la

transacción procesan las primitivas globales (bloqueo compartido, bloqueo exclusivo, y

liberación). 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 transacción

global tenga las características de seriabilidad y aislamiento.

Un problema principal que se presenta es la administración de múltiples copias de

datos, el cual, el DTM debe resolver.

Los mecanismos de bloqueo fueron desarrollados para bases de datos

centralizadas con la suposición implícita de que solo existe una copia única de los

datos; de esta manera, una transacción se da cuenta de que otra transacción 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

103



DTM-AGENT

DTM-AGENT

LTMen

sitio k

LTMen

sitio j

DTM-AGENT

LTMen

sitio i

Mensaje Mensaje

2’ 2’ 2’

1’1’1’

Manejador distribuido de transacciones

Manejadores de transacciones locales

copias del mismo dato almacenados en diferentes sitios, para los cuales la existencia

mutua es inadvertida para dichas transacciones.

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 transacción. 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 trabajaría, porque dos

transacciones en conflicto de bloqueo podrían 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. Mayoría de bloqueos. En ambos bloqueos compartido y exclusivo son

requeridos en una mayoría de las copias de los registros (el número de copias

que se bloquean son estrictamente más grande que el número 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 descubriría el

conflicto.

3. Bloqueo 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 método de control de concurrencia

104



Considérese primero que, si todas las transacciones logran un bloqueo de 2 fases,

entonces todas las entradas de bitácora son serializables. Considérese también un sitio

donde una transacción ejecuta alguna operación, la cual es únicamente una parte de]

conjunto total de operaciones ejecutadas por la transacción distribuida, entonces se

tendrá que, si una transacción distribuida logra un bloqueo de dos fases entonces

todas las subtransacciones en los diferentes sitios, lograrán separadamente un

bloqueo de dos fases. En el momento que el bloqueo de 2 fases es un método

correcto para el control de concurrencia para una base de datos centralizada, la

ejecución de las subtransacciones es serializable.

Considérese ahora que, las transacciones T1, T2, ..., Tn requieren de un bloqueo de

dos fases, esto tal vez no llegue a ocurrir. Considere el estado intermedio en el

conjunto T1 tiene bloqueado a X, T2 tiene bloqueado Y, ..., Tn-1 tiene bloqueado V y Tn

tiene bloqueado Z. Cada una de estas transacciones requieren de bloquear un dato el

cual, ya esta bloqueado por otra transacción; por lo tanto cada una de ellas tendrá que

esperar hasta que otra transacción 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 transacción.

Por lo tanto n transacciones alcanzarán un estado de deadlock, y pueden estar

esperando por siempre. Entonces, una de estas transacciones deberá ser abortada

por algún algoritmo de solución de deadlock. En cualquier caso, el conjunto de

transacciones no podrá ocurrir.

Lo anterior es independiente del número de transacciones y de la secuencia de

ejecución, pero sí depende únicamente del orden de los pares de operaciones en

conflicto. Por tanto, un algoritmo de detección y resolución de deadlock es necesario

en un bloqueo de dos fases.

Considérense dos transacciones Ti y Tj, 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:

Ti : Ri1(x) Wi1(x) Ri2(Y) Wi2(Y)

Tj : Rj1(x) Wj1(x) Rj2(Y) Wj2(Y)

105



Ti Ti

Ri(x) Ri(x)

Wi(x) Wi(x)

R2(Y) R2(Y)

W2(Y) W2(Y)

Se asume que cada transacción lee X, decrementa su valor, escribe el nuevo valor,

lee Y, incremento su valor, y escribe su nuevo valor.

Supóngase que ambas transacciones son activadas de manera simultánea. Un

bloqueo de 2 fases asegura la ejecución serializable de estas transacciones, y habría

un orden total en el que Ti < Tj o Tj < Ti; esto significaría que W i1(x) < Rj1(x) y

Wi2(y) < Rj2(y) o que Wj1(x) < Ri1(x) y Wj2(y) < Ri2(y)- Dado que existe una simetría, se

podrá considerar cualquiera de los dos casos. Para ejemplo considérese Ti < Tj.

Para lograr un análisis del grado de concurrencia que es permitido por el algoritmo

de control de concurrencia, es necesario incluir en el modelo de ejecución la noción de

"operaciones concurrentes" en diferentes sitios. Se representarán dos operaciones

concurrentes colocándolas una sobre otra, en la ejecución 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)

106



En esta representación de la ejecución, el hecho de que la operación 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

termine aun. Esta ejecución 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

algún sitio ocurrió antes o después 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 práctico asumir que los relojes disponibles en todos los

sitios están perfectamente sincronizados.

Varios métodos de control de concurrencia y algoritmos de prevención de deadlock

requieren determinar el orden en que se realizarán los eventos. La determinación 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 definición anterior es que el manejo de la relación

"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 definición precisa de la relación "ocurre antes" en un sistema distribuido es la

siguiente. Se asume que se conoce el significado de la declaración " el evento A

ocurrió antes que el evento B en el sitio i", La relación "ocurre antes", denotada por →

puede ser generalizada en un sistema distribuido por medio de las siguientes reglas:

107



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.

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

La relación → es parcialmente ordenada. Se puede llamar a dos eventos A y B

pseudosimultáneos debido a que en ocasiones no es posible saber cual de los casos

ocurre realmente A → B o B → A.

Considérese el siguiente ejemplo, Los eventos A y D, B y E, B y F, C y E, C y F son

pseudosimultáneos. La relación de tiempo entre dos eventos pseudosimultáneos no

puede ser determinada.

La segunda propiedad de la definición de estampa del tiempo se puede ver de una

manera precisa como sigue:

Nótese que, si Ay B son pseudosimultáneos, es posible que TS(timestamp) (A) <

TS(B) o

108



Sitio 1 Sitio 2

B

A

CF

E

D

Mensaje M2

TiempoLocal

TiempoLocal

Mensaje M1

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 pseudosimultáneos.

Considérese ahora la generación 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 del sitio en el cual fue generada, en la posición menos significativa. Lo

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 más 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 sincronización entre los contadores de diferentes sitios

podría llegar a ser difícil. Es posible que el sitio 1 genere más etiquetas que el sitio 2, y

por lo tanto el contador del sitio 1 se incrementaría más rápido.

Los contadores de dos sitios se pueden mantener aproximadamente alineados, esto

se logra, añadiendo a cada mensaje el valor del contador del sitio que lo envía. 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 mantendrán aproximadamente sincronizados; en el caso de que los

dos sitios no sean sitios cooperativos, no es muy importante la sincronización de sus

contadores.

Considérese 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 simultáneas 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 pasaría a ser TS(B)=(1 1,2). Nótese que TS(A) y TS(B)

difieren únicamente en el identificador del sitio en donde se generaron.

109



Finalmente, se vera que se tendrán que usar siempre contadores y no relojes, en la

implementación de etiquetas de tiempo. Sin embargo, en algunas implementaciones

será conveniente usar relojes en lugar de contadores. De esta manera se reflejará de

manera más real la secuencia en la ocurrencia de eventos.

4.1.7 Deadlocks distribuidos

La detección y solución de deadlocks constituye una actividad importante de un

sistema manejador de bases de datos. La detección de deadlocks es más difícil en un

sistema distribuido que un centralizado, esto, debido a un ciclo de espera involucro

varios sitios.

En la siguiente figura se muestra una gráfica wait-for distribuido (Distributed Wait-for

Graphics, DWFG) el cual contiene un ciclo y este corresponde a un deadlock. La

notación TAj hace referencia al agente A¡ de la transacción 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 transacción 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 TrAs. Hay dos razones por las cuales

un agente esperaría a otro:

110



T1A1

T2A1

Sitio 1

T1A2

T2A2

Sitio 2

T1A1

T2A1

Sitio 1

T1A2

T2A2

1. El agente TAj espera que el agente TAj libere un recurso que él

necesita; en este caso, Ti es una transacción diferente de T r, y los dos agentes

están 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 gráfica.

2. El agente TiAj espera por el agente TiA, para realizar alguna solicitud de

función; En este caso, los dos agentes pertenecen a la misma transacción, y el

agente TAj requiere que el agente TjA, ejecute alguna función en un sitio

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

gráfica.

La porción de una DWFG que contiene únicamente los nodos y flechas

concernientes a un solo sitio se llama gráfica 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 conexión 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 gráfica, 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

detección de un deadlock distribuido es una tarea que requiere el intercambio de

información entre los diferentes sitios del sistema.

La solución a un deadlock involucro la selección de una o más transacciones que

pueden se abortadas y reiniciadas. Cuando la transacción es abortada, esta libera los

recursos, para que otras transacciones puedan ser procesadas. Un criterio para

seleccionar que transacción será abortada, pudiera ser el que se aborte la transacción

que implique el menor costo en dicha operación (él abortar una transacción requiere de

operaciones de deshacer). Otros criterios podrían ser, el abortar la transacción más

joven; abortar la transacción que tiene la menor cantidad de recursos; o abortar la

transacción que requiere más tiempo para terminar.

La redundancia incremento la posibilidad de un deadlock. Considérense, por

ejemplo, dos transacciones Ti y T2, ambas bloquean de manera exclusiva el mismo

dato X. Si X no esta replicada, entonces una transacción obtendría el bloqueo y se

111



ejecutaría mientras que la otra tendría 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: T1 bloquea X1 ; T2 espera

Sitio2 : T2 bloquea X2; T1 espera

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

4.2 Recuperación

Nada trabaja perfectamente el 100% de las veces. Esta simple observación al

parecer trivial, tiene grandes consecuencias en el diseño 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 además y de manera más significativa un

conjunto exacto de procedimientos para recuperación de las fallas que,

inevitablemente, ocurren a pesar de estas verificaciones y controles.

La recuperación 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, después 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

programación en una aplicación, 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 recuperación se puede resumir en una sola

palabra, redundancia. Esto es la forma de proteger la base de datos y asegurarla de

manera de que cualquier parte de la información almacenada en ella pueda ser

reconstruida de alguna otra información almacenada redundantemente en alguna parte

del sistema, aunque, el hecho de incluir algún método de procesamiento o

almacenamiento en espejo, no nos garantiza que no ocurra alguna falla, por lo que de

cualquier manera se debe incluir algún procedimiento de recuperación, el cual puede

consistir en forma general de lo siguiente:

112



1. Periódicamente, 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 bitácora.

3. Si ocurre una falla hay dos posibilidades:

a) Que la base de datos no se halla dañado pero su contenido es incierto (por

ejemplo, la terminación anormal de un programa en medio de una

secuencia de actualizaciones lógicamente relacionadas) en este caso la

base de datos se restaura a un estado correcto utilizando la bitácora para

deshacer todas las actualizaciones "INCIERTAS' que hayan sido realizadas

en ese programa.

b) La base de datos se daña físicamente (por ejemplo, debido a algún

problema de hardware) la solución en este caso, consiste en recuperar la

base de datos utilizándola copia de respaldo más reciente, y después

aplicándole la bitácora 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 propósito fundamental de un sistema de bases de datos es realizar

transacciones. Una transacción es una unidad de trabajo, que consiste de la ejecución

de una secuencia de operaciones lógicamente relacionadas de una aplicación

especifica que inicia con el operador especial "BEGIN TRANSACTION” y termina con

la operación “COMMIT” o “ROLLBACK”. El commit se usa para indicar una

terminación exitosa (la unidad de trabajo ha terminado con éxito), el rollback se utiliza

para indicar una terminación no exitosa, es decir, la unidad de trabajo no puede ser

terminada completamente debido a que ha ocurrido una condición excepcional. La

ejecución de un programa puede corresponder a una secuencia de vanas

transacciones, una detrás de otra.

113



Las transacciones no se pueden anidar, esto es el begin transaction puede ser

ejecutado solamente cuando la aplicación no tiene una transacción en progreso, por

otro lado el commit y el rollback se pueden ejecutar solamente cuando se esta

ejecutando una transacción. Todas las acciones recuperables deben ser ejecutadas

dentro de los limites de una transacción, una operación recuperable es una operación

que puede ser deshecha o rehecha en el caso de alguna falla, es decir son las

operaciones que se deben registrar en la bitácora. 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 transacción 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 deberán perder o ser hechas

parcialmente o hechas más de una vez. Al aceptar el mensaje de entrada deberá

garantizar que una transacción se ejecute una vez que cualquier actualización sobre la

base de datos producida por la transacción sea aplicada una vez y que cualquier

mensaje de salida producido por la transacción sea transmitido al usuario solamente

una vez, el manejador de recuperación es el responsable de proveer esa confiabilidad.

4.2.2 Manejo de mensajes

La recuperación tiene varias aplicaciones tanto con el manejo de mensajes como de

la base de datos, considerando el aspecto del manejo de mensajes de una transacción,

esta no solo actualiza la base de datos sino que además envía mensajes al usuario

final, si la transacción llega a su terminación planeada (commit o rollback explícito) se

debe enviar un mensaje al usuario. Si la transacción falla, es decir, no llega a su

terminación planeada a causa de un error, entonces el sistema debe deshacerla

automáticamente, el efecto en este caso será como si la transacción nunca se hubiera

iniciado, sus actualizaciones en la base de datos deberán ser deshechas y ningún

mensaje generado por la transacción deberá ser mostrado. Los mensajes de salida

deberán ser transmitidos al usuario hasta que ocurra una terminación planeada en la

transacción. El componente responsable del manejo de los mensajes es el manejador

114



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 bitácora

que contiene el texto del mensaje. La transacción utiliza una operación get para

obtener una copia del mensaje de una cola de entrada y una operación put para

colocar un mensaje de salida en una cola de mensajes de salida. Las operaciones

commit y rollback explícitos, es decir planeados, provocan que el DC Manager escriba

un registro en la bitácora. Para los mensajes contenidos en la cola de salida, realiza la

transmisión de estos mensajes al usuario y remueve el mensaje de entrada de la cola

de correspondiente. Si la transacción falla, el sistema automáticamente genera un

rollback (implícito) y esto provoca que el DC Manager descarte los mensajes de la cola

de salida.

4.2.3 Estructura general de los registros de bitácora

Registro de control

Identificadores (id, transacción, 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

Considérese 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

115



T4 Transferir 1000 pesos de la cuenta Cl a C3

Id cuenta Saldo

C1 1000

C2 500

C3 3200

C4 8000

C5 1532

C6 4553

En la bitácora se almacenan los mensajes de entrada y salida, las operaciones de

alta, baja, depósito y retiro, así como los registros de control para cada una de las

transacciones:

T1 usr23 Begin transaction

T1 usr23 MsgEntrada Transferencia C1 C4 400

T1 usr23 (Retiro) C1 1000 C1 600

T1 usr23 (Deposito) C4 8000 C4 8400

T1 usr23 (mensaje) 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

116



T4 usr87 Rollback

Dando como resultado siguiente la tabla:

Id cuenta Saldo

C1 600

C2 500

C3 3200

C4 8400

C5 4532

C6 4553

C7 5000

4.2.4 Tipos de fallas

Una operación rollback permite asegurarse de que una falla no corrompa la base de

datos, en el caso de que la transacción por si misma descubra la condición de la falla,

desafortunadamente la mayor parte de las fallas no se pueden anticipar fácilmente y no

se puede dejar al programador de la aplicación el manejarlas de esta manera. Los

tipos de fallas que pueden ocurrir, caen en las siguientes categorías:

1. Fallas locales de la transacción, que son detectadas por el código de la

aplicación (Por ejemplo, una condición de fondos insuficientes en una

transacción bancaria).

2. Fallas locales de transacción, que no son explícitamente manejadas por el

código de la misma, por ejemplo un overflow aritmético, una división entre cero,

una violación de seguridad, etc.

117



3. Fallas del sistema que afectan a todas las transacciones que se encuentran en

ejecución, pero que no dañan la base de datos (por ejemplo, una falla en el

CPU).

4. Fallas en el medio que dañan la base de datos o alguna porción de esta y

afectan a todas las transacciones que están utilizando esta parte (Por ejemplo,

un aterrizaje de las cabezas de un disco duro).

4.2.5 Fallas de transacción

Este término se usa para indicar una falla causada por una terminación no planeada

y anormal de un programa. Las condiciones que pueden causar esta terminación no

planeada, incluyen overflow aritmético, división entre cero, Colaciones de seguridad, lo

que ocurre cuando se da una condición de este tipo, por regla general es lo siguiente:

1. Cuando se presenta una condición de error, el sistema enciende una condición

para ese tipo de error en particular por ejemplo, división entre cero. El

programador tiene la opción de incluir explícitamente el código correspondiente

para manejar esta condición, si no se incluye este código, el sistema realiza la

siguiente acción.

2. El sistema enciende una condición de error generalizada, de nuevo el

programador tiene la opción de incluir el código correspondiente para manejar

esta condición o permitir que el sistema tome la siguiente acción.

3. En este punto el sistema provoca la terminación anormal del programa y envía el

mensaje correspondiente al usuario, y es solamente en este punto que se dice

que a ocurrido una falla de transacción.

En general se dice que una falla de transacción ocurre si y solo si el programa

termina de manera no planeada, es decir, si ocurre un error para el cual no hay un

código incluido en la aplicación que maneje explícitamente ese error. La ejecución de

un rollback explícito no esta considerado como una falla de transacción, sino como una

terminación anormal planeada de la transacción, no del programa.

Una falla de transacción significa que la transacción no ha llegado a su terminación

planeada, por lo que es necesario que el sistema force un rollback, esto es, que

118



deshaga cualquier cambio que haya hecho la transacción 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 atrás en la

bitácora leyendo todos aquellos registros de bitácora generados por la transacción

hasta que se encuentre un registro de inicio de transacción (begin transaction) para

cada registro localizado en la base de datos. El cambio que representa un registro de

bitácora se deshace reemplazando los nuevos valores en la base de datos por los

valores antiguos registrados en la bitácora.

4.2.6 Bitácora en línea

De la descripción del procedimiento para deshacer una transacción dada

anteriormente se puede observar que el manejador de recuperación necesita tener la

posibilidad de accesar los registros de bitácora de una manera selectiva en lugar de

una manera secuencias, por lo tanto, es conveniente que la bitácora 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 bitácora al día, por lo que es claramente

inconveniente el mantener la bitácora completa en línea. Una posible solución podría

ser lo siguiente:

La bitácora activa es mantenida en el dispositivo de acceso directo. Cuando el

archivo de bitácora se llena, el administrador de la bitácora, activa otro archivo de

bitácora, donde se almacenaran los siguientes registros de bitácora, mientras que el

otro archivo se respalda en algún medio. Si una transacción es muy larga y en dado

momento el archivo de bitácora se llena y esta transacción 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 bitácora este activo.

4.2.7 Transacciones grandes

119



Una transacción es tanto una unidad de recuperación como una unidad de trabajo,

esto sugiere que, una transacción debe de ser corta con el fin de reducir la cantidad de

trabajo que se tiene que deshacer y quizás, posteriormente rehacer en el caso de una

falla, esta, además reduce la posibilidad de que una transacción falle debido a un

overflow en la bitácora. Si una aplicación es muy grande, lo más adecuado es

subdividirla en varia transacciones sin afectar el concepto de transacción.

4.2.8 Compresión de bitácora

Al momento de hacer el respaldo de la bitácora se puede eliminar parte de la

información contenida en la misma. Con el fin de ocupar menor cantidad de espacio

de almacenamiento posible, sin perjudicar el proceso de recuperación, este proceso se

puede realizar de la siguiente manera:

1. Debido a que la bitácora 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 recuperación, transacción por transacción, pues se hace un barrido y se

rehacen todas.

4. Se puede eliminar el identificador de la transacción, el del usuario, fecha, hora,

etc. (identificador de transacción no es lo mismo que tipo de transacción).

5. Se puede eliminar la parte UNDO de cada registro que representa una

actualización sobre la base de datos.

6. Se eliminan los apuntadores al registro anterior y registro siguiente.

7. Se eliminan los registros de la bitácora que modifican el mismo registro de la

base de datos quedando registrado únicamente la última actualización.

Considerando la bitácora de la sección 4, 2, 3, la cual después de la compresión,

quedaría como sigue:

T1 R C1 600

T1 D C4 8400

T2 D C5 4532

120



T3 A C7 5'000

Con el fin de optimizar el proceso de recuperación se puede ordenar los registros de

la bitácora de acuerdo con el orden físico que tienen los registros en la base de datos,

cuya actualización representan los registros de la bitácora.

4.2.9 Fallas del sistema

"Fallas del sistema” significa que algún 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 daño alguno. Así, las transacciones que en el

momento de la falla se estuvieran ejecutando, se deberán de deshacer, esto, si es que

estas no habían terminado. Pero, como podría el manejador de recuperación saber al

momento del restablecimiento, que transacciones deshacer.

Esto se puede resolver buscando en la bitácora desde el principio, identificando

aquellas transacciones para las cuales hay un registro de inicio de transacción (BT),

pero no un registro de terminación (commit o rollback). Sin embargo, tal búsqueda

podría consumir demasiado tiempo. Se puede reducir fuertemente la cantidad de

búsqueda, introduciendo el principio de punto de verificación (Checkpoint).

El principio de check-point es muy simple:

A cierto intervalos preestablecidos, por ejemplo, cada cierto tiempo o número de

entradas de bitácora, el sistema realiza un check-point que consiste en los siguientes

pasos:

1. Forza el contenido de los buffers de bitácora hacia la bitácora física. Esto obliga

la escritura de cualquier registro de bitácora que aun permanezca en la memoria

principal.

2. Forza la escritura de un registro de check-point en la bitácora.

121



3. Forza la escritura del contenido de los buffers de la base de datos, en la base de

datos almacenada físicamente. Esto obligará la escritura de cualquier

actualización que aun se encuentre en la memoria principal.

4. Escribe la dirección del registro de check-point incluido en la bitácora en un

archivo de restablecimiento.

El registro de check-point contiene la siguiente información:

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

2. La dirección del registro de bitácora más reciente de cada una de estas

transacciones.

Al momento del restablecimiento, el manejador de recuperación obtiene la dirección

del registro de check-point más reciente del archivo de restablecimiento, localiza este

registro de bitácora y procede a buscar adelante en la bitácora, desde este punto hasta

el final.

Como resultado de este proceso el manejador de recuperación 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 propósito del restablecimiento, las transacciones pueden ser clasificadas en 5

categorías:

Tipo Descripción

T1 Terminan antes del check-point

T2 Inician antes del check-point y terminan después de este

T3 Inician antes del check-point, sin embargo no han terminado al

momento de la falla.

T4 Inician después del check-point y terminan antes de que ocurra la falla

T5 Inician después del check-point, pero no termina porque se presenta la

falla.

122



T1

T2

T3

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 deberán ser rehechas, ya aunque las transacciones se

realizaron completas, no hay garantía de que sus actualizaciones hayan sido escritas

en la base de datos. Las transacciones del tipo Tl no se consideran en al proceso de

recuperación, ya que al realizar el paso 3 del check-point sus actualizaciones se

escribieron en la base de datos.

Para la recuperación se procede a deshacer todos los cambios hechos por las

transacciones que están en la lista UNDO de la siguiente manera:

1. Se lee hacia atrás, secuencialmente la bitácora desde el final hasta el registro de

check-point, sí el registro recuperado pertenece a una transacción 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 están 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

secuencial de la bitácora a partir del registro de check-point y rehacer el cambio

123



que representa cada registro de la bitácora 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 daña el medio de almacenamiento, daña parte o toda

la base de datos, y las transacciones que estaban usando esa parte se ven afectadas,

en este caso, los respaldos realizados periódicamente, juegan un papel fundamental, el

proceso de recuperación 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 bitácora de las transacciones que terminaron con

commit. La bitácora debe contener todos los movimientos efectuados desde que se

hizo el ultimo respaldo hasta el momento de la falla. La bitácora implica todos los

movimientos que se encuentran en la parte activa, como las partes que se respaldaron.

Considérese la tabla de la sección 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 bitácora, la cual fue sometida a un proceso de compactación y

respaldo. Supóngase que el disco duro en el cual estaba almacenada la tabla de

cuentas se daña, y es necesario recuperarla a partir del respaldo en el disco duro

nuevo, siguiendo el proceso de recuperación.

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

Cuentas

Id_cuenta Saldo

C1 1000

C2 500

124



C3 3200'

C4 8000

C5 1532

C6 4553

2.- Se aplican los movimientos almacenados en la bitácora, substituyendo directamente

el valor almacenado en la tabla por el valor obtenido de la bitácora.

Bitácora

T1 R C1 600

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

125

Id_cuenta Saldo

C1 600

C2 500

C3 3200

C4 8000

C5 1532

C6 4553



C4 8400

C5 4532

C6 4553

Id_cuenta Saldo

C1 600

C2 500

C3 3200

C4 8400

C5 4532

C6 4553

C7 5000

La tabla que resulta de la operación de recuperación es ahora idéntica a la tabla que

se tenía antes de la falla del disco duro.

4.3 Integridad

El término 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

126



ser provocadas por errores al introducir los datos, por errores por parte del operador o

del programador de la aplicación, por fallas del sistema, y aun por falsificación

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 actualización en cuestión y que la actualización es valida.

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

responsabilidades:

1. Monitorear las transacciones especialmente, operaciones de actualización y

detección de violaciones a la integridad de la base de datos.

2. En el caso de una violación, tomar la acción apropiada, por ejemplo,

rechazando la operación, reportando la violación 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: [condición de activación]

Restricción

[ELSE respuesta en caso de violación]

La condición de activación define el momento en el que se verifica que se cumpla la

regla.

Una restricción indica las acciones que se deben de realizar para que la base de

datos cumpla con la regia, y la respuesta en caso de violación, corresponde a un

conjunto de instrucciones que se van a ejecutar en el caso de que no se cumpla con la

restricción. 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

127



concentran en el diccionario de datos en lugar de estar distribuidas en los programas

de aplicación, por lo que es más fácil entenderlas en su totalidad, y por lo tanto

modificarlas en caso de ser necesario. Se tiene, además, mayor oportunidad de

detectar contradicciones y redundancias en ellas, así como también conseguir que el

proceso de validación se ejecute más 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 categorías:

Reglas de integridad de dominio.

Reglas de integridad de relación.

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 relación con otros valores en la

base de datos. Las reglas de integridad de relación conciernen a la admisibilidad de

una tupla determinada como candidato para la inserción en una relación determinada o

la asociación entre tuplas de una relación con otra.

4.3.1 Reglas de integridad de dominio

Cada atributo de cada relación esta definido sobre un dominio identificado en la

definición de la relación, para el atributo A de la relación R que se define sobre el

dominio D, cualquier valor dado como candidato del atributo A debe pertenecer a D. La

definición del dominio D entonces constituye una importante regla de integridad, la cual

deberá verificar en todas las operaciones de inserción y actualización que involucran

cualquier atributo definido sobre D. La regla de integridad de dominio, no es otra que,

la definición de ese dominio. Las violaciones a las reglas de integridad de dominio

ocurren lo suficientemente seguido como para justificar algunas utilerías especiales

para facilitar su manejo-

Cada dominio es un subconjunto de un dominio base y hereda por lo tanto, las

características de ese dominio base (los dominios base son el conjunto de todas las

128



cadenas de caracteres, el conjunto de todos los números enteros, el conjunto de todos

los números reales, etc.).

La sintaxis de una definición de dominio puede ser la siguiente:

DLC nombre del dominio [PRIMARY] DOMAIN

Tipo de datos [PREDICADO]

[ELSE respuesta en caso de violación]

4.3.2 Reglas de integridad de relación

La sintaxis de una regla de integridad de relación puede ser la siguiente:

Etiqueta: [Condición de activación]

restricción

[ELSE respuesta en caso de violación de la regia]

Condición de activación:

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 condición de activación, si se especifica, consiste de una sola cláusula when

commiting o de una lista de cláusulas Before y/o After separadas por comas,

129



en el caso de que no se especifique una condición de activación, se asume por

default las siguientes condiciones de activación:

AFTER INSERTING tabla

AFTER UPDATING tabla

2. Todos los parámetros mencionados en una condición de activación deben tener

el mismo cursor, ya sea explícito o implícito, en esta regla se asegura que

todas las cláusulas Before y/o After incluidas en una regla de integridad

determinada se refiere al mismo registro, por lo que cualquier referencia al

registro por sus campos en la restricción o en la respuesta en caso de violación

no es ambigua.

3. Si se especifica la cláusula 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 restricción y/o la respuesta en caso de

violación.

4. Si se especifican múltiples cláusulas FROM en la condición de activación

determinada, entonces todas estas cláusulas 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 dirección de algún registro especifico de

la base de datos, es decir, es un apuntador la un registro específico, la

expresión C → R se refiere a una instancia específica 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 restricción puede incluir referencias a parámetros, esto es referencias a

cursores que estén en la lista de condiciones de activación, así como también

referencias a las variables o estructuras indicadas en la cláusula, así como

también pueden hacer referencia a registros y campos de las tablas implícitas

en la regla.

130



7. La regla de integridad

i: BEFORE cambio

restricción

ELSE respuesta en caso de violación;

Es lógicamente equivalente a:

i : si se va a realizar el cambio entonces sino (restricción)

entonces ejecuta respuesta en caso de violación fin_si

fin_si

Si se ejecuta la respuesta en caso de violación y este incluye la operación

REJECT entonces el cambio se realiza, de otra manera se realiza y regresa a la

aplicación.

8. La regla de integridad

i: AFTER cambio

restricción

ELSE respuesta en caso de violación;

Es lógicamente equivalente a:

i : ejecuta el cambio

entonces sino (restricción)

entonces ejecuta respuesta en caso de violación

fin_si

Si respuesta en caso de violación y este incluye la operación REJECT entonces el

cambio se deshace

9. Las reglas de integridad de relación pueden involucrar a más de una

relación, por esta razón, se especifica generalmente en forma separada en

lugar de incluirse como parte de la definición de una relación.

En el ejemplo de la sección 4.2.3, se tiene que la transacción 4 fue desecha debido

a que no se contaba con el saldo suficiente para realizar la operación, esta validación

puede ser hecha por medio de reglas de integridad, por ejemplo:

131



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, después de que se realizo

la actualización, en caso de ser negativo la operación es forzada a deshacerse y se

envía el mensaje de "Saldo insuficiente".

Otro ejemplo, sería 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,

Supóngase que se tiene una tabla en la cual se almacenan los movimientos

mensuales de las cuentas (retiros, depósitos). En el momento en el que se desea

borrar una cuenta de la tabla de cuentas, todos los movimientos de la cuenta deberán

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;

132



De esta manera se realizaría un borrado en cascada de todos los movimientos de la

cuenta eliminada.

4.4 Seguridad

Se utiliza el término de seguridad en un contexto de bases de datos para indicar la

protección de la base de datos, acerca del acceso, alteración o destrucción no

autorizada. Existen numerosos aspectos del problema de seguridad, entre ellos los

siguientes:

1. Aspectos legales, sociales y éticos. Por ejemplo, la persona que hace la

solicitud, tal vez un usuario de crédito, tiene acceso legal a la información

solicitada.

2. Controles físicos. Considera si el cuarto de la computadora o las terminales

deberán estar cerrados o protegidos de alguna otra manera.

3. Políticas de acceso. Por ejemplo, como decide la empresa quien deberá tener

acceso a que datos.

4. Problemas de operación. 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

característica de seguridad, tales como llaves de protección de almacenamiento,

o un modo de operación privilegiada.

6. Seguridad del sistema operativo. Por ejemplo, cual es el esquema de

protección.

7. Situaciones que conciernen específicamente 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 podría verificar el subsistema de seguridad de una base

de datos son los siguientes.

133



Considerando la relación empleados (num - emp, nombre, dirección, departamento,

sueldo, evaluación-desempeño), los niveles de acceso a esta relación que podrían ser

otorgados a algún usuario en particular son:

1. El usuario tiene acceso sin restricciones a la relación completa para cualquier

tipo de operación.

2. El usuario no tiene acceso a la relación para ningún tipo de operación.

3. El usuario puede consultar cualquier parte de la relación pero no modificarla.

4. Puede ver exactamente un registro en la relación (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 dirección.

6. Puede ver únicamente el número de empleado, el nombre, la dirección y el

departamento de cualquier registro de la relación y puede modificar solamente

los valores del nombre, dirección y departamento.

7. Puede ver los campos del número 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 números 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 estadísticos al campo de sueldo, pero no

leer o alterar valores individuales.

10. El usuario puede ver los campos de número de empleado, nombre y la

evaluación del desempeño, y puede alterar la evaluación al desempeño si y solo

si es el gerente del departamento.

4.4.1 Identificación y autentificación

De la definición de seguridad se deduce que el sistema no debe permitir que se

ejecute cualquier operación 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 contraseña (Password) para permitir al usuario el acceso al

sistema. Existen algunos DBMS, tales como DB2 UDB de IBM, los cuales confían el

134



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, también, 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 tendrán 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 través de password.

El proceso de identificación puede involucrar el que se provea al usuario con una

cuenta que el puede teclear directamente en su termina] o a través de algún otro medio

(voz, huellas digitales o tarjetas).

El proceso de autentificación involucro el proporcionar información solamente

conocida por el usuario propietario de la cuenta.

4.4.2 Reglas de autorización

El sistema debe permitir la definición de reglas que deberán ser expresadas en

algún lenguaje de alto nivel, por ejemplo SQL utiliza el comando GRANT, GRANT

SELECT ON empleado TO Jones, esta instrucción especifica que el usuario Jones esta

autorizado para ejecutar operaciones de selección sobre la relación empleados, esta

información se almacena en el USER PROFILE de Jones. Las reglas de autorización

serán 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 autorización 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

135



permitirán la autorización a nivel de campos individuales. Sin embargo una medida

significativa esta dada por el rango de características que se permite incluir en el

cuerpo de la matriz.

4.4.3 Encriptación 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 contraseña,

a si mismo, que existe dentro del DBMS existe una matriz de accesos para este

usuario en la cual se han especificado reglas de autorización para este. Considérese

ahora el caso en que un "usuario" intenta acceder a la información rompiendo o

eludiendo los métodos de seguridad establecidos, por ejemplo, robando parte de la

información almacenada en algún medio de respaldo, o corriendo algún programa que

logre romper la seguridad del sistema operativo y del DBMS, o interceptando las líneas

de comunicación, es importante recordar que la mayor parte de la comunicación 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 información

contenida en la base de datos, es la encriptación de datos, esto es, almacenar y

transmitir todos los datos, mensajes, contraseñas en una forma encriptada.

En el concepto de la encriptación, los datos originales son llamados texto plano. El

texto plano es encriptado por algún algoritmo de encriptación, el cual requiere del texto

plano y de una llave de encriptación, obteniendo así, la forma encriptada del texto

plano, conocida como texto cifrado.

4.4.4 Encriptación por sustitución

El método de sustitución es uno de los métodos más sencillos de encriptación de

datos, es necesario tener una llave para determinar los caracteres de texto cifrado los

cuales sustituirán a los caracteres del texto plano. A continuación se presenta un

ejemplo:

Teniendo como llave de encriptación la palabra ELIOT, se encriptará el siguiente

texto:

136



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 carácter 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

3.- Repetir el paso 2 para la llave de encdptación:

0512091520

4.- Para cada grupo del texto plano, remplazar cada carácter por la suma,

módulo 27, de su código y el código de la llave de encriptación:

0119001109 1407060919 0805181900 0301200308 0006091805

0512091520 0512091520 0512091520 0512091520 0512091520

064092602 1919152412 1317000720 0813021801 0518180625

5.- Remplazar cada código por su correspondiente carácter, de acuerdo al

código del paso 2:

FDIZB SSOXL MQ_GT HMBRA ERRFY

El problema que se podría presentar en este método es, como dificultarle a un

posible "usuario” infiltrado el hecho de determinar la llave de encriptación. Es posible

también combinar con este método, el método de permutación, el cual consiste en

reordenar los caracteres resultantes de a cuerdo a alguna secuencia, previamente

definida.

137



4.4.5 Encriptación de llave publica

En este esquema de encriptación, la llave de encriptación es conocida por todos, y

cualquier persona puede convertir texto plano a texto cifrado. Pero la llave de

desencriptación es mantenida en secreto ( este esquema involucro dos llaves, una

para encriptar y otra para desencriptar). La llave de desencriptación no puede ser

deducida a partir de la llave de encriptación; de esta manera la persona que ejecuta la

encriptación no podrá ejecutar la desencriptación si no esta autorizada para hacerlo.

Este método de encriptación se basa en los siguientes hechos:

1.- Existe un algoritmo rápido para determinar si cualquier número grande es

primo.

2.- No hay un algoritmo rápido para determinar los factores primos de un número

grande.

Este método 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 dígitos.

Obténgase 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 común divisor entre e y (p -1) * (q - 1) es 1. Entonces e es la

llave de encriptación.

3.- Se calcula la llave de desencriptación, d, la cual corresponde al único inverso

multiplicativo de e, módulo (p -1) * (q - l); esto es:

(d * e) módulo (p -1) * (q - 1) = 1

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

138



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 = Pe módulo r

6.- Para desencriptar una parte del texto cifrado, este es reemplazado por P, que

se obtiene de la siguiente manera:

P = Cd módulo r

A continuación se presenta un ejemplo, por razones de facilidad se utilizaran

números pequeños:

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) módulo 8 = 1

La función módulo obtiene únicamente el residuo de la división y se tiene que d = 3

cumple con esta condición

Ahora se encripta P de la manera siguiente:

C = Pe módulo r

C = 1311 módulo 15

= 1792160394037 módulo 15

= 7 (este es el residuo de la división entera de 1792160394037 entre 15)

139



Para desencriptar C se realiza el siguiente proceso:

p = Cd módulo r

P = 73 módulo 15

= 343 módulo 15

= 13 este es el residuo de la división entera de 343 entre 15)

4.5 Resumen

Una transacción accesa la base de datos usando primitivas de lectura y escritura.

El conjunto de elementos de lectura de datos para una transacción es llamado conjunto

lector y el conjunto de elementos de escritura de datos para una transacción es

llamado conjunto escritor. Dos transacciones Ti y Tj se ejecutan serialmente en una

planificación S, si la ultima operación de Ti precede a la primera operación de Tj en S.

En otro caso las transacciones se ejecutarían concurrentemente.

140



En una planificación, si la operación O¡ precede a la operación O¡, se indica como

O¡ < Oj, es decir Oi se ejecuta primero que O¡.

Las transacciones se ejecutarán lo más concurrentemente posible, cuidando que

esta ejecución sea correcta. La definición más aceptada de correcto en una bitácora es

basada en la seriabilidad:

Una planificación es correcta si esta es seriabilizable, esto es, que sea

equivalente a una planificación serial.

Un mecanismo de control de concurrencia es correcto si permite a las transacciones

ejecutarse en una secuencia tal que solo una planificación señalizaba podría producir.

Un mecanismo de control de concurrencia restringe las posibles secuencias de

operación ejecutados por una transacción que fuerza a otra transacción 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 operación de lectura lee los mismos valores que fueron producidos por

las mismas operaciones de escritura en ambas planificaciones.

2. La operación de escritura final es igual en ambas planificaciones.

Es importante también considerar el hecho de que dos operaciones pueden llegar a

caer en conflicto:

Dos operaciones están en conflicto si, ellas procesan el mismo dato y

al menos una de estas operaciones es una operación de escritura, y

estas operaciones pertenecen a diferentes transacciones.

Usando este concepto es posible obtener una definición de planificación equivalente

de otra manera:

141



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 transacción ejecuta operaciones en vanos

sitios. La secuencia de operaciones procesada por las transacciones en un sitio es

una planificación local.

Si se aplica en cada sitio un mecanismo de control de concurrencia se aseguraría

que todas las planificaciones locales son serializables. Sin embargo, la seriabilidad

local no es suficiente para asegurar la exactitud de la ejecución de un conjunto de

transacciones distribuidas.

La ejecución de las transacciones T1, ..., Tn es correcta sí:

1. Cada entrada local Sk es serializable.

2. Existe un orden total de T1, ..., Tn tal que, si Ti < Ti en el orden total, entonces

hay una entrada serial Sk‘ tal que, Sk es equivalente a Sk ' y Ti < Tj en el

Señal(Sk'), para cada sitio k donde ambas transacciones tienen algún proceso

en ejecución.

La anterior definición puede ser explicada usando la definición de conflicto:

Sea T1, ..., Tn un conjunto de transacciones, y sea E una ejecución de

estas transacciones, modelado por el conjunto de entradas de bitácora

Sl,... Sm. E es correcto (serializable) si existe un orden total de las

transacciones, y además 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 básica del bloqueo (lock) es que cuando una transacción requiera accesar

un registro, esta bloquee dicho registro antes de intentar el acceso, y cuando una

transacción intente bloquear un registro que anteriormente ya fue bloqueado por otra

transacción, la primera deberá esperar a que la otra transacción libere dicho bloqueo

(unlock).

142



Una transacción 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 transacción puede bloquear un registro, sí este no esta bloqueado o sí lo

esta de manera compartida.

2. Una transacción puede bloquear de manera exclusiva, solo si el registro no esta

bloqueado.

Otra condición que se deberá de tener en cuenta es que, una transacción no debe

de requerir de un nuevo bloque después de que se libere algún registro, esto quiere

decir que la transacción debe de tener un bloqueo de dos fases (2PL), esto porque la

primera fase sería el bloqueo de todos los registros necesarios para realizar la

transacción, y la segunda fase es en la cual se hace la liberación de todos los registros

antes bloqueados.

Los manejadores de transacciones locales interpretan las primitivas locales de

bloqueo (bloqueo local compartido, bloqueo local exclusivo y, liberación local), mientras

que los agentes de la transacción procesan las primitivas globales (bloqueo

compartido, bloqueo exclusivo, y liberación). 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 transacción global

tenga las características 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 transacción. 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:

143



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. Mayoría de bloqueos. En ambos bloqueos compartido y exclusivo son

requeridos en una mayoría de las copias de los registros (el número de copias

que se bloquean son estrictamente más grande que el número 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.

Considérese primero que si todas las transacciones logran un bloqueo de 2 fases,

entonces todas las entradas de bitácora son serializables. Si una transacción

distribuida logra un bloqueo de dos fases entonces todas las subtransacciones en los

diferentes sitios, lograrán separadamente un bloqueo de dos fases.

Considérese ahora que, las transacciones T1, T2, ..., Tn requieren de un bloqueo de

dos fases, cada una de estas transacciones requieren de bloquear un dato el cual, ya

esta bloqueado por otra transacción. Por lo tanto cada una de ellas tendrá que esperar

hasta que otra transacción 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 transacción. Por lo

tanto n transacciones alcanzarán un estado de deadlock, y pueden estar esperando

por siempre. Entonces, una de estas transacciones deberá ser abortada por algún

algoritmo de solución de deadlock. En cualquier caso, el conjunto de transacciones no

podrá ocurrir.

Para lograr un análisis del grado de concurrencia que es permitido por el algoritmo

de control de concurrencia, es necesario incluir en el modelo de ejecución la noción de

"operaciones concurrentes" en diferentes sitios. Se representan dos operaciones

concurrentes colocándolas una sobre otra, en la ejecución concurrente de

transacciones.

En un sistema distribuido, es necesario, algunas veces, conocer si un evento A en

algún sitio ocurrió antes o después que un evento B en un sitio diferente.

144



Varios métodos de control de concurrencia y algoritmos de prevención de deadlock

requieren determinar el orden en que se realizarán los eventos. La determinación 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 relación “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→S.

2. Si el evento A consiste en enviar un mensaje y el evento B consiste en recibir

el mensaje de A, entonces A→B.

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

La detección y solución de deadlocks constituye una actividad importante de un

sistema manejador de bases de datos. La detección de deadlocks es más difícil en un

sistema distribuido que un centralizado, esto, debido a un ciclo de espera involucro

varios sitios.

La figura se muestra una gráfica wait-for distribuido (DWFG):

145



T1A1

T2A1

Sitio 1

T1A2

T2A2

Sitio 2

T1A1

T2A1

Sitio 1

T1A2

T2A2

Hay dos razones por las cuales un agente esperaría a otro:

1. T1A1 espera que T2A1 libere recursos en el sitio 1. Este tipo de espera se

representa por una flecha continua en la gráfica.

2. El agente TiAj requiere que el agente TiAs ejecute alguna función en un sitio

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

gráfica.

La porción de una DWFG que contiene únicamente los nodos y flechas

concernientes a un solo sitio se llama gráfica wait-for local. Dichas LWFG se extienden

con flechas, desde y hacia los nodos los cuales representan a agentes que tienen

conexión con el nodo local. Los nodos cuadrados son llamados puertos de entrada si

tienen una flecha hacia dentro de la gráfica, 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 solución a un deadlock involucro la selección de una o más transacciones que

pueden se abortadas y reiniciadas. Un criterio para seleccionar que transacción será

abortada, pudiera ser el que se aborte la transacción que implique el menor costo en

dicha operación. Otros criterios podrían ser, el abortar la transacción más joven;

abortar la transacción que tiene la menor cantidad de recursos; o abortar la transacción

que requiere más tiempo para terminar.

Algo que se debe de tener en cuenta es que, la redundancia incremento la

posibilidad de un deadlock.

La recuperación 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, después de que una falla la ha llevado a un estado incorrecto o al

146



menos incierto. El principio en el cual se basa la recuperación es la redundancia. Esto

es la forma de proteger la base de datos y asegurarla de manera de que cualquier

parte de la información almacenada en ella pueda ser reconstruida de alguna otra

información almacenada redundantemente en alguna parte del sistema. Se debe

incluir algún procedimiento de recuperación, el cual puede consistir en forma general

de lo siguiente:

1. Periódicamente, 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 bitácora.

3. Si ocurre una falla hay dos posibilidades:

a) Que la base de datos no se halla dañado pero su contenido es incierto en

este caso la base de datos se restaura a un estado correcto utilizando la

bitácora.

b) La base de datos se daña físicamente, la solución en este caso consiste en

recuperar la base de datos utilizándola copia de respaldo más reciente.

El propósito fundamental de un sistema de bases de datos es realizar

transacciones. Una transacción es una unidad de trabajo que inicia con el operador

especial "BEGIN TRANSACTION" y termina con la operación 'COMMIT' o

"ROLLBACK". El commit se usa para indicar una terminación exitosa, el rollback se

utiliza para indicar una terminación no exitosa.

Todas las acciones recuperables deben ser ejecutadas dentro de los limites de una

transacción, una operación recuperable es una operación que puede ser deshecha o

rehecha en el caso de alguna falla, que se deben registrar en la bitácora.

Las transacciones son proposiciones de todo o nada, se debe garantizar al usuario

que cada transacción es ejecutada completamente o no se ejecuta en lo absoluto.

Una operación rollback permite asegurarse de que una falla no corrompa la base de

datos, en el caso de que la transacción por si misma descubra la condición de la falla.

147



Los tipos de fallas que pueden ocurrir, caen en las siguientes categorías:

1. Fallas locales de la transacción, que son detectadas por el código de la

aplicación.

2. Fallas locales de transacción, que no son explícitamente manejadas por el código

de la misma.

3. Fallas del sistema que afectan a todas las transacciones que se encuentran en

ejecución, pero que no dañan la base de datos.

4. Fallas en el medio que dañan la base de datos o alguna porción de esta y

afectan a todas las transacciones que están utilizando esta parte.

El término fallas de transacción se usa para indicar una falla causada por una

terminación no planeada y anormal de un programa. Lo que ocurre cuando se da una

condición de este tipo, por regla general es lo siguiente:

1. Cuando se presenta una condición de error, el sistema enciende una condición

para ese tipo de error en particular. El programador tiene la opción de incluir

explícitamente el código correspondiente para manejar esta condición.

2. El sistema enciende una condición de error generalizada, de nuevo el

programador tiene la opción de incluir el código correspondiente para manejar

esta condición.

3. En este punto el sistema provoca la terminación anormal del programa y envía

el mensaje correspondiente al usuario, y es solamente en este punto que se

dice que a ocurrido una falla de transacción.

La ejecución de un rollback explícito no esta considerado como una falla de

transacción, sino como una terminación anormal planeada de la transacción, no del

programa.

Una falla de transacción significa que la transacción no ha llegado a su terminación

planeada, por lo que es necesario que el sistema force un rollback.

El término faltas del sistema significa que algún evento causo que el sistema se

detuviera y esto requerirá un subsecuente reinicio del sistema: El contenido del

148



almacenamiento primario, se pierde, pero la base de datos no sufre daño alguno. Así,

las transacciones que en el momento de la falla se estuvieran ejecutando, se deberán

de deshacer, esto si es que estas no habían terminado.

Esto se puede resolver buscando en la bitácora desde el principio, identificando

aquellas transacciones para las cuales hay un registro de inicio de transacción (BT),

pero no un registro de terminación (commit o rollback).

El principio de check-point es muy simple:

A cierto intervalos preestablecidos, por ejemplo, cada cierto tiempo o número de

entradas de bitácora, el sistema realiza un check-point que consiste en los siguientes

pasos:

1. Forza el contenido de los buffers de bitácora hacia la bitácora física.

2. Forza la escritura de un registro de check-point en la bitácora.

3. Forza la escritura del contenido de los buffers de la base de datos, en la base

de datos almacenada físicamente.

4. Escribe la dirección del registro de check-point incluido en la bitácora en un

archivo de restablecimiento.

El registro de check-point contiene la siguiente información:

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

2. La dirección del registro de bitácora más reciente de cada una de estas

transacciones.

Al momento del restablecimiento, el manejador de recuperación obtiene la dirección

del registro de check-point más reciente del archivo de restablecimiento, localiza este

registro de bitácora y procede a buscar adelante en la bitácora, desde este punto hasta

el final.

Para el propósito del restablecimiento, las transacciones pueden ser clasificadas en

5 categorías:

149



Tipo Descripción

T1 Terminan antes del check-point

T2 Inician antes del check-point y terminan después de este

T3 Inician antes del check-point, sin embargo no han terminado al momento

de la falla.

T4 Inician después del check-point y terminan antes de que ocurra la falla

T5 Inician después del check-point, pero no termina porque se presenta la

falla.

Las transacciones del tipo T3 y T5 se deben deshacer y las del tipo T2 y T4 deberán

ser rehechas. Las transacciones del tipo T1 no se consideran en al proceso de

recuperación, ya que al realizar el paso 3 del check-point sus actualizaciones se

escribieron en la base de datos.

El término 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 actualización y

detección de violaciones a la integridad de la base de datos.

2. En el caso de una violación, tomar la acción apropiada, por ejemplo,

rechazando la operación, reportando la violación 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

150



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 aplicación

Las reglas de integridad se pueden dividir en dos categorías:

Reglas de integridad de dominio.

Reglas de integridad de relación.

Se utiliza el término de seguridad en un contexto de bases de datos para indicar la

protección de la base de datos, acerca del acceso, alteración o destrucción no

autorizada. Existen numerosos aspectos del problema de seguridad, entre ellos los

siguientes:

1. Aspectos legales, sociales y éticos.

2. Controles físicos.

3. Políticas de acceso.

4. Problemas de operación.

5. Controles de hardware.

6. Seguridad del sistema operativo.

7. Situaciones que conciernen específicamente al propio manejador de la base

de datos.

De la definición de seguridad se deduce que el sistema no debe permitir que se

ejecute cualquier operación 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 definición de reglas que deberán ser expresadas en

algún lenguaje de alto nivel, por ejemplo SQL utiliza el comando GRANT, GRANT

151



SELECT, esta instrucción especifica que el usuario esta autorizado para ejecutar

operaciones de selección sobre una relación, esta información se almacena en el

USER PROFILE. Las reglas de autorización serán 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 autorización 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.

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 contraseña,

a si mismo, que existe dentro del DBMS existe una matriz de accesos para este

usuario en la cual se han especificado reglas de autorización para este.

Una forma efectiva de prevenir que "usuarios" no autorizados puedan ver la

información contenida en la base de datos, es la encriptación de datos, esto es,

almacenar y transmitir todos los datos, mensajes, contraseñas en una forma

encriptada.

En el concepto de la encriptación, los datos originales son llamados texto plano. El

texto plano es encriptado por algún algoritmo de encriptación, el cual requiere del texto

plano y de una llave de encriptación, obteniendo así, la forma encriptada del texto

plano, conocida como texto cifrado.

El método de sustitución es uno de los más sencillos métodos de eneriptación de

datos, es necesario tener una llave para determinar los caracteres de texto cifrado

los cuales sustituirán a los caracteres del texto plano. Es posible también combinar

con este método, el método de permutación, el cual consiste en reordenar los

caracteres resultantes de a cuerdo a alguna secuencia, previamente definida.

En el esquema de encriptación de llave publica, la llave de encriptación es conocida

por todos, y cualquier persona puede convertir texto plano a texto cifrado. Pero la llave

de desencriptación es mantenida en secreto (este esquema involucro dos llaves, una

para encriptar y otra para desencriptar). La llave de desencriptación no puede ser

deducida a partir de la llave de encriptación; de ésta manera la persona que ejecuta la

encriptación no podrá ejecutar la desencriptación si no esta autorizada para hacerlo.

152




1.- ¿Cuál es la condición para que dos transacciones sean serializables?

Dos transacciones Ti y Tj se ejecutan serialmente en una planificación S, si la última

operación de Ti precede a la primera operación de Tj en S.

2.- ¿Cuándo dos transacciones son concurrentes?

Dos transacciones son concurrentes si no cumplen la condición de seriabilidad.

3.- ¿Cuáles son las dos condiciones que deben cumplir dos planificaciones para

que sean equivalentes?

4.- ¿Por qué dos operaciones pueden caer en conflicto?

Dos operaciones están en conflicto, cuando procesan el mismo dato y al menos una

de ellas es una operación de escritura, y dichas operaciones pertenecen a diferentes

transacciones.

5.- ¿Cómo funciona el control de concurrencia basado en bloqueos distribuidos?

6.- Mencione y describa los esquemas o métodos que existen para evitar los

conflictos entre bloqueos.

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.

Mayoría de bloqueos: Tanto los bloqueos exclusivos como los

compartidos son hechos en la mayoría de las copias existentes,

tomando en cuenta que el número de copias bloqueadas sea mayor que

el número de las no bloqueadas.

Bloqueo de copia primaria: Todos los bloqueo son hechos en una sola

copia del fragmento, llamada copia primaria.

7.- Explique brevemente en que consiste el bloqueo de 2 fases.

153



8.- ¿En que consisten las etiquetas de tiempo?

Una etiqueta de tiempo, es un identificador único asignado a cada transacción

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 podría

ser abortada en caso de presentarse un interbloqueo.

9.- ¿Que se entiende por deadlocks distribuidos?

10.- ¿Que es la recuperación?

La recuperación de un sistema de bases de datos consiste en llevarla a un estado

correcto después de que ha ocurrido una falla y la base de datos se encuentra en un

estado incorrecto o incierto.

11.- ¿De que manera garantizamos que en dado momento, una base de datos

pueda ser recuperada?

12.- Además de la replicación de la base de datos, ¿qué es recomendable hacer?

Junto con la replicación, es necesario llevar una bitácora 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 bitácora y se rehagan todas éstas actualizaciones

después de haber recuperado la base de datos a partir de la copia, esto para que las

pérdidas de información sean mínimas o casi nulas.

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?

Una base de datos es integra cuando todos los datos almacenados en ella son

correctos o validos en el contexto de la definición de la base de datos.

15.- ¿Cuales son las responsabilidades de un subsistema de integridad?

16.- ¿Explique la regla de integridad de dominio?

154



Cada atributo de la relación esta definido sobre un dominio, identificado en la

definición de la relación y todo valor de este atributo debe estar definido dentro del

domino.

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?

La existencia de controles de seguridad físicos.

Las políticas de acceso.

Los controles de acceso por medio de hardware.

La seguridad del sistema operativo.

Las situaciones concernientes al DBMS.

19.- ¿Que son las reglas de autorización?

20.- ¿Que es la encriptación de datos?

La encriptación de datos es el hecho de almacenar o transmitir la información de

manera que no seria entendible para cualquier persona que intentara accesaria

4.7 Ejercicios

1.- Para las siguiente tabla defina las reglas de integridad para el retiro de

fondos, creación de una cuenta, transferencia de fondo y para la cancelación de una

cuenta (considerando que existe una tabla de movimientos).

Cuentas

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 regístrelas en una bitácora,

155



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: Cancelación de la cuenta C54.

3.- Utilizando el método de encriptación de llave publica, y teniendo encuentra

que p = 5 y q = 7, realice la encriptación y desencriptación de los siguientes

números: 8, 9.

Bibliografía

[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

156



Respuestas a preguntas y ejercicios de repaso

Capítulo I

Preguntas de repaso

2.-

La mayor parte de las organizaciones ya están distribuidas.

Permiten interconexión de las bases de datos existentes.

Es posible realizar un desarrollo incrementar.

Permite reducir la carga de las líneas de comunicación.

Existe un incremento en el desempeño del sistema.

Son más confiables.

La mayor parte del tiempo se encuentra disponible la información.

4.-

Porque describe la forma en como deberá de funcionar una base de datos

distribuida. Vista desde el exterior la distribución 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 estación de trabajo o sitio de trabajo.

8.-

157



Es llamado por el usuario y se ejecuta durante la sesión.

Se ejecuta de modo local.

Tiene capacidad de iniciar la comunicación con el servidor.

10.-

Deberá ser capaz de soportar múltiples usuarios.

Deberá ser capaz de satisfacer las demandas de los clientes.

Deberá de proveer altos niveles de desempeño-

Deberá de contar con capacidad de red.

Capítulo 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 información, es posible conmutar a una copia altema

cuando la copia que era accesada comúnmente no se encuentre disponible.

Distribución de la carga de trabajo: La carga de trabajo es distribuida en

relación con la capacidad de cómputo de cada uno de los sitios participantes,

permitiendo un grado más 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

espacio disponible en algún sitio para el almacenamiento de nueva

información.

4.-

Fragmentación horizontal primaria: Consiste en particionar las tuplas de una

relación global en subconjuntos de tuplas, donde cada uno de estos tiene

propiedades geográficas comunes. La reconstrucción de la relación global se

lleva a cabo por medio de la operación unión.

Fragmentación horizontal derivada: Esta genera cuando una relación no puede

ser fragmentada en base a alguna propiedad de sus atributos, entonces, su

fragmentación se deriva de la fragmentación horizontal de otra relación.

158



Fragmentación vertical: se obtiene por la subdivisión de sus atributos en

grupos. Los fragmentos son obtenidos por medio de proyecciones sobre la

relación global. La reconstrucción de la relación global se da por medio de una

operación join.

Fragmentación mixta: Los fragmentos son obtenidos a partir de la aplicación de

fragmentaciones iterativas sobre la relación global. La reconstrucción de la

relación se logra al aplicar las operaciones en orden inverso a la fragmentación.

Ejercicios de repaso

1.-

q1: Obtener los nombres de todos los clientes.

q2: Obtener los números de cliente (no_cli) por estado.

q3: Obtener los nombres de los clientes (nom_cli) por empresa.

No_cli Nom_cli Empresa Estado

C01 Juárez Gamesa Gto

C02 Vidal Lara Qro

C03 Ávila Gamesa Jal

C04 Mejía Lara Jal

C05 Herrera Lara Gto

C06 Cervantes Gamesa Qro

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}

159



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

m6 = Jal ^ Gamesa

m1


C05 Herrera Lara Gto

m2


C01 Juárez Gamesa Gto

160



m3


C02 Vidal Lara Qro

m4


C06 Cervantes Gamesa Qro

m5


C04 Mejía Lara Jal

m6


C03 Ávila Gamesa Jal

3.-

q1: Obtener los nombres de todos los clientes.

q2: Obtener los números y nombres de los clientes por estado.

q3: Obtener los nombres de los clientes por empresa.

Matriz de accesos

S1 S2

Ql 3 2

161



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

Al A2 A3 A4

Al 3 3 0 3

A2 3 10 2 3

A3 0 2 2 0

A4 3 3 0 3

162



F1={No_cli, Nom_cli}

F2={No_cli, Empresa, Estado}

O

F1={ No_cli, Nom_cli, Empresa}

F2={ No el¡, Estado}

Capítulo III

Preguntas de repaso

2.-

Es necesario definir el número de copias físicas de cada uno de los fragmentos

que existen en el sistema, y obtener una expresión de consulta sobre cada uno

de los fragmentos.

Se deberá seleccionar el orden de ejecución del conjunto de consultas sobre

cada uno de los sitios.

Seleccionar el método optimo para la ejecución de cada operación.

4.-

Son expresiones que aparecen más de una vez dentro de una misma consulta y

que solo deberá ser ejecutada una sola vez para optimizar la ejecución de la consulta.

6.-

Iteración simple.

Iteración orientada a bloques.

Merge - join.

Hash - join.

Tree - way join.

Join paralelo

Pipeline muitiway join.

8.-

163



Convertir la consulta a alguna expresión apropiada par el sistema administrador

de la base de datos, para que de esta manera pueda ser ejecutada

adecuadamente, eliminando las características de la sintaxis del lenguaje de

nivel externo con el cual fue hecha la consulta.

Convertir la consulta a su forma canónica, es decir, llevar a la expresión hasta

su forma más 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

canónica, generando, generando subprocedimientos para la ejecución de las

operaciones de bajo nivel, tales como join, select, etc.

Por ultimo, se construyen un conjunto de planes de ejecución de la consulta y

se elige el más económico de ellos. Donde económico se refiere a la ejecución

de menor costo en el sistema.

164




1.-

PJEMP:NOM

DF

JNDEPTNUM=DEPTNUM JNDEPTNUM=DEPTNUM

EMP SLDESC=X SLSAL<=11000 SLDESC=x

DEPT EMP DEPT

3.

PJEMP:NOM

EMP SLDESC=X

DEPT

Capítulo IV-

Preguntas de repaso

2.-

Dos transacciones son concurrentes si no cumplen la condición de seriabilidad.

4.-

165



SLSAL>35000

JNDEPTNUM=DEPTNUM

DF

Dos operaciones están en conflicto, cuando procesan el mismo dato y al menos una

de ellas es una operación 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.

Mayoría de bloqueos: Tanto los bloqueos exclusivos como los

compartidos son hechos en la mayoría de las copias existentes,

tomando en cuenta que el número de copias bloqueadas sea mayor que

el número 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 transacción

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 podría

ser abortada en caso de presentarse un interbloqueo.

10.-

La recuperación de un sistema de bases de datos consiste en llevarla a un estado

correcto después de que ha ocurrido una falla y la base de datos se encuentra en un

estado incorrecto o incierto.

12.-

Junto con la replicación, es necesario llevar una bitácora 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 bitácora y se rehagan todas éstas actualizaciones

después de haber recuperado la base de datos a partir de la copia, esto para que las

perdidas de información sean mínimas o casi nulas.

166



14.-

Una base de datos es integra cuando todos los datos almacenados en ella son

correctos o validos en el contexto de la definición de la base de datos.

16.-

Cada atributo de la relación esta definido sobre un dominio, identificado en la

definición de la relación y todo valor de este atributo debe estar definido dentro del

domino.

18.-

La existencia de controles de seguridad físicos.

Las políticas de acceso.

Los controles de acceso por medio de hardware.

La seguridad del sistema operativo.

Las situaciones concernientes al DBMS.

19.-

La encriptación de datos es el hecho de almacenar o transmitir la información de

manera que no seria entendible para cualquier persona que intentara accesaria.


1.

Para una transferencia o retiro

After Update ng cuentas

cuentas.saldo >= 0

Else

Set retum code to "Saldo insuficiente”

167



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;

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

168



Encriptación

C1 = (8)11 módulo 35 = 22

C2 = (9)11 módulo 35 = 4

Desencriptación

P1 = (22)11 módulo 35 = 8

P2 = (4)11 módulo 359

Conclusiones

Durante la realización 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,

169



permitiendo así una rápida asimilación de los temas y conceptos que en esta obra se

tratan.

Es también, un texto que podría ser utilizado por personas autodidactas con

conocimientos de generales de computación y de bases de datos, permitiendo un

entendimiento claro del concepto de lo que son las bases de datos distribuidas.

170



Bases de Datos Distribuidas Completo.doc

Documents

Transcript of Bases de Datos Distribuidas Completo.doc