base de datos distribuidas, Guías, Proyectos, Investigaciones de Tecnología

¡Descarga base de datos distribuidas y más Guías, Proyectos, Investigaciones en PDF de Tecnología solo en Docsity!

DISEÑO DE BASE DE

DATOS DISTRIBUIDA

(Texto Base)

Materia: Sistemas Distribuidos

AQUINO BOLIVIA – 2005

Cochabamba - Bolivia

CAPITULO 1. INTRODUCCION

La cantidad de innovaciones tecnológicas que ha habido en los últimos años ha promovido un cambio en la forma de observar a los sistemas de información y, en general, a las aplicaciones computacionales. Existen avances tecnológicos que se realizan continuamente en circuitos, dispositivos de almacenamiento, programas y metodologías. Sin embargo, los cambios tecnológicos van de la mano con la demanda de los usuarios y programas para la explotación exhaustiva de tales dispositivos mejorados. Por tanto, existe un continuo desarrollo de nuevos productos los cuales incorporan ideas nuevas desarrolladas por compañías e instituciones académicas.

Aún cuando es posible que un usuario común no perciba los desarrollos relevantes de nuevos productos, para las aplicaciones existe una demanda permanente por mayor funcionalidad, mayor número de servicios, más flexibilidad y mejor rendimiento. Así, al diseñar un nuevo sistema de información o al prolongar la vida de uno ya existente, se debe buscar siempre formas para enlazar las soluciones ofrecidas por la tecnología disponible a las necesidades de las aplicaciones de los usuarios.

Una área en la cual las soluciones están integrando tecnología con nuevas arquitecturas o formas de hacer las cosas es, sin lugar a dudas, el área de los sistemas distribuidos de información. Ellos se refieren al manejo de datos almacenados en facilidades de cómputo localizadas en muchos sitios ligados a través de una red de comunicaciones. Un caso específico de estos sistemas distribuidos es lo que se conoce como bases de datos distribuidas, tópico a estudiar en estas notas.

1. MOTIVACION

Existen dos fuerzas que han impulsado la evolución de los sistemas de bases de datos. Por un lado los usuarios como parte de organizaciones más complejas han demandado una serie de capacidades que se han ido incorporando en los sistemas de bases de datos (Figura 1.1). Un ejemplo de esto es la necesidad de integrar información proveniente de fuentes diversas. Por otro lado, la tecnología ha hecho posible que algunas facilidades inicialmente imaginadas solo en sueños se conviertan en realidad. Por ejemplo, las transacciones en línea que permite el sistema bancario actual no hubiera sido posible sin el desarrollo de los equipos de comunicación. Los sistemas de cómputo distribuido son ejemplos claros en donde presiones organizacionales se combinan con la disponibilidad de nuevas tecnologías para hacer realidad tales aplicaciones.

1.1 La presión por datos distribuidos

La presión de los usuarios

Las bases de datos grandes permiten organizar la información relevantes a alguna parte de la operación de una organización como por ejemplo servicios de salud, corporaciones industriales o bancos. Casi cualquier organización que ha incorporado sistemas de información para su funcionamiento ha experimentado dos fases.

Figura 1.1. Fuerzas evolucionarias en los sistemas de bases de datos.

• Asegurar que el acceso entre diferentes sitios o nodos y el procesamiento de datos se realice de manera eficiente, presumiblemente óptima.
• Transformar datos e integrar diferentes tipos de procesamiento entre nodos de un ambiente distribuido.
• Distribuir datos en los nodos del ambiente distribuido de una manera óptima.
• Controlar el acceso a los datos disponibles en el ambiente distribuido.
• Soportar la recuperación de errores de diferentes módulos del sistema de manera segura y eficiente.
• Asegurar que los sistemas locales y globales permanezcan como una imagen fiel del mundo real evitando la interferencia destructiva que pueden ocasionar diferentes transacciones en el sistema.

Así también, la aplicación de técnicas de distribución de información requiere de superar algunas dificultades de índole organizacional y algunas otras relacionadas con los usuarios. Entre ellas se puede mencionar:

• El desarrollo de modelos para estimar la capacidad y el tráfico esperado en el sistema distribuido.
• Soportar el diseño de sistemas de información distribuidos. Por ejemplo, ayudar a decidir donde localizar algún dato particular o donde es mejor ejecutar un programa de aplicación.
• Considerar la competencia que habrá por el uso de los recursos entre nodos diferentes.

