1

BASES DE DATOS DISTRIBUIDAS CARRANZA ATHÓ FREDY

BASES DE DATOS II

ESCUELA ACADÉMICO PROFESIONAL DE INFORMÁTICA 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 definición y explicando las características que las hacen

particulares. A la vez, se hace un pequeño paralelo entre las BDD y las BDC. Además 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 tópico el las consultas en las BDD, donde existe un

tratamiento especial.

1. INTRODUCCIÓN

Al observar la evolución de la tecnología en cuanto al campo de las Redes, y todo proceso que indique la participación de más de un ordenador, surge para el campo de las Bases de Datos, la necesidad de crear una manera de cómo con el uso de una red, desempeñarse desarrollando las funciones que comúnmente las haría 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 información de manera centralizada utilizando un conjunto de herramientas que facilitarían 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 información almacenada en un solo lugar. Una BDD, permitirá que ya no un usuario, sino un número muy alto de usuarios accedan a la información, de una manera ordenada, consistente y coherente. Este tipo de BD, permiten que los datos queden repartidos en más de un ordenador, lo cual es lo más 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 impresión de cómo 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 Información, en la cual las soluciones están integrando tecnologías con nuevas arquitecturas o formas de hacer las cosas es, sin lugar a dudas, un campo muy estudiado. Un caso específico 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. DEFINICIÓN DE BASE DE DATOS DISTRIBUIDA Una Base de Datos Distribuida (BDD) es un conjunto de múltiples bases de datos lógicamente relacionadas las cuales se encuentran distribuidas entre diferentes sitios interconectados por una red de comunicaciones, los cuales tienen la capacidad de procesamiento autónomo lo cual indica que puede realizar operaciones locales o distribuidas. [Según 1]

2

Es una colección de datos que se encuentran distribuidos en varios sitios y que están interconectados por una red de comunicaciones, donde cada sitio tiene capacidad de procesamiento autónomo de transacciones y puede hacer procesos locales. Y además, cada sitio realiza la ejecución de al menos una transacción global, la cual requiere accesos a datos en diversos sitios. [Según 2] Colección de múltiples Bases de Datos interrelacionadas lógicamente 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 están almacenadas en varias bases de datos “reales” distintas que se encuentran en varias sitios distintos (de hecho, es la unión lógica de esas bases de datos reales). La figura 2.1 muestra un ejemplo de la aplicación de la BDD: [Según 4]

Red de comunicación

Nueva

YorkLondres

Los

Angeles San

Francisco Figura 2.1. Un sistema de SBDD típico, muestra como la BDD funciona interconectándose.

3. DEFINICIÓN DE SISTEMA MANEJADOR DE BASE DE DATOS DISTRIBUIDA

