Bases de Datos Distribuidas

CONSIDERACIONES GENERALES

En un sistema de base de datos distribuida, los datos se almacenan en varios computadores. Los
computadores de un sistema distribuido se comunican entre s a travs de diversos medios de
comunicacin, tales como cables de alta velocidad o lneas telefnicas. No comparten la memoria
principal ni el reloj.

Los procesadores de un sistema distribuido pueden variar en cuanto su tamao y funcin. Pueden
incluir microcomputadores pequeos, estaciones de trabajo y sistemas de computadores grandes de
aplicacin general. Estos procesadores reciben diferentes nombres, tales como localidades, nodos o
computadores.

Un sistema distribuido de bases de datos consiste en un conjunto de localidades, cada uno de las
cuales puede participar en la ejecucin de transacciones que accedan a datos de una o varias localidades.
La diferencia principal entre los sistemas de base de datos centralizados y distribuidos es que, en los
primeros, los datos residen en una sola localidad, mientras que, en los ltimos, se encuentran en varias
localidades.

ESTRUCTURA DE BASE DE DATOS DISTRIBUIDAS

Un sistema distribuido de base de datos consiste en un conjunto de localidades, cada una de las
cuales mantiene un sistema de base de datos local. Cada localidad puede procesar transacciones locales, o
bien transacciones globales entre varias localidades, requiriendo para ello comunicacin entre ellas.

Las localidades pueden conectarse fsicamente de diversas formas, las principales son:

Red totalmente conectada

Red parcialmente conectada

Red con estructura de rbol

Red de estrella

Red de anillo

Las diferencias principales entre estas configuraciones son:

Costo de instalacin: El costo de conectar fsicamente las localidades del sistema,

esta dado por los dispositivos de comunicacin utilizados, as como el medio en el que se da
la comunicacin (par trenzado, fibra ptica, coaxial, inalmbrico).

Costo de comunicacin: El costo en tiempo y dinero que implica enviar un

mensaje desde la localidad A a la localidad B.

Fiabilidad: La frecuencia con que falla una lnea de comunicacin o una localidad.
Bases de Datos Distribuidas

Disponibilidad: La posibilidad de acceder a informacin a pesar de fallos en

algunas localidades o lneas de comunicacin.

Las localidades pueden estar dispersas, ya sea por un rea geogrfica extensa (a lo largo de un
pas), llamadas redes de larga distancia; o en un rea reducida (en un mismo edificio), llamadas redes de
rea local. Para las primeras se utilizan en la comunicacin lneas telefnicas, conexiones de microondas y
canales de satlites; mientras que para las segundas se utiliza cables coaxiales de banda base o banda
ancha, fibra ptica y la actual red inalmbrica.

CONSIDERACIONES AL DISTRIBUIR LA BASE DE DATOS

Existen varias razones para construir sistemas distribuidos de bases de datos que incluyen
compartir la informacin, fiabilidad y disponibilidad adems de agilizar el procesamiento de las
consultas. Pero tambin tiene sus desventajas, como desarrollos de software ms costosos, mayor
posibilidad de errores y costos extras de procesamiento.

Ventajas de la distribucin de datos

La principal ventaja de los sistemas distribuidos es la capacidad de compartir y acceder a la

informacin de una forma fiable y eficaz.

Utilizacin compartida de los datos y distribucin del control

La ventaja principal de compartir los datos por medio de la distribucin es que cada localidad
pueda controlar hasta cierto punto los datos almacenados localmente. En un sistema centralizado, el
administrador de base de datos de la localidad central controla la base de datos. En un sistema
distribuido existe un administrador global de la base de datos que se encarga de todo el sistema. Parte de
esta responsabilidad se delega al administrador de base de datos de cada localidad. Dependiendo del
diseo del sistema distribuido, cada administrador local podr tener un grado de autonoma diferente,
que se conoce como autonoma local. La posibilidad de contar con autonoma local es en muchos casos
una ventaja importante de las bases de datos distribuidas.

Fiabilidad y disponibilidad

Si se produce un fallo en una localidad de un sistema distribuido, es posible que las dems
localidades puedan seguir trabajando. En particular, si los datos se repiten en varias localidades, una
transaccin que requiere un dato especfico puede encontrarlo en ms de una localidad. As, el fallo de
una localidad no implica necesariamente la desactivacin del sistema.

El sistema debe detectar cuando falla una localidad y tomar las medidas necesarias para
recuperarse del fallo. El sistema no debe seguir utilizando la localidad que fall. Por ltimo, cuando se
recupere o repare esta localidad, debe contarse con mecanismos para reintegrarla al sistema con el
mnimo de complicaciones.

La disponibilidad es fundamental para los sistemas de bases de datos que se utilizan en

aplicaciones de tiempo real. Por ejemplo, si una lnea area no puede tener acceso a la informacin, es
posible que pierda clientes a favor de la competencia.
Bases de Datos Distribuidas

Agilizacin del procesamiento de consultas

Si una consulta comprende datos de varias localidades, puede ser posible dividir la consulta en
varias subconsultas que se ejecuten en paralelo en distintas localidades. Sin embargo, en un sistema
distribuido no se comparte la memoria principal, as que no todas las estrategias de interseccin se
pueden aplicar en estos sistemas. En los casos en que hay repeticin de los datos, el sistema puede pasar
la consulta a las localidades ms ligeras de carga.

Desventajas de la distribucin de los datos

La desventaja principal de los sistemas distribuidos es la mayor complejidad que se requiere para
garantizar una coordinacin adecuada entre localidades.

El aumento de la complejidad se refleja en:

Costo del desarrollo de software: es ms difcil estructurar un sistema de bases de

datos distribuidos y por tanto su costo es mayor.

Mayor posibilidad de errores: puesto que las localidades del sistema distribuido
operan en paralelo, es ms difcil garantizar que los algoritmos sean correctos.

Mayor tiempo extra de procesamiento: el intercambio de mensajes y los clculos

adicionales son una forma de tiempo extra que no existe en los sistemas centralizados.

TRANSPARENCIA Y AUTONOMA

Se ha visto que una relacin r puede almacenarse de varias formas en un sistema de base de datos
distribuida. Es esencial que el sistema reduzca al mnimo la necesidad de que el usuario se d cuenta de
cmo est almacenada una relacin. Un sistema puede ocultar los detalles de la distribucin de la
informacin en la red. Esto se denomina transparencia de la red. La transparencia de la red se relaciona,
en algn modo, a la autonoma local. La transparencia de la red es el grado hasta el cual los usuarios del
sistema pueden ignorar los detalles del diseo distribuido. La autonoma local es el grado hasta el cual el
diseador o administrador de una localidad pueden ser independientes del resto del sistema distribuido.
Los temas de transparencia y autonoma sern considerados desde los siguientes puntos de vista:

Nombre de los datos.

Repeticin de los datos.

Fragmentacin de los datos.

Localizacin de los fragmentos y copias.

Asignacin de nombres y autonoma local

Todo elemento de informacin de una base de datos debe tener un nombre nico. Esta propiedad
se asegura fcilmente en una base de datos que no est distribuida. Sin embargo, en una base de datos
Bases de Datos Distribuidas

