BENEMÉRITA UNIVERSIDAD AUTÓNOMA DE PUEBLA TESIS LICENCIADO EN CIENCIAS DE LA COMPUTACIÓN NOÉ NARANJO LÓPEZ FACULTAD DE CIENCIAS DE LA COMPUTACIÓN

Transcripción

1 BENEMÉRITA UNIVERSIDAD AUTÓNOMA DE PUEBLA FACULTAD DE CIENCIAS DE LA COMPUTACIÓN ASPECTOS FUNDAMENTALES DE LA ADMINISTRACIÓN DE REPLICAS EN SQL SERVER 2000 TESIS PARA OBTENER EL TITULO DE: LICENCIADO EN CIENCIAS DE LA COMPUTACIÓN PRESENTA: NOÉ NARANJO LÓPEZ ASESOR: MARÍA DEL ROCÍO BOONE ROJAS PUEBLA PUE. NOVIEMBRE 2002

2 Índice Introducción Capitulo 1 PRINCIPALES PROBLEMAS EN EL DISEÑO DE BASES DE DATOS DISTRIBUIDAS Definición de Bases de Datos Distribuidas Diseño de Bases de Datos Distribuidas Diseño de la Distribución La fragmentación Tipos de fragmentación Alternativas de asignación Manejo de transacciones distribuidas Procesamiento de consultas en bases de datos distribuidas Costos de la transferencia de datos en el procesamiento de consultas distribuidas Procesamiento de consultas distribuidas por semirreunión Descomposición de consultas y de actualizaciones Referencias Capitulo 2 MICROSOFT SQL SERVER Microsoft SQL Server Sistemas SQL Server Sistema cliente/servidor Sistema independiente Arquitectura cliente-servidor Características de SQL Server Transacciones Referencias Capitulo 3 DUPLICACIÓN EN MICROSOFT SQL SERVER Duplicación en Microsoft SQL Server Duplicación de Bases de Datos

3 3.3 La Duplicación Planificación de la duplicación en SQL Server Temporización y latencia de los datos duplicados Autonomía del sitio Particiones de datos Coherencia de los datos duplicados Metodologías de distribución Duplicación de mezclas Duplicación de instantáneas Duplicación transaccional Suscripciones actualizables Actualización inmediata Actualización en cola Actualización inmediata con actualización en cola como opción de conmutación 33 por error Duplicación de instantáneas con suscriptores de actualización Duplicación transaccional con suscriptores de actualización Transacciones distribuidas Componente de la duplicación Publicadores Distribuidores Suscriptores Datos de las duplicaciones Artículos Consideraciones de definición de datos Trabajo con la propiedad IDENTITY Publicaciones Suscripción de inserción y de extracción Suscripción de inserción Suscripciones de extracción Agentes de duplicación Agente de instantáneas Agente de lector del registro Agente de distribución Agente de Mezcla Agente de lectura de cola Referencias

4 Capitulo 4 TIPOS DE DUPLICACIÓN Tipos de Duplicación Duplicación instantánea Duplicación transaccional Usos de la duplicación transaccional Cómo funciona la duplicación transaccional Implementación de la duplicación transaccional Duplicación de unos a varios Duplicación de varios a uno Duplicación por la WAN Duplicación de mezcla Usos de la duplicación de mezcla Filtrar datos publicados Filtros de filas Filtros de columnas Filtros dinámicos Referencias Capitulo 5 ESCENARIO DE DUPLICACIÓN Escenario de duplicación Publicador central Publicador central con un distribuidor remoto Republicador Suscriptor central Múltiples publicadores y suscriptores Cómo transformar los datos publicados Cómo publicar base de datos de SQL Server 2000 en Internet Cómo publicar mediante un VPN Cómo publicar mediante Microsoft Proxy Server Cómo publicar mediante FTP Cuestiones relacionadas con la duplicación en un entorno heterogéneo Cómo publicar datos en bases de datos que no sean de SQL Server Cómo publicar datos que no son de SQL Server 2000 en SQL Server

5 Referencias Capitulo 6 CONFIGURACIÓN DE LA DUPLICACIÓN EN SQL SERVER Asistente Comprensión de las cuestiones relacionadas con la seguridad Configuración de sus servidores Registro del servidor Instalación de la duplicación Instalación del servidor de distribución Creación de una publicación Creación de una suscripción Sincronización manual Cómo comprobar la sincronización inicial Cómo probar la duplicación Consideraciones sobre la duplicación Cuestiones relacionadas con la duplicación Cuestiones relacionadas con los suscriptores Cuestiones relacionadas con el rendimiento Cómo mantener la duplicación Uso del monitor de duplicación Administración del servidor de distribución Secuencias de comandos de duplicación Referencias Conclusiones Bibliografías y referencias Anexo A Requisitos para instalar Microsoft SQL Server