Aun cuando las dificultades mencionadas son importantes, las ventajas de la distribución de información han promovido su aplicación en ambientes del presente y del futuro.

1.2 Heterogeneidad y la presión para integrar datos

La descentralización de los sistemas de información y el advenimiento de los sistemas distribuidos están bien justificados. Sin embargo, existe todavía un argumento importante para el desarrollo de sistemas de bases de datos distribuidas; éste se refiere a la integración de necesidades de procesamiento no locales en donde es necesario intercambiar información proveniente de otras áreas o departamentos. La descentralización de la información promueve la heterogeneidad en su manejo. La heterogeneidad se puede dar a muchos niveles, desde la forma y significado de cada dato hasta el formato y el medio de almacenamiento que se elige para guardarlo. La integración de la información es de importancia mayor para el funcionamiento de una organización.

En resumen, en los sistemas de bases de datos distribuidas se persigue la integración de sistemas de bases de datos diversos no necesariamente homogéneos para dar a los usuarios una visión global de la información disponible. Este proceso de integración no implica la centralización de la información, más bien, con la ayuda de la tecnología de redes de computadoras disponible, la información se mantiene distribuida (localizada en diversos lugares) y los sistemas de bases de datos distribuidos permiten el acceso a ella como si estuviera localizada en un solo lugar. La distribución de la información permite, entre otras cosas, tener accesos rápidos a la información, tener copias de la información para accesos más rápidos y para tener respaldo en caso de fallas.

1.3 Computación Distribuida

Los sistemas de bases de datos distribuidas son un caso particular de los sistemas de cómputo distribuido en los cuales un conjunto de elementos de procesamiento autónomos (no necesariamente homogéneos) se interconectan por una red de comunicaciones y cooperan entre ellos para realizar sus tareas asignadas. Históricamente, el cómputo distribuido se ha estudiado desde muchos puntos de vista. Así, es común encontrar en la literatura un gran número de términos que se han usado para identificarlo. Entre los términos más comunes que se utilizan para referirse al cómputo distribuido podemos encontrar: funciones distribuidas, procesamiento distribuido de datos, multiprocesadores, multicomputadoras, procesamiento satelital, procesamiento tipo "backend", computadoras dedicadas y de propósito específico, sistemas de tiempo compartido, sistemas funcionalmente modulares.

Existen muchas componentes a distribuir para realizar una tarea. En computación distribuida los elementos que se pueden distribuir son:

• Control. Las actividades relacionadas con el manejo o administración del sistema.
• Datos. La información que maneja el sistema.
• Funciones. Las actividades que cada elemento del sistema realiza.
• Procesamiento lógico. Las tareas específicas involucradas en una actividad de procesamiento de información.

Figura 1.2. Motivación de los sistemas de bases de datos distribuidos.

1.4 Sistemas de bases de datos distribuidas

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 (ver Figura 1.2).

Un sistema de bases de datos distribuida (SBDD) es un sistema en el cual múltiples sitios de bases de datos están ligados por un sistema de comunicaciones, de tal forma que, un usuario en cualquier sitio puede accesar los datos en cualquier parte de la red exactamente como si los datos estuvieran almacenados en su sitio propio.

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

Figura 1.4. Un medio ambiente distribuido para bases de datos.

1.4.1 Ambientes con múltiples procesadores

Desde el punto de vista de las bases de datos, conceptualmente existen tres tipos de ambientes que se integran con múltiples procesadores:

1. Arquitecturas de memoria compartida. Consisten de diversos procesadores los cuales accesan una misma memoria y un misma unidad de almacenamiento (uno o varios discos). Algunos ejemplos de este tipo son las computadoras Sequent Encore y los mainframes IBM4090 y Bull DPS8 (Figura 1.5).

Figura 1.5. Arquitectura de memoria compartida.

2. Arquitecturas de disco compartido. Consiste de diversos procesadores cada uno de ellos con su memoria local pero compartiendo una misma unidad de almacenamiento (uno o varios discos). Ejemplos de estas arquitecturas son los cluster de Digital, y los modelos IMS/VS Data Sharing de IBM (Figura 1.6).

Figura 1.6. Arquitectura de disco compartido.

3. Arquitecturas nada compartido. Consiste de diversos procesadores cada uno con su propia memoria y su propia unidad de almacenamiento. Aquí se tienen los clusters de estaciones de trabajo, la computadoras Intel Paragon, NCR 3600 y 3700 e IBM SP2 (Figura 1.7).

