INSTITUTO TECNOLOGICO SUPERIOR DE ZONGOLICA BASES DE DATOS DISTRIBUIDAS LSC. RAFAEL JUAN CORDOBA DE LA LLAVE

Transcripción

1 INSTITUTO TECNOLOGICO SUPERIOR DE ZONGOLICA BASES DE DATOS DISTRIBUIDAS LSC. RAFAEL JUAN CORDOBA DE LA LLAVE MAYO 2014

2 I N T R O D U C C I O N El mundo moderno se caracteriza por exceso de tecnología. Esta tecnología en muchos casos ha sido creada para administrar mejor múltiples servicios que se imparten a muchas personas. Tenemos el ejemplo de las compañías telefónicas. Antes, existían operadoras telefónicas sentadas todo el día listas para recibir llamadas y darles apoyo. Ahora, todo eso está automatizado. Lo hace la tecnología, sin embargo, una pieza fundamental de la tecnología es que pueden grabar la información en las llamadas bases de datos. Con el tiempo, cada vez es más frecuente que una empresa tenga sucursales y que desde lejos tenga que administrar esa sucursal. Para lograr esto hay varias formas. Una de ellas es la base de datos distribuida, donde la casa matriz tiene bases de datos de la sucursal que está lejos físicamente, es decir, distribuye la información de modo que la sucursal tenga su información particular y la matriz pueda acceder a ella. De la forma en que se configuran estas bases de datos y de la forma en que se estructura es de lo que trata esta materia. P R O P O S I T O Y C O N T E N I D O Esta asignatura aporta al perfil del Ingeniero en Sistemas Computacionales la capacidad para: Administrar proyectos que involucren tecnologías de la información ycomunicaciones en las organizaciones conforme a requerimientos establecidos. Diseñar, desarrollar y mantener sistemas de bases de datos asegurando laintegridad, disponibilidad y confidencialidad de la información almacenada. Desarrollar e implementar sistemas de información para el control y la toma dedecisiones utilizando metodologías basadas en estándares internacionales. Utilizar tecnologías y herramientas actuales y emergentes acordes a las necesidades del entorno. Integrar soluciones que interactúen mediante sistemas de comunicaciones. Para integrarla se ha hecho un análisis de materias tales como Programación II, Fundamentos de Bases de Datos, Taller de Bases de Datos y materias del área de Redes.

3 Esta materia requiere de conocimientos previos abordados en otras materias; se inserta en el octavo semestre. De manera particular, lo trabajado en esta asignatura se aplica en el estudio de los temas: diseño de esquemas de fragmentación y distribución, diccionario de datos de bases de datos distribuidas, consultas distribuidas, transacciones distribuidas y replicación de datos. Para el estudio de esta materia se opto por dividir en cinco unidades donde primero se realizaun acercamiento a los conceptos básicos y necesarios para la comprensión del estudio de base de datos distribuidas, posteriormente se abordan temas para el diseño del esquema de fragmentación, distribución, diccionario de datos, replicación, consultas distribuidas y transacciones distribuidas. En la unidad uno, se estudian los conceptos básicos, los objetivos, disciplinas de estudio y arquitecturas de base de datos distribuidas, con la finalidad que el estudiante pueda comprender la importancia del estudio de las BDD. En la unidad dos, se abordan temas necesarios para el diseño de BDD, tales como consideraciones y niveles de transparencia, posteriormente se abordan temas que llevan al diseño de esquemas de fragmentación, así como de esquemas de distribución necesarios para la elaboración de un diccionario de datos para BDD. La unidad tres, se centra en el estudio del procesamiento de consultas distribuidas, dondese conocen temas sobre metodologías, estrategias y optimización de consultas distribuidas. La unidad cuatro, aborda temas exclusivos de transacciones de base de datos, control de concurrencia y confiabilidad, con la finalidad de mantener la integridad yconfiabilidad de los datos. En la unidad cinco, se incluyen temas de Arquitectura de Sistemas Distribuidos, entre ellas SOA,.Net