6 INTRODUCCION El diseño de base de datos es el proceso por el que se determina la organización de una base de datos, incluidos sus estructuras, contenido y las aplicaciones por desarrollar. Durante mucho tiempo, el diseño de base de datos fue considerado una tarea para expertos: más un arte que una ciencia. La base de datos son componentes esenciales de los sistemas de información, de los supercomputadoras intercomunicados hasta los computadores medianos o pequeños. A finales de las décadas de los 60 s, cuando las base de datos entraron por primera vez en el mercado de software, los diseñadores de base de datos actuaban como artesanos, con herramientas muy primitivas: diagramas de bloques y estructuras de registros, eran los formatos comunes para las especificaciones, y el diseño de bases de datos se confundía frecuentemente con la implementación de la base de datos. Estas situaciones ahora han cambiado los métodos y modelos de diseño de base de datos han evolucionado paralelamente con el progreso de la tecnología en los sistemas de base de datos. Se ha entrado en la era de los sistemas relaciones de base de datos, que ofrecen poderosos lenguajes de consulta, herramientas para el desarrollo de aplicaciones e interfaces amables con los usuarios. La tecnología de base de datos cuanta ya con un marco teórico, que incluye la teoría relacional de datos, procedimiento y optimización de consultas, control de comunicación, gestión de transacciones, recuperación. Según ha avanzado la tecnología de bases de datos, así se han desarrollado las metodología y técnicas de diseño. Desafortunadamente, las metodologías de diseño de base de datos no son muy populares; La mayoría de las organizaciones y de los diseñadores individuales confía muy poco en las metodologías para llevar el diseño y esto se considera con frecuencia, una de las principales causas de fracaso en el desarrollo de los sistema de información. En el Diseño de una base de dato distribuida, resulta bastante frecuente dividir cada relación en subrelaciones menores denominadas fragmentos que luego se ubican en uno u otro sitio. De ahí que el proceso del diseño de la distribución conste de dos actividades fundamentales: La fragmentación Y La asignación. Cuando una serie de datos se asignan, éstos pueden duplicarse para mantener una copia. Las razones para la réplica giran en torno a la seguridad y a la eficiencia de las consultas de lectura. En caso de réplica, podemos considerar una base de datos totalmente replicada, donde existe una copia de todo el banco de datos en cada sitio, o considerar una base de datos parcialmente replicada donde existan copias de los fragmentos ubicados en diferentes sitios. El presente trabajo se ha desarrollado dentro del Programa de Diplomado en Computación de la FCC. Cómo objetivo general se ha establecido documentar y analizar los aspectos fundamentales de la Administración de réplicas en SQL Server Cómo objetivo particular se ha planteado abordar las Técnicas de replicación que ofrece Microsoft SQL Server 2000: Instantánea, Transaccional y de Mezcla; así como los diferentes escenarios que se pueden presentar al 1

7 manejar réplicas y la configuración de SQL Server 2000 para trabajar con réplicas. Se utiliza en forma uniforme réplica o duplicación que se utilizará indistintamente. Cabe mencionar que el presente trabajo de Tesis forma parte del proyecto de Investigación Administración de réplicas en DDBMS comerciales bajo la dirección de la Profesora Maria del Rocío Boone Rojas, y que existe un trabajo de tesis relacionado de Odilón Corona Valencia. El presente reporte, está organizado en seis capítulos. En el primer capítulo se hace un breve análisis sobre el diseño de bases de datos distribuidas. El problema del diseño de bases de datos distribuidas podría enfocarse en aquellos en el que no existe compartición. Cuando se aborda el diseño de una base de datos distribuidas se opta por dos tipos de estrategias: la estrategia ascendente y la estrategia descendente. Para la estrategia ascendente podría aplicarse en aquel caso donde haya que proceder a un diseño a partir de un número de pequeñas base de datos existentes con el fin de integrarse en una sola. La estrategia descendente debería resultar familiar a la persona que posee conocimiento sobre el diseño de base de datos, exceptuando la fase del diseño de distribución. En un sistema de Base de Datos centralizado, todos los componentes del sistema residen en uno solo computador o sitio: los componentes consisten en los datos, el software del DDBMS y los dispositivos de almacenamiento secundario asociados, como discos para el almacenamiento en línea de la base de datos y cintas parta las copias de seguridad. El diseño de las vistas trata de definir las interfaces para el usuario final y, por otro lado, el diseño conceptual se encarga de examinar la empresa para determinar los tipos de entidades y establecer la relación entre ellas. Existe un vínculo entre el diseño de las vistas y el diseño conceptual. El diseño conceptual puede interpretarse como la integración de las vistas del usuario, este aspecto es de vital importancia ya que el modelo conceptual debería soportar no sólo las aplicaciones existentes, sino que debería estar preparado para futuras aplicaciones. El diseño conceptual y de las vistas del usuario se especificarán las entidades de datos y se determinarán las aplicaciones que funcionarán sobre la base de datos, así mismo, se recopilarán datos estadísticos o estimaciones sobre la actividad de estas aplicaciones. Dichas estimaciones deberían girar en torno a la frecuencia de acceso, por parte de una aplicación, a las distintas relaciones de las que hace uso, podría afirmarse más anotando los atributos de la relación a la que accede. El objetivo de esta etapa consiste en diseñar los esquema conceptuales locales que se distribuirán a lo largo de todos los puestos del sistema distribuido. Sería posible tratar cada entidad como una unidad de distribución; en el caso del modelo relacional, cada entidad se corresponde con una relación. Resulta bastante frecuente dividir cada relación en subrelaciones menores denominadas fragmentos que luego se ubican en uno u otro sitio. De ahí que el proceso del 2