distribuida, las distintas localidades deben asegurarse no utilizar el mismo nombre para dos datos
diferentes.

Una solucin para este problema es requerir que se registren todos los nombres en un asignador
central de nombres. Sin embargo, este enfoque tiene varias desventajas:

Es posible que el asignador de nombres se convierta en un cuello de botella.

Si el asignador de nombres se cae, es posible que ninguna de las localidades del sistema
distribuido pueda seguir trabajando.

Se reduce la autonoma local, ya que la asignacin de nombres se controla de forma

centralizada.

Un enfoque diferente que origina una mayor autonoma local es exigir que cada localidad ponga
como prefijo un identificador de localidad a cualquier nombre que genere. Esto garantiza que dos
localidades nunca generarn el mismo nombre (ya que cada localidad tiene un identificador nico).
Adems, no se requiere un control central.

Esta solucin al problema de asignacin de nombres, logra autonoma local, pero no transparencia
de la red, ya que se agregan identificadores de localidad a los nombres.

Cada copia y fragmento de un elemento de informacin deben tener un nombre nico. Es

importante que el sistema pueda determinar qu copias son copias del mismo elemento de informacin y
qu fragmentos son fragmentos del mismo elemento de informacin.

Transparencia de la repeticin y la fragmentacin

No es conveniente requerir que los usuarios hagan referencia a una copia especfica de un
elemento de informacin. El sistema debe ser el que determine a qu copia debe acceder cuando se le
solicite su lectura, y debe modificar todas las copias cuando se produzca una peticin de escritura.

Cuando se solicita un dato, no es necesario especificar la copia. El sistema utiliza una tabla-
catlogo para determinar cules son todas las copias de ese dato.

De manera similar, no debe exigirse a los usuarios que sepan cmo est fragmentado un elemento
de informacin. Es posible que los fragmentos verticales contengan id-tuplas, que representan
direcciones de tuplas. Los fragmentos horizontales pueden haberse obtenido por predicados de
seleccin complejos. Por tanto, un sistema de bases de datos distribuido debe permitir las consultas que
se hagan en trminos de elementos de informacin sin fragmentar. Esto no presenta problemas graves,
ya que siempre es posible reconstruir el elemento de informacin original a partir de sus fragmentos.
Sin embargo, este proceso puede ser ineficiente.

Transparencia de localizacin

Si el sistema es transparente en cuanto a repeticin y fragmentacin, se ocultar al usuario gran

parte del esquema de la base de datos distribuida. Sin embargo, el componente de los nombres que
identifican a la localidad obliga al usuario a darse cuenta del hecho de que el sistema est distribuido.
Bases de Datos Distribuidas

La transparencia de localizacin se logra creando un conjunto de seudnimos o alias para cada

usuario. As, el usuario puede referirse a los datos usando nombres sencillos que el sistema traduce a
nombres completos.

Con el uso de seudnimos, no ser necesario que el usuario conozca la localizacin fsica de un
dato. Adems, el administrador de la base de datos puede cambiar un dato de una localidad a otra sin
afectar a los usuarios.

Esquema completo de asignacin de nombres

Ya vimos que un nombre proporcionado por el usuario debe pasar por varios pasos de traduccin
antes de que pueda servir como referencia a una copia especfica de un fragmento determinado en una
localidad especfica.

Para ilustrar cmo funciona el esquema, consideramos un usuario que se encuentra en la sucursal
1 (L1). Este usuario emplea el seudnimo depsito-local para el fragmento local depsito-F1 de la
relacin deposito. Cuando este usuario hace referencia a depsito-local, el subsistema de procesamiento
de consultas busca depsito-local en la tabla de seudnimos y la sustituye por Ll.depsito.F1. Es posible
que L1.depsito.Fl est repetido. Si es as, debe consultarse la tabla de copias para elegir una copia. Esta
copia podra tambin estar fragmentada, lo que hara necesario consultar la tabla de fragmentacin. En
la mayor parte de los casos, slo es preciso consultar una o dos tablas.

Transparencia y actualizaciones

De alguna forma es ms difcil hacer transparente la base de datos para usuarios que la
actualizan que para aquellos que slo leen datos. El problema principal es asegurarse de que se
actualizan todas las copias de un dato y tambin los fragmentos afectados.

En el caso ms general, el problema de actualizacin de informacin repetida y fragmentada est

relacionado con el problema de actualizacin de vistas.

Cuando sacamos dinero del banco actualiza nuestro estado de cuenta

DISEO DE LA DISTRIBUCIN:

Introduccin

El diseo de un sistema de base de datos distribuido implica la toma de decisiones sobre la

ubicacin de los programas que accedern a la base de datos y sobre los propios datos que constituyen
esta ltima, a lo largo de los diferentes puestos que configuren una red de ordenadores. La ubicacin de
los programas, a priori, no debera suponer un excesivo problema dado que se puede tener una copia de
ellos en cada mquina de la red (de hecho, en este documento se asumir que as es). Sin embargo, cul es
la mejor opcin para colocar los datos: en una gran mquina que albergue a todos ellos, encargada de
Bases de Datos Distribuidas

responder a todas las peticiones del resto de las estaciones sistema de base de datos centralizado , o
podramos pensar en repartir las relaciones, las tablas, por toda la red. En el supuesto que nos
decidiramos por esta segunda opcin, qu criterios se deberan seguir para llevar a cabo tal
distribucin? Realmente este enfoque ofrecer un mayor rendimiento que el caso centralizado? Podra
optarse por alguna otra alternativa? En los prrafos sucesivos se tratar de responder a estas cuestiones.

Tradicionalmente se ha clasificado la organizacin de los sistemas de bases de datos distribuidos

sobre tres dimensiones: el nivel de comparticin, las caractersticas de acceso a los datos y el nivel de
conocimiento de esas caractersticas de acceso (vea la figura 1). El nivel de comparticin presenta tres
alternativas: inexistencia, es decir, cada aplicacin y sus datos se ejecutan en un ordenador con ausencia
total de comunicacin con otros programas u otros datos; se comparten slo los datos y no los programas,
en tal caso existe una rplica de las aplicaciones en cada mquina y los datos viajan por la red; y, se
reparten datos y programas, dado un programa ubicado en un determinado sitio, ste puede solicitar un
servicio a otro programa localizado en un segundo lugar, el cual podr acceder a los datos situados en un
tercer emplazamiento. Como se coment lneas atrs, en este caso se optar por el punto intermedio de
comparticin.

Figura 1. Enfoque de la distribucin.

Respecto a las caractersticas de acceso a los datos existen dos alternativas principalmente: el modo
de acceso a los datos que solicitan los usuarios puede ser esttico, es decir, no cambiar a lo largo del
tiempo, o bien, dinmico. Se puede comprender fcilmente la dificultad de encontrar sistemas
distribuidos reales que puedan clasificarse como estticos. Sin embargo, lo realmente importante radica,
estableciendo el dinamismo como base. Esta dimensin establece la relacin entre el diseo de bases de
datos distribuidas y el procesamiento de consultas.

