1

BASES DE DATOS DISTRIBUIDAS

CARRANZA ATH FREDY

BASES DE DATOS II
ESCUELA ACADMICO PROFESIONAL DE INFORMTICA
UNIVERSIDAD NACIONAL DE TRUJILLO
Trujillo Per
2006

Resumen. El presente documento plasma temas relevantes con respecto a las Bases de Datos
distribuidas, empezando por su definicin y explicando las caractersticas que las hacen
particulares. A la vez, se hace un pequeo paralelo entre las BDD y las BDC. Adems se da a
conocer la arquitectura de las BDD, donde se pone en manifiesto cierta similitud con la de las
BDC, as como la arquitectura de su correspondiente SGBD, que en este caso se le denomina
SGBDD. Finalmente se toma como tpico el las consultas en las BDD, donde existe un
tratamiento especial.

1. INTRODUCCIN

Al observar la evolucin de la tecnologa en cuanto al campo de las Redes, y todo proceso que indique la
participacin de ms de un ordenador, surge para el campo de las Bases de Datos, la necesidad de crear
una manera de cmo con el uso de una red, desempearse desarrollando las funciones que comnmente
las hara de manera centralizada.

Para dicho objetivo surgen las Bases de Datos Distribuidas (BDD). El nacimiento de las BDD, se debe a la
vez, que originalmente se pens en almacenar informacin de manera centralizada utilizando un
conjunto de herramientas que facilitaran este tipo de almacenamiento. Pero con el paso del tiempo esto
produjo ciertos inconvenientes que no eran posibles solucionar y mucho menos poder subsanarlos con
tan solo la informacin almacenada en un solo lugar.

Una BDD, permitir que ya no un usuario, sino un nmero muy alto de usuarios accedan a la
informacin, de una manera ordenada, consistente y coherente. Este tipo de BD, permiten que los datos
queden repartidos en ms de un ordenador, lo cual es lo ms interesante ya que surge la necesidad de
obtener un programa que maneje todas estas partes de la BDD, como si fuese una sola, y le den al
usuario la impresin de cmo si l tuviese una BD centralizada. A este programa se le conoce como el
Sistema Manejador de BDD.

Todas estas innovaciones hacen que el rea de los Sistemas Distribuidos de Informacin, en la cual las
soluciones estn integrando tecnologas con nuevas arquitecturas o formas de hacer las cosas es, sin
lugar a dudas, un campo muy estudiado. Un caso especfico de estos sistemas y que el campo de las
Bases de Datos toca muy a fondo, es lo que hemos mencionado, las Bases de Datos Distribuidas.

2. DEFINICIN DE BASE DE DATOS DISTRIBUIDA

Una Base de Datos Distribuida (BDD) es un conjunto de mltiples bases de datos lgicamente
relacionadas las cuales se encuentran distribuidas entre diferentes sitios interconectados por una red de
comunicaciones, los cuales tienen la capacidad de procesamiento autnomo lo cual indica que puede
realizar operaciones locales o distribuidas. [Segn 1]

2
Es una coleccin de datos que se encuentran distribuidos en varios sitios y que estn interconectados por
una red de comunicaciones, donde cada sitio tiene capacidad de procesamiento autnomo de
transacciones y puede hacer procesos locales. Y adems, cada sitio realiza la ejecucin de al menos una
transaccin global, la cual requiere accesos a datos en diversos sitios. [Segn 2]

Coleccin de mltiples Bases de Datos interrelacionadas lgicamente y distribuidas sobre una red de
computador. Donde los datos residen en varias localidades y las relaciones pueden estar fragmentadas
y/o replicadas. Y cada localidad tiene un sistema de B. de D. local, puede procesar transacciones locales
y participar en transacciones globales.

Un Base de Datos Distribuida es en realidad un tipo de base de datos virtual cuyas partes
componentes estn almacenadas en varias bases de datos reales distintas que se encuentran en varias
sitios distintos (de hecho, es la unin lgica de esas bases de datos reales). La figura 2.1 muestra un
ejemplo de la aplicacin de la BDD: [Segn 4]

Red de comunicacin
Nueva
York
Londres
Los
Angeles San
Francisco

Figura 2.1. Un sistema de SBDD tpico, muestra como la BDD funciona interconectndose.

3. DEFINICIN DE SISTEMA MANEJADOR DE BASE DE DATOS DISTRIBUIDA

El Sistema Manejador de Base de Datos Distribuida maneja la BD distribuida y hace transparente esa
distribucin al usuario. El cual no es un sistema multiproceso. [Segn 3]

Un Sistema de manejo de bases de datos distribuidas (SMBDD) es aquel que se encarga del manejo de la
BDD y proporciona un mecanismo de acceso que hace que la distribucin sea transparente a los
usuarios. El trmino transparente significa que la aplicacin trabajara, desde un punto de vista lgico,
como si un solo SMBD ejecutado en una sola mquina, administrara esos datos. [Segn 5]