8 diseño de la distribución conste de dos actividades fundamentales: La fragmentación Y La asignación. El último paso del diseño de la distribución es el diseño físico, el cual proyecta los esquema conceptuales locales sobre los dispositivos de almacenamiento físico disponibles en los distintos sitios. Las entradas para este paso son los esquemas conceptuales locales y la información de acceso a los fragmentos. En el segundo Capítulo sobre Microsoft SQL Server Microsoft SQL Server 2000 han incluido muchos nuevas características y muchos aspectos han sido simplificados y optimizados para proporcionar un mejor rendimiento, la posibilidad de integración con Internet permite realizar comercio electrónico a través de esta vía y construir sitios a precio-calidad al reducir la carga de administración y disminuir el costo total de posesión con un diseño orientado hacia la configuración dinámica. Lo más interesante de SQL Server es la única base de datos diseñada para funcionar en un entorno de computación distribuida y puede beneficiarse de muchas de las oportunidades inherentes a la plataforma PC, de una forma que otras base de datos no pueden. El modelo Cliente-Servidor es de dos niveles lo que significa que hay dos computadoras implicadas un cliente y un servidor. En los sistemas clienteservidor, el servidor es un equipo relativamente grande situado en una ubicación central que administra recursos utilizados por varios individuos. Cuando los individuos tienen que utilizar un recurso, se conectan con el servidor desde sus equipos, o cliente a través de la red. En la arquitectura cliente-servidor de las bases de datos, los archivos de la base de datos y software DBMS residen en el servidor. Los cuales proporcionan componentes de comunicaciones para que las aplicaciones se puedan ejecutar en equipos cliente y se comuniquen con el servidor de bases de datos a través de la red. Las aplicaciones del servidor suelen poder trabajar con varios clientes al mismo tiempo. SQL Server puede operar con miles de aplicaciones cliente simultáneas. El servidor tiene funciones que impiden que se produzcan problemas de lógica si un usuario intenta leer o modificar los datos actualmente utilizados por otros usuarios. SQL Server ha sido diseñado como servidor para redes cliente-servidor, también puede funcionar directamente como base de datos independiente en el cliente SQL Server es capaz de operar de manera eficiente en un sistema de un solo usuario en una sobrecarga administrativa mínima. En el tercer capítulo se lleva a cabo la Duplicación en Microsoft SQL Server La duplicación es una potente funcionalidad de SQL Server que se puede utilizar en muy diversas situaciones de la empresa. Las compañías pueden utilizarlas para cualquier cosa, desde la realización de informes de consolidados hasta liberar al servidor principal de las tareas de realización de consultas e informes. 3

9 La Replicación es la mejor solución para trasladar datos de un servidor a otro de una manera rápida y eficiente. La duplicación en SQL Server proporciona varias ventajas: La primera de ellas es que los datos pueden suministrase a diferentes ubicaciones, con el fin de eliminar tráfico de red y la carga innecesaria sufrida por un único servidor. Por ejemplo se puede traspasar toda o parte de la información de una base de datos que procesa transacciones en línea a un servidor diferente que permita la generación de informe. Otra ventaja es que los datos se pueden pasar de un servidor a varios servidores, lo que proporciona una alta disponibilidad y descentralización de los datos. En este caso, se podría crear un espejo de la base de datos principal en otro servidor, de modo que, si el servidor principal se detuviera, los usuarios podrían conmutar al otro. Este escenario también permitiría a sitios diferentes operar de forma independiente entre sí. Se analiza sus componentes los cuales son publicadores, distribuidores y suscriptores. También sobre los cincos agentes de duplicación los cuales permiten trasladar los datos duplicados. En el cuarto capítulo se ven lostipos de duplicación. Se estudia los tres tipos como son duplicación instantánea, transaccional y de mezcla. Duplicación de Instantánea. Una copia completa de la publicación se envía a todos los suscriptores, lo que incluye tantos los datos modificados como los no modificados. Duplicación Transaccional. Los cambios se hacen sólo en la ubicación de origen y se envían a los suscriptores, puesto que los cambios sólo de efectúan en un sitio, no se produce conflictos. Duplicación de Mezcla. Todos los sitios hacen cambios en los datos locales de forma independiente y luego actualizan el publicador. En el quinto capítulo se ve los tipos de escenario que existe. SQL Server cuenta con vario tipo de escenario como son: Publicador central, Publicador central con un distribuidor remoto, Republicador, Suscriptor central, Múltiples publicadores y suscriptores. Los cuales se basan en los publicadores, distribuidores y suscriptores ya que son los que hacen posibles las transacciones de un servidor a otros. En el sexto capítulo se lleva a cabo con el asistenta la creación de la configuración de la duplicación en SQL Server Se lleva a cabo con el asistente la creación de los servidores, permite crear una publicación y crear una suscripción, los cuales cada uno de ellos presentan varios pasos para poder implementar la duplicación. CAPITULO 1 4