La tercera clasificacin es el nivel de conocimiento de las caractersticas de acceso. Una posibilidad

es que los diseadores carezcan de informacin alguna sobre cmo los usuarios acceden a la base de
datos. Es una posibilidad terica, pero sera muy laborioso abordar el diseo de la base de datos con tal
ausencia de informacin. Lo ms prctico sera conocer con detenimiento la forma de acceso de los
usuarios o, en el caso de su imposibilidad, conformarnos con una informacin parcial de sta.

A la hora de abordar el diseo de una base de datos distribuida podremos optar principalmente por
dos tipos de estrategias: la estrategia ascendente y la estrategia descendente. La estrategia ascendente
podra aplicarse en aquel caso donde haya que proceder a un diseo a partir de un nmero de pequeas
bases de datos existentes, con el fin de integrarlas en una sola. En este caso se partira de los esquemas
conceptuales locales y se trabajara para llegar a conseguir el esquema conceptual global. Aunque este
Bases de Datos Distribuidas

caso se pueda presentar con facilidad en la vida real, se prefiere pensar en el caso donde se parte de cero y
se avanza en el desarrollo del trabajo siguiendo la estrategia descendente.

Figura 2.

Estrategia descendente.

Comienza con un anlisis de los requisitos que definirn el entorno del sistema con la finalidad de
obtener tanto los datos como las necesidades de procesamiento de todos los posibles usuarios del banco
de datos. Igualmente, se debern fijar los requisitos del sistema, los objetivos que debe cumplir respecto a
los grados de rendimiento, seguridad, disponibilidad y flexibilidad, sin olvidar el importante aspecto
econmico. El diseo de las vistas trata de definir las interfaces para el usuario final y, por otro lado, el
diseo conceptual se encarga de examinar la empresa para determinar los tipos de entidades y establecer
la relacin entre ellas. El diseo conceptual puede interpretarse como la integracin de las vistas del
usuario, este aspecto es de vital importancia ya que el modelo conceptual debera soportar no slo las
aplicaciones existentes, sino que debera estar preparado para futuras aplicaciones. En el diseo
Bases de Datos Distribuidas

conceptual y de las vistas del usuario se especificarn las entidades de datos y se determinarn las
aplicaciones que funcionarn sobre la base de datos. Desarrollado el trabajo hasta aqu, se puede abordar
el diseo del esquema conceptual global. Este esquema y la informacin relativa al acceso de los datos
sirven de entrada al paso distintivo: el diseo de la distribucin. El objetivo de esta etapa consiste en
disear los esquemas conceptuales locales que se distribuirn a lo largo de todas las localidades del
sistema distribuido. Sera posible tratar cada entidad como una unidad de distribucin; en el caso del
modelo relacional, cada entidad se corresponde con una tabla. Resulta bastante frecuente dividir cada
tabla en subtablas menores denominadas fragmentos que luego se ubican en una u otra localidad. De ah,
que el proceso del diseo de la distribucin conste de dos actividades fundamentales: la fragmentacin y
la asignacin. El ltimo paso del diseo de la distribucin es el diseo fsico, el cual proyecta los esquemas
conceptuales locales sobre los dispositivos de almacenamiento fsico disponibles en los distintos sitios. Las
entradas para este paso son los esquemas conceptuales locales y la informacin de acceso a los
fragmentos. Por ltimo, se sabe que la actividad de desarrollo y diseo es un tipo de proceso que necesita
de una monitorizacin y un ajuste peridicos, para que si se llegan a producir desviaciones, se pueda
retornar a alguna de las fases anteriores.

Diseo

Existen diversas formas de afrontar el problema del diseo de la distribucin. Las ms usuales se
muestran en la figura siguiente. En el primer caso, caso A, los dos procesos fundamentales, la
fragmentacin y la asignacin, se abordan de forma simultnea. Esta metodologa se encuentra en desuso,
sustituida por el enfoque en dos fases, caso B: la realizacin primeramente de la particin para luego
asignar los fragmentos generados.

Figura 3. Enfoques para realizar el diseo

distributivo.

Se ha comentado la conveniencia de
descomponer las tablas de la base de datos en pequeos fragmentos, pero no se ha justificado el hecho ni
se han aportado razones para efectuarlo.

El principal problema de la fragmentacin radica en encontrar la unidad apropiada de distribucin.

Una tabla no es una buena unidad de distribucin por muchas razones. Primero, las vistas de la aplicacin
normalmente son subconjuntos de tablas. Adems, la localidad de los accesos de las aplicaciones no est
definida sobre tablas enteras pero s sobre subconjuntos de las mismas. Por ello, sera normal considerar
como unidad de distribucin a estos subconjuntos de tablas.

Segundo, si las aplicaciones tienen vistas definidas sobre una determinada tabla (considerndola
ahora una unidad de distribucin) que reside en varios sitios de la red, se puede optar por dos
Bases de Datos Distribuidas

alternativas. Por un lado, la tabla no estar replicada y se almacena en un nico sitio, o existe rplica en
todos o algunos de los sitios en los cuales reside la aplicacin. Las consecuencias de esta estrategia son la
generacin de un volumen de accesos remotos innecesario. Adems, se pueden realizar rplicas
innecesarias que causen problemas en la ejecucin de las actualizaciones y puede no ser deseable si el
espacio de almacenamiento est limitado.

Tercero, la descomposicin de una tabla en fragmentos, tratados cada uno de ellos como una
unidad de distribucin, permite el proceso concurrente de las transacciones. Tambin la relacin de estas
tablas, normalmente, provocar la ejecucin paralela de una consulta al dividirla en una serie de
subconsultas que operar sobre los fragmentos.

Pero la fragmentacin tambin acarrea inconvenientes. Si las aplicaciones tienen requisitos tales que
prevengan la descomposicin de la tabla en fragmentos, estas aplicaciones cuyas vistas estn definidas
sobre ms de un fragmento pueden sufrir una degradacin en el rendimiento. Por tanto, puede ser
necesario recuperar los datos de dos fragmentos y llevar a cabo sobre ellos operacin de unin y produto,
lo cual es costoso.

Un segundo problema se refiere al control semntico. Como resultado de la fragmentacin los

atributos implicados en una dependencia se descomponen en diferentes fragmentos los cuales pueden
destinarse a sitios diferentes. En este caso, la sencilla tarea de verificar las dependencias puede resultar
una tarea de bsqueda de los datos implicados en un gran nmero de sitios.

TIPOS DE FRAGMENTACIN:

Dado que una relacin (tabla) corresponde esencialmente con una tabla y la cuestin consiste en
dividirla en fragmentos menores, inmediatamente surgen dos alternativas lgicas para llevar a cabo el
proceso: la divisin horizontal y la divisin vertical. La divisin o fragmentacin horizontal trabaja sobre
las tuplas, dividiendo la tabla en subtablas que contienen un subconjunto de las tuplas(ES UNA FILA DE
UN ATABLA) que alberga la primera. La fragmentacin vertical, en cambio, se basa en los atributos(ES
UNA CAMPO) de la tabla para efectuar la divisin. Estos dos tipos de particin podran considerarse los
fundamentales y bsicos. Sin embargo, existen otras alternativas. Se habla de fragmentacin mixta o
hbrida cuando el proceso de particin hace uso de los dos tipos anteriores.