4 Es de vital importancia que el profesor, oriente al estudiante de tal manera que éste no solo tenga las bases para diseñar y administrar una base de datos distribuidas, sino que lo lleve a casos reales, donde, con lo ayuda de un Sistema Administrador de Bases de Datos pueda realmente implementar un esquema de distribución de base de datos distribuidas y administrarlo, programando e implementando réplicas, transacciones y consultas distribuidas. También es importante que el estudiante desarrolle e implemente un sistema integral que administre e incluya la base de datos distribuida. O B J E T I V O Aplicar técnicas de diseño de bases de datos que permitan diseñar y desarrollar soluciones de software basadas en arquitecturas y bases de datos distribuidas. COMPETENCIAS PREVIAS Y RELACION CON CURSOS ANTERIORES Y POSTERIORES Competencias previas: Identificar y aplicar distintos Sistemas Administradores de Bases de Datos, así como sus herramientas. Aplicar el entorno operativo del Sistema Administrador de Bases de Datos, para crear el esquema de una Base de Datos. Aplicar esquema de integridad, seguridad y recuperación. Su relación con cursos anteriores: - Programación II, - Fundamentos de Bases de Datos - Taller de Bases de Datos - Materias del área de Redes. Su relación con cursos posteriores, no tiene debido a que esta materia se cursa en 8vo. Semestre.

5 CONTENIDO Unidad Temas Subtemas 1 Fundamentos de Bases de Datos Distribuidas 1.1 Conceptos básicos 1.2 Objetivos de las B.D.D. 1.3 Disciplinas de estudio. 1.4 Arquitectura de Bases 2 Diseño de Bases de Datos Distribuidas 3 Procesamiento de consultas distribuidas de Datos Distribuidas 2.1 Consideraciones de diseño de Bases de Datos Distribuidas. 2.2 Niveles de transparencia. 2.3 Fragmentación de datos. 2.4 Distribución de datos. 2.5 Diccionario de Datos Metodología del procesamiento de consultas distribuidas Estrategias de procesamiento de consultas distribuidas Optimización de consultas 4 Manejo de Transacciones 4.1 Transacciones. 4.2 Control de concurrencia. 4.3 Confiabilidad 5 Arquitecturas de Sistemas Distribuidos 5.1 Arquitectura SOA 5.2 Arquitectura de la plataforma.net 5.3 Aplicaciones distribuidas RMI 5.4 CORBA COMPETENCIAS A ALCANZAR EN EL CURSO Al término del curso el participante logrará las siguientes competencias: Unidad: I Fundamentos de Bases de Datos Distribuidas Identificar la arquitectura de los sistemas de bases de datos distribuidos, niveles de abstracción y lenguajes para definir arquitecturas de un sistema de gestión de bases de

6 datos. Unidad II:Diseño de Bases de Datos Distribuidas Aplicar el diseño de bases de datos distribuidas incluyendo niveles de transparencia y fragmentación de datos e implementar un diccionario de datos para bases de datos distribuidas. Unidad III: Procesamiento de consultas distribuidas Crear estrategias de optimización de procesamiento de consultas distribuidas para la recuperación de datos. Unidad IV: Manejo de Transacciones Administrar transacciones en sistemas distribuidos para garantizar la integridad y seguridad de datos en una BDD. Unidad V: Arquitecturas de Sistemas Distribuidos Instalará las diferentes arquitecturas de los sistemas distribuidos así como implantar las tecnologías de información desarrolladas para la aplicación de las mismas. UNIDAD 1 Fundamentos de Bases de Datos Distribuidas Competencia específica de la unidad: Identificar la arquitectura de los sistemas de bases de datos distribuidos, niveles de abstracción y lenguajes para definir arquitecturas de un sistema de gestión de bases de datos.