Figura 1.7. Arquitectura nada compartido.

1.4.2 Aplicaciones

Los ambientes en los que se encuentra con mayor frecuencia el uso de las bases de datos distribuidas son:

• Cualquier organización que tiene una estructura descentralizada.
• Casos típicos de lo anterior son: organismos gubernamentales y/o de servicio público.
• La industria de la manufactura, particularmente, aquella con plantas múltiples. Por ejemplo, la industria automotriz.
• Aplicaciones de control y comando militar.
• Líneas de transportación aérea.
• Cadenas hoteleras.
• Servicios bancarios y financieros.

manejar un solo directorio global. Sin embargo, si existen también usuarios locales, el directorio combina información local con información global.

2. Procesamiento de consultas. El procesamiento de consultas es de suma importancia en bases de datos centralizadas. Sin embargo, en BDD éste adquiere una relevancia mayor. El objetivo es convertir transacciones de usuario en instrucciones para manipulación de datos. No obstante, el orden en que se realizan las transacciones afecta grandemente la velocidad de respuesta del sistema. Así, el procesamiento de consultas presenta un problema de optimización en el cual se determina el orden en el cual se hace la menor cantidad de operaciones. Este problema de optimización es NP-difícil, por lo que en tiempos razonables solo se pueden obtener soluciones aproximadas. En BDD se tiene que considerar el procesamiento local de una consulta junto con el costo de transmisión de información al lugar en donde se solicitó la consulta. 3. Control de concurrencia. El control de concurrencia es la actividad de coordinar accesos concurrentes a la base de datos. El control de concurrencia permite a los usuarios accesar la base de datos en una forma multiprogramada mientras se preserva la ilusión de que cada usuario está utilizándola solo en un sistema dedicado. El control de concurrencia asegura que transacciones múltiples sometidas por usuarios diferentes no interfieran unas con otras de forma que se produzcan resultados incorrectos. En BDD el control de concurrencia es aún más complejo que en sistemas centralizados. Los algoritmos más utilizados son variaciones de aquellos usados en sistemas centralizados: candados de dos fases, ordenamiento por estampas de tiempo, ordenamiento por estampas de tiempo múltiples y control de concurrencia optimista. Un aspecto interesante del control de concurrencia es el manejo de interbloqueos. El sistema no debe permitir que dos o más transacciones se bloqueen entre ellas.

4. Confiabilidad. En cualquier sistema de bases de datos, centralizado o distribuido, se debe ofrecer garantías de que la información es confiable. Así cada consulta o actualización de la información se realiza mediante transacciones, las cuales tienen un inicio y fin. En sistemas distribuidos, el manejo de la atomicidad y durabilidad de las transacciones es aún más complejo, ya que una sola transacción puede involucrar dos o más sitios de la red. Así, el control de recuperación en sistemas distribuidos debe asegurar que el conjunto de agentes que participan en una transacción realicen todos un compromiso (commit) al unísono o todos al mismo tiempo restablezcan la información anterior (roll-back).

En la Figura 1.8 se presenta un diagrama con las relaciones entre los aspectos relevantes sobre las BDD.

Figura 1.8. Factores importantes en BDD.

1.6 Estado del Arte

Aun cuando los beneficios del uso de BDD son claramente perceptibles, en la actualidad muchos de los desarrollos se encuentran únicamente en sistemas experimentales (de investigación). A continuación se discute el estado actual de las bases de datos comerciales respecto de cuatro logros potenciales asequibles en BDD.