La fragmentacin mixta puede llevarse a cabo de tres formas diferentes: desarrollando primero la
fragmentacin vertical y, posteriormente, aplicando la particin horizontal sobre los fragmentos verticales
(denominada particin VH), o aplicando primero una divisin horizontal para luego, sobre los
fragmentos generados, desarrollar una fragmentacin vertical (llamada particin HV). Otro enfoque
distinto y relativamente nuevo, consiste en aplicar sobre una tabla, de forma simultnea y no secuencial,
la fragmentacin horizontal y la fragmentacin vertical; en este caso, se generar una rejilla y los
fragmentos formarn las celdas de esa rejilla, cada celda ser exactamente un fragmento vertical y un
fragmento horizontal
Bases de Datos Distribuidas

Volviendo a la figura 3, puede observarse como los casos C y D se basan en la mencionada

generacin de la rejilla, con la diferencia que en el primero de ellos se produce una fusin, una
desfragmentacin de las celdas, agrupndolas de la manera ms adecuada para obtener mayor
rendimiento, ya que los fragmentos generados son muy pequeos. En el segundo caso se asignan las
celdas a los sitios y luego se realiza una rigurosa optimizacin de cada sitio. El caso E sera aquel en el que
se utiliza la fragmentacin VH o la fragmentacin HV.

Figura 3. Enfoques para realizar el diseo distributivo.

Bases de Datos Distribuidas

Figura 4. Distintos tipos de fragmentacin.

Grado de Fragmentacin

Cuando se va a fragmentar una base de datos deberamos sopesar qu grado de fragmentacin va a

alcanzar, ya que ste ser un factor que influir notablemente en el desarrollo de la ejecucin de las
consultas. El grado de fragmentacin puede variar desde una ausencia de la divisin, considerando a las
relaciones unidades de fragmentacin; o bien, fragmentar a un grado en el cada tupla o atributo forme un
fragmento.

EL GRADO DE FRAGMENTACION:

ES EL NUMERO DE FRAGMENTOS RESULTANTE DE UNA TABLA

Reglas de correccin de la fragmentacin

Durante el proceso de fragmentacin se deben cumplir tres reglas las cuales asegurarn la ausencia
de cambios semnticos en la base de datos durante el proceso.

1. Complecin. Si una tabla R se descompone en una serie de fragmentos R1, R2, ..., Rn, cada
elemento de datos que pueda encontrarse en R deber poder encontrarse en uno o varios
fragmentos Ri. Esta propiedad extremadamente importante asegura que los datos de la tabla
global se proyectan sobre los fragmentos sin prdida alguna. Tenga en cuenta que en el caso
horizontal el elemento de datos, normalmente, es una tupla, mientras que en el caso vertical es
un atributo.

2. Reconstruccin. Si una tabla R se descompone en una serie de fragmentos R1, R2, ..., Rn, puede
definirse un operador relacional tal que el operador ser diferente dependiendo de las
diferentes formas de fragmentacin. La reconstruccin de la tabla a partir de sus fragmentos
asegura la preservacin de las restricciones definidas sobre los datos en forma de dependencias.

3. Disyuncin. Si una tabla R se descompone horizontalmente en una serie de fragmentos R1,

R2, ..., Rn, y un elemento de datos di se encuentra en algn fragmento Rj, entonces no se
Bases de Datos Distribuidas

encuentra en otro fragmento Rk (k j). Esta regla asegura que los fragmentos horizontales sean
disjuntos. Si una tabla R se descompone verticalmente, sus atributos primarios clave
normalmente se repiten en todos sus fragmentos.

Alternativas de asignacin

Partiendo del supuesto que la base de datos se haya fragmentado correctamente, habr que decidir
sobre la manera de asignar los fragmentos a los distintos sitios de la red. Cuando una serie de datos se
asignan, stos pueden replicarse para mantener una copia. Las razones para la rplica giran en torno a la
seguridad y a la eficiencia de las consultas de lectura. Si existen muchas reproducciones de un elemento
de datos, en caso de fallo en el sistema se podra acceder a esos datos ubicados en sitios distintos. Adems,
las consultas que acceden a los mismos datos pueden ejecutarse en paralelo, ya que habr copias en
diferentes sitios. Por otra parte, la ejecucin de consultas de actualizacin, de escritura, implicara la
actualizacin de todas las copias que existan en la red, cuyo proceso puede resultar problemtico y
complicado. Por tanto, un buen parmetro para afrontar el grado de rplica consistira en conocer la
cantidad de consultas de lectura que se efectuarn, as como el nmero de consultas de escritura que se
llevarn a cabo.

En una red donde las consultas que se procesen sean mayoritariamente de lectura, se podra
alcanzar un alto grado de rplica, no as en el caso contrario. Una base de datos fragmentada es aquella
donde no existe rplica alguna. Los fragmentos se alojan en sitios donde nicamente existe una copia de
cada uno de ellos a lo largo de toda la red. En caso de rplica, podemos considerar una base de datos
totalmente replicada, donde existe una copia de toda la base de datos en cada sitio, o considerar una base
de datos parcialmente replicada donde existan copias de los fragmentos ubicados en diferentes sitios.

Rplica
Rplica total Particin
parcial

Procesamiento de consultas fcil dificultad Similar

Gestin del directorio fcil o inexistente dificultad Similar

Control de concurrencia moderado Difcil Fcil

Seguridad muy alta Alta Baja

\Realidad posible aplicacin realista posible aplicacin

Informacin necesaria

Un aspecto importante en el diseo de la distribucin es la cantidad de factores que contribuyen a

un diseo ptimo. La organizacin lgica de la base de datos, la localizacin de las aplicaciones, las
Bases de Datos Distribuidas

caractersticas de acceso de las aplicaciones a la base de datos y las caractersticas del sistema en cada sitio,
tienen una decisiva influencia sobre la distribucin. La informacin necesaria para el diseo de la
distribucin puede dividirse en cuatro categoras: la informacin de la base de datos, la informacin de la
aplicacin, la informacin sobre la red de computadoras y la informacin sobre las computadoras en s.
Las dos ltimas son de carcter cuantitativo y servirn, principalmente, para desarrollar el proceso de
asignacin.

FRAGMENTACIN HORIZONTAL:

La fragmentacin horizontal se realiza sobre las tuplas de la tabla. Existen dos variantes de la
fragmentacin horizontal: la primaria y la derivada. La fragmentacin horizontal primaria de una tabla se
desarrolla empleando los predicados definidos en esa tabla. Por el contrario, la fragmentacin horizontal
derivada consiste en dividir una tabla partiendo de los predicados definidos sobre alguna otra.

Informacin necesaria para la fragmentacin horizontal

Informacin sobre la base de datos.