10 En el presente capítulo se presentan los aspectos fundamentales del Diseño de una Base de Datos Distribuidas: la fragmentación y la asignación. Relacionado con estos aspectos se introduce el concepto de Réplicas y se presenta una introducción a los problemas que plantea el procesamiento de consultas en un medio ambiente distribuido Definición de Bases de Datos Distribuidas Una Base de Datos Distribuida es una base de datos construida sobre una red computacional y no por el contrario en una máquina aislada. La información que constituye la base de datos esta almacenada en diferentes sitios en la red, y las aplicaciones que se ejecutan accesan datos en distintos sitios. Una Base de Datos Distribuida entonces es una colección de datos que pertenecen lógicamente a un sólo sistema, pero se encuentra físicamente esparcido en varios "sitios" de la red. Un sistema de base de datos distribuidas se compone de un conjunto de sitios, conectados entre sí mediante algún tipo de red de comunicaciones, en el cual: Cada sitio es un sistema de base de datos en sí mismo. Los sitios han convenido en trabajar juntos (si es necesario) con el fin de que un usuario de cualquier sitio pueda obtener acceso a los datos de cualquier punto de la red tal como si todos los datos estuvieran almacenados en el sitio propio del usuario. En consecuencia, la llamada base de datos distribuida es en realidad una especie de objeto virtual, cuyas partes componentes se almacenan físicamente en varias bases de datos reales distintas ubicadas en diferentes sitios. De hecho, es la unión lógica de esas bases de datos. En otras palabras, cada sitio tiene sus propias bases de datos reales locales, sus propios usuarios locales, sus propios DBMS y programas para la administración de transacciones (incluyendo programas de bloqueo, bitácoras, recuperación, etc), y su propio administrador local de comunicación de datos (administrador DC). En particular un usuario dado puede realizar operaciones sobre los datos en su propio sitio local exactamente como si ese sitio no participara en absoluto en el sistema distribuido (al menos, ése es uno de los objetivos). Así pues, el sistema de bases de datos distribuidas puede considerarse como una especie de sociedad entre los DBMS individuales locales de todos los sitios. Un nuevo componente de software en cada sitio (en el aspecto lógico, una extensión del DBMS local) realiza las funciones de sociedad necesarias; y es la combinación de este nuevo componente y el DBMS ya existente lo que constituye el llamado sistema de administración de bases de datos distribuidas (DDBMS, distributed database management system). Entre las ventajas proporcionadas por los DDBMS encontramos las siguientes: 5

11 La naturaleza distribuida de algunas aplicaciones de base de datos. Muchas de estas aplicaciones están distribuidas naturalmente en diferentes lugares. Por ejemplo, una compañía puede tener oficinas en varias ciudades, o un banco puede tener múltiples sucursales. Es natural que las bases de datos empleadas en tales aplicaciones estén distribuidas en esos lugares. Muchos usuarios locales tienen acceso exclusivamente a los datos que están en el lugar, pero otros usuarios globales - como la oficina central de la compañía- pueden requerir acceso ocasional a los datos almacenados en varios de estos lugares. Cabe señalar que, por lo regular, los datos en cada sitio local describen un minimundo en ese sitio. Las fuentes de los datos y la mayoría de los usuarios y aplicaciones de la base de datos local residen físicamente en ese lugar. Mayor fiabilidad y disponibilidad. Estas son dos de las ventajas potenciales de las bases de datos distribuidas que se citan comúnmente. La fiabilidad se define a grandes rasgos como la probabilidad de que un sistema esté en funciones en un momento determinado, y la disponibilidad es la probabilidad de que el sistema esté disponible continuamente durante un intervalo de tiempo. Cuando los datos y el software del DBMS están distribuidos en varios sitios, un sitio puede fallar mientras que los demás siguen operando. Solo los datos y el software que residen en el sitio que falló están inaccesibles. En un sistema centralizado, el fallo de un solo sitio hace que el sistema completo deje de estar disponible para todos los usuarios. Posibilidad de compartir los datos al tiempo que se mantiene un cierto grado de control local. En algunos tipos de DDBMS es posible controlar los datos y el software localmente en cada sitio. Sin embargo, los usuarios de otros sitios remotos pueden tener acceso de ciertos datos a través del software del DBMS. Esto hace posible el comportamiento controlado de los datos en todo el sistema distribuido. Mejor rendimiento. Cuando una base de datos está distribuida en múltiples sitios, hay base de datos más pequeña en cada uno de éstos. En consecuencia las consultas locales y las transacciones que tienen acceso a datos de un sitio tienen un mejor rendimiento porque las bases de datos locales son más pequeñas. Además, cada sitio tiene un menor número de transacciones en ejecución que si todas las transacciones se enviaran a una sola base de datos centralizada. En el caso de las transacciones que impliquen acceso a mas de un sitio, el procesamiento en los diferentes sitios puede efectuarse en paralelo, reduciéndose así el tiempo de respuesta. 1.2 Diseño de Bases de Datos Distribuidas 6