7 Contenido temático: Concepto de bases de datos distribuidas Los sistemas de bases de datos multiusuarios están soportados por diversas arquitecturas de sistemas distintos; anteriormente los más comunes eran los sistemas de teleprocesamiento, y conforme los costos de los equipos de cómputo han ido disminuyendo ha sido más factible la utilización de más de una computadora, lo cual ha producido alternativas de bases de datos multiusuarios. Por tal motivo, antes de comenzar a hablar del concepto de bases de datos distribuidas hay que conocer los conceptos relacionados con el esquema cliente-servidor. El esquema cliente-servidor se puede definir, desde el punto de vista funcional, como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información en forma transparente, aún en entornos multiplataforma. Pero antes de empezar a profundizar en el esquema cliente-servidor hay que definir qué es un cliente y qué es un servidor. En términos conceptuales, cliente es aquella entidad en la que se formula un requerimiento y valida los datos indispensables para solicitarlo al servidor; el servidor es una entidad que recibe requerimientos por parte del cliente, los procesa, genera los resultados y los envía al cliente, éste recibe los resultados del servidor y los utiliza para mostrarlos al usuario para que, a su vez, éste disponga de ellos (ver Figura 1). Figura 1. Esquema cliente-servidor. Para que los clientes y los servidores puedan comunicarse, se requiere una infraestructura de comunicaciones que proporcione los mecanismos básicos de direccionamiento y

8 transporte. La mayoría de los sistemas cliente-servidor actuales se basan en redes locales y, por lo tanto, utilizan protocolos no orientados a conexión, lo cual implica que las aplicaciones deben hacer las verificaciones. La red debe tener características adecuadas de desempeño, confiabilidad, transparencia y administración. Teniendo ya las bases sobre el esquema cliente-servidor, iniciaremos con el concepto de base de datos distribuida. Una 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, es la unión lógica de esas bases de datos. (Date, C. 2001) Al hablar de bases de datos distribuidas nos referimos a la base de datos la cual está distribuida, es decir, la base de datos o una porción de ella está almacenada en varias computadoras. Por lo anterior, podemos definir a una base de datos distribuida (BDD) como 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). Figura 2. Representación general de sistemas de bases de datos distribuidas. Ventajas de las bases de datos distribuidas Autonomía local: Cuando las organizaciones tienen varias localidades, pudiera haber un conjunto de datos para una localidad dada que se use con más frecuencia y quizás exclusivamente. Mejoramiento de la performance: Permitir que cada sitio almacene y mantenga su propia base de datos, facilita el acceso inmediato y eficaz a los datos que se usan con más frecuencia.

9 Mejoramiento de la confiabilidad/disponibilidad: Si un sitio falla, los sitios restantes pueden continuar operando. Si los datos están duplicados en más de un sitio, los datos pueden estar disponibles en otro lugar. Satisfacción de los usuarios: Permitir el control local de los datos que se usan con más frecuencia en un sitio puede mejorar el grado de satisfacción de los usuarios. Acceso compartido: Los usuarios de un sitio pueden acceder a los datos que residen en otros sitios. Desventajas de las bases de datos distribuidas En situaciones de gran cantidad de comunicación entre los sitios, el sobrecosto de las coordinaciones y las tareas de control puede degradar severamente el rendimiento. El procesamiento de las transacciones y la recuperación de datos es más complejo, puede significar un requisito de leer y actualizar datos en los diferentes sitios y en transmitir los mensajes respectivos entre ellos. Después de terminar una transacción, el gestor de BD debe asegurarse que todos los sitios relevantes hayan completado su procesamiento. Características Desde el punto de vista del usuario, un sistema distribuido debe ser idéntico a un sistema no distribuido. Autonomía local: Los sitios distribuidos deben ser autónomos, es decir, que todas las operaciones en un sitio dado se controlan en ese sitio. No dependencia de un sitio central: No debe haber dependencia de un sitio central para obtener un servicio, ya que implicaría cuello de botella. Caída del servicio operación continua: El sistema nunca debería apagarse para que se pueda realizar alguna función, como añadir un nuevo sitio. Independencia respecto de la localización: El usuario desconoce dónde están físicamente los datos. Independencia respecto de la fragmentación: La fragmentación de datos se refiere a la forma en la cual las relaciones se pueden subdividir y distribuir entre los sitios de la red. Reglas básicas de los sistemas de BDD