Esta informacin implica al esquema conceptual global. Es importante sealar cmo las tablas de la
base de datos se conectan con otras. En una conexin de tablas normalmente se denomina tabla
propietaria a aquella situada en la cabecera del vnculo, mientras que se llama tabla miembro a la que est
ubicada en la cola del enlace. Dicho de otra forma podemos pensar en tablas de origen cuando nos
refiramos a las propietarias y tablas destino cuando lo hagamos con las miembro. Definiremos dos
funciones: propietaria y miembro, las cuales proyectarn un conjunto de enlaces sobre un conjunto de
tablas. Adems, dado un enlace, devolvern el miembro y el propietario de la relacin, respectivamente.
La informacin cuantitativa necesaria gira en torno a la cardinalidad de cada relacin, notada como
card(R).

Informacin sobre la aplicacin.

Necesitaremos tanto informacin cualitativa como cuantitativa. La informacin cualitativa guiar la

fragmentacin, mientras que la cuantitativa se necesitar en los modelos de asignacin. La principal
informacin de carcter cualitativo son los predicados empleados en las consultas de usuario. Si no fuese
posible investigar todas las aplicaciones para determinar estos predicados, al menos se deberan
investigar las ms importantes. Podemos pensar en la regla "80/20" para guiarnos en nuestro anlisis, esta
regla dice que el 20% de las consultas existentes acceden al 80% de los datos. Llegados a este punto, sera
interesante determinar los predicados simples.

A parte de los predicados simples, las consultas emplean predicados ms complejos resultado de
combinaciones lgicas de los simples. Una combinacin especialmente interesante es la conjuncin de
predicados simples, al predicado resultante se le denomina predicado mintrmino. Partiendo de que
siempre es posible transformar una expresin lgica en su forma normal conjuntiva, usaremos los
predicados mintrmino en los algoritmos para no causar ninguna prdida de generalidad.

Sobre la informacin cuantitativa necesaria relativa a las aplicaciones, necesitaremos definir dos
conjuntos de datos.

1. Selectividad mintrmino. Es el nmero de tuplas de una relacin a las que accede una consulta de
acuerdo a un predicado mintrmino dado. Notaremos la selectividad de un mintrmino mi como
sel(mi).
Bases de Datos Distribuidas

2. Frecuencia de acceso. Es la frecuencia con la que un usuario accede a los datos. Si Q = {q1, q2, ..., qq} es
un conjunto de consultas de usuario, acc(qi) indica la frecuencia de acceso a la consulta qi en un
periodo dado.

Fragmentacin horizontal primaria

Un fragmento horizontal Ri de una relacin R contiene todas las tuplas de R que satisfacen un
predicado mintrmino mi. Por tanto, dado un conjunto de predicados mintrmino M, existen tantos
fragmentos horizontales de la relacin R como predicados mintrmino.

Un aspecto importante de los predicados simples es su complecin, as como su minimalidad. Un

conjunto de predicados simples Pr se dice que es completo si y solo si existe una probabilidad idntica de
acceder por cada aplicacin a cualquier par de tuplas pertenecientes a cualquier fragmento mintrmino.
Se puede apreciar como la definicin de complecin de un conjunto de predicados simples difiere de la
regla de complecin de la fragmentacin.

El segundo paso en el proceso de fragmentacin primaria consiste en derivar el conjunto de

predicados mintrmino que pueden definirse sobre los predicados del conjunto Pr'. Estos predicados
mintrmino establecen los fragmentos candidatos para el proceso de asignacin. El establecimiento de los
predicados mintrmino es trivial; la dificultad radica en el tamao del conjunto de predicados
mintrmino, que puede ser muy grande.

El tercer paso aborda la eliminacin de algunos fragmentos mintrmino que puedan ser
redundantes. Esta eliminacin se desarrolla identificando aquellos mintrminos que puedan resultar
contradictorios sobre un conjunto de implicaciones.

Fragmentacin horizontal derivada

Una fragmentacin horizontal derivada se define sobre una relacin miembro de acuerdo a una
operacin de seleccin especificada sobre su propietaria. Se deben dejar claros dos puntos. Primero, el
enlace entre las relaciones propietaria y miembro se define como un equi-yunto. Segundo, un equi-yunto
puede desarrollarse a travs de semiyuntos. Este segundo punto es especialmente importante, ya que
deseamos fraccionar una relacin miembro segn la fragmentacin de su propietaria, adems es necesario
que el fragmento resultante se defina nicamente sobre los atributos de la relacin miembro.

Las tres entradas necesarias para desarrollar la fragmentacin horizontal derivada son las
siguientes: el conjunto de particiones de la relacin propietaria, la relacin miembro y el conjunto se
predicados resultados de aplicar el semi-yunto entre la propietaria y la miembro.

Existe una posible complicacin. En un esquema de base de datos, resulta frecuente que existan ms
de dos enlaces sobre una relacin R. En este caso, aparecen ms de una posibilidad de fragmentacin
horizontal derivada. La decisin para elegir una u otra se basa en dos criterios: Uno, la fragmentacin con
mejores caractersticas de yunto. Dos, la fragmentacin empleada en ms aplicaciones.

Discutamos el segundo criterio primero. Resulta sencillo de establecer si tomamos en consideracin

la frecuencia con la que cada aplicacin accede a los datos. Si es posible, deberamos intentar facilitar el
acceso a los usuarios que hagan mayor uso de los datos para, de esta manera, minimizar el impacto total
del rendimiento del sistema.
Bases de Datos Distribuidas

Figura 5. Grafo de yuntos entre fragmentos.

El primer criterio, sin embargo, no es tan sencillo. Considere, por ejemplo, la fragmentacin
expuesta en el ejemplo 8. El objetivo de esta fragmentacin consiste en beneficiar a la consulta que haga
uso de las dos relaciones al poder realizarse el yunto de CLIENTES y PROVINC sobre relaciones ms
pequeas (es decir, fragmentos), y posibilitar la confeccin de yuntos de manera distribuida. El primer
aspecto resulta obvio. Los fragmentos de CLIENTES son ms pequeos que la propia relacin CLIENTES.
Por tanto, resultar ms rpido llevar a cabo el yunto de un fragmento de PROVINC con otro de
CLIENTES que trabajar con las propias relaciones. El segundo punto, sin embargo, es ms importante ya
que es la esencia de las bases de datos distribuidas. Si, adems de estar ejecutando un nmero de
consultas en diferentes sitios, podemos ejecutar una consulta en paralelo, se espera que el tiempo de
respuesta del sistema aumente. En el caso de yuntos, esto es posible bajo ciertas circunstancias. Considere,
por ejemplo, el grafo de yunto (los enlaces) entre los fragmentos de CLIENTES y la derivada PROVINC.
Hay nicamente un enlace entrando o saliendo de un fragmento. De ah, que se denomine a este grafo,
grafo simple. La ventaja de este diseo donde la relacin de yunto entre los fragmentos es simple, radica
en la asignacin a un sitio tanto de la propietaria como de la miembro y los yuntos entre pares diferentes
de fragmentos pueden realizarse independientemente y en paralelo. Desgraciadamente, la obtencin de
grafos de yunto simples no siempre es posible. En tal caso, la mejor alternativa sera realizar un diseo
que provoque un grafo de yuntos fragmentados. Un grafo fragmentado consiste en dos o ms subgrafos
que no estn enlazados entre ellos. Por tanto, los fragmentos que se obtengan no se distribuirn para
ejecuciones paralelas de un modo tan fcil como aquellos obtenidos a travs de grafos simples, pero su
asignacin an ser posible.