Un Sistema de administracin de base de datos distribuida, DDBMS, por sus siglas en ingls Distributed
Database Management System, en una base de datos distribuida, es el conjunto de transacciones y
administradores de base de datos distribuidos en todas las computadoras. [Segn 6]

Un Sistema de Gestin de Bases de Datos Distribuidas (SGBDD) es un sistema compuesto de varios
sistemas de bases de datos distribuidas operando en sitios locales que estn conectados por facilidades
de manejo de mensajes. El diccionario del daros del SGBB incluye informacin usual necesaria para la
3
gestin de los datos junto con la informacin concerniente a cada localidad, a la duplicacin y
fragmentacin de los datos en varias relaciones. [Segn 7]

El sistema de base de datos distribuid puede ser considerado una sociedad entre los SMBDs locales en
cada uno de los sitios locales; un nuevo componente de software en cada sitio de manera lgica, una
extensin del SMBD local- proporciona la funcionalidad de sociedad necesaria y es la combinacin de
este nuevo componente y el DBMS existente, lo que constituye lo que generalmente llamamos Sistema
de Administracin de Base de Datos Distribuida (SABDD) [Segn 4]

4. CARACTERSTICAS DE UNA BASE DE DATOS DISTRIBUIDA

Para poder describir las caractersticas, en necesario conocer el siguiente principio fundamental de las
bases de datos distribuidas.

Ante el usuario, un sistema debe lucir exactamente igual que un sistema que no es distribuido.

En otras palabras, los usuarios de un sistema distribuido deben ser capaces de comportarse exactamente
igual como si el sistema no fuera distribuido. Todos los problemas de los sistemas distribuidos son, o
deberan ser, problemas internos o en el nivel de implementacin y no externos o en nivel usuario.
[Segn 4]

Autonoma Local

Los sitios distribuido deben ser autnomos, es decir que todas las operaciones en un sitio dado se
controlan en ese sitio. [Segn 1]

Los sitios de un sistema distribuido deben ser autnomos. La autonoma local significa que todas las
operaciones en un sitio dado se controlan en ese sitio; ningn sitio X deber depender de algn otro sitio
Y para su buen funcionamiento (pues de otra manera el sitio X podra ser incapaz de trabajar, aunque no
tenga en s problema alguno, si se cae el sitio Y). La autonoma local implica tambin un propietario y
una administracin locales de los datos, con responsabilidad local: todos los datos pertenecen en
realidad a una base de datos local, aunque sean accesibles desde algn sitio remoto. Por tanto, las
cuestiones de seguridad, integridad y representacin en almacenamiento de los datos locales
permanecen bajo el control de la instalacin local.

El objetivo de la autonoma local es imposible de lograr por completo, ya que existen situaciones en las
cuales un sitio dado X debe ceder un cierto grado de control a otro sitio Y. As pues, sera ms correcto
expresar el objetivo de la autonoma de esta manera: los sitios deber ser autnomos hasta donde sea
posible. [Segn 4]

No dependencia de un sitio central

No debe de haber dependencia de un sitio central para obtener un servicio. [Segn 1]

La autonoma local implica que todos los sitios deben tratarse igual; no debe haber dependencia de un
sitio central maestro para obtener un servicio central, como por ejemplo un procesamiento
centralizado de las consultas o una administracin centralizada de las transacciones, de modo que todo
el sistema dependa de ese sitio central. Este segundo objetivo es por tanto un corolario del primero (si se
logra el primero, se lograr por fuerza el segundo). Pero la no dependencia de un sitio central es
deseable por s misma, aun si no se logra la autonoma local completa. Por ello vale la pena expresarlo
como un objetivo separado.

La dependencia de un sitio central sera indeseable al menos por las siguientes razones:
4
- Ese sitio central podra ser un cuello de botella.
- El sistema sera vulnerable; si el sitio central sufriera un desperfecto, todo el sistema dejara de
funcionar. [Segn 4]

Operacin Continua
Nunca debera apagarse para que se pueda realizar alguna funcin, como aadir un nuevo sitio o alguna
operacin requerida. [Segn 1]

En un sistema distribuido, lo mismo que en uno no distribuido, idealmente nunca debera haber
necesidad de apagar a propsito el sistema. Es decir, el sistema nunca debera necesitar apagarse para
que se pueda realizar alguna funcin, como aadir un nuevo sitio o instalar una nueva versin del
DBMS en un sitio ya existente. [Segn 4]

Independencia con respecto a la localizacin

No debe de ser necesario que los usuarios sepan dnde estn almacenados fsicamente los datos, sino
que ms el usuario lo debe de ver como si solo existiera un sitio local. [Segn 1]