12 El diseño de un sistema de base de datos distribuido implica la toma de decisiones sobre la ubicación de los programas que accederán a la base de datos y sobre los propios datos que constituyen esta última, a lo largo de los diferentes puestos que configuren una red de ordenadores. La ubicación de los programas, a priori, no deberían suponer un excesivo problema dado que se puede tener una copia de ellos en cada maquina de la red. Tradicionalmente se han clasificado la organización de los sistemas de bases de datos distribuidos sobre tres dimensiones: 1) El nivel de compartición, 2) Las características de acceso a los datos, 3) El nivel de conocimiento de las características de acceso (Figura 1.1). Figura 1.1. Enfoque de la distribución 1) El nivel de compartición Presenta tres alternativas: inexistencia, es decir, cada aplicación y sus datos de ejecutan en un ordenador con ausencia total de comunicación con otros programas u otros datos; se comparten solo los datos y no los programas, en tal caso existe una réplica de las aplicaciones en cada maquina y los datos viajan por la red; y se reparten datos y programas, dado un programa ubicado en un determinado sitio, éste puede solicitar un servicio a otro programa localizado en un segundo lugar, el cual podrá acceder a los datos situados en un tercer emplazamiento. En este caso se optará por el punto intermedio de compartición. 2) Las características de acceso a los datos Existen dos alternativas principalmente: El modo de acceso a los datos que solicitan los usuarios puede ser estático, es decir, no cambiará a lo largo del tiempo, o bien, dinámico. El lector podrá comprender fácilmente la dificultad de encontrar sistemas distribuidos reales que puedan clasificarse como estático. Sin embargo, lo realmente importante radica, estableciendo el dinamismo como base, cómo de dinámico es, cuántas variaciones sufren a lo largo del tiempo. Esta 7

13 dimensión establece la relación entre el diseño de bases de datos distribuidas y el procesamiento de consultas. 3) El nivel de conocimiento de las características de acceso Una posibilidad es, evidentemente, que los diseñadores carezcan de información alguna sobre cómo los usuarios acceden a la base de datos. Es una posibilidad teórica, pero sería muy laborioso abordar el diseño de la base de datos con tal ausencia de información. Lo más práctico sería conocer con detenimiento la forma de acceso de los usuarios o, en el caso de su imposibilidad, conformarnos con una información parcial de ésta. El problema del diseño de base de datos distribuidas podría enfocarse a través de esta trama de opciones. En todos los casos, excepto aquel en el que no existe compartición, aparecerán una serie de nuevos problemas que son irrelevantes en el caso centralizado. A la hora de borda el diseño de una base de datos distribuidas podremos optar principalmente por dos tipos de estrategias: a) La estrategia ascendente y b) La estrategia descendente. Ambos tipos no son excluyentes, y no resultaría extraño a la hora de abordar un trabajo real de diseño de una base de datos que se pudiesen emplear en diferentes etapas del proyecto una u otra estrategia. a) La Estrategia ascendente: Podría aplicarse en aquel caso donde haya que proceder a un diseño a partir de un número de pequeñas bases de datos existentes, con el fin de integrarlas en una sola. En este caso se partiría de los esquemas conceptual locales y se trabajaría para llegar a conseguir el esquema conceptual global. Aunque este caso se pueda presentar con facilidad en la vida real, se prefiere pensar en el caso donde se parte de cero y se avanza en el desarrollo del trabajo siguiendo la estrategia descendentes. b) La estrategia descendente: Debería resultar familiar a la persona que posea conocimientos sobre el diseño de bases de datos, exceptuando la fase del diseño de la distribución. Pese a todo, se resumirán brevemente las etapas por las que se transcurre (Figura 1.2). 8

