Bases de Datos Distribuidas (RES)

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.
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.
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
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 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.
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 depsitolocal, 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 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 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 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 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
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.
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 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 total
Rplica
parcial
Particin
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 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).
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.
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.
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 semiyunto 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 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.
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. 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.
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 L c, deposito en la L d y sucursal en la L b. Sea Li la
localidad donde se origin la consulta. El sistema debe producir el resultado en la localidad
Li. 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 Ld.
Enviar cliente x depsito de L d 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 L c, Ld

y L b.
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 L 2 y calcular r1 x r2 en L2. al mismo tiempo se puede enviar r 3
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. Una vez que las tuplas de (r1 x r2) y (r3 x r4) lleguen a Li, esta
localidad podr empezar el clculo de (r1 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 r 1 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 L 1. 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 L 1, 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 r2. 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.
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.

Bases de Datos Distribuidas (RES)

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Bases de Datos Distribuidas (RES)

Caricato da

Copyright:

Formati disponibili

Bases de Datos Distribuidas

Un sistema distribuido de base de datos consiste en un conjunto de localidades, cada

Red totalmente conectada

Red parcialmente conectada

Red con estructura de rbol

Las diferencias principales entre estas configuraciones son:

Costo de instalacin: El costo de conectar fsicamente las localidades