10 En 1987 uno de los más importantes y conocidos teóricos de las bases de datos relacionales, C. J. Date, propuso 12 objetivos que debían alcanzar los diseñadores en sus BDD junto con sus SGBDD. Con ellas se pretende lograr que, para el usuario, un sistema distribuido (SD) funcione exactamente igual que si no fuera distribuido. Las 12 reglas son las siguientes: 1. Autonomía local: Los nodos de un SD deben ser autónomos en el mayor grado posible, lo que permite una mayor seguridad, control de concurrencia y copias de seguridad. Esto quiere decir que los datos deben ser gestionados localmente, las operaciones son locales y todas las operaciones en un puesto son controladas por ese puesto. 2. Independencia de un sitio central: Cada nodo debe actuar independientemente de un nodo central y del resto de nodos. Cada nodo debe tener las mismas capacidades y ser tratado igual al resto. Por lo tanto, no debe existir ningún sitio maestro central del cual dependa el resto. Esto es así por dos razones fundamentales: o Puede ser un cuello de botella. o Puede ser vulnerable: si éste falla también fallará todo el sistema. 3. Independencia de fallos (operación continua): Un fallo en uno de los nodos no debe afectar al sistema. Tampoco si se añaden nuevos nodos. Así, un SD mejorará las siguientes características. o Fiabilidad (o confiabilidad): probabilidad de que el sistema esté listo y funcionando en cualquier momento dado. o Disponibilidad: probabilidad de que el sistema esté listo y funcionando continuamente a lo largo de un periodo especificado. Podemos decir que nunca debería ser necesario apagar el sistema para realizar tareas como: añadir un sitio, creación dinámica de fragmentos, actualización de versiones, etcétera. 4. Independencia de localización: Para el usuario la localización física de los datos debe ser transparente; no necesita saber dónde está el dato para utilizarlo. 5. Independencia de fragmentación: Los usuarios no necesitan conocer los fragmentos físicos en que está dividida cada colección lógica de datos. 6. Independencia de replicación: A nivel lógico, los usuarios no necesitan tener en cuenta si los datos tienen réplicas o no. La replicación es necesaria por las siguientes razones: o o Un mayor rendimiento, puesto que disponemos de copias locales. Una mayor disponibilidad, puesto que los datos son accesibles siempre al tenerse varias copias. La principal desventaja, es que hay que mantener actualizadas todas las copias de ese objeto o dato replicado. Esto nos lleva al problema de la propagación de las actualizaciones. 7. Procesamiento de consultas distribuidas: El SD debe disponer de mecanismos para optimizar las consultas y, en especial, para reducir la carga de tráfico necesaria. Este hecho puede ser considerado como otra razón por la que los sistemas distribuidos siempre son relacionales (las peticiones relacionales son optimizables, mientras que las no relacionales no lo son). 8. Gestión de transacciones distribuidas: El SD debe disponer de mecanismos (protocolos) adecuados para el control de concurrencia y la recuperación de

11 transacciones distribuidas. Una transacción puede acceder y modificar datos en diferentes nodos sin que el usuario se entere de que múltiples sitios se están viendo afectados por la transacción. 9. Independencia del hardware: El SD se debe poder implementar en cualquier plataforma válida, es decir, ordenadores con recursos hardware suficientes. 10. Independencia del sistema operativo: El SD se debe poder implementar en sitios con cualquier sistema operativo multiusuario. 11. Independencia de la red: El SD se debe poder implementar en cualquier red de comunicaciones. 12. Independencia del SGBD: Debe permitirse la heterogeneidad, es decir, que cada sitio pueda funcionar con un SGBD diferente, incluso basado en un modelo de datos diferente, siempre y cuando compartan un interfaz común. En el diseño de una base de datos distribuida podremos optar principalmente por dos tipos de estrategias: la estrategia ascendente y la estrategia descendente. 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 conceptuales 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 descendente. 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. Preguntas de estudio 1. Qué es el esquema cliente-servidor? 2. Qué son las bases de datos distribuidas? 3. Cuáles son las ventajas de las bases de datos distribuidas? UNIDAD 2 Diseño de Bases de Datos Distribuidas Competencia específica de la unidad:

12 Aplicar el diseño de bases de datos distribuidas incluyendo niveles de transparencia y fragmentación de datos e implementar un diccionario de datos para bases de datos distribuidas. Contenido temático: El diseño de las bases de datos distribuidas está basado en la manera de cómo se particiona la información. El analista de sistemas debe conocer a fondo los datos de todos los departamentos de la empresa y según eso, se particionarán los datos en diferentes bases de datos. Esta manera de organizar la información se llama fragmentación. Esto aplica en empresas grandes donde se trabaja con una casa matriz y sus sucursales. La fragmentación es el proceso encargado de dividir una relación en otras subrelaciones de menor tamaño, y su objetivo es encontrar la unidad apropiada de distribución. Existe una serie de razones por las que llevar a cabo la fragmentación: Utilización: En general, las aplicaciones funcionan con vistas que normalmente son subconjuntos de relaciones; por lo tanto, es lógico considerar como unidad de distribución a esos subconjuntos de relaciones. Eficiencia: Los datos se almacenan cerca del lugar en que son utilizados con mayor frecuencia; además, los datos que las aplicaciones locales no necesitan no se almacenan en ese nodo. Paralelismo: La descomposición de una relación en fragmentos permite que una transacción pueda ser dividida en subconsultas; cada subconsulta operará sobre el fragmento adecuado. En definitiva, se aumenta el grado de concurrencia. Seguridad: Los datos no requeridos por las aplicaciones locales no se almacenan en ese nodo, por lo que no están disponibles para los usuarios no autorizados. La fragmentación también tiene inconvenientes, los cuales son los siguientes: Rendimiento: El rendimiento de las aplicaciones globales, cuyas vistas están definidas sobre más de un fragmento y que, además, dichos fragmentos pueden estar ubicados en distintos nodos, puede degradarse debido a que habrá que recuperar dichos fragmentos y aplicar operaciones de unión sobre los mismos para satisfacer la consulta que lanzó la aplicación global. Integridad: Como resultado de la fragmentación los atributos implicados en una dependencia se descomponen en diferentes fragmentos, los cuales pueden destinarse a

13 nodos distintos. Debido a ello el control de integridad puede ser más difícil, pues puede que haya que buscar datos en varios nodos. Cuando se va a fragmentar una base de datos debe pensarse seriamente el grado de fragmentación que se va a alcanzar, ya que éste será un factor que influirá notablemente en el desarrollo de la ejecución de las consultas. El grado de fragmentación puede variar desde una ausencia de la división, considerando a las relaciones unidades de fragmentación; o bien, fragmentar a un grado en el que cada tupla o atributo forme un fragmento. 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. Reglas de corrección de la fragmentación Las tres reglas que han de cumplirse durante el proceso de fragmentación son las siguientes: 1. Completitud: Si una relación R se descompone en una serie de fragmentos Ri, cada elemento de datos que aparezca en R debe aparecer al menos en un fragmento Ri. Con esta regla aseguramos que no haya pérdida de datos durante la fragmentación. 2. Reconstrucción: Debe ser posible definir una operación relacional que permita reconstruir la relación R a partir de los fragmentos Ri. Esta regla garantiza que se preserven las dependencias funcionales. 3. Disyunción: Si un elemento de datos aparece en un fragmento Ri, entonces no debe aparecer en ningún otro fragmento. Existe una excepción a esta regla, que es la fragmentación vertical. Con este tipo de fragmentación los atributos que forman parte de la clave primaria tienen que repetirse en todos los fragmentos verticales para permitir la reconstrucción de la relación. Esta regla garantiza una redundancia mínima de los datos. Antes de decidir cómo distribuir los datos, hay que determinar las unidades lógicas de las bases de datos que se van a distribuir; las unidades lógicas de la base de datos son las relaciones, es decir, cada relación completa se almacenará en un sitio específico. Tipos de fragmentación Existen tres tipos de fragmentación: vertical, horizontal y mixta. Los dos primeros son los principales y todos cumplen las reglas de corrección de la fragmentación. Fragmentación horizontal