Procederemos ahora a probar la correccin de los algoritmos presentados con respecto a los tres
criterios enunciados pginas atrs.

1. Complecin. La complecin de una fragmentacin horizontal primaria se basa en la seleccin de los

predicados a usar. En la medida que los predicados seleccionados sean completos, se garantizar que
el resultado de la fragmentacin tambin lo ser. Partiendo de la base que el algoritmo de
fragmentacin es un conjunto de predicados completos y mnimos Pr', se garantiza la complecin
siempre que no aparezcan errores al realizar la definicin de Pr'. La complecin de una fragmentacin
horizontal derivada es algo ms difcil de definir. La dificultad viene dada por el hecho de que los
predicados que intervienen en la fragmentacin forman parte de dos relaciones. Definamos la regla de
complecin formalmente. Sea R la relacin miembro de un enlace cuya propietaria es la relacin S, la
cual est fragmentada como FS = {S1, S2, ..., Sw}. Adems, sea A el atributo de yunto entre R y S.
Entonces para cada tupla t de R, existir una tupla t' de S tal que t[A] = t'[A].

2. Reconstruccin. La reconstruccin de una relacin global a partir de sus fragmentos se desarrolla con
el operador de unin tanto para la fragmentacin horizontal primaria como para la derivada.
Bases de Datos Distribuidas

3. Disyuncin. Resulta sencillo establecer la disyuncin de la fragmentacin tanto para la primaria como
para la derivada. En el primer caso, la disyuncin se garantiza en la medida en que los predicados
mintrmino que determinan la fragmentacin son mutuamente exclusivos. En la fragmentacin
derivada, sin embargo, implica un semi-yunto que aade complejidad al asunto. La disyuncin puede
garantizarse si el grafo de yunto es simple. Si no es simple, ser necesario investigar los valores de las
tuplas. En general, no se desea juntar una tupla de una relacin miembro con dos o ms tuplas de una
relacin propietaria cuando estas tuplas se encuentran en fragmentos diferentes a los de la
propietaria. Esto no es fcil de establecer, e ilustra por qu los esquemas de la fragmentacin derivada
que generan un grafo de yunto simple son siempre ms atractivos.

FRAGMENTACIN VERTICAL:

Introduccin

Recurdese que la fragmentacin vertical de una relacin R produce una serie de fragmentos R1,
R2, ..., Rr, cada uno de los cuales contiene un subconjunto de los atributos de R as como la clave primaria
de R. El objetivo de la fragmentacin vertical consiste en dividir la relacin en un conjunto de relaciones
ms pequeas tal que algunas de las aplicaciones de usuario slo hagan uso de un fragmento. Sobre este
marco, una fragmentacin ptima es aquella que produce un esquema de divisin que minimiza el
tiempo de ejecucin de las aplicaciones que emplean esos fragmentos.

La particin vertical resulta ms complicada que la horizontal. Esto se debe al aumento del nmero
total de alternativas que tenemos disponibles.

Existen dos enfoques heursticos para la fragmentacin vertical de relaciones:

1. Agrupacin. Comienza asignando cada atributo a un fragmento, y en cada paso, junta algunos de los
fragmentos hasta que satisface un determinado criterio. La agrupacin sugiri en principio para bases
de datos centralizadas y se us posteriormente para las bases de datos distribuidas.

2. Escisin. A partir de la relacin se deciden que fragmentos resultan mejores, basndose en las
caractersticas de acceso de las aplicaciones a los atributos. Esta tcnica se present, tambin, para
bases de datos centralizadas. Posteriormente, se extendi al entorno distribuido.

La escisin genera fragmentos no solapados mientras que la agrupacin normalmente produce

fragmentos solapados. Dentro del contexto de los sistemas de bases de datos distribuidos, son preferibles
los fragmentos no solapados. Evidentemente, los fragmentos no solapados se refieren nicamente a
atributos clave no primarios.

La rplica de las claves de la relacin en los fragmentos. Es una caracterstica de la fragmentacin

vertical que permite la reconstruccin de la relacin global. Por tanto, la escisin considera nicamente
aquellos atributos que no son parte de la clave primaria.

La rplica de los atributos clave supone una gran ventaja, a pesar de los problemas que pueda
causar. La ventaja est relacionada con el esfuerzo para mantener la integridad semntica. Tenga en
cuenta que cada dependencia es, de hecho, una restriccin que influye sobre el valor de los atributos de
las respectivas relaciones en todo momento. Tambin muchas de estas dependencias implican a los
atributos clave de una relacin. Si queremos disear una base de datos tal que los atributos clave sean
parte de una fragmento que est ubicado en un sitio, y los atributos relacionados sean parte de otro
Bases de Datos Distribuidas

fragmento asignado a un segundo sitio, cada peticin de actualizacin provocar la verificacin de

integridad que necesitar de una comunicacin entre esos sitios. La rplica de los atributos clave de cada
fragmento reduce esta problemtica, pero no elimina toda su complejidad, ya que la comunicacin puede
ser necesaria para las restricciones de integridad que implican a las claves primarias, as como para el
control de concurrencia.

Una posible alternativa a la rplica de los atributos clave es el empleo de identificadores de tuplas,
que son valores nicos asignados por el sistema a las tuplas de una relacin. Mientras el sistema
mantenga los identificadores, los fragmentos permanecern disjuntos.

Informacin necesaria para la fragmentacin vertical

La principal informacin que necesitaremos se referir a las aplicaciones. Teniendo en cuenta que la
fragmentacin vertical coloca en un fragmento aquellos atributos a los que se accede de manera
simultnea, necesitaremos alguna medida que defina con ms precisin el concepto de simultaneidad.
Esta medida es la afinidad de los atributos, que indica la relacin estrecha existente entre los atributos.
Desgraciadamente, no es muy realista esperar que el diseador o los usuarios puedan especificar estos
valores.

El principal dato necesario relativo a las aplicaciones es la frecuencia de acceso. Sea Q = {q1, q2, ...,
qq} el conjunto de consultas de usuario (aplicaciones) que funcionan sobre una relacin R(A1, A2, ..., An).

Los vectores uso(qi,) pueden definirse muy fcilmente para cada aplicacin siempre que el
diseador conozca las aplicaciones existentes en el sistema. La regla 80/20 expuesta pginas atrs podra
resultar til para el desarrollo de esta tarea.

Los valores del uso de los atributos en general no son suficientes para desarrollar la base de la
escisin y la fragmentacin de los atributos, ya que estos valores no representan el peso de las frecuencias
de la aplicacin. La dimensin de esta frecuencia puede incluirse en la definicin de la medida de los
atributos afines afd(Ai, Aj), la cual mide el lmite entre dos atributos de una relacin de acuerdo a cmo las
aplicaciones acceden a ellos.

FRAGMENTACIN MIXTA O HBRIDA:

En muchos casos la fragmentacin vertical u horizontal del esquema de la base de datos no ser
suficiente para satisfacer los requisitos de las aplicaciones. Como ya se cit al comienzo de este
documento podemos combinar ambas, utilizando por ello la denominada fragmentacin mixta. Cuando al
proceso de fragmentacin vertical le sigue una horizontal, es decir, se fragmentan horizontalmente los
fragmentos verticales resultantes, se habla de la fragmentacin mixta HV. En el caso contrario, estaremos
ante una fragmentacin VH. Una caracterstica comn a ambas es la generacin de rboles que
representan la estructura de fragmentacin (vea la figura 8).

Considere, por ejemplo, la relacin PROVINC. Recordar que se le aplic una fragmentacin
horizontal de acuerdo al valor del atributo CCODZONA resultando cuatro fragmentos horizontales.
Podramos pensar en aplicarle una nueva fragmentacin de carcter vertical. Entonces resultaran cuatro
fragmentos horizontales divididos, por ejemplo, en dos fragmentos verticales. En este caso el nmero total
de fragmentos ascendera, lgicamente, a ocho.
Bases de Datos Distribuidas

Figura 8. Estructura arbrea de fragmentacin mixta.

No se desea entrar en excesivos detalles sobre las reglas y condiciones para efectuar la
fragmentacin mixta. Entre otras razones porque, tanto a la fragmentacin HV como la fragmentacin
VH, se le pueden aplicar los mismos criterios y reglas que a la fragmentacin horizontal y vertical. Es
decir, volviendo al ejemplo anterior, al cual le practicamos la fragmentacin HV, al realizar la
fragmentacin horizontal tal como se ha expuesto, lo que se obtienen no son ms que subrelaciones, la
unin de las cuales da lugar a la relacin PROVINC. Por tanto, para fragmentar cada subrelacin sera
perfectamente viable aplicarle el mtodo de fragmentacin vertical que se ha desarrollado. Como, en este
caso, se han querido generar dos fragmentos verticales por cada uno horizontal, simplemente deberamos
confeccionar la matriz de grupos afines (a travs del algoritmo BEA) para cada fragmento horizontal y
aplicarle, posteriormente, el algoritmo de fragmentacin binaria PARTICIN.

Tambin debe tenerse en cuenta el nmero de niveles arbreos que se generen, es decir, nadie
impide que tras realizar una fragmentacin VH, podamos aplicar a los fragmentos resultantes una nueva
fragmentacin vertical, y a estos ltimos una nueva fragmentacin horizontal, etc. Dicho nmero puede
ser grande, pero tambin ser ciertamente finito. En el caso horizontal, el nivel mximo de profundidad se
alcanzar cuando cada fragmento albergue una nica tupla, mientras que en el caso vertical el final llegar
cuando cada fragmento contenga un nico atributo. Sin embargo, aunque no deba tomarse como dogma,
el nmero de niveles no debera superar el par (VH y HV). El porqu de esta afirmacin es bien sencillo,
piense, por ejemplo, en el coste que supondra realizar la unin o el yunto de una relacin con
fragmentacin nivel 7. Evidentemente, el coste sera muy elevado y ese aumento de rendimiento que se
persigue al aplicar estas tcnicas, quizs, no se produzca.

Antes de pasar a estudiar el problema de la asignacin se desea comentar la tcnica de

fragmentacin mixta basada en celdas [2]. Esta tcnica se basa en la generacin de celdas de rejilla. Qu es
una celda de rejilla, podramos definirla como un fragmento horizontal y vertical simultneo. La tcnica
aplica un algoritmo de fragmentacin vertical y otro horizontal de manera concurrente sobre la relacin.
Bases de Datos Distribuidas

Los algoritmos realizan una fragmentacin mxima, es decir, se persigue que en cada celda nicamente
haya un atributo y una tupla. Quiz el lector pueda encontrar el mtodo contradictorio con lo citado
anteriormente respecto a la eficiencia, dada la gran cantidad de fragmentos generados, el nmero es,
efectivamente, el mximo. Sin embargo, este slo es el primer paso del proceso. Una vez generadas las
celdas se aplica un mtodo para optimizar la rejilla mediante fusin o desfragmentacin, de acuerdo,
fundamentalmente, a las aplicaciones que acten sobre esos fragmentos. El mtodo, por tanto, persigue
una fragmentacin los ms especfica posible acorde con las aplicaciones y los sitios existentes en la red.

Informacin necesaria

En esta etapa de la asignacin, necesitaremos datos cuantitativos sobre la base de datos, las
aplicaciones que funcionan sobre ella, la red de comunicaciones, las caractersticas de proceso, y el lmite
de almacenamiento de cada sitio de la red. Procederemos a discutirlos en detalle.

Informacin de la base de datos. Para desarrollar la fragmentacin horizontal, definimos la

selectividad de los mintrminos. Ahora, necesitamos extender esta definicin a los fragmentos y definir la
selectividad de un fragmento Fj con respecto a una consulta qi. Es el nmero de tuplas de Fj a las que se
necesita acceder para procesar qi. Este valor lo notaremos como seli(Fj). Otro elemento informativo de los
fragmentos de la base de datos es su tamao. El tamao de un fragmento Fj viene dado por tamao(Fj) =
card(Fj)*long(Fj), donde long(Fj) es la longitud (en octetos) de una tupla del fragmento Fj.

Informacin de los sitios. Sobre cada ordenador necesitamos conocer sus capacidades de
procesamiento y almacenamiento. Obviamente, estos valores pueden calcularse a travs de funciones
elaboradas o por simples estimaciones. La unidad de coste de almacenar datos en el sitio Sk ser denotada
como UCAk. As mismo, especificaremos como medida de coste UPTk al coste de procesar una unidad de
trabajo en el sitio Sk. La unidad de trabajo debera ser idntica a aquella utilizada en las medidas RR y UR.

Informacin sobre la red. En nuestro modelo asumiremos la existencia de una red simple donde el
coste de comunicaciones se define respecto a una trama de datos. Entonces gij nota el coste de
comunicacin por trama entre los sitios Si y Sj. Para permitir el clculo del nmero de mensajes, usaremos
ftamao como el tamao (en octetos) de una trama. Es evidente que existen modelos de red mucho ms
elaborados que toman en cuenta las capacidades del canal, las distancias entre sitios, las caractersticas del
protocolo, etc. Sin embargo, se cree que la derivacin de estas ecuaciones se sale fuera de este documento.

PROCESAMIENTO DISTRIBUIDO DE CONSULTAS

Existen varios medios para calcular la respuesta a una consulta. En el caso de sistemas
centralizado, el criterio principal para determinar el costo de una estrategia especifica es el nmero de
accesos al disco. En un sistema distribuido es preciso tener en cuenta otros factores, como son:

El costo de transmisin de datos en la red.

El beneficio potencial que supondra en la ejecucin el que varias localidades procesaran en paralelo
partes de la consulta.

El costo relativo de la transferencia de datos en la red y la transferencia de datos entre la memoria

y el disco varia en forma considerable, dependiendo del tipo de red y de la velocidad de los discos. Por
tanto, en un caso general, no podemos tener en cuenta solo los costos del disco o los de la red. es necesario
llegar a un equilibrio adecuado entre los dos.
Bases de Datos Distribuidas