La idea bsica de la independencia con respecto a la localizacin (tambin conocida como transparencia
de localizacin) es simple: no debe ser necesario que los usuarios sepan dnde estn almacenados
fsicamente los datos, sino que ms bien deben poder comportarse (al menos desde un punto de vista
lgico) como si todos los datos estuvieran almacenados en su propio sitio local. La independencia con
respecto a la localizacin es deseable porque simplifica los programas de los usuarios y sus actividades
terminales. En particular, hace posible la migracin de datos de un sitio a otro sin anular la validez de
ninguno de esos programas o actividades. Esta posibilidad de migracin es deseable porque permite
modificar la distribucin de los datos dentro de la red en respuesta a cambios en los requerimientos.

En realidad, esta independencia puede considerarse como una extensin de la independencia de los
datos. [Segn 4]

Independencia con respecto a la fragmentacin

La fragmentacin es deseable por razones de desempeo, los datos, pueden almacenarse en la localidad
donde se utilizan con mayor frecuencia de manera que la mayor parte de las operaciones sean slo
locales y se reduzca el trfico en la red. [Segn 1]

Un sistema maneja fragmentacin de los datos si es posible dividir una relacin en partes o
fragmentos para propsitos de almacenamiento fsico. La fragmentacin es deseable por razones de
desempeo: los datos pueden almacenarse en la localidad donde se utilizan con mayor frecuencia, de
manera que la mayor parte de las operaciones sea slo locales y se reduzca el trfico en la red. Por
ejemplo, una relacin Empleados podra fragmentase de manera que los registros de los empleados de
Ciudad Real se almacenen en el emplazamiento de Ciudad Real, mientras que los empleados de
Valdepeas se almacenan en el emplazamiento de Valdepeas:

Figura 4.1. Representacin de las tablas en el caso de la Independencia en la fragmentacin
5

Existen en esencia dos clases de fragmentacin (aunque veremos que hay ms), horizontal y vertical,
correspondientes a las operaciones relacionales de restriccin y proyeccin respectivamente. En trminos
ms generales, un fragmento puede ser cualquier subrelacin arbitraria que pueda derivarse de la
relacin original mediante operaciones de restriccin y proyeccin (excepto que, en el caso de la
proyeccin, es obvio que las proyecciones deben conservar la clave primaria de la relacin original). La
reconstruccin de la relacin original a partir de los fragmentos se hace mediante operaciones de
reunin y unin apropiadas (reunin en el caso de los fragmentos verticales, unin en el de los
horizontales). La facilidad de la fragmentacin y de la reconstruccin es una de las muchas razones por
las cuales los sistemas distribuidos son relacionales; el modelo relacional ofrece las operaciones precisas
requeridas para estas tareas.