14 Figura 1.2. Estrategia descendente Todo comienza con un análisis de los requisitos que definirán el entorno del sistema en aras a obtener tanto los datos como las necesidades de procesamiento de todos los posibles usuarios del banco de datos. Igualmente se deberán fijar los requisitos del sistema, los objetivos que debe cumplir respecto a unos grados de rendimiento, seguridad, disponibilidad y flexibilidad, sin olvidar el importante aspecto económico. Como puede observarse, los resultados de este último paso sirven de entrada para dos actividades que se realizan de forma paralela. El diseño de las vistas trata de definir las interfaces para el usuario final y, por otro lado, el diseño conceptual se encarga de examinar la empresa para determinar los tipos de entidades y establecer la relación entre ellas. Existe un vínculo entre el diseño de las vistas y el diseño conceptual. El diseño conceptual puede interpretarse como la integración de las vistas del usuario, este aspecto es de vital importancia ya que el modelo conceptual debería soportar no sólo las aplicaciones existentes, sino que debería estar preparado para futuras aplicaciones. El diseño conceptual y de las vistas del usuario se especificarán las entidades de datos y se determinarán las aplicaciones que funcionarán sobre la base de datos, así mismo, se recopilarán datos estadísticos o estimaciones sobre 9

15 la actividad de estas aplicaciones. Dichas estimaciones deberían girar en torno a la frecuencia de acceso, por parte de una aplicación, a las distintas relaciones de las que hace uso, podría afinarse más anotando los atributos de la relación a la que accede. Desarrollado el trabajo hasta aquí, se puede abordar la confección del esquema conceptual global. Este esquema y la información relativa al acceso a los datos sirven de entrada al paso distintivo: el diseño de la distribución. El objetivo de esta etapa consiste en diseñar los esquemas conceptuales locales que se distribuirán a lo largo de todos los puestos del sistema distribuido. Sería posible tratar cada entidad como una unidad de distribución; en el caso del modelo relacional, cada entidad se corresponde con una relación. Resulta bastante frecuente dividir cada relación en subrelaciones menores denominadas fragmentos que luego se ubican en uno u otro sitio. De ahí, que el proceso del diseño de la distribución conste de dos actividades fundamentales: la fragmentación y la asignación. El último paso del diseño de la distribución es el diseño físico, el cual proyecta los esquemas conceptuales locales sobre los dispositivos de almacenamiento físico disponibles en los distintos sitios. Las entradas para este paso son los esquemas conceptuales locales y la información de acceso a los fragmentos Diseño de la Distribución Existen diversas formas de afrontar el problema del diseño de la distribución Las más usuales se muestran en la Figura 1.3. En el primer caso, caso A, los dos procesos fundamentales la Fragmentación y la Asignación, se abordan de forma simultánea. Esta metodología se encuentra en desuso, sustituida por el enfoque en dos fases, caso B: la realización primeramente de la partición para luego asignar los fragmentos generados. El resto de los casos se comentan en la sección referente a los distintos tipos de la fragmentación. Figura 1.3 Enfoques para realizar el diseño distributivo 10

16 1.4 La Fragmentación El principal problema de la fragmentación radica en encontrar la unidad apropiada de distribución. Una relación no es una buena unidad por muchas razones. Primero, las vistas de la aplicación normalmente son subconjuntos de relaciones. Además, la localidad de los accesos de las aplicaciones no está definida sobre la relaciones enteras pero sí sobre subconjuntos de las mismas. Por ello, sería normal considerar como unidad de distribución a estos subconjuntos de relaciones. Segundo, si las aplicaciones tienen vistas definidas sobre una determinada relación que reside en varios sitios de la red, se puede optar por dos alternativas. Por un lado, la relación no estará replicada y se almacena en un único sitio, o existe réplica en todos o algunos de los sitios en los cuales reside la aplicación. Las consecuencias de esta estrategia son la generación de un volumen de accesos remotos innecesario. Además, se pueden realizar réplicas innecesarias que causen problemas en la ejecución de las actualizaciones y puede no ser deseable si el espacio de almacenamiento está limitado. Tercero, la descomposición de una relación en fragmentos, tratados cada uno de ellos como una unidad de distribución, permite el proceso concurrente de las transacciones. También la relación de estas relaciones normalmente, provocará la ejecución paralela de una consulta al dividirla en una serie de subconsultas que operará sobre los fragmentos. Pero la fragmentación también acarrea inconvenientes. Si las aplicaciones tienen requisitos tales que provengan la descomposición de la relación en fragmentos mutuamente exclusivos, estas aplicaciones cuyas vistas estén definidas sobre más de un fragmento pueden sufrir una degradación en el rendimiento. Por tanto, puede ser necesario recuperar los datos de dos fragmentos y llevar a cabo sobre ellos operación de unión y joinn, los cual es costoso. Un segundo problema se refiere al control semántico. Como resultado de la fragmentación los atributos implicados en una dependencia se descomponen en diferentes fragmentos los cuales pueden destinarse a sitios diferentes. En este caso, la sencilla tarea de verificar las dependencias puede resultar una tarea de búsqueda de los datos implicados en un gran número de sitios. 1.5 Tipos de Fragmentación Dado que una relación se corresponde esencialmente con una tabla y la cuestión consiste en dividirla en fragmentos menores, inmediatamente surgen dos alternativas lógicas para llevar a cabo el proceso: la división horizontal y la división vertical. La división o fragmentación horizontal trabaja sobre las tuplas, dividiendo la relación en subrelaciones que contienen un subconjunto de las tuplas que alberga la primera. La fragmentación vertical, en cambio, se basa en los atributos de la relación para efectuar la división. Estos dos tipos de partición podrían considerarse los fundamentales y básicos. Sin embargo, existen otras alternativas. Fundamentalmente, se habla de fragmentación mixta o híbrida cuando el proceso de partición hace uso de los dos tipos anteriores. 11