Repeticin y fragmentacin

Considere una consulta muy sencilla: encontrar todas las tuplas de la relacin depsito. Aunque
la consulta es muy simple, de hecho es trivial; su procesamiento no es trivial, ya que es posible que la
relacin depsito est fragmentada, repetido o las dos cosas, como ya se vio. Si la relacin deposito est
repetida, es preciso decidir qu copia se va a utilizar. Si ninguna de las copias est fragmentada, se elige
la copia que implique costos de transmisin ms reducidos. Pero si una copia est fragmentada, la
eleccin no se tan sencilla, ya que es preciso calcular varios productos o uniones para reconstruir la
relacin depsito. En tal caso, el nmero de estrategias para este ejemplo sencillo puede ser grande. De
hecho, la eleccin de una estrategia puede ser una tarea tan compleja como hacer una consulta arbitraria.

Procesamiento de interseccin simple

Considere la expresin en lgebra relacional:

cliente x deposito x sucursal

Suponemos que ninguna de las tres relaciones est repetida o fragmentada y que cliente est
almacenada en la localidad Lc, deposito en la Ld y sucursal en la L b. Sea Li la localidad donde se origin la
consulta. El sistema debe producir el resultado en la localidad L i. Entre las posibles estrategias para
procesar esta consulta se encuentran las siguientes:

Enviar copias de las tres relaciones a la localidad L i. Al emplear las tcnicas de procesamiento de
consulta, escoger una estrategia para procesar en forma local la consulta completa en Li.

Enviar una copia de la relacin cliente a la localidad L i y calcular cliente x depsito de L d. Enviar
cliente x depsito de Ld a Lb, donde se calcula (cliente x depsito) x sucursal. El resultado de esta
operacin es enviado a Li.

Pueden elaborarse estrategias similares a la anterior al intercambiar los papeles de Lc, Ld y Lb.

No puede garantizarse que una estrategia sea la mejor en todos los casos. entre los factores que
deben tomarse en cuenta estn la cantidad de datos que debe transmitirse, el costo de transmitir un
bloque de datos entre dos localidades determinadas y la velocidad de procesamiento relativa en cada
localidad.

Estrategias de interseccin utilizando el paralelismo

Considere un producto de cuatro relaciones:

r1 x r2 r3 r4

donde la relacin r1 est almacenada en la localidad L i. Suponemos que el resultado ha de

presentarse en la localidad Li. Existen, por supuesto muchas estrategias que se pueden considerar. Un
mtodo atractivo sera utilizar la estrategia de interseccin encauzada. Por ejemplo, se puede enviar r1 a
L2 y calcular r1 x r2 en L2. al mismo tiempo se puede enviar r3 a L4 y calcular r3 x r4 en L4.

La localidad L2 puede enviar tuplas de (r1 x r2) a Li conforme se vayan produciendo, en vez de
esperar a que se calcule el producto completo. De forma similar, L 4 pude enviar tuplas de (r3 x r4) a Li.
Bases de Datos Distribuidas

Una vez que las tuplas de (r 1 x r2) y (r3 x r4) lleguen a Li, esta localidad podr empezar el clculo de (r 1 x
r2) x (r3 x r4) en paralelo con el clculo de (r1 x r2) en L2 y de (r3 x r4) en L4.

Estrategia de seminterseccin

Suponer que deseamos calcular la expresin r1 x r2, donde r1 y r2 estn almacenados en las
localidades L1 y L2 respectivamente. Sean R1 y R2 los esquemas de r1 y r2. Suponer que queremos obtener el
resultado en L1. Si hay muchas tuplas de r2 que no interseccionan con ninguna de r1, entonces el envo de
r2 a S1 requiere el envo de tuplas que no contribuyen al resultado. Es conveniente borrar tales tuplas antes
de enviar los datos a L1, particularmente si los costos de la red son muy elevados.

Para hacerlo vemos la siguiente estrategia:

1. Calcular temp1 r1 r2 (r1) en L1.

2. enviar temp1 de L1 a L2.

3. Calcular temp2 r2 x temp1 en L2.

4. Enviar temp2 de L2 a L1.

5. Calcular r1 x temp2 en L1.

La estrategia anterior es ventajosa particularmente cuando en el producto participan

relativamente pocas tuplas de r 2. Es probable que suceda esta situacin si r 1 es el resultado de una
expresin de lgebra relacional que contenga la seleccin.

Esta estrategia es conocida como una estrategia de semiproducto, despus del operador de
semiproducto, indicado por x, de lgebra relacional.

CONCLUSIONES Y CONSIDERACIONES:

A lo largo de este documento se ha intentado dar una visin global y genrica de los problemas y
caractersticas que contiene el diseo de una base de datos distribuida. Se ha hecho especial hincapi en
las tcnicas de fragmentacin horizontal y vertical a travs de mtodos y algoritmos muy frecuentes en la
literatura referida al tema. Se espera que el lector no haya tenido demasiados problemas para su
comprensin, las tcnicas son sencillas y se ha procurado incluir distintos ejemplos para facilitar el
entendimiento. Igualmente, la puesta en prctica de los algoritmos, es decir, su codificacin, no es un
proceso complicado si se poseen nociones en el desarrollo de algoritmos. Piense, por ejemplo, que los dos
algoritmos de particin vertical presentados, no hacen ms que manipular matrices.

Tambin debera tenerse presente la existencia de enfoques de fragmentacin distintos y,

posiblemente, ms complejos, pero se debe pensar que ms eficientes. Sean, por ejemplo, las tcnicas de
fragmentacin vertical basadas en grafos, como el algoritmo de Navathe y Ra que genera en un solo paso
fragmentos verticales. Adems, estn apareciendo mtodos de fragmentacin mixta como el que se ha
comentado. Si bien, estos mtodos son enfoques formales ms que prcticos, desarrollados por insignes
investigadores en universidades, por tanto, lejos todava de su desarrollo comercial.
Bases de Datos Distribuidas

Pese a la aparicin de los mtodos de bases de datos distribuidas hace ya aos, parece que el salto
de lo centralizado a lo distribuido a escala comercial est por venir. Todava no se ha extendido
suficientemente el esquema distribuido, pero se espera que prximamente se produzca el avance
definitivo. Considere los dos componentes bsicos de los sistemas de bases de datos distribuidos (la
propia base de datos y la red de ordenadores) y piense en la situacin actual de la informtica. Si las bases
de datos es una de las ramas ms antiguas e importantes de la informtica, muchas empresas compran
ordenadores para dedicarlos exclusivamente a la gestin de sus datos (pienso que, prcticamente, en el
100% de las PYMES se produce este hecho) y, como parece ser que se ha asumido por parte de todo tipo
de empresarios los beneficios que acarrea la conexin de los ordenadores, la instalacin de una red, se
puede concluir diciendo que el terreno ya est abonado para su extensin comercial. Slo falta que
determinadas multinacionales decidan apostar ms fuerte por este enfoque a travs de sus famosos
sistemas gestores de bases de datos y que se produzca la consolidacin de la resolucin de los problemas
que el enfoque distribuido acarrea.