Ahora llegamos al punto principal: un sistema que maneja la fragmentacin de los datos deber ofrecer
tambin una independencia con respecto a la fragmentacin (transparencia de fragmentacin); es decir,
los usuarios debern poder comportarse (al menos desde el punto de vista lgico) como si los datos no
estuvieran fragmentados en realidad. La independencia con respecto a la fragmentacin (al igual que la
independencia con respecto a la localizacin (es deseable porque simplifica los programas de los
usuarios y sus actividades terminales. En particular, hace posible refragmentar los datos (y redistribuir
los fragmentos) en cualquier momento en respuesta a cambios en los requerimientos de desempeo sin
anular la validez de esos programas o actividades.

La independencia con respecto a la fragmentacin implica que se presentar a los usuarios una vista de
los datos en la cual los fragmentos estn combinados lgicamente mediante las reuniones y uniones
apropiadas. Corresponde al optimizador del sistema determinar a cules fragmentos fsicos es necesario
tener acceso para satisfacer cualquier solicitud dada de un usuario. [Segn 4]

Independencia de rplica

Si una relacin dada (es decir, un fragmento dado de una relacin) se puede presentar en el nivel fsico
mediante varias copias almacenadas o rplicas, en muchos sitios distintos. [Segn 1]

Un sistema maneja rplica de datos si una relacin dada (o, en trminos ms generales, un fragmento
dado de una relacin) se puede representar en el nivel fsico mediante varias copias almacenadas o
rplicas, en muchos sitios distintos. La rplica es deseable al menos por dos razones: en primer lugar,
puede producir un mejor desempeo (las aplicaciones pueden operar sobre copias locales en vez de
tener que comunicarse con sitios remotos); en segundo lugar, tambin puede significar una mejor
disponibilidad (un objeto estar disponible para su procesamiento mientras est disponible por lo menos
una copia, al menos para propsitos de recuperacin). La desventaja principal de las rplicas es que
cuando se actualiza un cierto objeto copiado, deben actualizarse todas las rplicas de ese objeto: el
problema de la propagacin de actualizaciones. La rplica, como la fragmentacin, debe ser transparente
para el usuario. En otras palabras, un sistema que maneja la rplica de los datos deber ofrecer tambin
una independencia de rplica (transparencia de rplica); es decir, los usuarios debern poder
comportarse (al menos desde un punto de vista lgico) como si slo existiera una copia de los datos. La
independencia de rplica (como la independencia con respecto a la localizacin y a la fragmentacin) es
deseable porque simplifica los programas de los usuarios y sus actividades terminales. En particular,
permite la creacin y eliminacin dinmicas de las rplicas en cualquier momento en respuesta a
cambios en los requerimientos, sin anular la validez de los programas o actividades de los usuarios.
[Segn 4]

Procesamiento Distribuido de Consultas

6
El objetivo es convertir transacciones de usuario en instrucciones para manipulacin de datos, y as
reducir el trfico en la red implica que el proceso mismo de optimizacin de consultas debe ser
distribuido. [Segn 1]

En este aspecto debemos mencionar dos puntos amplios:

Primero consideremos la consulta obtener los proveedores de tornillos en Valdepeas. Supongamos
que el usuario est en la instalacin de Ciudad Real y los datos estn en el emplazamiento de
Valdepeas. Supongamos tambin que son n los registros de proveedor que satisfacen la solicitud. Si el
sistema es relacional, la consulta implicar en esencia dos mensajes: uno para transmitir la solicitud de
Ciudad Real a Valdepeas, y otro para devolver el conjunto resultante de n registros de Valdepeas a
Ciudad Real. Si, por otro lado, el sistema no es relacional, sino de un registro a la vez, la consulta
implicar en esencia 2n mensajes: n de Ciudad Real a Valdepeas solicitando el siguiente registro, y n de
Valdepeas a Ciudad Real para devolver ese siguiente registro. As, el ejemplo ilustra el punto de que
un sistema relacional tendr con toda probabilidad un mejor desempeo que uno no relacional (para
cualquier consulta que solicite varios registros).

En segundo lugar, la optimizacin es todava ms importante en un sistema distribuido que en uno
centralizado. Lo esencial es que, en una consulta como la anterior, donde estn implicados varios sitios,
habr muchas maneras de trasladar los datos en la red para satisfacer la solicitud, y es crucial encontrar
una estrategia eficiente, ya que de esta estrategia depende el tiempo de respuesta. Esta es otra razn ms
por la cual los sistemas distribuidos son siempre relacionales (pues las solicitudes relacionales son
posibles de optimizar, mientras que las de un registro a la vez no lo son). [Segn 4]

Manejo Distribuido de Transacciones

Tiene dos aspectos principales, el control de recuperacin y el control de concurrencia, cada uno de los
cuales requiere un tratamiento ms amplio en el ambiente distribuido. [Segn 1]

El manejo de transacciones tiene dos aspectos principales: el control de recuperacin y el control de
concurrencia, cada uno de los cuales requiere un tratamiento ms amplio en el ambiente distribuido.
Para explicar ese tratamiento ms amplio es preciso introducir primero un trmino nuevo, agente. En
un sistema distribuido, una sola transaccin puede implicar la ejecucin de cdigo en vario sitios (en
particular, puede implicar actualizaciones en varios sitios). Por tanto, se dice que cada transaccin est
compuesta de varios agentes, donde un agente es el proceso ejecutado en nombre de una transaccin
dada en un determinado sitio. Y el sistema necesita saber cundo dos agentes son parte de la misma
transaccin; por ejemplo, es obvio que no puede permitirse un bloqueo mutuo entre dos agentes que
sean parte de la misma transaccin.

Control de recuperacin: para asegurar que una transaccin dada sea atmica (todo o nada) en el
ambiente distribuido, el sistema debe asegurarse de que todos los agentes correspondientes a esa
transaccin se comprometan al unsono o bien que retrocedan al unsono. Este efecto puede lograrse
mediante el protocolo de compromiso en dos fases.

Control de concurrencia: esta funcin en un ambiente distribuido estar basada con toda seguridad en el
bloque, como sucede en los sistemas no distribuidos. [Segn 4]

Independencia con respecto al equipo

Las instalaciones de cmputo en el mundo real, por lo regular incluyen varias mquinas diferentes y
existe una verdadera necesidad de poder integrar los datos en todos esos sistemas y presentar al usuario
una sola imagen del sistema. Por tanto, es conveniente poder ejecutar el mismo DBMS en diferentes
7
equipos, y adems lograr que esos diferentes equipos participen como socios iguales en un sistema
distribuido. [Segn 4]

Independencia con respecto al Sistema Operativo

Este objetivo es en parte un corolario del anterior. Resulta obvia la conveniencia no slo de poder
ejecutar el mismo DBMS en diferentes equipos, sino tambin de poder ejecutarlo en diferentes sistemas
operativos (incluso en diferentes sistemas operativos dentro del mismo equipo) y lograr que (por
ejemplo) una versin MVS y una versin UNIX y una versin PC/DOS participen todas en el mismo
sistema distribuido. [Segn 4]

Independencia con respecto a la red

Es que se puede leer o escribir datos localizados en diferentes nodos de la red [Segn 1]

Si el sistema ha de poder manejar mltiples sitios diferentes, con equipo distinto y diferentes sistemas
operativos, resulta obvia la conveniencia de poder manejar tambin varias redes de comunicaciones
distintas. [Segn 4]

Independencia con respecto al DBMS.

Bajo este ttulo consideramos las implicaciones de relajar la suposicin de homogeneidad estricta.

Puede alegarse que esa suposicin es quiz demasiado rgida. En realidad, no se requiere sino que los
DBMS en los diferentes sitios manejen todos la misma interfaz; no necesitan ser por fuerza copias del
mismo sistema. Por ejemplo, si tanto Ingres como Oracle manejaran la norma oficial de SQL, podra ser
posible lograr una comunicacin entre los dos en el contexto de un sistema distribuido. Dicho de otro
modo, el sistema distribuido podra ser heterogneo, al menos hasta cierto grado.

Definitivamente sera deseable poder manejar la heterogeneidad. Una vez ms, en la realidad las
instalaciones de cmputo no slo suelen emplear varias mquinas diferentes y varios sistemas
operativos distintos, sino que tambin ejecutan diferentes DBMS; y sera agradable que todos esos DBMS
distintos pudieran participar de alguna manera en un sistema distribuido. En otras palabras, el sistema
distribuido ideal deber ofrecer independencia respecto al DBMS. [Segn 4]

5. DIFERENCIAS ENTRE BDD Y BDC

DISTRIBUIDAS CENTRALIZADAS
Transparencia en la Distribucin:
Localizacin de los datos es un aspecto
adicional de independencia de datos

Independencia de Datos:
Organizacin de los datos es
transparente para el programador

Replicacin de Datos: copias mltiples de
datos que incrementa la localidad y la
disponibilidad de datos

Reduccin de redundancia: una sola
copia de datos que se comparta

No hay estructuras intersitios. Uso de
optimizacin global para reducir transferencia
de datos

Estructuras fsicas complejas
para accesos eficientes

Problemas de seguridad intrnsecos

Seguridad

[Segn 8]
8

DISTRIBUIDAS CENTRALIZADAS
Se cuenta con poca experiencia en su estudio,
pero eso no indica que se sigan desarrollando
Su estudio es muy profundizado, y de por s es base
para las BD distribuidas.
Ejecucin de algunas consultas en paralelo
sobre un menor volmen de datos.
Las consultas dada su estructura monoltica,
producen ms retardo en las consultas
Crecimiento : Ms facil adecuarse al
crecimiento de la Organizacin.

No se puede adecuar al crecimiento, dado que tan
solo esta en un ordenador.
El costo de implantacin es mucho mas
elevado, como requerir ms personal por
ejemplo.
Los costos son mucho ms bajos, dado que la
implantacin no requiere mucho personal.
[Segn 3]

DISTRIBUIDAS CENTRALIZADAS
Permite un distribucin en las empresas, en
una manera jerrquica: divisiones, grupos,
departamentos.
La informacin se mantiene en un solo lugar, de
donde todos deben extraerla.
Existe accesibilidad de mucha facilidad, dada
su reparticin en varias pequeas o medianas
partes
La accesibilidad muestra ciertos inconvenientes, que
producen en el mayor de los casos retrasos.
Son muy complejos, y requieren un estudio
profundizado en el lugar donde se las va a
implantar
El estudio, en el caso de la implantacin puede ser
somero, dada su simplicidad en relacin a una BD
distribuida.
[Segn 4]

6. ARQUITECTURA DE UNA BASE DE DATOS DISTRIBUIDA

La mayora de los sistemas de manejo de bases de datos disponibles actualmente estn basadas en la
arquitectura ANSI-SPARC la cual divide a un sistema en tres niveles: interno, conceptual y externo.

La vista conceptual, conocida tambin como vista lgica global, representa la visin de la comunidad de
usuarios de los datos en la base de datos. No toma en cuenta la forma en que las aplicaciones
individuales observan los datos o como stos son almacenados. La vista conceptual est basada en el
esquema conceptual y su construccin se hace en la primera fase del diseo de una base de datos.

Los usuarios, incluyendo a los programadores de aplicaciones, observan los datos a travs de un
esquema externo definido a nivel externo. La vista externa proporciona una ventana a la vista
conceptual lo cual permite a los usuarios observar nicamente los datos de inters y los asla de otros
datos en la base de datos. Puede existir cualquier nmero de vistas externas y ellos pueden ser
completamente independientes o traslaparse entre s.

El esquema conceptual se mapea a un esquema interno a nivel interno, el cual es el nivel de descripcin
ms bajo de los datos en una base de datos. Este proporciona una interfaz al sistema de archivos del
sistema operativo el cual es el responsable del acceso a la base de datos. El nivel interno tiene que ver
con la especificacin de qu elementos sern indexados, qu tcnica de organizacin de archivos utilizar
y como los datos se agrupan en el disco mediante "clusters" para mejorar su acceso. [Segn 6]

Tambin se puede enfocar la misma arquitectura pero tomando en cuenta dos tipos de niveles
conceptuales: el local y el global.

9


Figura 6.1. Arquitectura de un BDD considerando un esquema global

LIS: Esquema interno local (Local internal schema)
LCS: Esquema conceptual local (Local conceptual schema)
GCS: Esquema conceptual global (Global conceptual schema)
ES: Esquema externo (External schema)
[Segn 3]

Adems se puede contar con el siguiente esquema para comprender la arquitectura.

Para manejar los aspectos de la distribucin, se deben agregar dos niveles a la arquitectura estndar
ANSI/SPARC: American National Standards Institute/Standards Planning and Requirements Comitee
(Instituto Nacional Americano de Normas/Comit de Planes y Requerimientos), como se muestra en la
figura 6.2 [Segn 6]


Figura 6.2. Arquitectura de un BDD segn la ANSI/SPARC

Podemos tambin notar que la arquitectura puede dividirse, partiendo de la bsica ANSI/SPATC en la
siguiente figura.
10

Figura 6.3. Arquitectura de un BDD segn la ANSI/SPARC con esquemas de fragmentacin

Definiendo las partes de la arquitectura:

Esquema conceptual global. El esquema conceptual global es la descripcin lgica de la base de datos
completa, como si no estuviera distribuida. Este nivel corresponde al nivel conceptual de la arquitectura
ANSI-SPARC y contiene definiciones de entidades, relaciones, constantes e informacin sobre seguridad
e integridad. Proporciona independencia de datos fsicas desde el entorno distribuido. Los esquemas
externos globales proporcionan independencia de datos lgica.

Esquemas de fragmentacin y localizacin. El esquema de fragmentacin es una descripcin de cmo los
datos estn particionados lgicamente. El esquema de localizacin es una descripcin de dnde estn
localizados los datos. El esquema de localizacin tiene en cuenta cualquier replicacin.

Esquemas locales. Cada SGBD local tiene su propio conjunto de esquemas. Los esquemas conceptual e
interno locales corresponden a los equivalentes de la arquitectura ANSI-SPARC. [Segn 9]

7. ARQUITECTURA DE UN SISTEMA MANEJADOR DE UNA BASE DE DATOS DISTRIBUIDA

Para poder comprender la arquitectura, ser necesario mencionar conceptos previos.

Los usuarios interactan con el SGBDD ejecutando programas que se llamas transacciones. Las
transacciones en tales sistemas no estn ya restringidas a un solo proceso controlado por un mdulo de
software, sino que pueden invocar un conjunto de procesos cooperantes, funcionando en vario sitios y
controlados por mdulos independientes de software.

Cada uno de esos procesos cooperantes en la transaccin de llama un agente. Una transaccin que
requiere slo un agente se llama transaccin local. Una transaccin que requiere varios afeares se
denomina transaccin global.

Un agente dado que puede slo acceder a los datos controlados por su software de gestin de datos loca.
Acceder a los datos de otro sitio requiere de la cooperacin de los agentes de esos sitios. Un agente que
inicia una transaccin se llama agente iniciador. El agente iniciador puede demandar la activacin de
11
agentes de otros sitios para poder acceder a los datos necesarios. Una vez que estn activados, do o ms
agentes se pueden comunicar mediante intercambio de mensajes.

Cada participante en el SGBDD tpicamente ejecuta uno o ms de los siguientes mdulos de software: un
administrador de transacciones (AT), un administrador de datos (AD) o un planificador. A toda esta
estructura de comunicacin y de mdulos se le conoce como la arquitectura del SGBDD.


Figura 7.1. Arquitectura de un SGBDD

8. PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS

El xito creciente de la tecnologa de bases de datos relacionales en el procesamiento de datos se debe, en
parte, a la disponibilidad de lenguajes no procedurales los cuales pueden mejorar significativamente el
desarrollo de aplicaciones y la productividad del usuario final. Ocultando los detalles de bajo nivel
acerca de la localizacin fsica de datos, los lenguajes de bases de datos relacionales permiten la
expresin de consultas complejas en una forma concisa y simple. Particularmente, para construir la
respuesta a una consulta, el usuario no tiene que especificar de manera precisa el procedimiento que se
debe seguir. Este procedimiento es llevado a cabo por un mdulo del DBMS llamado el procesador de
consultas (query processor).

Dado que la ejecucin de consultas es un aspecto crtica en el rendimiento de un DBMS, el
procesamiento de consultas ha recibido una gran atencin tanto para bases de datos centralizadas como
distribuidas. Sin embargo, el procesamiento de consultas es mucho ms difcil en ambientes distribuidos
que en centralizados, ya que existe un gran nmero de parmetros que afectan el rendimiento de las
consultas distribuidas. En este captulo revisaremos el procesamiento de consultas para bases de datos
distribuidas.

La funcin principal de un procesador de consultas relacionales es transformar una consulta en una
especificacin de alto nivel, tpicamente en clculo relacional, a una consulta equivalente en una
especificacin de bajo nivel, tpicamente alguna variacin del lgebra relacional. La consulta de bajo
nivel implementa de hecho la estrategia de ejecucin para la consulta. La transformacin debe ser
correcta y eficiente. Es correcta si la consulta de bajo nivel tiene la misma semntica que la consulta
original, esto es, si ambas consultas producen el mismo resultado. El mapeo bien definido que se conoce
entre el clculo relacional y el lgebra relacional hace que la correctitud de la transformacin sea fcil de
verificar. Sin embargo, producir una estrategia de ejecucin eficiente es mucho ms complicado. Una
consulta en el clculo relacional puede tener muchas transformaciones correctas y equivalentes en el
lgebra relacional. Ya que cada estrategia de ejecucin equivalente puede conducir a consumos de
12
recursos de cmputo muy diferentes, la dificultad ms importante es seleccionar la estrategia de
ejecucin que minimiza el consumo de recursos.

Optimizacin de Consultas Distribuidas

Como se estableci antes, el objetivo del procesamiento de consultas en un ambiente distribuido es
transformar una consulta sobre una base de datos distribuida en una especificacin de alto nivel a una
estrategia de ejecucin eficiente expresada en un lenguaje de bajo nivel sobre bases de datos locales.

As, el problema de optimizacin de consultas es minimizar una funcin de costo tal que funcin de
costo total = costo de I/O + costo de CPU + costo de comunicacin

Los diferentes factores pueden tener pesos diferentes dependiendo del ambiente distribuido en el que se
trabaje. Por ejemplo, en las redes de rea amplia (WAN), normalmente el costo de comunicacin domina
dado que hay una velocidad de comunicacin relativamente baja, los canales estn saturados y el trabajo
adicional requerido por los protocolos de comunicacin es considerable. As, los algoritmos diseados
para trabajar en una WAN, por lo general, ignoran los costos de CPU y de I/O. En redes de rea local
(LAN) el costo de comunicacin no es tan dominante, as que se consideran los tres factores con pesos
variables.

Arquitectura del procesamiento de consultas

El problema de procesamiento de consultas se puede descomponer en varios sub-problemas que
corresponden a diferentes niveles. En la Figura 3, se presenta un esquema por niveles genrico para el
procesamiento de consultas. Para simplificar la discusin, suponga que se tiene un procesador de
consultas esttico semicentralizado en donde no se tienen fragmentos replicados. Cuatro capas
principales estn involucradas en mapear una consulta a una base de datos distribuida en una secuencia
optimizada de operaciones locales, cada una de ellas actuando en una base de datos local.

Las cuatro capas principales son: descomposicin de consultas, localizacin de datos, optimizacin
global de consultas y optimizacin local de consultas. Las primeras tres se realizan en un nodo central
usando informacin global. La cuarta capa se realiza en cada nodo local.

Descomposicin de consultas

La primera capa descompone una consulta en el clculo relacional en una consulta en el lgebra
relacional que opera sobre relaciones globales. Consiste de cuatro partes:

1.-Normalizacin. Involucra la manipulacin de los cuantificadores de la consulta y de los calificadores
de la misma mediante la aplicacin de la prioridad de los operadores lgicos.
2.-Anlisis. Se detecta y rechazan consultas semnticamente incorrectas.
3.-Simplificacin. Elimina predicados redundantes.
4.-Reestructuracin. Mediante reglas de transformacin una consulta en el clculo relacional se
transforma a una en el lgebra relacional. Se sabe que puede existir ms de una transformacin. Por
tanto, el enfoque seguido usualmente es empezar con una consulta algebraica y aplicar transformaciones
para mejorarla.

Localizacin de Datos. La entrada a esta capa es una consulta algebraica definida sobre relaciones
distribuidas. El objetivo de esta capa es localizar los datos de la consulta usando la informacin sobre la
distribucin de datos. Esta capa determina cuales fragmentos estn involucrados en la consulta y
transforma la consulta distribuida en una consulta sobre fragmentos.

13
Optimizacin Global de Consultas. Dada una consulta algebraica sobre fragmentos, el objetivo de esta
capa es hallar una estrategia de ejecucin para la consulta cercana a la ptima. La estrategia de ejecucin
para una consulta distribuida puede ser descrita con los operadores del lgebra relacional y con
primitivas de comunicacin para transferir datos entre nodos. Para encontrar una buena transformacin
se consideran las caractersticas de los fragmentos, tales como, sus cardinalidades. Un aspecto
importante de la optimizacin de consultas es el ordenamiento de juntas, dado que algunas
permutaciones de juntas dentro de la consulta pueden conducir a un mejoramiento de varios rdenes de
magnitud. La salida de la capa de optimizacin global es una consulta algebraica optimizada con
operacin de comunicaciones incluidas sobre los fragmentos.

Optimizacin Local de Consultas. El trabajo de la ltima capa se efecta en todos los nodos con
fragmentos involucrados en la consulta. Cada subconsulta que se ejecuta en un nodo, llamada consulta
local, es optimizada usando el esquema local del nodo. Hasta este momento, se pueden eligen los
algoritmos para realizar las operaciones relacionales. La optimizacin local utiliza los algoritmos de
sistemas centralizados.
[Segn 1]

9. CONCLUSIONES

- Las BDD, son innovaciones que van en creciente desarrollo, y profundizacin en su estudio. Si bien es cierto, la
implantacin, o el uso de un BDD, es mucho ms difcil de obtener, debido a la economa, este tipo de BD ha
empezado a ser utilizada desde mucho atrs por empresas, que como se explica en el apartado 2, encaja muy
bien ellas y todo tipo de organizacin jerrquica, dado que las BDD, cuentan al igual que las compaas con
particiones y subdivisiones que permiten un trabajo ms prctico y anlogo.

- Al pensar que una base de datos, cuenta con ms opciones, operaciones, y distintos tipos de caractersticas,
podra presumirse de que son ms riesgosas y porque no muy complejas en su estructura. Pero como se
describi anteriormente, son algo complejas, pero su tratamiento solo requiere una pequea modificacin con
respecto a las BDC.

- Las arquitecturas si bien es cierto, muestran variaciones en los distintos ejemplos, todas ellas manifiestan cierta
gran parte de relacin. En todas ellas se pone al descubierto los tres niveles que contienen las BDD en su
arquitectura, y que valdra aclarar igualmente a las BDC. Estas arquitecturas permiten concluir que finalmente
las BD, sean centralizadas o distribuidas basan sus principios en hechos muy comunes y ms cercanos de lo que
normalmente se cree.

- Los SGBDD, muestran ciertas caractersticas que los hacen especiales, frente a cualquier manejador
convencional, pero ello no es motivo de considerar a este sistema como un programa muy diferente al que se
utiliza con las BDC, sino que lo nico que pretender hacer es simular que las partes de la BD repartidas en
diferentes estaciones de trabajo, aparezcan ante el usuario como si el tuviese una sola BD sin particiones.









14
REFERENCIAS BIBLIOGRFICAS

[1] J.C. VARGAS HERNNDEZ, Fundamentos tericos de Bases de Datos Distribuidas[en lnea], Mxico, 2001,
disponible en:
<http://www.geocities.com/ddbqp/>
[2] L. CAMPOY MEDRANO, Tutorial de Bases de Datos I[en lnea], Instituto Tecnolgico de la Paz, ,1999 disponible
en:
<http://www.itlp.edu.mx/publica/tutoriales/sistsdist2/t62.htm>
[3] M. JIMENEZ, Seminario de Bases de Datos, Universidad de los Alpes, Chile, 2002
[4] C.J. DATE, Introduccin a los Sistemas de Bases de Datos, ed 7, Mxico, Pg. 651 670, 2001
[5] A. DIAZ, Bases de Datos distribuidas[en lnea], Mxico, 2004
<http://www.cs.cinvestav.mx/SC/prof_personal/adiaz/Disdb/Cap_1.html>
[6] F. LORENZO CASTRO, Modelos de Datos: conceptos y clasificacin, Pg. 47, 2000
[7] G.H. HANSEN, J.V. HANSEN, Diseo y Administracin de BDx, ed 2, Pg. 393 410, Universidad de Salamanca
Madrid, Espaa, 2000, ISBN: 8483220024
[8] J.C. LAVARIEGA JARQUIN, Bases de Datos Avanzadas, ITESM, Monterrey Mxico, 2000
[9] F. RUIZ, Arquitectura de Sistemas de Bases de Datos, Universidad de Castilla La Mancha, Pg. 43 60, 2000






Ttulo del trabajo: BASES DE DATOS DISTRIBUIDAS
Alumno: CARRANZA ATH FREDY

Veracidad Actualidad Claridad Profundidad Autenticidad Formato
Referencias
Bibliogrficas