1. Manejo transparente de datos distribuidos, fragmentados y replicados. Comercialmente aún no se soporta la replicación de información. La fragmentación utilizada es únicamente de tipo horizontal (ésta se discute en el capítulo 3). La distribución de información no se realiza aún con la transparencia requerida. Por ejemplo, el usuario debe indicar la localización de un objeto y el acceso a los datos es mediante sesiones remotas a bases de datos locales. La mayoría de los sistemas comerciales utilizan el modelo múltiples clientes-un solo servidor. 2. Mejoramiento de la confiabilidad y disponibilidad de la información mediante transacciones distribuidas. Algunos sistemas como Ingres, NonStop SQL y Oracle V 7.x ofrecen el soporte de transacciones distribuidas. En Sybase, por ejemplo, es posible tener transacciones distribuidas pero éstas deber ser implementadas en las aplicaciones mediante primitivas dadas. Respecto del soporte para replicación de información o no se ofrece o se hace a través de la regla une-lee-todos-escriben. 3. Mejoramiento de la eficiencia. Una mayor eficiencia es una de las grandes promesas de los SMBDD. Existen varias partes en donde ésto se puede lograr. En primer lugar, la ubicación de los datos a lugares próximos a donde se usan puede mejorar la eficiencia en el acceso a la información. Sin embargo, para lograrlo es necesario tener un buen soporte para fragmentación y replicación de información. Otro punto en donde se puede incrementar la eficiencia es mediante la explotación del paralelismo entre operaciones. Especialmente en el caso de varias consultas independientes, éstas se pueden procesar por sitios diferentes. Más aún, el procesamiento de una sola consulta puede involucrar varios sitios y así procesarse de manera más rápida. Sin embargo, la explotación del paralelismo requiere que se tenga tanta información requerida por cada aplicación en el sitio donde la aplicación se utiliza, lo cual conduciría a una replicación completa, esto es, tener toda la información en cada sitio de la red. El manejo de réplicas es complicado dado que las actualizaciones a este tipo de datos involucran a todos los sitios teniendo copias del dato. Los sistemas comerciales ofrecen únicamente aproximaciones a este requisito. Por ejemplo, en los bancos se destina usualmente el horario de oficina para hacer lecturas y las horas no hábiles para hacer actualizaciones. Otra estrategia es tener dos bases de datos, una para consultas y otra para actualizaciones.

4. Mejor escalabilidad de las BD. El tener sistemas escalables de manera fácil y económica se ha logrado por el desarrollo de la tecnología de microprocesadores y estaciones de trabajo. Sin embargo, respecto de la escalabilidad, la comunicación de la información tiene un costo el cual no se ha estudiado con suficiente profundidad.

La transparencia sobre replicación de datos se refiere a que si existen réplicas de objetos de la base de datos, su existencia debe ser controlada por el sistema no por el usuario. Se debe tener en cuenta que al cuando el usuario se encarga de manejar las réplicas en un sistema, el trabajo de éste es mínimo por lo que se puede obtener una eficiencia mayor. Sin embargo, el usuario puede olvidarse de mantener la consistencia de las réplicas teniendo así datos diferentes.

La transparencia a nivel de fragmentación de datos permite que cuando los objetos de la bases de datos están fragmentados, el sistema tiene que manejar la conversión de consultas de usuario definidas sobre relaciones globales a consultas definidas sobre fragmentos. Así también, será necesario mezclar las respuestas a consultas fragmentadas para obtener una sola respuesta a una consulta global. El acceso a una base de datos distribuida debe hacerse en forma transparente.

Ejemplo 2.1. Como un ejemplo se utilizará a lo largo de estas notas una base de datos que modela una compañía de ingeniería. Las entidades a ser modeladas son ingenieros y proyectos. Para cada ingeniero, se desea conocer su número de empleado (ENO), su nombre (ENOMBRE), el puesto ocupado en compañía (TITULO), el salario (SAL), la identifiación de los nombres de proyectos en los cuales está trabajando (JNO), la responsabilidad que tiene dentro del proyecto (RESP) y la duración de su responsabilidad en meses (DUR). Similarmente, para cada proyecto se desea conocer el número de proyecto (JNO), el nombre del proyecto (JNOMBRE), el presupuesto asignado al proyecto (PRESUPUESTO) y el lugar en donde se desarrolla el proyecto (LUGAR).

Un ingeniero puede participar en más de un proyecto pero su salario corresponde únicamente al puesto que ocupa en la compañía. Así, después de aplicar normalización se obtienen las relaciones E –para ingenieros, J –para proyectos, S –para los salarios asignados a los puestos y G –para los ingenieros asignados a cada proyecto. Un ejemplo de las instancias para cada relación se presenta en la Figura 2.1.

E

ENO ENOMBRE TITULO E1 Juan Rodríguez Ingeniero Eléctrico E2 Miguel Sánchez Analista de Sistemas E3 Armando Legarreta Ingeniero Mecánico E4 Beatriz Molleda Programador E5 Jorge Castañeda Analista de Sistemas E6 Luis Chávez Ingeniero Eléctrico E7 Roberto Dávila Ingeniero Mecánico E8 Julia Jiménez Analista de Sistemas

G

ENO JNO PUESTO DUR E1 J1 Administrador 12 E2 J1 Analista 24 E2 J2 Analista 6 E3 J3 Consultor 10