El Sistema Manejador de Base de Datos Distribuida maneja la BD distribuida y hace transparente esa distribución al usuario. El cual no es un sistema multiproceso. [Según 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 distribución sea transparente a los usuarios. El término transparente significa que la aplicación trabajaría, desde un punto de vista lógico, como si un solo SMBD ejecutado en una sola máquina, administrara esos datos. [Según 5]

Un Sistema de administración de base de datos distribuida, DDBMS, por sus siglas en inglés 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. [Según 6] Un Sistema de Gestión de Bases de Datos Distribuidas (SGBDD) es un sistema compuesto de varios sistemas de bases de datos distribuidas operando en sitios locales que están conectados por facilidades de manejo de mensajes. El diccionario del daros del SGBB incluye información usual necesaria para la

3

gestión de los datos junto con la información concerniente a cada localidad, a la duplicación y fragmentación de los datos en varias relaciones. [Según 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 lógica, una extensión del SMBD local- proporciona la funcionalidad de sociedad necesaria y es la combinación de este nuevo componente y el DBMS existente, lo que constituye lo que generalmente llamamos Sistema de Administración de Base de Datos Distribuida (SABDD) [Según 4]

4. CARACTERÍSTICAS DE UNA BASE DE DATOS DISTRIBUIDA Para poder describir las características, 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 deberían ser, problemas internos o en el nivel de implementación y no externos o en nivel usuario. [Según 4] Autonomía Local Los sitios distribuido deben ser autónomos, es decir que todas las operaciones en un sitio dado se controlan en ese sitio. [Según 1] Los sitios de un sistema distribuido deben ser autónomos. La autonomía local significa que todas las operaciones en un sitio dado se controlan en ese sitio; ningún sitio X deberá depender de algún otro sitio Y para su buen funcionamiento (pues de otra manera el sitio X podría ser incapaz de trabajar, aunque no tenga en sí problema alguno, si se cae el sitio Y). La autonomía local implica también un propietario y una administración locales de los datos, con responsabilidad local: todos los datos pertenecen en realidad a una base de datos local, aunque sean accesibles desde algún sitio remoto. Por tanto, las cuestiones de seguridad, integridad y representación en almacenamiento de los datos locales permanecen bajo el control de la instalación local. El objetivo de la autonomía 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, sería más correcto expresar el objetivo de la autonomía de esta manera: los sitios deber ser autónomos hasta donde sea posible. [Según 4] No dependencia de un sitio central No debe de haber dependencia de un sitio central para obtener un servicio. [Según 1] La autonomía local implica que todos los sitios deben tratarse igual; no debe haber dependencia de un sitio central “maestro” para obtener un servicio central, como por ejemplo un procesamiento centralizado de las consultas o una administración 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 autonomía local completa. Por ello vale la pena expresarlo como un objetivo separado. La dependencia de un sitio central sería indeseable al menos por las siguientes razones:

4

- Ese sitio central podría ser un cuello de botella. - El sistema sería vulnerable; si el sitio central sufriera un desperfecto, todo el sistema dejaría de funcionar. [Según 4] Operación Continua Nunca debería apagarse para que se pueda realizar alguna función, como añadir un nuevo sitio o alguna operación requerida. [Según 1] En un sistema distribuido, lo mismo que en uno no distribuido, idealmente nunca debería haber necesidad de apagar a propósito el sistema. Es decir, el sistema nunca debería necesitar apagarse para que se pueda realizar alguna función, como añadir un nuevo sitio o instalar una nueva versión del DBMS en un sitio ya existente. [Según 4] Independencia con respecto a la localización No debe de ser necesario que los usuarios sepan dónde están almacenados físicamente los datos, sino que más el usuario lo debe de ver como si solo existiera un sitio local. [Según 1] La idea básica de la independencia con respecto a la localización (también conocida como transparencia de localización) es simple: no debe ser necesario que los usuarios sepan dónde están almacenados físicamente los datos, sino que más bien deben poder comportarse (al menos desde un punto de vista lógico) como si todos los datos estuvieran almacenados en su propio sitio local. La independencia con respecto a la localización es deseable porque simplifica los programas de los usuarios y sus actividades terminales. En particular, hace posible la migración de datos de un sitio a otro sin anular la validez de ninguno de esos programas o actividades. Esta posibilidad de migración es deseable porque permite modificar la distribución de los datos dentro de la red en respuesta a cambios en los requerimientos. En realidad, esta independencia puede considerarse como una extensión de la independencia de los datos. [Según 4] Independencia con respecto a la fragmentación La fragmentación es deseable por razones de desempeño, los datos, pueden almacenarse en la localidad donde se utilizan con mayor frecuencia de manera que la mayor parte de las operaciones sean sólo locales y se reduzca el tráfico en la red. [Según 1] Un sistema maneja fragmentación de los datos si es posible dividir una relación en partes o “fragmentos” para propósitos de almacenamiento físico. La fragmentación es deseable por razones de desempeño: los datos pueden almacenarse en la localidad donde se utilizan con mayor frecuencia, de manera que la mayor parte de las operaciones sea sólo locales y se reduzca el tráfico en la red. Por ejemplo, una relación Empleados podría 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 Valdepeñas se almacenan en el emplazamiento de Valdepeñas:

Figura 4.1. Representación de las tablas en el caso de la Independencia en la fragmentación

5

Existen en esencia dos clases de fragmentación (aunque veremos que hay más), horizontal y vertical, correspondientes a las operaciones relacionales de restricción y proyección respectivamente. En términos más generales, un fragmento puede ser cualquier subrelación arbitraria que pueda derivarse de la relación original mediante operaciones de restricción y proyección (excepto que, en el caso de la proyección, es obvio que las proyecciones deben conservar la clave primaria de la relación original). La reconstrucción de la relación original a partir de los fragmentos se hace mediante operaciones de reunión y unión apropiadas (reunión en el caso de los fragmentos verticales, unión en el de los horizontales). La facilidad de la fragmentación y de la reconstrucción 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 fragmentación de los datos deberá ofrecer también una independencia con respecto a la fragmentación (transparencia de fragmentación); es decir, los usuarios deberán poder comportarse (al menos desde el punto de vista lógico) como si los datos no estuvieran fragmentados en realidad. La independencia con respecto a la fragmentación (al igual que la independencia con respecto a la localización (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 desempeño sin anular la validez de esos programas o actividades. La independencia con respecto a la fragmentación implica que se presentará a los usuarios una vista de los datos en la cual los fragmentos están combinados lógicamente mediante las reuniones y uniones apropiadas. Corresponde al optimizador del sistema determinar a cuáles fragmentos físicos es necesario tener acceso para satisfacer cualquier solicitud dada de un usuario. [Según 4] Independencia de réplica Si una relación dada (es decir, un fragmento dado de una relación) se puede presentar en el nivel físico mediante varias copias almacenadas o réplicas, en muchos sitios distintos. [Según 1] Un sistema maneja réplica de datos si una relación dada (o, en términos más generales, un fragmento dado de una relación) se puede representar en el nivel físico mediante varias copias almacenadas o réplicas, en muchos sitios distintos. La réplica es deseable al menos por dos razones: en primer lugar, puede producir un mejor desempeño (las aplicaciones pueden operar sobre copias locales en vez de tener que comunicarse con sitios remotos); en segundo lugar, también puede significar una mejor disponibilidad (un objeto estará disponible para su procesamiento mientras esté disponible por lo menos una copia, al menos para propósitos de recuperación). La desventaja principal de las réplicas es que cuando se actualiza un cierto objeto copiado, deben actualizarse todas las réplicas de ese objeto: el problema de la propagación de actualizaciones. La réplica, como la fragmentación, debe ser transparente para el usuario. En otras palabras, un sistema que maneja la réplica de los datos deberá ofrecer también una independencia de réplica (transparencia de réplica); es decir, los usuarios deberán poder comportarse (al menos desde un punto de vista lógico) como si sólo existiera una copia de los datos. La independencia de réplica (como la independencia con respecto a la localización y a la fragmentación) es deseable porque simplifica los programas de los usuarios y sus actividades terminales. En particular, permite la creación y eliminación dinámicas de las réplicas en cualquier momento en respuesta a cambios en los requerimientos, sin anular la validez de los programas o actividades de los usuarios. [Según 4] Procesamiento Distribuido de Consultas

6

El objetivo es convertir transacciones de usuario en instrucciones para manipulación de datos, y así reducir el tráfico en la red implica que el proceso mismo de optimización de consultas debe ser distribuido. [Según 1] En este aspecto debemos mencionar dos puntos amplios: Primero consideremos la consulta “obtener los proveedores de tornillos en Valdepeñas”. Supongamos que el usuario está en la instalación de Ciudad Real y los datos están en el emplazamiento de Valdepeñas. Supongamos también 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 Valdepeñas, y otro para devolver el conjunto resultante de n registros de Valdepeñas 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 Valdepeñas solicitando el siguiente registro, y n de Valdepeñas 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 desempeño que uno no relacional (para cualquier consulta que solicite varios registros). En segundo lugar, la optimización es todavía más importante en un sistema distribuido que en uno centralizado. Lo esencial es que, en una consulta como la anterior, donde están implicados varios sitios, habrá muchas maneras de trasladar los datos en la red para satisfacer la solicitud, y es crucial encontrar una estrategia eficiente, ya que de esta estrategia depende el tiempo de respuesta. Esta es otra razón más 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). [Según 4] Manejo Distribuido de Transacciones Tiene dos aspectos principales, el control de recuperación y el control de concurrencia, cada uno de los cuales requiere un tratamiento más amplio en el ambiente distribuido. [Según 1] El manejo de transacciones tiene dos aspectos principales: el control de recuperación y el control de concurrencia, cada uno de los cuales requiere un tratamiento más amplio en el ambiente distribuido. Para explicar ese tratamiento más amplio es preciso introducir primero un término nuevo, “agente”. En un sistema distribuido, una sola transacción puede implicar la ejecución de código en vario sitios (en particular, puede implicar actualizaciones en varios sitios). Por tanto, se dice que cada transacción está compuesta de varios agentes, donde un agente es el proceso ejecutado en nombre de una transacción dada en un determinado sitio. Y el sistema necesita saber cuándo dos agentes son parte de la misma transacción; por ejemplo, es obvio que no puede permitirse un bloqueo mutuo entre dos agentes que sean parte de la misma transacción. Control de recuperación: para asegurar que una transacción dada sea atómica (todo o nada) en el ambiente distribuido, el sistema debe asegurarse de que todos los agentes correspondientes a esa transacción se comprometan al unísono o bien que retrocedan al unísono. Este efecto puede lograrse mediante el protocolo de compromiso en dos fases. Control de concurrencia: esta función en un ambiente distribuido estará basada con toda seguridad en el bloque, como sucede en los sistemas no distribuidos. [Según 4] Independencia con respecto al equipo Las instalaciones de cómputo en el mundo real, por lo regular incluyen varias máquinas diferentes y existe una verdadera necesidad de poder integrar los datos en todos esos sistemas y presentar al usuario una sola imagen del sistema. Por tanto, es conveniente poder ejecutar el mismo DBMS en diferentes

7

equipos, y además lograr que esos diferentes equipos participen como socios iguales en un sistema distribuido. [Según 4] Independencia con respecto al Sistema Operativo Este objetivo es en parte un corolario del anterior. Resulta obvia la conveniencia no sólo de poder ejecutar el mismo DBMS en diferentes equipos, sino también de poder ejecutarlo en diferentes sistemas operativos (incluso en diferentes sistemas operativos dentro del mismo equipo) y lograr que (por ejemplo) una versión MVS y una versión UNIX y una versión PC/DOS participen todas en el mismo sistema distribuido. [Según 4] Independencia con respecto a la red Es que se puede leer o escribir datos localizados en diferentes nodos de la red [Según 1] Si el sistema ha de poder manejar múltiples sitios diferentes, con equipo distinto y diferentes sistemas operativos, resulta obvia la conveniencia de poder manejar también varias redes de comunicaciones distintas. [Según 4] Independencia con respecto al DBMS. Bajo este título consideramos las implicaciones de relajar la suposición de homogeneidad estricta. Puede alegarse que esa suposición es quizá demasiado rígida. 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, podría ser posible lograr una comunicación entre los dos en el contexto de un sistema distribuido. Dicho de otro modo, el sistema distribuido podría ser heterogéneo, al menos hasta cierto grado. Definitivamente sería deseable poder manejar la heterogeneidad. Una vez más, en la realidad las instalaciones de cómputo no sólo suelen emplear varias máquinas diferentes y varios sistemas operativos distintos, sino que también ejecutan diferentes DBMS; y sería 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. [Según 4]

5. DIFERENCIAS ENTRE BDD Y BDC

DISTRIBUIDAS CENTRALIZADAS Transparencia en la Distribución: Localización de los datos es un aspecto adicional de independencia de datos

Independencia de Datos: Organización de los datos es transparente para el programador

Replicación de Datos: copias múltiples de datos que incrementa la localidad y la disponibilidad de datos

Reducción de redundancia: una sola copia de datos que se comparta

No hay estructuras intersitios. Uso de optimización global para reducir transferencia de datos

Estructuras físicas complejas para accesos eficientes

Problemas de seguridad intrínsecos

Seguridad

[Según 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.

Ejecución de algunas consultas en paralelo ó sobre un menor volúmen de datos.

Las consultas dada su estructura monolítica, producen más retardo en las consultas

Crecimiento : Más facil adecuarse al crecimiento de la Organización.

No se puede adecuar al crecimiento, dado que tan solo esta en un ordenador.

El costo de implantación es mucho mas elevado, como requerir más personal por ejemplo.

Los costos son mucho más bajos, dado que la implantación no requiere mucho personal.

[Según 3]

DISTRIBUIDAS CENTRALIZADAS Permite un distribución en las empresas, en una manera jerárquica: divisiones, grupos, departamentos.

La información se mantiene en un solo lugar, de donde todos deben extraerla.

Existe accesibilidad de mucha facilidad, dada su repartición en varias pequeñas 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 implantación puede ser somero, dada su simplicidad en relación a una BD distribuida.

[Según 4]

6. ARQUITECTURA DE UNA BASE DE DATOS DISTRIBUIDA La mayoría de los sistemas de manejo de bases de datos disponibles actualmente están basadas en la arquitectura ANSI-SPARC la cual divide a un sistema en tres niveles: interno, conceptual y externo. La vista conceptual, conocida también como vista lógica global, representa la visión 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 construcción se hace en la primera fase del diseño de una base de datos. Los usuarios, incluyendo a los programadores de aplicaciones, observan los datos a través 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 interés y los aísla de otros datos en la base de datos. Puede existir cualquier número 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 descripción más 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 especificación de qué elementos serán indexados, qué técnica de organización de archivos utilizar y como los datos se agrupan en el disco mediante "clusters" para mejorar su acceso. [Según 6] También 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) [Según 3] Además se puede contar con el siguiente esquema para comprender la arquitectura. Para manejar los aspectos de la distribución, se deben agregar dos niveles a la arquitectura estándar 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 [Según 6]

Figura 6.2. Arquitectura de un BDD según la ANSI/SPARC

Podemos también notar que la arquitectura puede dividirse, partiendo de la básica ANSI/SPATC en la siguiente figura.

10

Figura 6.3. Arquitectura de un BDD según la ANSI/SPARC con esquemas de fragmentación

Definiendo las partes de la arquitectura: Esquema conceptual global. El esquema conceptual global es la descripción lógica 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 información sobre seguridad e integridad. Proporciona independencia de datos físicas desde el entorno distribuido. Los esquemas externos globales proporcionan independencia de datos lógica. Esquemas de fragmentación y localización. El esquema de fragmentación es una descripción de cómo los datos están particionados lógicamente. El esquema de localización es una descripción de dónde están localizados los datos. El esquema de localización tiene en cuenta cualquier replicación. 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. [Según 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 interactúan con el SGBDD ejecutando programas que se llamas transacciones. Las transacciones en tales sistemas no están ya restringidas a un solo proceso controlado por un módulo de software, sino que pueden invocar un conjunto de procesos cooperantes, funcionando en vario sitios y controlados por módulos independientes de software. Cada uno de esos procesos cooperantes en la transacción de llama un agente. Una transacción que requiere sólo un agente se llama transacción local. Una transacción que requiere varios afeares se denomina transacción global. Un agente dado que puede sólo acceder a los datos controlados por su software de gestión de datos loca. Acceder a los datos de otro sitio requiere de la cooperación de los agentes de esos sitios. Un agente que inicia una transacción se llama agente iniciador. El agente iniciador puede demandar la activación de

11

agentes de otros sitios para poder acceder a los datos necesarios. Una vez que estén activados, do o más agentes se pueden comunicar mediante intercambio de mensajes. Cada participante en el SGBDD típicamente ejecuta uno o más de los siguientes módulos de software: un administrador de transacciones (AT), un administrador de datos (AD) o un planificador. A toda esta estructura de comunicación y de módulos 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 tecnología 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 localización física de datos, los lenguajes de bases de datos relacionales permiten la expresión 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 módulo del DBMS llamado el procesador de consultas (query processor). Dado que la ejecución de consultas es un aspecto crítica en el rendimiento de un DBMS, el procesamiento de consultas ha recibido una gran atención tanto para bases de datos centralizadas como distribuidas. Sin embargo, el procesamiento de consultas es mucho más difícil en ambientes distribuidos que en centralizados, ya que existe un gran número de parámetros que afectan el rendimiento de las consultas distribuidas. En este capítulo revisaremos el procesamiento de consultas para bases de datos distribuidas. La función principal de un procesador de consultas relacionales es transformar una consulta en una especificación de alto nivel, típicamente en cálculo relacional, a una consulta equivalente en una especificación de bajo nivel, típicamente alguna variación del álgebra relacional. La consulta de bajo nivel implementa de hecho la estrategia de ejecución para la consulta. La transformación debe ser correcta y eficiente. Es correcta si la consulta de bajo nivel tiene la misma semántica que la consulta original, esto es, si ambas consultas producen el mismo resultado. El mapeo bien definido que se conoce entre el cálculo relacional y el álgebra relacional hace que la correctitud de la transformación sea fácil de verificar. Sin embargo, producir una estrategia de ejecución eficiente es mucho más complicado. Una consulta en el cálculo relacional puede tener muchas transformaciones correctas y equivalentes en el álgebra relacional. Ya que cada estrategia de ejecución equivalente puede conducir a consumos de

12

recursos de cómputo muy diferentes, la dificultad más importante es seleccionar la estrategia de ejecución que minimiza el consumo de recursos. Optimización 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 especificación de alto nivel a una estrategia de ejecución eficiente expresada en un lenguaje de bajo nivel sobre bases de datos locales. Así, el problema de optimización de consultas es minimizar una función de costo tal que función de costo total = costo de I/O + costo de CPU + costo de comunicación 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 comunicación domina dado que hay una velocidad de comunicación relativamente baja, los canales están saturados y el trabajo adicional requerido por los protocolos de comunicación es considerable. Así, los algoritmos diseñados 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 comunicación 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 genérico para el procesamiento de consultas. Para simplificar la discusión, suponga que se tiene un procesador de consultas estático semicentralizado en donde no se tienen fragmentos replicados. Cuatro capas principales están 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: descomposición de consultas, localización de datos, optimización global de consultas y optimización local de consultas. Las primeras tres se realizan en un nodo central usando información global. La cuarta capa se realiza en cada nodo local. Descomposición de consultas La primera capa descompone una consulta en el cálculo relacional en una consulta en el álgebra relacional que opera sobre relaciones globales. Consiste de cuatro partes: 1.-Normalización. Involucra la manipulación de los cuantificadores de la consulta y de los calificadores de la misma mediante la aplicación de la prioridad de los operadores lógicos. 2.-Análisis. Se detecta y rechazan consultas semánticamente incorrectas. 3.-Simplificación. Elimina predicados redundantes. 4.-Reestructuración. Mediante reglas de transformación una consulta en el cálculo relacional se transforma a una en el álgebra relacional. Se sabe que puede existir más de una transformación. Por tanto, el enfoque seguido usualmente es empezar con una consulta algebraica y aplicar transformaciones para mejorarla. Localización 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 información sobre la distribución de datos. Esta capa determina cuales fragmentos están involucrados en la consulta y transforma la consulta distribuida en una consulta sobre fragmentos.

13

Optimización Global de Consultas. Dada una consulta algebraica sobre fragmentos, el objetivo de esta capa es hallar una estrategia de ejecución para la consulta cercana a la óptima. La estrategia de ejecución para una consulta distribuida puede ser descrita con los operadores del álgebra relacional y con primitivas de comunicación para transferir datos entre nodos. Para encontrar una buena transformación se consideran las características de los fragmentos, tales como, sus cardinalidades. Un aspecto importante de la optimización 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 optimización global es una consulta algebraica optimizada con operación de comunicaciones incluidas sobre los fragmentos. Optimización Local de Consultas. El trabajo de la última capa se efectúa 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 optimización local utiliza los algoritmos de sistemas centralizados. [Según 1]

9. CONCLUSIONES

- Las BDD, son innovaciones que van en creciente desarrollo, y profundización en su estudio. Si bien es cierto, la

implantación, o el uso de un BDD, es mucho más difícil de obtener, debido a la economía, este tipo de BD ha

empezado a ser utilizada desde mucho atrás por empresas, que como se explica en el apartado 2, encaja muy

bien ellas y todo tipo de organización jerárquica, dado que las BDD, cuentan al igual que las compañías con

particiones y subdivisiones que permiten un trabajo más práctico y análogo.

- Al pensar que una base de datos, cuenta con más opciones, operaciones, y distintos tipos de características,

podría presumirse de que son más riesgosas y porque no muy complejas en su estructura. Pero como se

describió anteriormente, son algo complejas, pero su tratamiento solo requiere una pequeña modificación con

respecto a las BDC.

- Las arquitecturas si bien es cierto, muestran variaciones en los distintos ejemplos, todas ellas manifiestan cierta

gran parte de relación. En todas ellas se pone al descubierto los tres niveles que contienen las BDD en su

arquitectura, y que valdría 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 más cercanos de lo que

normalmente se cree.

- Los SGBDD, muestran ciertas características 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 BIBLIOGRÁFICAS

[1] J.C. VARGAS HERNÁNDEZ, Fundamentos teóricos de Bases de Datos Distribuidas[en línea], México, 2001,

disponible en:

<http://www.geocities.com/ddbqp/>

[2] L. CAMPOY MEDRANO, Tutorial de Bases de Datos I[en línea], Instituto Tecnológico 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, Introducción a los Sistemas de Bases de Datos, ed 7, México, Pág. 651 – 670, 2001

[5] A. DIAZ, Bases de Datos distribuidas[en línea], México, 2004

<http://www.cs.cinvestav.mx/SC/prof_personal/adiaz/Disdb/Cap_1.html>

[6] F. LORENZO CASTRO, Modelos de Datos: conceptos y clasificación, Pág. 47, 2000

[7] G.H. HANSEN, J.V. HANSEN, Diseño y Administración de BDx, ed 2, Pág. 393 – 410, Universidad de Salamanca

Madrid, España, 2000, ISBN: 8483220024

[8] J.C. LAVARIEGA JARQUIN, Bases de Datos Avanzadas, ITESM, Monterrey México, 2000

[9] F. RUIZ, Arquitectura de Sistemas de Bases de Datos, Universidad de Castilla La Mancha, Pág. 43 – 60, 2000

Título del trabajo: BASES DE DATOS DISTRIBUIDAS

Alumno: CARRANZA ATHÓ FREDY

Veracidad Actualidad Claridad Profundidad Autenticidad Formato Referencias Bibliográficas