14 Un fragmento horizontal de una relación es un subconjunto de las tuplas de la relación. Las tuplas que pertenecen al fragmento horizontal se especifican mediante una condición sobre uno o más de los atributos de la relación, normalmente sólo interviene un atributo. La fragmentación horizontal divide la relación horizontalmente agrupando filas para crear subconjuntos de tuplas, donde cada subconjunto tiene cierto significado lógico y éstos pueden asignarse a diferentes sitios en el sistema distribuido. Existen dos variantes de fragmentación horizontal: Primaria: Se define como una operación de selección (σ) sobre una relación del esquema de la base de datos: Dada una relación R, un fragmento horizontal primario sería σpredicado (R). Derivada: Intuitivamente este tipo de fragmentación consiste en dividir una relación R en subconjuntos de tuplas a partir de otra relación ya fragmentada P; además, R hace referencia a P mediante una clave ajena. Formalmente, dada una relación hija R y otra padre S, la fragmentación derivada de R se define como R f Si (operación de semicombinación), y donde f es el atributo de combinación, y Si es un fragmento de S. Fragmentación horizontal, se puede representar en álgebra relacional con σci(r), en donde R es una relación. El conjunto de fragmentos horizontales cuyas condiciones C1, C2..., Cn incluye todas las tuplas de R y se denomina fragmentación horizontal completa de R. Fragmentación vertical La fragmentación vertical divide una relación verticalmente en columnas. Un fragmento vertical de una relación mantiene sólo ciertos atributos de la relación. En la fragmentación vertical es necesario incluir el atributo de clave primaria o clave candidata en todo fragmento vertical para que sea posible reconstruir la relación completa a partir de los fragmentos. Un fragmento vertical de una relación R puede especificarse con una operación ПLi(R) del álgebra relacional; al conjunto de fragmentos verticales cuyas lista de proyección L1, L2..., Ln incluye todos los atributos de R pero sólo comparten el atributo clave primaria de R, se le llama fragmentación vertical completa de R. 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 relaciones enteras pero