E3 J4 Ingeniero 48 E4 J2 Programador 18 E5 J2 Administrador 24 E6 J4 Administrador 48 E7 J3 Ingeniero 36 E7 J5 Ingeniero 23 E8 J3 Administrador 40

J

JNO JNOMBRE PRESUPUESTO LUGAR J1 Instrumentación 150000 Monterrey J2 Desarrollo de bases de datos

135000 México

J3 CAD/CAM 250000 Puebla J4 Mantenimiento 310000 México J5 CAD/CAM 500000 Monterrey

S

TITULO SALARIO Ingeniero Eléctrico 40000 Analista de Sistemas 34000 Ingeniero Mecánico 27000 Programador 24000

Figura 2.1. Bases de datos de una empresa con cuatro relaciones.

Si se quisiera obtener todos los empleados y sus salarios en la corporación quienes han trabajado más de 12 meses se haría la consulta siguiente en SQL:

SELECT ENOMBRE, SALARIO

FROM E, G, S

WHERE JORNADA > 12 AND

E.ENO = G.ENO AND

E.TILE = S.TITLE

Se debe tener en cuenta que en cada sitio de la corporación puede haber esquemas diferentes o repetidos. Por ejemplo, en la Figura 2.2 se presentan esquemas diferentes para el manejo de proyectos, empleados y puestos en cada sitio de la bases de datos del Ejemplo 2.1.

2.2 ARQUITECTURA DE UN SISTEMA DE BASES DE DATOS DISTRIBUIDAS

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, como se puede apreciar en la Figura 2.4.

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.

En las Figuras 2.5, 2.6 y 2.7 se presenta la definición de los esquemas conceptual, interno y externo para las relaciones de la Figura 2.1.

Figura 2.4. Arquitectura ANSI/SPARC de una base de datos.

Figura 2.5. Vista conceptual de las relaciones E, S, J y G.

Figura 2.6. Definición de una vista interna a partir de la relación S.

Figura 2.7. Dos ejemplos de vistas externas.

Desafortunadamente, no existe un equivalente de una arquitectura estándar para sistemas de manejo de bases de datos distribuidas. La tecnología y prototipos de SMBDD se han desarrollado más o menos en forma independiente uno de otro y cada sistema ha adoptado su propia arquitectura.

Para definir un esquema de estandarización en bases de datos distribuidas se debe definir un modelo de referencia el cual sería un marco de trabajo conceptual cuyo propósito es dividir el trabajo de

• Autonomía de diseño. La habilidad de un componente del SMBD para decidir cuestiones relacionadas a su propio diseño.
• Autonomía de comunicación. La habilidad de un componente del SMBD para decidir como y cuando comunicarse con otros SMBD.
• Autonomía de ejecución. La habilidad de un componente del SMBD para ejecutar operaciones locales de la manera que él quiera.

Figura 2.9. Arquitectura de un SMBDD homogéneo.

Desde el punto de vista funcional y de organización de datos, los sistemas de datos distribuidos están divididos en dos clases separadas, basados en dos filosofía totalmente diferentes y diseñados para satisfacer necesidades diferentes:

1. Sistemas de manejo de bases de datos distribuidos homogéneos
2. Sistemas de manejo de bases de datos distribuidos heterogéneos

Un SMBDD homogéneo tiene múltiples colecciones de datos; integra múltiples recursos de datos como se muestra en la Figura 2.9. Los sistemas homogéneos se parecen a un sistema centralizado, pero en lugar de almacenar todos los datos en un solo lugar, los datos se distribuyen en varios sitios comunicados por la red. No existen usuarios locales y todos ellos accesan la base de datos a través de una interfaz global. El esquema global es la unión de toda las descripciones de datos locales y las vistas de los usuarios se definen sobre el esquema global.

Para manejar los aspectos de la distribución, se deben agregar dos niveles a la arquitectura estándar ANSI-SPARC, como se muestra en la Figura 2.10. El esquema de fragmentación describe la forma en que las relaciones globales se dividen entre las bases de datos locales. La Figura 2.11 presenta el ejemplo de una relación, R, la cual se divide en cinco fragmentos. El esquema de asignamiento especifica el lugar en el cual cada fragmento es almacenado. De aquí, los fragmentos pueden migrar de un sitio a otro en respuesta a cambios en los patrones de acceso.

Figura 2.10. Arquitectura de los esquemas de un SMBDD homogéneo.

Figura 2.11. Fragmentación de una relación global.