UNIDAD I: BASE DE DATOS DISTRIBUIDAS
1.1 ARQUITECTURA
En el presente capítulo se mostrará la arquitectura general de un sistema de
bases de datos distribuida, se introducirá el concepto de fragmentación de
datos relacionado con el nivel de transparencia de distribución que un SBDD
debe ofrecer. Se dará una descripción acerca de las componentes de las bases
de datos distribuidas.
La arquitectura define la estructura de un sistema. Al definir la arquitectura
se deben identificar las componentes de un sistema, las funciones que realiza
cada una de las componentes y las interrelaciones e interacciones entre cada componente.
1.1.1 AUTONOMÍA
Presentan las diferentes dimensiones (factores) que se deben considerar para
la implementación de un sistema manejador de base de datos. Las dimensiones son:
1. Heterogeneidad. La heterogeneidad se puede presentar a varios niveles: hardware, sistema de comunicaciones, sistema operativo o SMBD. Para el caso de
SMBD heterogéneos ésta se puede presentar debido al modelo de datos, al lenguaje
de consultas o a los algoritmos para manejo de transacciones.
2. Autonomía. La autonomía se puede presentar a diferentes niveles:
• 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
1.1.2 HETEROGENIDAD
La clase de sistemas heterogéneos es aquella caracterizada por manejar diferentes SMBD en los nodos locales. Una subclase importante dentro de esta clase es la de
los sistemas de manejo multi-bases de datos. Un sistema multi-bases de datos (Smulti-BD) tiene múltiples SMBDs, que pueden ser de tipos diferentes, y múltiples bases de datos existentes. La integración de todos ellos se realiza mediante subsistemas de software.
2.12. En contraste con los sistemas homogéneos, existen usuarios locales y globales.
Los usuarios locales accesan sus bases de datos locales sin verse afectados por la presencia del Smulti-BD.
En algunas ocasiones es importante caracterizar a los sistemas de bases de datos distribuidas por la forma en que se organizan sus componentes.
2.13 se presenta la arquitectura basada en componentes de un SMBD distribuido. Consiste de dos partes fundamentales, el procesador de usuario y el procesador de datos. El procesador de usuario se encarga de procesar las solicitudes del usuario, por tanto, utiliza el esquema externo del usuario y el esquema conceptual global. Así también, utiliza un diccionario de datos global. El procesador de usuario consiste de cuatro partes: un manejador de la interfaz con el usuario, un controlador semántico de datos, un optimizador global de consultas y un supervisor de la ejecución global. El procesador de datos existe en cada nodo de la base de datos distribuida. Utiliza un esquema local conceptual y un esquema local interno. El procesador de datos consiste de tres partes: un procesador de consultas locales, un manejador de recuperación de fallas locales y un procesador de soporte para tiempo de ejecución.
1.1.3 DISTRIBUCIÓN Y ESQUEMA GLOBAL
Distribución. Determina si las componentes del sistema están localizadas en la
misma computadora o no.
1.2 DISEÑO DE BASES DE DATOS DISTRIBUIDAS
BASE 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, los cuales tienen la capacidad de procesamiento autónomo lo cual indica que puede realizar operaciones locales o distribuidas. 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 acceder los datos en cualquier parte de la red exactamente como si los datos estuvieran siendo accedidos de forma local.
En un sistema distribuido de bases de datos se almacenan en varias computadoras.
Los principales factores que distinguen un SBDD de un sistema centralizado son los siguientes:
• Hay múltiples computadores, llamados sitios o nodos.
• Estos sitios deben de estar comunicados por medio de algún tipo de red de comunicaciones para transmitir datos y órdenes entre los sitios.
Por lo que el hardware que compone una base de datos distribuida se reduce a servidores y la red.
También consta con una serie de software:
Sistema de Administración de Base de Datos Distribuida (DDBMS)
Este sistema está formado por las transacciones y los administradores de la base de datos distribuidos.
Administrador de transacciones distribuidas (DTM)
Este es un programa que recibe las solicitudes de procesamiento de los programas de consulta o transacciones y las traduce en acciones para los administradores de la base de datos.
Administrador de la base de datos (DBM)
Es un programa que procesa cierta porción de la base de datos distribuida. Se encarga de recuperar y actualizar datos del usuario y generales de acuerdo con los comandos recibidos de los DTM.
Nodo
Un nodo es una computadora que ejecuta un DTM o un DBM o ambos. Un nodo de transacción ejecuta un DTM y un nodo de base de datos ejecuta un DBM.
Ventajas y Desventajas
Ventajas
• Refleja una estructura organizacional - los fragmentos de la base de datos se ubican en los departamentos a los que tienen relación.
• Autonomía local - un departamento puede controlar los datos que le pertenecen.
• Disponibilidad - un fallo en una parte del sistema solo afectará a un fragmento, en lugar de a toda la base de datos.
• Rendimiento - los datos generalmente se ubican cerca del sitio con mayor demanda, también los sistemas trabajan en paralelo, lo cual permite balancear la carga en los servidores.
• Economía - es más barato crear una red de muchas computadoras pequeñas,
que tener una sola computadora muy poderosa.
• Modularidad - se pueden modificar, agregar o quitar sistemas de la base
de datos distribuida sin afectar a los demás sistemas (módulos).
Desventajas
• Complejidad - Se debe asegurar que la base de datos sea transparente, se debe lidiar con varios sistemas diferentes que pueden presentar dificultades únicas. El diseño de la base de datos se tiene que trabajar tomando en cuenta su naturaleza distribuida, por lo cual no podemos pensar en hacer joins que afecten varios sistemas.
• Economía - la complejidad y la infraestructura necesaria implica que se necesitará una mayor mano de obra.
• Seguridad - se debe trabajar en la seguridad de la infraestructura así como cada uno de los sistemas.
• Integridad - Se vuelve difícil mantener la integridad, aplicar las reglas
de integridad a través de la red puede ser muy caro en términos de transmisión de datos.
• Falta de experiencia - las bases de datos distribuidas son un campo relativamente nuevo y poco común por lo cual no existe mucho personal con experiencia o conocimientos adecuados.
• Carencia de estándares - aún no existen herramientas o metodologías que ayuden a los usuarios a convertir un DBMS centralizado en un DBMS distribuido.
• Diseño de la base de datos se vuelve más complejo - además de las dificultades que generalmente se encuentran al diseñar una base de datos, el diseño de una base de datos distribuida debe considerar la fragmentación, replicación y ubicación de los fragmentos en sitios específicos.
1.2.1 Diseño top-down: fragmentación.
Existen dos estrategias generales para abordar el problema de diseño de bases de datos distribuidas:
El enfoque de arriba hacia abajo (top-down).
Este enfoque es más apropiado para aplicaciones nuevas y para sistemas homogéneos. Consiste en partir desde el análisis de requerimientos para definir el diseño conceptual y las vistas de usuario. A partir de ellas se define un esquema conceptual global y los esquemas externos necesarios. Se prosigue con el diseño de la fragmentación de la base de datos, y de aquí se continúa con la localización de los fragmentos en los sitios, creando las imágenes físicas. Esta aproximación se completa ejecutando, en cada sitio, "el diseño físico" de los datos, que se localizan en éste. En la Figura 3.1 se presenta un diagrama con la estructura general del enfoque top-down.
1.2.2 Diseño bottom-up: integración de bases de datos.
El diseño de abajo hacia arriba (bottom-up).
Se utiliza particularmente a partir de bases de datos existentes, generando con esto bases de datos distribuidas. En forma resumida, el diseño bottom-up de una base de datos distribuida requiere de la selección de un modelo de bases de datos común para describir el esquema global de la base de datos. Esto se debe es posible que se utilicen diferentes SMBD. Después se hace la traducción de cada esquema local en el modelo de datos común y finalmente se hace la integración del esquema local en un esquema global común.
El diseño de una base de datos distribuida, cualquiera sea el enfoque que se siga, debe responder satisfactoriamente las siguientes preguntas:
• �Por qué hacer una fragmentación de datos?
• �Cómo realizar la fragmentación?
• �Qué tanto se debe fragmentar?
• �Cómo probar la validez de una fragmentación?
• �Cómo realizar el asignamiento de fragmentos?
• �Cómo considerar los requerimientos de la información?
1.3 ARQUITECTURAS CLIENTE/SERVIDOR PARA SGBD
Durante años, las bases de datos se han utilizado en sistemas que se ajustaban a una arquitectura conocida como cliente/servidor. En ella los datos residen en un ordenador que actúa como servidor, ejecutando el software que denominábamos antes servidor de datos (SGBD). Los usuarios, desde ordenadores remotos, se sirven de un software cliente para comunicarse con el servidor de datos. Ese software cliente es especifico para cada servidor de datos existen.
Supongamos que esta utilizando SQL Server como Servidor de datos, estando instalado dicho software en una maquina que reside en un centro de proceso de datos. Desde su ordenador, ubicado en otra planta del mismo edificio, se comunicaría con ese servidor mediante el software cliente de Sql Server que, lógicamente, debería estar instalado en su máquina. Dicho software cliente no serviría para comunicar con un servidor Oracle, etc. por poner un caso, teniendo que disponer del software cliente que corresponda en cada caso.
1.3.1FILOSOFÍA CLIENTE/SERVIDOR
En el sentido más estricto, el término cliente/servidor describe un sistema en el que una máquina cliente solicita a una segunda máquina llamada servidor que ejecute una tarea específica. El cliente suele ser una computadora personal común conectada a una LAN, y el servidor es, por lo general, una máquina anfitriona, como un servidor de archivos PC, un servidor de archivos de UNIX o una macrocomputadora o computadora de rango medio. El programa cliente cumple dos funciones distintas: por un lado gestiona la comunicación con el servidor, solicita un servicio y recibe los datos enviados por aquél. Por otro, maneja la interfaz con el usuario: presenta los datos en el formato adecuado y brinda las herramientas y comandos necesarios para que el usuario pueda utilizar las prestaciones del servidor de forma sencilla. El programa servidor en cambio, básicamente sólo tiene que encargarse de transmitir la información de forma eficiente. No tiene que atender al usuario. De esta forma un mismo servidor puede atender a varios clientes al mismo tiempo. Algunas de las principales LAN cliente/servidor con servidores especializados que pueden realizar trabajos para clientes incluyen a Windows NT, NetWare de Novell, VINES de Banyan y LAN Server de IBM entre otros. Todos estos sistemas operativos de red pueden operar y procesar solicitudes de aplicaciones que se ejecutan en clientes, mediante el procesamiento de las solicitudes mismas.
1.3.2 SOCKETS
Un socket es un mecanismo de comunicación entre dos o más procesos, gracias al cual es posible enviar o recibir información. A efectos de programación un socket funciona como un descriptor de ficheros de bajo nivel; comandos como read () y write () funcionan con sockets de la misma forma que lo hacen con ficheros y tuberías.
El conjunto de servicios que ofrece un socket fue diseñado para facilitar una conexión entre procesos, tanto si se ejecutan en una sola máquina, como si lo hacen en red. Los procesos se intercambian información transmitiendo datos a través de mensajes que circulan entre un socket en un proceso y otro socket en otro proceso. Para la comunicación entre máquinas se suelen utilizar los protocolos TCP/IP, logrando así la independencia del hardware y de la arquitectura de red mediante la cual se establece el enlace; siendo esto posible gracias a la estructura en forma de capas que posee una red de ordenadores. Los sockets son conexiones que pertenecen a la capa de transporte de la estructura OSI. Una aplicación con sockets debe especificar los puertos de protocolo local y remoto y la dirección IP remota que utilizará, si usará TCP o UDP, y si iniciará transferencia o esperará por una conexión (es decir, si funcionará como servidor o cliente).
Tipos de sockets
El mecanismo de sockets está diseñado de forma genérica; un socket por sí mismo no contiene información suficiente para describir la comunicación entre procesos. Los sockets operan dentro de dominios de comunicación, que determinan el formato de direcciones a utilizar y el protocolo de comunicación. Además el dominio define si los dos procesos que se comunican se encuentran en el mismo sistema o en sistemas diferentes y cómo pueden ser direccionados. De esta forma un socket puede clasificarse según su dominio y según el tipo de conexión que realice.
En función del tipo de conexión se dispone de varios tipos de socket, que describen la forma en la que se transfiere información a través de ese socket: sockets stream, sockets datagrama y sockets raw.
• Los sockets stream son un servicio orientado a conexión donde los datos se transfieren sin encuadrarlos en registros o bloques. Para establecer una comunicación utilizando el protocolo TCP.
• Los sockets datagrama son un servicio de transporte si conexión que utilizan el protocolo de transporte UDP. Cada vez que se envían datagramas es necesario enviar el descriptor del socket local y la dirección del socket que deve recibir el datagrama. Por tanto, hay que enviar datos adicionales cada vez que se realice una comunicación. Los datos se envían y reciben en paquetes cuya entrega no está garantizada.
• Los sockets raw dan acceso a la capa de software de red subyacente o a protocolos de más bajo nivel. Se utilizan sobre todo para la depuración del código de los protocolos. Los sockets raw proporcionan acceso al Internet Control Message Protocol, ICMP, y se utiliza para comunicarse entre varias entidades IP.
Con respecto a la clasificación en función del dominio, bajo Unix existen dos dominios: uno para comunicaciones internas al sistem (dominio UNIX) y el otro para comunicaciones entre sistemas (dominio Internet). El dominio UNIX (AF_UNIX) permite una comunicación intrasistema entre procesos que corren en el mismo microprocesador. Se permiten tanto los sockets stream como los datagrama; no se permiten los sockets de tipo raw. El dominio Internet (AF_INET) soporta los protocolos estándar de Internet TCP y UDP y se utiliza para comunicar procesos que corren en distintos microprocesadores. Permite sockets stream, datagrama y raw.
1.3.3 RPC
El RPC (del inglés Remote Procedure Call, Llamada a Procedimiento Remoto) es un protocolo que permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, estando éstas encapsuladas dentro de las RPC.
Las RPC son muy utilizadas dentro del paradigma cliente-servidor. Siendo el cliente el que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando éste de vuelta el resultado de dicha operación al cliente.
Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser el RPC de Sun denominado ONC RPC (RFC 1057), el RPC de OSF denominado DCE/RPC y el Modelo de Objetos de Componentes Distribuidos de Microsoft DCOM, aunque ninguno de estos es compatible entre sí. La mayoría de ellos utilizan un lenguaje de descripción de interfaz (IDL) que define los métodos exportados por el servidor.
1.3.4 CORBA
En computación, CORBA (Common Object Request Broker Architecture — arquitectura común de intermediarios en peticiones a objetos), es un estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos.
CORBA fue definido y está controlado por el Object Management Group (OMG) que define las APIs, el protocolo de comunicaciones y los mecanismos necesarios para permitir la interoperabilidad entre diferentes aplicaciones escritas en diferentes lenguajes y ejecutadas en diferentes plataformas, lo que es fundamental en computación distribuida.
En un sentido general, CORBA "envuelve" el código escrito en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos. Los objetos que resultan, pueden entonces ser invocados desde otro programa (u objeto CORBA) desde la red. En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras, pero con más información.
CORBA utiliza un lenguaje de definición de interfaces (IDL) para especificar las interfaces con los servicios que los objetos ofrecerán. CORBA puede especificar a partir de este IDL, la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Implementaciones estándar existen para Ada, C, C++, Smalltalk, Java, Python, Perl y Tcl.
Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). El código del cliente sirve para poder realizar las llamadas a métodos remotos. Es el conocido como stub, el cual incluye un proxy (representante) del objeto remoto en el lado del cliente. El código generado para el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que rellenar para implementar los métodos del objeto.
CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones. Y así este no es un sistema operativo en si, en realidad es un middleware.
CORBA es una tecnología que oculta la programación a bajo nivel de aplicaciones distribuidas, de tal forma que el programador no se tiene que ocupar de tratar con sockets, flujos de datos, paquetes, sesiones etc. CORBA oculta todos estos detalles de bajo nivel. No obstante CORBA también brinda al programador una tecnología orientada objetos, las funciones y los datos se agrupan en objetos, estos objetos pueden estar en diferentes máquinas, pero el programador accederá a ellos a través de funciones normales dentro de su programa.
Veamos un ejemplo:
...
GNOME_Evolution_Calendar_Cal__setMode (object, MODE_LOCAL, &ev);
...
Esta función ejecutaría el método setMode sobre el objeto object, para el programador esta llamada es como una operación local, no hay más complejidad.
Los métodos y datos CORBA se agrupan formando lo que se demoninan interfaces, los interfaces pueden ser interpretados como objetos que grupan datos y métodos para acceder a estos. Todos estos interfaces se definen usado un lenguaje IDL (Interface Definition Language), que es precisamente esto, un lenguaje para la definición de interfaces. Este lenguaje es estandar y lo soportan todas las implementaciones CORBA.
1.4 OPTIMIZACIÓN DE PREGUNTAS Y TRANSACCIONES
El propósito es seleccionar el mejor camino de acceso para una consulta local.
¿Se estudia el coste de las comunicaciones?
¿Objetivo: la reducción de la cantidad de datos transferidos?
¿Optimización mediante operación de semijoin?
¿Proceso distribuido de consultas utilizando semijoin?
¿Reducción del número de tuplasantes de ser transferidas a otro nodo?
¿Se envía la columna con la que se va a realizar el join de una relación R al nodo donde se encuentra la otra relación, allí se realiza el join con la otra relación S?
Se envían las columnas implicadas en el resultado al nodo inicial y se vuelve a realizar el join con R.??Sólo se transfieren las columnas de R que intervienen en la realización del join en una dirección y el subconjunto de columnas de S resultantes en la otra.