15 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 (considerándola ahora una unidad de distribució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. Inconvenientes de la fragmentación Si las aplicaciones tienen requisitos tales que prevengan 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 lo tanto, puede ser necesario recuperar los datos de dos fragmentos y llevar a cabo sobre ellos operación de unión y yunto, lo 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. Réplica de datos La replicación es útil para mejorar la disponibilidad de los datos. La réplica de datos ocurre si el sistema mantiene copias de una relación R en dos o más sitios. Si se guarda una réplica en cada sitio, se tiene una réplica completa, también mejora el rendimiento de la recuperación en globales, porque el resultado de la consulta se puede obtener localmente en cualquier sitio. Ventajas de la réplica de datos Mejor desempeño: Si la réplica es completa, las aplicaciones pueden operar sobre copias locales en vez de tener que comunicarse con sitios remotos, minimizando el tráfico de datos.

16 Disponibilidad: Si se produce un fallo en un sitio, es posible que los demás sitios puedan seguir trabajando. Una transacción que requiere un dato específico puede encontrarlo en más de una localidad. Desventajas de la réplica de datos Hay que propagar las actualizaciones. Se puede reducir drásticamente la rapidez de las operaciones de actualizaciones. Tipos de sistemas de bases de datos distribuidas El primer factor a considerar es el grado de homogeneidad del software de SGBDD. Si todos los servidores utilizan software idéntico y todos los usuarios también, se habla de que el SGBDD es homogéneo; en el caso contrario se denomina heterogéneo. Continuando con el término homogeneidad, otro factor relacionado es el grado de autonomía local, el cual se refiere a permitir a las transacciones locales acceso libre a un servidor. Los sistemas homogéneos son más fáciles de diseñar y gestionar. Este enfoque proporciona crecimiento incremental, siendo más fácil añadir nuevas localizaciones al SGBDD, y permitiendo mejorar el funcionamiento explotando la capacidad de procesamiento paralelo en varias localizaciones. Los sistemas heterogéneos normalmente aparecen cuando localizaciones individuales han implementado sus propias bases de datos y la integración de éstas es muy costosa; un ejemplo de éste es el SGBDD federado o sistema de múltiples bases de datos, donde cada servidor es un SGBD centralizado independiente y autónomo que tiene sus propios usuarios locales, transacciones locales y ABD, y por lo tanto tiene alto grado de autonomía local. El término sistema de bases datos federadas (SBDF) se utiliza cuando hay algún esquema o vista global de la federación de bases de datos que es compartido por las aplicaciones. Un sistema de bases de datos federadas es una colección de sistemas de bases de datos cooperativos y autónomos. En un sistema federado los usuarios tienen acceso a los datos, de los distintos sistemas, a través de una interfaz común; sin embargo, no existe un esquema global que describa a todos los datos de las distintas bases de datos, en su lugar hay varios esquemas unificados, cada uno describiendo porciones de bases de datos y archivos para el uso de cierta clase de usuarios. Un sistema múltiple de bases de datos no tiene esquema global e interactivamente construye uno según la aplicación lo necesite. Los dos sistemas son un híbrido entre sistemas centralizados y distribuidos, por lo cual ambos son SBDF en un sentido genérico.

17 UNIDAD 3 Procesamiento de consultas distribuidas Competencia específica de la unidad: Crear estrategias de optimización de procesamiento de consultas distribuidas para la recuperación de datos. Contenido temático: En esta sección se analizará cómo un SGBDD procesa y optimiza una consulta, comenzando con los costos de comunicación; al hablar de costos de comunicación nos referimos al costo de transferir datos por la red. El objetivo de los SGBDD es optimizar las consultas, considerando el objetivo de reducir la cantidad de transferencia de datos como criterio de optimación al elegir una estrategia de ejecución de una consulta distribuida. Para comprender este tema se muestra el siguiente ejemplo de consulta distribuida. Ejemplo 1. Se tienen dos relaciones Empleados y Departamento, las cuales no están fragmentadas y tienen las siguientes características. Sitio 1 Empleado. NOM APE BRE INICLLIDO NSSFECHA_ DIRE NCTO CCIÓN SEXOSALA NSS_ RIO SUPERV ND 10,000 registros, cada registro tiene 100 bytes de longitud, el campo NSS tiene 9 bytes de longitud, el campo ND tiene 4 bytes de longitud, el nombre y apellido tiene 15 bytes de longitud cada uno. Sitio 2

18 Departamento. NOMBRE NÚMEROOD NSS_JEFE FECHA_INC_JEFE 10,000 registros, cada registro tiene 35 bytes de longitud, el NÚMEROOD tiene 4 bytes de longitud, el campo NOMBRE tiene 10 bytes de longitud, el NSS_JEFE 9 bytes de longitud. Departamento, reside en el sitio 3. Hay tres estrategias simples para ejecutar esta consulta distribuida. 1. Transferir las relaciones Empleados y Departamento al sitio del resultado, y efectuar la reunión en el sitio 3, por lo que se transferirá un total de 1,000, ,500 = 1,003,500 bytes. 2. Transferir la relación Empleado al sitio 2, ejecutar la reunión en ese sitio y enviar el resultado al sitio 3. El tamaño del resultado de la consulta es 40*10 000= bytes, de modo que debemos transferir = bytes. 3. Transferir la relación Departamento al sitio 1, ejecutar la reunión en ese sitio y enviar el resultado al sitio 3. En este caso tenemos que transferir = bytes. Como el objetivo es minimizar la cantidad de transferencia de datos, deberemos elegir la estrategia 3. Una estrategia más compleja, que muchas veces funciona mejor que las estrategias simples anteriormente mencionadas, es la utilización de semijoins o también llamada semirreunión. El proceso distribuido de consultas utilizando semijoin o semirreunión: Reduce el número de tuplas antes de ser transferidas a otro nodo. 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. 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. Panorama sobre el control de concurrencia y recuperación en base de datos distribuidas

19 Al hablar de control de concurrencia y la recuperación en un entorno de SGBDD, surgen numerosos problemas que no se encuentran en los entornos de SGBD centralizadas El control de concurrencia trata con los problemas de aislamiento y consistencia del procesamiento de transacciones. El control de concurrencia distribuido de una DDBMS asegura que la consistencia de la base de datos se mantiene en un ambiente distribuido multiusuario. Si las transacciones son internamente consistentes, la manera más simple de lograr este objetivo es ejecutar cada transacción sola, una después de otra; sin embargo, esto puede afectar grandemente el desempeño de un DDBMS, dado que el nivel de concurrencia se reduce al mínimo. También podemos definir nivel de concurrencia como el número de transacciones activas, y es uno de los parámetros más importante en los sistemas distribuidos. Por lo tanto, los mecanismos de control de concurrencia buscan encontrar un balance entre el mantenimiento de la consistencia de la base de datos y el mantenimiento de un alto nivel de concurrencia. Si no se hace un adecuado control de concurrencia se pueden presentar dos anomalías: en primer lugar, se pueden perder actualizaciones provocando que los efectos de algunas transacciones no se reflejen en la base de datos; en segundo término, pueden presentarse recuperaciones de información inconsistentes. Existen varios métodos de control de concurrencia para manejar los elementos de los datos replicados en una base de datos distribuida, estos métodos se analizarán en el contexto de extender el bloqueo centralizado, la idea es designar una copia determinada de cada elemento de datos como una copia distinguida. Los bloqueos para los elementos de datos se asocian a la copia distinguida y todas las solicitudes de bloqueo y desbloqueo se envían al sitio que contiene esa copia. Hay varias técnicas diferentes basadas en esa idea, pero difieren de cómo se escogen las copias distinguidas, tales como: Técnica del sitio primario Todas las copias distinguidas se guardan en el mismo sitio. En este método se designa un solo sitio primario como sitio coordinador para todos los elemento de las BD. Técnica del sitio de respaldo Este enfoque busca subsanar la segunda desventaja del método anterior, designando un segundo sitio como sitio de respaldo. Técnica de copia primaria Este método intenta distribuir la carga de la coordinación de los bloqueos entre varios sitios, manteniendo las copias distinguidas de diferentes elementos de datos almacenadas en

20 diferentes sitios. Técnica de sitio coordinador en caso de fallo Siempre que un sitio coordinador falle en cualquiera de las técnicas anteriores, los sitios que siguen activos deberán elegir un nuevo coordinador. Definición de otro autor: Las consultas distribuidas obtienen acceso a datos de varios orígenes de datos heterogéneos. Estos orígenes de datos pueden estar almacenados en el mismo equipo o en equipos diferentes. Microsoft SQL Serveradmite consultas distribuidas utilizando OLE DB. Los usuarios de SQL Server pueden utilizar consultas distribuidas para obtener acceso a lo siguiente: Datos distribuidos almacenados en varias instancias de SQL Server. Datos heterogéneos almacenados en varios orígenes de datos relacionales y no relacionales a los que se obtiene acceso mediante un proveedor OLE DB. Los proveedores OLE DB exponen datos en objetos tabulares denominados conjuntos de filas. SQL Server permite hacer referencia a conjuntos de filas desde proveedores OLE DB en instrucciones Transact-SQL como si fuesen tablas de SQL Server. En las instrucciones SELECT, INSERT, UPDATE y DELETE de Transact-SQL, se puede hacer referencia directa a las tablas y vistas de orígenes de datos externos. Puesto que las consultas distribuidas usan OLE DB como interfaz subyacente, éstas tienen acceso a los sistemas DBMS relacionales tradicionales con procesadores de consultas SQL, así como a los datos administrados por orígenes de datos de diversa capacidad y sofisticación. Siempre que el software propietario de los datos los exponga en un conjunto de filas tabular a través del proveedor OLE DB, los datos se podrán usar en consultas distribuidas. Nota Usar consultas distribuidas en SQL Server es similar a la funcionalidad de tablas vinculadas a través de ODBC. Esta funcionalidad, que ofrecía antes Microsoft Access, se ha incorporado ahora a SQL Server utilizando OLE DB como interfaz a los datos externos. La siguiente ilustración muestra las conexiones entre un equipo cliente, una instancia de SQL Server y un proveedor OLE DB.