17 La fragmentación mixta puede llevarse a cabo de tres formas diferentes: desarrollando primero la fragmentación vertical y, posteriormente, aplicando la partición horizontal sobre los fragmentos verticales (denominada partición VH), o aplicando primero una división horizontal para luego, sobre los fragmentos generados, desarrollar una fragmentación vertical (llamada partición HV), o bien, de forma directa considerando la semántica de las transacciones. Otro enfoque distinto y relativamente nuevo, consiste en aplicar sobre una relación, de forma simultánea y no secuencial, la fragmentación horizontal y la fragmentación vertical; en este caso, se generara una rejilla y los fragmentos formaran las celdas de esa rejilla, cada celda será exactamente un fragmento vertical y un fragmento horizontal (nótese que en este caso el grado de fragmentación alcanzado es máximo, y no por ello la descomposición resultará más eficiente). Volviendo a la figura 3.1, puede observarse como los casos C y D se basan en la mencionada generación de la rejilla, con la diferencia que en el primero de ellos se produce una fusión, una desfragmentación de las celdas, agrupándolas de la manera más adecuada para obtener mayor rendimiento, ya que los fragmentos generados son muy pequeños. En el segundo caso se asignan las celdas a los sitios y luego se realiza una rigurosa optimización de cada sitio. El caso E sería aquel en el que se utiliza la fragmentación VH o la fragmentación HV. Fragmentación horizontal. Un fragmento horizontal de una relación es un conjunto de las tuplas de esa relación. Las tuplas que pertenecen al fragmento horizontal se especifica mediante una condición sobre uno o más de los atributos de la relación. Con frecuencia, sólo interviene un atributo. La fragmentación horizontal divide una relación horizontalmente agrupando filas para crear subconjuntos de tuplas, donde cada subconjunto tiene un cierto significado lógico. Estos fragmentos pueden entonces asignarse a diferentes sitios en el sistema distribuido. Fragmentación vertical Recuérdese que la fragmentación vertical de una relación R produce una serie de fragmentos R1, R2,..., Rr, cada uno de los cuales contiene un subconjunto de los atributos de R así como la clave primaria de R. El objetivo de la fragmentación vertical consiste en dividir la relación en un conjunto de relaciones más pequeñas tal que algunas de las aplicaciones de usuario sólo hagan uso de un fragmento. Sobre este marco, una fragmentación óptima es aquella que produce un esquema de división que minimiza el tiempo de ejecución de las aplicaciones que emplean esos fragmentos. Fragmentación Mixta Podemos entremezclar los dos tipos de fragmentación, para obtener una fragmentación mixta. Podemos combinar las fragmentaciones horizontales y 12

18 verticales. Un esquema de fragmentación de una base de datos es una definición de un conjunto de fragmentos que incluyen todos los atributos y tuplas de la base de datos y satisface la condición de que una base de datos completa se puede reconstruir a partir de los fragmentos mediante alguna secuencia de operación UNION EXTERNA y UNION. Un esquema de reparto describe el reparto de fragmentos entre los sitios del SBDD; por tanto, es una correspondencia que especifica el sitio o sitios donde se almacena cada fragmento. Si un fragmento se almacena en más de un sitio, se dice que está replicado. 1.6 Alternativas de Asignación Suponiendo que el banco de datos se haya fragmentado correctamente, habrá que decidir sobre la manera de asignar los fragmentos a los distintos sitios de la red. Cuando una serie de datos se asignan, éstos pueden duplicarse para mantener una copia. Las razones para la réplica giran en torno a la seguridad y a la eficiencia de las consultas de lectura. Si existen muchas reproducciones de un elemento de datos, en caso de fallo en el sistema se podría acceder a esos datos ubicados en sitios distintos. Además, las consultas que acceden a los mismos datos pueden ejecutarse en paralelo, ya que habrá copias en diferentes sitios. Por otra parte, la ejecución de consultas de actualización, de escritura, implicaría la actualización de todas las copias que existan en la red, cuyo proceso puede resultar problemático y complicado. Por tanto, un buen parámetro para afrontar el grado de réplica consistiría en sopesar la cantidad de consultas de lectura que se efectuarán, así como el número de consultas de escritura que se llevará a cabo. En una red donde las consultas que se procesen sean mayoritariamente de lectura, se podría alcanzar un alto grado de réplica, no así en el caso contrario. Una base de datos fragmentada es aquella donde no existe réplica alguna. Los fragmentos se alojan en sitios donde únicamente existe una copia de cada uno de ellos a lo largo de toda la red. En caso de réplica, podemos considerar una base de datos totalmente replicada, donde existe una copia de todo el banco de datos en cada sitio, o considerar una base de datos parcialmente replicada donde existan copias de los fragmentos ubicados en diferentes sitios. 1.7 Manejo de Transacciones Distribuidas 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 varios sitios (en particular puede implicar a 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 determinado sitio. Y el sistema necesita saber cuándo dos agentes son parte de la 13

19 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. La cuestión especifica del control de recuperación; para asegurar, pues 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. En cuanto al control de concurrencia, esta función en un ambiente distribuido estará basada con toda seguridad en el bloqueo, como sucede en los sistemas no distribuidos. 1.8 Procesamiento de Consultas en Bases de Datos Distribuidas Panorama sobre un DDBMS procesa y optimiza una consulta. Primero analizaremos los costos de comunicación del procesamiento de una consulta distribuida; luego examinaremos una operación especial, llamada semirreunion, que sirve para optimizar algunos tipos de consultas en un DDBMS Costos de la transferencia de datos en el procesamiento de consultas distribuidas. En un sistema distribuido varios factores adicionales complican aún más el procesamiento de consultas. El primer es el costo de transferir datos por la red. Estos datos incluyen los archivos intermedios que se transfiere a otro sitios para continuar su procesamiento así como los archivos de resultado final que tal vez deban transferirse al sitio donde se necesita el resultado de la consulta. Aunque es posible que estos costos no sean demasiado altos si los sitios están conectados en una red de área local de alto rendimiento, adquieren una importancia considerable en otros tipos de redes. Por ello, los algoritmos de optimización de consultas de los DDBMS consideran el objetivo de reducir la cantidad de transferencia de datos como criterio de optimización al elegir una estrategia de ejecución de una consulta distribuida Procesamiento de consultas distribuidas por semirreunión Se basa en la idea de reducir el número de tuplas de una relación antes de transferirla a otro sitio. Intuitivamente, la idea es enviar la columna de reunión de una relación R al sitio donde se encuentra la otra relación S; esta columna se reúne entonces con S. Después de ello, los atributos de reunión, junto con los atributos requeridos en el resultado, se extraen por proyección y se devuelve al sitio original donde se reúnen con R. Así pues, sólo se transfiere la columna de reunión de R en una dirección, y un subconjunto de S que no contenga tuplas que no intervengan en el resultado se transfiere en la otra dirección. Si sólo una pequeña fracción de las tuplas de S participan en la reunión, esto puede ser una solución bastante eficiente para minimizar la transferencia de datos. 14

20 1.8.3 Descomposición de consultas y de actualizaciones En un DDBMS sin transparencia de distribución, el usuario expresa su consulta directamente en términos de fragmentos específicos. Por otro lado DDBMS que ofrezca transparencia de distribución, de fragmentación y de replicación completa permitirá el usuario especificar una consulta o solicitud de actualización sobre el esquema igual que si el DDBMS fuera centralizado. En el caso de las actualizaciones, el sistema se encarga de mantener la consistencia entre los elementos replicados usando alguno de los algoritmo de control de concurrencia distribuidas. En el caso de las consultas, un módulo de descomposición de consultas deberá dividir o descomponer una consulta en subconsultas que se puedan ejecutar en los sitio individuales. Deberá generarse una estrategia para combinar los resultados de las subconsultas y formar el resultado de la consulta. Siempre que el DDBMS determine que un elemento al que se hace referencia en la consulta está replicado, deberá escoger o materializar una réplica específica a la que se hará referencia durante la ejecución. Para determinar cuáles réplicas incluyen los elementos de información a los que se hace referencia en una consulta, el DDBMS consulta la información de fragmentación, replicación y distribución almacenada en su catálogo. En la fragmentación vertical, la lista de atributos de cada fragmento se guarda en el catálogo. En la fragmentación horizontal, se guarda una condición se selección que se especifica cuáles tuplas están en el fragmento; se llama guardia porque solo las tuplas que sastifacen esta condición pueden estar almacenadas e el fragmento. En el caso de fragmento mixtos, tanto la lista de atribuios como la condición de guardia de mantienen en el catálogo. Para la descomposición de consultas, el DDBMS puede determinar cuáles fragmentos contienen las tuplas requeridas comparando la condición de la consulta y las condiciones de guardia. Una estrategia alternativa consistiría en enviar la consulta C completa al sitio 1, que contiene todas las tuplas de la base de datos, donde se ejecutaría localmente y desde donde se enviaría el resultado de regreso al sitio 2. El optimizador de consultas estimaría los costos de ambas estrategias y escogería la que tuviera la estimación más baja. Referencias La sección 1.1. Bases de datos distribuidas [Elmasri y Navathe, 1997]. La sección 1.2 Diseño de bases de datos distribuidas [Özsu y Valduriez 1991]. 15