SBD D

Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic.
Julio Ismael Gonzlez Tllez
1.
Fundamentos Bases de Datos Distribuidas
1.1. Conceptos Bsicos

1.2. Objetivos Bases de Datos Distribuidas 1.3. Disciplinas Estudio Bases de Datos Distribuidas 1.4. Arquitectura Bases de Datos Distribuidas 2. Diseo de bases de datos distribuidas 2.1. Consideraciones Diseo Bases de Datos Distribuidas 2.2. Diccionario de Datos 2.3. Niveles de Transparencia 2.3.1.Transparencia de Localizacin 2.3.2.Transparencia de Fragmentacin 2.3.3.Transparencia de Replica 2.4. Fragmentacin de Datos 2.4.1.Fragmentacin Horizontal 2.4.2.Fragmentacin Vertical 2.4.3.Fragmentacin Hibrida 2.5. Distribucin de Datos 2.5.1.Algoritmos Distribucin Datos No Replicados 2.5.2.Algoritmos Distribucin Datos Replicados 3. Procesamiento de consultas distribuidas 3.1. Metodologa Procesamiento Consultas Distribuidas 3.2. Estrategias Procesamiento Consultas Distribuidas 3.2.1.Arboles de Consultas 3.2.2.Transformaciones Equivalentes Consultas Distribuidas 3.2.3.Mtodos Ejecucin del Join 3.3. Optimizacin de Consultas Distribuidas 3.3.1.Optimizacin Global Consultas Distribuidas 3.3.2.Optimizacin Local Consultas Distribuidas 4. Manejo de transacciones 4.1. Transacciones Conceptos 4.1.1.Estructura de Transacciones 4.1.2.Ejecucin Transacciones Centralizada Distribuida 4.1.3.Estructura de transacciones 4.2. Control de Concurrencia 4.2.1.Serializacin de Transacciones 4.2.2.Algoritmos de Control de Concurrencia 4.2.2.1.Basados en Bloqueo. 4.2.2.2.Basados en Estampas de Tiempo 4.2.2.3.Pruebas Validacin Optimistas 4.2.3.Disciplinas del Interbloqueo prevencin deteccin eliminacin y recuperacin 4.3. Confiabilidad 4.3.1.Conceptos Bsicos de Confiabilidad 4.3.2.Protocolos Redo Undo 4.3.3.Puntos de Verificacin checkpoints 4.3.4.Protocolo 2PC de Confiabilidad Distribuida
Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic. Julio Ismael Gonzlez Tllez
1 Fundamentos Bases de Datos Distribuidas 1.1Conceptos Bsicos

Un sistema de administracin de bases de datos distribuida (DDBMS) rige el almacenamiento y procesamiento de datos lgicamente relacionados a travs de un sistema de computadoras interconectadas, donde tanto los datos como las funciones de procesamiento se distribuyen entre varios sitios. Para entender cmo y por qu el DDBMS es diferente del DBMS, es necesario examinar brevemente los cambios en el ambiente de base de datos. Durante los aos 70s, las corporaciones ejercieron sistemas de administracin de base de datos centralizados para satisfacer sus necesidades de informacin estructuradas. Las necesidades de informacin estructurada son, por lo tanto, bien atendidas por los sistemas centralizados. Bsicamente, el uso de una base de datos centralizada requera que los datos corporativos se guardaran en un solo sitio central. El acceso a los datos se proporcionaba mediante terminales no inteligentes. El mtodo centralizado funcionaba bien para satisfacer las necesidades de informacin estructurada de las corporaciones, pero se quedaba corto cuando los eventos siempre en movimiento requeran tiempos de respuesta y accesos a la informacin ms rpidos. La lenta progresin desde la solicitud de informacin hasta su aprobacin, y desde el especialista hasta el usuario, simplemente no era til para los tomadores de decisiones en un ambiente dinmico. Lo que se requera era un acceso rpido, no estructurado a la base de datos utilizando consultas ad hoc para generar informacin al momento. Los sistemas de administracin de base de datos basados en el modelo relacional, podran crear el ambiente en el cual las necesidades de informacin no estructuradas serian satisfechas mediante consultas ad hoc. Los usuarios finales podran accesar a los datos cuando lo requirieran. Tambin existieron otros tipos de modelos como: base de datos de red o base de datos jerrquico. Los aos 80s dieron lugar a una serie de cambios tecnolgicos y sociales que afectaron el desarrollo y el diseo de las bases de datos tales como: Los negocios se volvieron ms geogrficamente descentralizados. La competencia se globalizo. Las demandas de los clientes favorecieron el estilo de administracin descentralizado. Los rpidos cambios tecnolgicos crearon computadoras de bajo costo, y un nmero cada vez mayor de corporaciones adoptaron las redes LAN como base para sus soluciones. Estos factores crearon un ambiente de negocios dinmico en el cual las compaas tuvieron que responder con rapidez a las presiones competitivas y tecnolgicas. Conforme las grandes unidades de negocios se reestructuraron para formar operaciones ms simples, dispersas y de reaccin rpida, dos requerimientos de base de datos se volvieron obvios: El acceso rpido a los datos se volvi crucial para la toma de decisiones dinmicas La descentralizacin de las estructuras de administracin basadas en la descentralizacin de unidades de negocios hicieron de las bases de datos Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic. Julio Ismael Gonzlez Tllez
descentralizadas ubicadas en lugares mltiples y de acceso mltiple, una necesidad. Durante los aos 90s todos los factores anteriores se vieron influenciados fuertemente por: La creciente aceptacin de internet y, en particular la red mundial (www), como plataforma para el acceso y distribucin de los datos. El creciente enfoque en el anlisis de los datos que condujo al manejo y almacenamiento de los datos. Aunque el almacn de datos en general no es una base de datos distribuida, depende de tcnicas tales como la replicacin de datos y consultas distribuidas que facilitan la extraccin e integracin de sus datos. El impacto ms importante que promovi el xito de las bases de datos distribuidas fue el uso de internet y la solucin a los problemas de ancho de banda, de cualquier manera, las bases de datos distribuidas existen hoy en da.
Computacin Distribuida
Los sistemas de bases de datos distribuidas son un caso particular de los sistemas de cmputo distribuido en los cuales un conjunto de elementos de procesamiento autnomos (no necesariamente homogneos) se interconectan por una red de comunicaciones y cooperan entre ellos para realizar sus tareas asignadas. Histricamente, el cmputo distribuido se ha estudiado desde muchos puntos de vista. As, es comn encontrar en la literatura un gran nmero de trminos que se han usado para identificarlo. Entre los trminos ms comunes que se utilizan para referirse al cmputo distribuido podemos encontrar: funciones distribuidas, procesamiento distribuido de datos, multiprocesadores, multicomputadoras, procesamiento satelital, procesamiento tipo "backend", computadoras dedicadas y de propsito especfico, sistemas de tiempo compartido, sistemas funcionalmente modulares. Existen muchos componentes a distribuir para realizar una tarea. En computacin distribuida los elementos que se pueden distribuir son: Control. Las actividades relacionadas con el manejo o administracin del sistema. Datos. La informacin que maneja el sistema. Funciones. Las actividades que cada elemento del sistema realiza. Procesamiento lgico. Las tareas especficas involucradas en una actividad de procesamiento de informacin.(Bolivia, 2005)
Figura 1.1. Motivacin de los sistemas de bases de datos distribuidos. Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic. Julio Ismael Gonzlez Tllez
Sistemas de bases de datos distribuidas

Una base de datos distribuida (BDD) es un conjunto de mltiples bases de datos lgicamente relacionadas las cuales se encuentran distribuidas entre diferentes sitios interconectados por una red de comunicaciones (ver Figura 1.1).(Bolivia, 2005) Un sistema de bases de datos distribuidos (SBDD) es un sistema en el cual mltiples sitios de bases de datos estn ligados por un sistema de comunicaciones, de tal forma que, un usuario en cualquier sitio puede accesar los datos en cualquier parte de la red exactamente como si los datos estuvieran almacenados en su sitio propio. (Bolivia, 2005) Un sistema de manejo de bases de datos distribuidas (SMBDD) es aquel que se encarga del manejo de la BDD y proporciona un mecanismo de acceso que hace que la distribucin sea transparente a los usuarios. El trmino transparente significa que la aplicacin trabajara, desde un punto de vista lgico, como si un solo SMBD se ejecutara en una sola mquina, y administrara esos datos.(Bolivia, 2005) Un sistema de base de datos distribuida (SBDD) es entonces el resultado de la integracin de una base de datos distribuida con un sistema para su manejo. Dada la definicin anterior, es claro que algunos sistemas no se pueden considerar como SBDD. Por ejemplo, un sistema de tiempo compartido no incluye necesariamente un sistema de manejo de bases de datos y, en caso de que lo haga, ste es controlado y administrado por una sola computadora.(Bolivia, 2005) Un sistema de multiprocesamiento puede administrar una base de datos pero lo hace usualmente a travs de un solo sistema de manejo de base de datos; los procesadores se utilizan para distribuir la carga de trabajo del sistema completo o incluso del propio SMBD pero actuando sobre una sola base de datos. Finalmente, una base de datos la cual reside en un solo sitio de una red de computadoras y que es accesada por todos los nodos de la red no es una base de datos distribuida (Figura 1.2). Este caso se trata de una base de datos cuyo control y administracin est centralizado en un solo nodo pero se permite el acceso a ella a travs de la red de computadoras.(Bolivia, 2005) El medio ambiente tpico de un SMBDD consiste de un conjunto de sitios o nodos, los cuales tiene un sistema de procesamiento de datos completo que incluye una base de datos local, un sistema de manejo de bases de datos y facilidades de comunicaciones. Si los diferentes sitios pueden estar geogrficamente dispersos, entonces, ellos estn interconectados por una red de tipo WAN. Por otro lado, si los sitios estn localizados en diferentes edificios o departamentos de una misma organizacin pero geogrficamente en la misma ubicacin, entonces, estn conectados por una red local (LAN) (Figura 1.3).(Bolivia, 2005)
Figura 1.2. Un sistema centralizado sobre una red.
Figura 1.3. Un medio ambiente distribuido para bases de datos.
1.2 Objetivos Bases de Datos Distribuidas

Principio Fundamental: Ante el usuario, un sistema distribuido debe lucir exactamente igual que un sistema que no es distribuido En otras palabras, los usuarios de un sistema distribuido deben ser capaces de comportarse exactamente como si no fuera distribuido. Todos los problemas de los sistemas distribuidos son o deberan ser, problemas internos o en el nivel de implementacin, y no externos o en el nivel de usuario. El principio fundamental nos conduce a 12 reglas u objetivos: 1.- Autonoma local. Los sitios en un sistema distribuido deben ser autnomos. La autonoma local significa que todas las operaciones en un sitio dado estn controladas por ese sitio; ningn sitio X debe depender de algn otro sitio para su operacin satisfactoria. La seguridad, integridad y representacin de almacenamiento de los datos locales permanecen bajo el control y jurisdiccin del sitio local. 2.- No dependencia de un sitio central. La autonoma local implica que todos los sitios deben ser tratados como iguales. Por lo tanto, no debe haber particularmente ninguna dependencia de un sitio maestro central para algn servicio central, tal que todo el sistema dependa de ese sitio central. Razones por las cuales no debera haber un sitio central: El sitio central puede ser un cuello de botella El sistema sera vulnerable; es decir, si el sitio central falla, tambin fallar todo el sistema 3.- Operacin contina. Una ventaja de los sistemas distribuidos es que deben proporcionar mayor confiabilidad y mayor disponibilidad. Confiabilidad. La probabilidad de que el sistema est listo y funcionando en cualquier momento dado. Los SD no son una propuesta de todo o nada; pueden continuar operando cuando hay alguna falla en algn componente independiente. Disponibilidad. La probabilidad de que el sistema est listo y funcionando continuamente a lo largo de un perodo especificado. 4.- Independencia de ubicacin. Conocida tambin como transparencia de ubicacin. Los usuarios no tienen que saber dnde estn almacenados fsicamente los datos, sino que deben ser capaces de comportarse como si todos los datos estuvieran almacenados en su propio sitio local. Esto simplifica los programas de los usuarios. En particular, permite que los datos emigren de un sitio a otro sin invalidar ninguno de estos programas o actividades. 5.- Independencia de fragmentacin. Un sistema soporta la fragmentacin de datos cuando puede ser dividida en partes o fragmentos, para efectos de almacenamiento fsico. La fragmentacin es necesaria por razones de rendimiento: los datos pueden estar almacenados en la ubicacin donde son usados ms frecuentemente para que la mayora de las operaciones sean locales y se reduzca el trfico en la red. Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic. Julio Ismael Gonzlez Tllez
Los usuarios deben comportarse como si los datos en realidad estuvieran sin fragmentacin alguna.
6.- Independencia de replicacin 1. Pueden significar una mejor disponibilidad (un objeto replicado permanece disponible para su procesamiento, mientras est disponible al menos una copia). Por supuesto, la principal desventaja de las rplicas es que al actualizarlas es necesario actualizar todas: el problema de la propagacin de la actualizacin. 7.- Procesamiento de consultas distribuidas. La optimizacin es importante en un sistema distribuido que en uno centralizado, incluso mucho ms. El punto bsico es que en una consulta que involucra a varios sitios, habr muchas formas posibles de mover los datos en el sistema para satisfacer la solicitud, y es crucialmente importante que se encuentre una estrategia eficiente. 8.- Administracin de transacciones distribuidas Puede involucrar actualizaciones en muchos sitios y se debe de cuidar que la transaccin no caiga en un bloqueo mortal (basado en el bloqueo). Para el control de la recuperacin, es necesario asegurarse que una transaccin dada sea atmica en el ambiente distribuido, el sistema debe por lo tanto asegurarse de que la transaccin sea confirmada o deshecha (se puede utilizar el protocolo de confirmacin de dos fases). 9.- Independencia de hardware. Soporte para un gran nmero de mquinas diferentes. Poder integrar todos los datos de todos estos sistemas y presentar al usuario una imagen del sistema nico. 10.- Independencia de sistema operativo. Obviamente es necesario no slo tener la posibilidad de ejecutar el mismo DBMS en diferentes plataformas de hardware, sino tambin ejecutarlo en diferentes plataformas de sistema operativo. 11.- Independencia de red. Si el sistema va a tener la posibilidad de soportar muchos sitios distintos es obviamente necesario tener la posibilidad de soportar tambin una variedad de redes de comunicacin distintas. 12.- Independencia de DBMS. Lo que se necesita es que todos los ejemplares de DBMS en sitios diferentes soporten la misma interfaz. Aunque no tienen que ser necesariamente copias del mismo software DBMS. En otras palabras, sera posible que el sistema distribuido fuera heterogneo, al menos en cierto grado. Sera muy bueno si diferentes DBMS pudieran participar de alguna forma en un sistema distribuido.
1.3 Disciplinas de Estudio de Bases de Datos Distribuidas

Son las aplicaciones ms usuales son para la gestin de empresas e instituciones pblicas. Tambin son ampliamente utilizadas en entornos cientficos con el objeto de almacenar la informacin experimental. Aunque las bases de datos pueden contener muchos tipos de datos, algunos de ellos se encuentran protegidos por las leyes de varios pases. Por ejemplo en Espaa, los datos personales se encuentran protegidos por la Ley Orgnica de Proteccin de Datos de Carcter Personal (LOPD).
1.4 Arquitectura Bases de Datos Distribuidas

La arquitectura define la estructura de un sistema. Al definir la arquitectura se deben identificar los componentes de un sistema, las funciones que realiza cada uno de las componentes y las interrelaciones e interacciones entre cada componente. Arquitectura de un sistema de bases de datos distribuidas La mayora de los sistemas de manejo de bases de datos disponibles actualmente estn basadas en la arquitectura ANSI-SPARC la cual divide a un sistema en tres niveles: interno, conceptual y externo. La vista conceptual, conocida tambin como vista lgica global, representa la visin de la comunidad de usuarios de los datos en la base de datos. No toma en cuenta la forma en que las aplicaciones individuales observan los datos o como stos son almacenados. La vista conceptual est basada en el esquema conceptual y su construccin se hace en la primera fase del diseo de una base de datos. Los usuarios, incluyendo a los programadores de aplicaciones, observan los datos a travs de un esquema externo definido a nivel externo. La vista externa proporciona una ventana a la vista conceptual lo cual permite a los usuarios observar nicamente los datos de inters y los asla de otros datos en la base de datos. Puede existir cualquier nmero de vistas externas y ellos pueden ser completamente independientes o traslaparse entre s. El esquema conceptual se mapea a un esquema interno a nivel interno, el cual es el nivel de descripcin ms bajo de los datos en una base de datos. Este proporciona una interfaz al sistema de archivos del sistema operativo el cual es el responsable del acceso a la base de datos. El nivel interno tiene que ver con la especificacin de qu elementos sern indexados, qu tcnica de organizacin de archivos utilizar y como los datos se agrupan en el disco mediante "clusters" para mejorar su acceso.
Figura 1.4 Arquitectura ANSI/SPARC de una base de datos.
Figura 1.5 Vista conceptual de las relaciones E, S, J y G.
Figura 1.6 Definicin de una vista interna a partir de la relacin S.
Figura 1.7 Dos ejemplos de vistas externas. Desafortunadamente, no existe un equivalente de una arquitectura estndar para sistemas de manejo de bases de datos distribuidas. La tecnologa y prototipos de SMBDD se han desarrollado ms o menos en forma independiente uno de otro y cada sistema ha adoptado su propia arquitectura. Para definir un esquema de estandarizacin en bases de datos distribuidas se debe definir un modelo de referencia el cual sera un marco de trabajo conceptual cuyo propsito es dividir el trabajo de estandarizacin en piezas manejables y mostrar a un nivel general como esas piezas se relacionan unas con otras. Para definir ese modelo de referencia se puede seguir uno de los siguientes tres enfoques: Basado en componentes. Se definen los componentes del sistema junto con las relaciones entre ellas. As, un SMBD consiste de un nmero de componentes, cada uno de los cuales proporciona alguna funcionalidad. Basado en funciones. Se identifican las diferentes clases de usuarios junto con la funcionalidad que el sistema ofrecer para cada clase. La especificacin del sistema en esta categora tpicamente determina una estructura jerrquica para las clases de usuarios. La ventaja de este enfoque funcional es la claridad con la cual se especifican los objetivos del sistema. Sin embargo, este enfoque no proporciona una forma de alcanzar los objetivos. Basado en datos. Se identifican los diferentes tipos de descripcin de datos y se especifica un marco de trabajo arquitectural el cual define las unidades funcionales que realizarn y/o usarn los datos de acuerdo con las diferentes vistas. La ventaja de este enfoque es la importancia que asigna al manejo de datos. Este es un enfoque significativo para los SMBD dado que su propsito principal es manejar datos. Sin embargo, la desventaja de este enfoque es que es prcticamente imposible especificar un modelo arquitectural sin especificar los modelos para cada una de sus unidades funcionales. Este es el enfoque seguido por el modelo ANSI/SPARC.
Unidad 2 Diseo de bases de datos distribuidas

El diseo de un sistema de base de datos distribuido implica la toma de decisiones sobre la ubicacin de los programas que accedern 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. La ubicacin de los programas, a priori, no debera suponer un excesivo problema dado que se puede tener una copia de ellos en cada mquina de la red (de hecho, en este documento se asumir que as es). Sin embargo, cul es la mejor opcin para colocar los datos: en una gran mquina que albergue a todos ellos, encargada de responder a todas las peticiones del resto de las estaciones sistema de base de datos centralizado , o podramos pensar en repartir las relaciones, las tablas, por toda la red. En el supuesto que nos decidiramos por esta segunda opcin, qu criterios se deberan seguir para llevar a cabo tal distribucin?, Realmente este enfoque ofrecer un mayor rendimiento que el caso centralizado?, Podra optarse por alguna otra alternativa?. En los prrafos sucesivos se tratar de responder a estas cuestiones. Tradicionalmente se ha clasificado la organizacin de los sistemas de bases de datos distribuidos sobre tres dimensiones: el nivel de comparticin, las caractersticas de acceso a los datos y el nivel de conocimiento de esas caractersticas de acceso (vea la figura 2.1). El nivel de comparticin presenta tres alternativas: inexistencia, es decir, cada aplicacin y sus datos se ejecutan en una PC con ausencia total de comunicacin con otros programas u otros datos; se comparten slo los datos y no los programas, en tal caso existe una rplica de las aplicaciones en cada mquina 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. Como se coment lneas atrs, en este caso se optar por el punto intermedio de comparticin. ()
Figura 2.1 Enfoque de la distribucin. Respecto a las caractersticas de acceso a los datos existen dos alternativas principalmente: el modo de acceso a los datos que solicitan los usuarios puede ser esttico, es decir, no cambiar a lo largo del tiempo, o bien, dinmico. El lector podr comprender fcilmente la dificultad de encontrar sistemas distribuidos reales que puedan clasificarse como estticos. Sin embargo, lo realmente importante radica, estableciendo el dinamismo como base, cmo de dinmico es, cuntas variaciones Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic. Julio Ismael Gonzlez Tllez
sufre a lo largo del tiempo. Esta dimensin establece la relacin entre el diseo de bases de datos distribuidas y el procesamiento de consultas. () La tercera clasificacin es el nivel de conocimiento de las caractersticas de acceso. Una posibilidad es, evidentemente, que los diseadores carezcan de informacin alguna sobre cmo los usuarios acceden a la base de datos. Es una posibilidad terica, pero sera muy laborioso abordar el diseo de la base de datos con tal ausencia de informacin. Lo ms prctico sera conocer con detenimiento la forma de acceso de los usuarios o, en el caso de su imposibilidad, conformarnos con una informacin parcial de sta. () El problema del diseo de bases de datos distribuidas podra enfocarse a travs de esta trama de opciones. En todos los casos, excepto aquel en el que no existe comparticin, aparecern una serie de nuevos problemas que son irrelevantes en el caso centralizado. () A la hora de abordar el diseo de una base de datos distribuida podremos optar principalmente por dos tipos de estrategias: la estrategia ascendente y la estrategia descendente. Ambos tipos no son excluyentes, y no resultara extrao a la hora de abordar un trabajo real de diseo de una base de datos que se pudiesen emplear en diferentes etapas del proyecto una u otra estrategia. La estrategia ascendente podra aplicarse en aquel caso donde haya que proceder a un diseo a partir de un nmero de pequeas bases de datos existentes, con el fin de integrarlas en una sola. En este caso se partira de los esquemas conceptuales locales y se trabajara 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 (vea la figura 2.2) debera resultar familiar a la persona que posea conocimientos sobre el diseo de bases de datos, exceptuando la fase del diseo de la distribucin. Pese a todo, se resumirn brevemente las etapas por las que se transcurre.()
Figura 2.2 Estrategia descendente. Todo comienza con un anlisis de los requisitos que definirn 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 debern 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 econmico. Como puede observarse, los resultados de este ltimo paso sirven de entrada para dos Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic. Julio Ismael Gonzlez Tllez
actividades que se realizan de forma paralela. El diseo de las vistas trata de definir las interfaces para el usuario final y, por otro lado, el diseo conceptual se encarga de examinar la empresa para determinar los tipos de entidades y establecer la relacin entre ellas. Existe un vnculo entre el diseo de las vistas y el diseo conceptual. El diseo conceptual puede interpretarse como la integracin de las vistas del usuario, este aspecto es de vital importancia ya que el modelo conceptual debera soportar no slo las aplicaciones existentes, sino que debera estar preparado para futuras aplicaciones. En el diseo conceptual y de las vistas del usuario se especificarn las entidades de datos y se determinarn las aplicaciones que funcionarn sobre la base de datos, as mismo, se recopilarn datos estadsticos o estimaciones sobre la actividad de estas aplicaciones. Dichas estimaciones deberan girar en torno a la frecuencia de acceso, por parte de una aplicacin, a las distintas relaciones de las que hace uso, podra afinarse ms anotando los atributos de la relacin a la que accede. Desarrollado el trabajo hasta aqu, se puede abordar la confeccin del esquema conceptual global. Este esquema y la informacin relativa al acceso a los datos sirven de entrada al paso distintivo: el diseo de la distribucin. El objetivo de esta etapa consiste en disear los esquemas conceptuales locales que se distribuirn a lo largo de todos los puestos del sistema distribuido. Sera posible tratar cada entidad como una unidad de distribucin; en el caso del modelo relacional, cada entidad se corresponde con una relacin. Resulta bastante frecuente dividir cada relacin en subrelaciones menores denominadas fragmentos que luego se ubican en uno u otro sitio. De ah, que el proceso del diseo de la distribucin conste de dos actividades fundamentales: la fragmentacin y la asignacin. El ltimo paso del diseo de la distribucin es el diseo fsico, el cual proyecta los esquemas conceptuales locales sobre los dispositivos de almacenamiento fsico disponibles en los distintos sitios. Las entradas para este paso son los esquemas conceptuales locales y la informacin de acceso a los fragmentos. Por ltimo, se sabe que la actividad de desarrollo y diseo es un tipo de proceso que necesita de una monitorizacin y un ajuste peridicos, para que si se llegan a producir desviaciones, se pueda retornar a alguna de las fases anteriores. ()
2.1 Consideraciones para el Diseo Bases de Datos Distribuidas

Un sistema de administracin de base de datos distribuida rige el almacenamiento y procesamiento de datos lgicamente relacionados a travs de sistemas de computadoras interconectadas en las cuales, tanto las funciones de datos como de procesamiento, se distribuyen entre varios sitios. Un DBMS debe contar por lo menos con las funciones siguientes para ser considerado como distribuido: Interface de la aplicacin para interactuar con el usuario final o con programas de aplicacin y con otros DBMS dentro de la base de datos distribuida. Transformacin para determinar que componentes de solicitud de datos se distribuyen y cuales son locales. Optimizacin de consultas para encontrar la mejor estrategia de acceso (Cules fragmentos deben ser accesados por la consulta y como, si las hay, se deben sincronizar las actualizacin es de los datos?) Mapeo para determinar la ubicacin de los datos de fragmentos locales y remotos. Interface de E/S para leer o escribir datos de en medios de almacenamientos locales permanentes. Formateo para preparar los datos para su presentacin al usuario final o un programa de aplicacin. Seguridad para proporcionar privacidad tanto en bases de datos locales como en remotas. Respaldo y recuperacin para garantizar la disponibilidad y recuperabilidad de la base de datos en caso de una falla. Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic. Julio Ismael Gonzlez Tllez
Administracin de base de datos para el administrador de la base de datos. Control de concurrencia para manejar el acceso simultaneo a los datos y para garantizar su consistencia a travs de los fragmentos en el DDBMS. Manejo de transacciones para garantizar que los datos pasen de un estado consistente a otro. Esta actividad incluye la sincronizacin de transacciones locales y remotas, lo mismo que transacciones a travs de segmentos mltiples distribuidos.
2.2 Diccionario de Datos

Un diccionario de datos es un conjunto de metadatos que contiene las caractersticas lgicas de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripcin, alias, contenido y organizacin.() Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la informacin, se desarrolla durante el anlisis de flujo de datos y auxilia a los analistas que participan en la determinacin de los requerimientos del sistema, su contenido tambin se emplea durante el diseo.() En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos ms importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripcin de todos estos elementos.()
2.3 Niveles de Transparencia

El propsito de establecer una arquitectura de un sistema de bases de datos distribuidas es ofrecer un nivel de transparencia adecuado para el manejo de la informacin. La transparencia se puede entender como la separacin de la semntica de alto nivel de un sistema de los aspectos de bajo nivel relacionados a la implementacin del mismo. Un nivel de transparencia adecuado permite ocultar los detalles de implementacin a las capas de alto nivel de un sistema y a otros usuarios. En sistemas de bases de datos distribuidos el propsito fundamental de la transparencia es proporcionar independencia de datos en el ambiente distribuido. Se pueden encontrar diferentes aspectos relacionados con la transparencia. Por ejemplo, puede existir transparencia en el manejo de la red de comunicacin, transparencia en el manejo de copias repetidas o transparencia en la distribucin o fragmentacin de la informacin. La independencia de datos es la inmunidad de las aplicaciones de usuario a los cambios en la definicin y/u organizacin de los datos y viceversa. La independencia de datos se puede dar en dos aspectos: lgica y fsica. Independencia lgica de datos. Se refiere a la inmunidad de las aplicaciones de usuario a los cambios en la estructura lgica de la base de datos. Esto permite que un cambio en la definicin de un esquema no afecte a las aplicaciones de usuario. Por ejemplo, el agregar un nuevo atributo a una relacin, la creacin de una nueva relacin, el reordenamiento lgico de algunos atributos. Independencia fsica de datos. Se refiere al ocultamiento de los detalles sobre las estructuras de almacenamiento a las aplicaciones de usuario. Esto es, la descripcin Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic. Julio Ismael Gonzlez Tllez
fsica de datos puede cambiar sin afectar a las aplicaciones de usuario. Por ejemplo, los datos pueden ser movidos de un disco a otro, o la organizacin de los datos puede cambiar. La transparencia al nivel de red se refiere a que los datos en un SBDD se accesan sobre una red de computadoras, sin embargo, las aplicaciones no deben notar su existencia. La transparencia al nivel de red conlleva a dos cosas: Ejemplo Las entidades a ser modeladas son ingenieros y proyectos. Para cada ingeniero, se desea conocer su nmero de empleado (ENO), su nombre (ENOMBRE), el puesto ocupado en la compaa (TITULO), el salario (SAL), la identificacin de los nombres de proyectos en los cuales est trabajando (JNO), la responsabilidad que tiene dentro del proyecto (PUESTO) y la duracin de su responsabilidad en meses (DUR). Similarmente, para cada proyecto se desea conocer el nmero de proyecto (JNO), el nombre del proyecto (JNOMBRE), el presupuesto asignado al proyecto (PRESUPUESTO) y el lugar en donde se desarrolla el proyecto (LUGAR). Un ingeniero puede participar en ms de un proyecto pero su salario corresponde nicamente al puesto que ocupa en la compaa. As, despus de aplicar normalizacin se obtienen las relaciones E ?para ingenieros, J ?para proyectos, S ?para los salarios asignados a los puestos y G ?para los ingenieros asignados a cada proyecto.
Bases de datos de una empresa con cuatro relaciones: E (ingenieros) EN O E1 E2 E3 E4 E5 E6 E7 E8 ENOMBRE Juan Rodrguez Miguel Snchez Armando Legarreta Beatriz Molleda Jorge Castaeda Luis Chvez Roberto Dvila Julia Jimnez TITULO Ingeniero Elctrico Analista de Sistemas Ingeniero Mecnico Programador Analista de Sistemas Ingeniero Elctrico Ingeniero Mecnico Analista de Sistemas
G (ingenieros asignados a proyecto) ENO JNO PUESTO DUR E1 E2 E2 E3 E3 E4 E5 J1 J1 J2 J3 J4 J2 J2 Administrador Analista Analista Consultor Ingeniero Programador Administrador 12 24 6 10 48 18 24
JNO J1 J2 J3 J4 J5
J (proyectos) JNOMBRE PRESUPUEST O Instrumentac 150000 in Desarrollo de 135000 bases de datos CAD/CAM 250000 Mantenimien 310000 to CAD/CAM 500000
LUGAR Monterr ey Mxico Puebla Mxico Monterr ey
S (salarios asignados al puesto) TITULO Ingeniero Elctrico Analista de Sistemas 2Ingeniero Mecnico Programador SALARI O 40000 34000 27000 24000
Si se quisiera obtener todos los empleados y sus salarios en la corporacin quienes han trabajado ms de 12 meses se hara la consulta siguiente en SQL: SELECT ENOMBRE, SALARIO FROM E, G, S WHERE G.DUR > 12 AND E.ENO = G.ENO AND E.TILE = S.TITLE Se debe tener en cuenta que en cada sitio de la corporacin puede haber esquemas diferentes o repetidos.
Figura 2.3 Diferentes sitios de una corporacin. En el primer nivel se soporta la transparencia de red. En el segundo nivel se permite la transparencia de replicacin de datos. En el tercer nivel se permite la transparencia de la fragmentacin. Finalmente, en el ltimo nivel se permite la transparencia de acceso (por medio de lenguaje de manipulacin de datos). La responsabilidad sobre el manejo de transparencia debe estar compartida tanto por el sistema operativo, el sistema de manejo de bases de datos y el lenguaje de acceso a la base de datos distribuida. Entre estos tres mdulos se deben resolver los aspectos sobre el procesamiento distribuido de consultas y sobre el manejo de nombres de objetos distribuidos.
Figura 2.4 Organizacin en capas de los niveles de transparencia.
Caractersticas de la Transparencia
Un sistema de base de datos distribuida requiere caractersticas funcionales que puedan ser agrupadas y descritas como caractersticas de transparencia. Las caractersticas de transparencia de DDBMS tiene la propiedad comn de permitir que el usuario sienta que es el nico que esta utilizando la base de datos. En otras palabras, el usuario cree que el o ella esta trabajando con un DBMS centralizado; todas las complejidades de una base de datos distribuida estn escondidas, o son transparentes, para el usuario. (Coronel, 2004) Las caractersticas de transparencia del DDBMS son: Transparencia de distribucin, la cual permite que una base de datos distribuida sea tratada como una sola base de datos lgica. Si un DDBMS exhibe transparencia de distribucin, el usuario no necesita saber: Que los datos estn en particiones Que los datos pueden ser replicados en varios sitios La ubicacin de los datos (Coronel, 2004) Transparencia de transaccin, la cual permite que una transaccin actualice datos en varios sitios de la red. La transparencia de transaccin garantiza que la transaccin ser completada en su totalidad o abortada, con lo cual se mantiene la integridad de la base de datos. (Coronel, 2004) Transparencia de falla, la cual permite que el sistema contina operando en el caso de una falla de nodo. Las funciones que se perdieron a causa de la falla sern recobradas por otro nodo de la red. (Coronel, 2004) Transparencia de desempeo, la cual permite que el sistema funcione como si fuera un DBMS centralizado. El sistema no sufrir ninguna degradacin de desempeo por su uso en una red o por diferencia de plataforma de la red. Tambin garantiza que el sistema encontrara la ruta de acceso mas optima a los datos remotos. (Coronel, 2004) Transparencia de heterogeneidad, la cual permite la integracin de varios DBMS locales diferentes conforme a un esquema comn, global. El DDBMS es responsable de transformar las solicitudes de datos del esquema global en es quema de DDBMS local. (Coronel, 2004)
2.3.1 Transparencia de Localizacin (de ubicacin)

Existe cuando el usuario o programador debe especificar el nombre de los objetos de la base de datos pero no su ubicacin. (Coronel, 2004) Transparencia de ubicacin local Existe cuando el usuario o programador debe especificar tanto los nombres como las ubicaciones de los fragmentos.(Coronel, 2004)
2.3.2 Transparencia de Fragmentacin

Es el mayor nivel de transparencia. El usuario o programador no necesita saber que una base de datos esta en particiones. Por consiguiente, ni los nombres ni la ubicacin de los fragmentos se especifican antes de acceder a los datos.(Coronel, 2004)
2.3.3 Transparencia de Replica

Consiste en que si existen replicas de objetos de la base de datos, su existencia debe ser controlada por el sistema no por el usuario.
SI LA SENTENCIA SQL REQUIERE: NOMBRE DEL FRAGMENTO Si Si No Si No No NOMBRE DE LA UBICACIN EL DBMS SOPORTA Mapeo Local Transparencia de ubicacin Transparencia de fragmentacin NIVEL DE TRANSPARENCIA DE DISTRIBUCIN Bajo Medio Alto
PRACTICA DE LABORATORIO No.1 Para ilustrar el uso de varios niveles de transparencia suponga que se tiene una tabla T_EMPLEADO que contiene los atributos EMP_CLAVE, EMP_APAT, EMP_AMAT, EMP_NOM, EMP_FNAC, EMP_FING y PUE_CLAVE. Los datos EMPLEADO estn distribuidos en 3 lugares: New York, Atlanta y Miami. La tabla est dividida por ubicacin, es decir, todos los datos del empleado de Nueva York estn guardados en el fragmento E1, los datos de los empleados de Atlanta en el E2 y los de Miami en el E3. T_EMPLEADO EMP_CLAVE varchar(5) PK PUE_CLAVE EMP_APAT EMP_AMAT EMP_NOM EMP_FNAC EMP_FING varchar(2) FK varchar(50) varchar(50) varchar(50) datetime datetime DBMS distribuido Tabla EMPLEADO E1 E2 E3 TC_PUESTO PUE_CLAVE varchar(2) PK PUE_DESC varchar(50)
Fragmen to Ubicaci n
New York
Atlanta
Miami
Figura 2.5 Ubicaciones de los fragmentos Ahora suponga que el usuario desea poner en lista todos los empleados con fecha de nacimiento anterior al primero de Enero de 1940. Para enfocarse en los temas de transparencia, tambin suponga que la tabla EMPLEADO esta fragmentada y que cada fragmento es nico (la condicin de fragmento nico indica que todas las filas son nicas, sin hacer caso de que un fragmento este localizado en ellas). Por ltimo, suponga que ninguna parte de la base de datos esta replicada en algn otro sitio de la red. INSTANCIA ADMINISTRADOR sa sa sa sa PASSWORD newyork atlanta Miami rechum
DESKTOP\SVR_NEWYORK DESKTOP\SVR_ATLANTA DESKTOP\SVR_MIAMI DESKTOP\SVR_RECHUM
Segn el nivel de la transparencia de distribucin, pueden examinarse tres casos de consulta:
CASO 1: LA BASE DE DATOS SOPORTA TRANSPARENCIA DE FRAGMENTACIN

La consulta se ajusta al formato de consulta de base de datos no distribuida; es decir, no especifica nombres o ubicaciones de fragmento. Previamente a esta instruccin SELECT simple, el DBA debi de generar la vista dividida para el acceso a datos, linkeando los servidores necesarios, para ello el administrador de la Base de Datos ser configurado con servidores vinculados. Esto se hace con el procedimiento sp_addlinkedserver, para emplear dicho procedimiento se debe tener en cuenta la sintaxis del mismo: sp_addlinkedserver [ @server = ] 'server' [ , [ @srvproduct = ] 'product_name' ] [ , [ @provider = ] 'provider_name' ] [ , [ @datasrc = ] 'data_source' ] [ , [ @location = ] 'location' ] [ , [ @provstr = ] 'provider_string' ] [ , [ @catalog = ] 'catalog' ] [ @server = ] 'server'. Es el nombre local del servidor vinculado que se va a crear, es decir el alias con el que nombraremos al servidor. server es de tipo sysname y no tiene ningn valor predeterminado. Con mltiples instancias de SQL Server, server puede ser servername\instancename. Entonces, al servidor vinculado podr hacerse referencia como el origen de datos de SELECT *FROM [servername\instancename.]pubs.dbo.authors. Si no se especifica data_source, el servidor es el nombre real de la instancia. [ @srvproduct = ] 'product_name'. Es el nombre de producto del origen de datos OLE DB que se va a agregar como servidor vinculado. product_name es de tipo nvarchar(128) y su valor predeterminado es NULL. Si es SQL Server, no es necesario especificar provider_name, data_source, location, provider_string y catalog. [ @provider = ] 'provider_name'. Es el identificador de programacin nico (PROGID) del proveedor OLE DB correspondiente a este origen de datos. provider_name debe ser nico para el proveedor OLE DB especificado que se ha instalado en el equipo actual. provider_name es de tipo nvarchar(128) y su valor predeterminado es NULL. Se espera que el proveedor OLE DB se registre con el PROGID proporcionado en el registro. [ @datasrc = ] 'data_source'. Es el nombre del origen de datos segn lo interpreta el proveedor OLE DB. data_source es de tipo nvarchar(4000) y su valor predeterminado es NULL. data_source se pasa como la propiedad DBPROP_INIT_DATASOURCE para inicializar el proveedor OLE DB. Cuando se crea el servidor vinculado para el proveedor OLE DB de SQL Server, data_source puede especificarse en el formato nombreServidor\nombreInstancia, que puede utilizarse para conectarse a una instancia especfica de SQL Server que se ejecute en el equipo especificado. nombreServidor es el nombre del equipo en el que se ejecuta SQL Server y nombreInstancia es el nombre de la instancia de SQL Server especfica a la que se conectar el usuario. [ @location = ] 'location'. Es la ubicacin de la base de datos segn la interpreta el proveedor OLE DB. location es de tipo nvarchar(4000) y su valor predeterminado es NULL. location se pasa como la propiedad DBPROP_INIT_LOCATION para inicializar el proveedor OLE DB. [ @provstr = ] 'provider_string'. Es la cadena de conexin especfica del proveedor OLE DB que identifica un origen de datos nico. provider_string es de tipo nvarchar(4000) y su valor predeterminado es NULL. provstr se pasa como la propiedad DBPROP_INIT_PROVIDERSTRING para inicializar el proveedor OLE DB. Cuando se crea el servidor vinculado para el proveedor OLE DB de SQL Server, la instancia puede especificarse mediante la palabra clave SERVER como, por ejemplo, SERVER=nombreServidor\nombreInstancia para especificar una instancia especfica de SQL Server.
nombreServidor es el nombre del equipo en el que se ejecuta SQL Server y nombreInstancia es el nombre de la instancia de SQL Server especfica a la que se conectar el usuario. [ @catalog = ] 'catalog'. Es el catlogo que va a utilizarse cuando se establezca una conexin con el proveedor OLE DB. catalog es de tipo sysname y su valor predeterminado es NULL. catalog se pasa como la propiedad DBPROP_INIT_CATALOG para inicializar el proveedor OLE DB.
SQL Server 2005

En el analizador de consultas de DESKTOP\SVR_NEWYORK se ejecutar de la siguiente forma: sp_addlinkedserver 'DESKTOP\SVR_MIAMI','','SQLOLEDB', 'DESKTOP\SVR_MIAMI', '','User ID=sa; Password=miami','BD_MIAMI' sp_addlinkedserver 'DESKTOP\SVR_ATLANTA', '', 'SQLOLEDB', 'DESKTOP\SVR_ATLANTA', '', 'User ID=sa; Password=atlanta', 'BD_ATLANTA'
As mismo en DESKTOP\SVR_ATLANTA la sintaxis ser la siguiente:
sp_addlinkedserver 'DESKTOP\SVR_NEWYORK', '', 'SQLOLEDB', 'DESKTOP\SVR_NEWYORK', '', 'User ID=sa; Password=newyork', 'BD_NEWYORK'
sp_addlinkedserver 'DESKTOP\MIAMI', '', 'SQLOLEDB', 'DESKTOP\SVR_MIAMI', '', 'User ID=sa; Password=miami', 'BD_MIAMI'
As mismo en DESKTOP\SVR_MIAMI la sintaxis ser la siguiente: sp_addlinkedserver 'DESKTOP\SVR_NEWYORK','','SQLOLEDB', 'DESKTOP\SVR_NEWYORK','', 'User ID=sa; Password=newyork', 'BD_NEWYORK' sp_addlinkedserver 'DESKTOP\SVR_ATLANTA', '', 'SQLOLEDB', 'DESKTOP\SVR_ATLANTA', '', 'User ID=sa; Password=atlanta', 'BD_ATLANTA'
Para conocer los servidores disponibles, que se han agregado, ejecute sp_helpserver en cada una de las instancias instaladas. En cualquiera de las instancias ejecute la consulta sp_helpserver deber verse de esta forma:
Para eliminar los servidores vinculados o disponibles, que se han agregado, ejecute sp_dropserver para cada instancias que desee eliminar. En cualquiera de las instancias ejecute la consulta sp_dropserver deber verse de esta forma:
Ahora bien, si al ejecutar una consulta distribuida obtuviramos un mensaje de error referente a las consultas Ad Hoc como el siguiente:
Mens. 15281, Nivel 16, Estado 1, Lnea 3 SQL Server bloque el acceso a STATEMENT 'OpenRowset/OpenDatasource' del componente 'Ad Hoc Distributed Queries' porque este componente est desactivado como parte de la configuracin de seguridad de este servidor. Un administrador del sistema puede habilitar el uso de 'Ad Hoc Distributed Queries' mediante sp_configure. Para obtener ms informacin sobre cmo habilitar 'Ad Hoc Distributed Queries', vea el tema sobre la configuracin de superficie en los Libros en pantalla de SQL Server.
Quiere decir que debemos reconfigurar el servidor para que soporte dichas consultas mediante los siguientes comandos: En el analizador de consultas de DESKTOP\SVR_NEWYORK se ejecutar de la siguiente forma: sp_configure 'show advanced options',1 reconfigure with override go Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic. Julio Ismael Gonzlez Tllez
sp_configure 'Ad Hoc Distributed Queries',1 reconfigure with override go As mismo en DESKTOP\MIAMI , en DESKTOP\SVR_ATLANTA y DESKTOP\SVR_RECHUM
Cuando un usuario inicia la sesin en el servidor local y ejecuta una consulta distribuida que obtiene acceso a una tabla del servidor vinculado, el servidor local debe iniciar la sesin en el servidor vinculado en nombre del usuario para obtener acceso a esa tabla. Mediante el procedimiento sp_addlinkedsrvlogin especificaremos las credenciales de inicio de sesin que utiliza el servidor local para iniciar sesin en el servidor vinculado. Al ejecutar sp_addlinkedserver, se crea automticamente una asignacin predeterminada entre todos los inicios de sesin del servidor local y los inicios de sesin remotos del servidor vinculado. La asignacin predeterminada indica que SQL Server utiliza las credenciales de usuario del inicio de sesin local al conectarse al servidor vinculado en nombre del inicio de sesin. En el analizador de consultas de DESKTOP\SVR_NEWYORK se ejecutar de la siguiente forma: EXEC sp_addlinkedsrvlogin 'DESKTOP\SVR_MIAMI','false','sa','sa','miami' EXEC sp_addlinkedsrvlogin 'DESKTOP\SVR_ATLANTA','false','sa','sa', 'atlanta' As mismo en DESKTOP\MIAMI y en DESKTOP\SVR_ATLANTA
SQL Server 2000

En el analizador de consultas de DESKTOP\SVR_NEWYORK se ejecutar de la siguiente forma: EXEC sp_addlinkedserver 'DESKTOP\ SVR_MIAMI', '', 'SQLOLEDB', 'DESKTOP\ SVR_MIAMI','','', 'BD_MIAMI' EXEC sp_addlinkedserver 'DESKTOP\SVR_ATLANTA', '', 'SQLOLEDB', 'DESKTOP\SVR_ATLANTA', '', '', 'BD_ATLANTA' EXEC sp_addlinkedsrvlogin 'DESKTOP\SVR_MIAMI','false','sa','sa','miami' EXEC sp_addlinkedsrvlogin 'DESKTOP\SVR_ATLANTA','false','sa','sa', 'atlanta'
As mismo en DESKTOP\SVR_ATLANTA la sintaxis ser la siguiente: EXEC sp_addlinkedserver 'DESKTOP\SVR_NEWYORK', '', 'SQLOLEDB', 'DESKTOP\SVR_NEWYORK','', '', 'BD_NEWYORK' EXEC sp_addlinkedserver 'DESKTOP\SVR_MIAMI', '', 'SQLOLEDB', 'DESKTOP\SVR_MIAMI','', '', 'BD_MIAMI' EXEC sp_addlinkedsrvlogin 'DESKTOP\ SVR_MIAMI','false','sa','sa','miami' EXEC sp_addlinkedsrvlogin 'DESKTOP\SVR_NEWYORK','false','sa','sa', 'newyork'
As mismo en DESKTOP\MIAMI la sintaxis ser la siguiente: EXEC sp_addlinkedserver 'DESKTOP\SVR_NEWYORK', '', 'SQLOLEDB', 'DESKTOP\SVR_NEWYORK','', '', 'BD_NEWYORK' EXEC sp_addlinkedserver 'DESKTOP\SVR_ATLANTA', '', 'SQLOLEDB', 'DESKTOP\SVR_ATLANTA','', '', 'BD_ATLANTA' EXEC sp_addlinkedsrvlogin 'DESKTOP\SVR_NEWYORK','false','sa','sa', 'newyork' EXEC sp_addlinkedsrvlogin 'DESKTOP\SVR_ATLANTA','false','sa','sa', 'atlanta'
Para conocer los servidores disponibles, que se han agregado, ejecute sp_helpserver en cada una de las instancias instaladas. En cualquiera de las instancias ejecute la consulta sp_helpserver deber verse de esta forma:
Para verificar que efectivamente se vinculo el servidor y se registro de forma correcta al usuario sa procederemos a ejecutar una consulta SELECT simple en el analizador de consultas de DESKTOP\SVR_NEWYORK la cual permita extraer informacin del servidor vinculado: SELECT * FROM [DESKTOP\SVR_MIAMI].BD_MIAMI.dbo.T_EMPLEADO
Ahora, es importante conocer la manera de poder eliminar un registro de un usuario seguidamente revertir el proceso de vincular un servidor, esto se puede lograr utilizando los procedimientos almacenados sp_droplinkedsrvlogin y sp_dropserver, en ese mismo orden. Para ejemplificar esto, utilizaremos el analizador de consultas de DESKTOP\SVR_NEWYORK. EXEC sp_droplinkedsrvlogin 'DESKTOP\SVR_MIAMI','sa' EXEC sp_droplinkedsrvlogin 'DESKTOP\SVR_ATLANTA','sa' EXEC sp_dropserver 'DESKTOP\SVR_MIAMI' EXEC sp_dropserver 'DESKTOP\SVR_ATLANTA'
Luego de lo anterior nuestro servidor esta capacitado para realizar las consultas distribuidas requeridas sobre los diversos servidores. Ahora bien, para poder realizar la transparencia de fragmentacin es necesaria la creacin de vistas distribuidas, estas se realizaran con la siguiente sintaxis en el servidor de DESKTOP\SVR_NEWYORK, y posteriormente hacer lo correspondiente para los servidores de DESKTOP\SVR_ATLANTA y DESKTOP\SVR_MIAMI:
De esta forma la instruccin SELECT final del usuario seria una consulta simple como la siguiente: SELECT * FROM dbo.V_EMPLEADO WHERE EMP_APAT LIKE 'K%'
Creacion de UPDATE, DELETE e INSERT Distribuidos

UPDATE OPENDATASOURCE ('SQLOLEDB','Data Source= LAPTOP\SVR_MIAMI; User ID = sa; password=miami').BD_MIAMI.dbo.TC_PUESTO SET PUE_DESC ='SOPORTE TCNICO' WHERE PUE_CLAVE LIKE 'ST' INSERT INTO dbo.Table_1 -MIGRAR INFORMACION DE TABLA A TABLA SELECT UNO FROM OPENDATASOURCE ('SQLOLEDB','Data Source= LAPTOP\SVR_ATLANTA; User ID = sa; password=atlanta').BD_atlanta.dbo.Table_1 INSERT INSERTAR DATOS EN UNA TABLA OPENDATASOURCE ('SQLOLEDB','Data Source= evolution-v2.\SVR_ATLANTA; User ID = sa; password=atlanta').BD_ATLANTA.dbo.TC_PUESTO VALUES('DOS') DELETE OPENDATASOURCE ('SQLOLEDB','Data Source= LAPTOP\SVR_ATLANTA; User ID = sa; password=atlanta').BD_ATLANTA.dbo.Table_1
CASO 2: LA BASE DE DATOS SOPORTA TRANSPARENCIA DE UBICACIN

En la consulta deben especificarse los nombres de fragmento, ms no su ubicacin. En este ejemplo obtendremos informacin de la tabla T_EMPLEADO ubicadas en los servidores SVR_MIAMI Y SVR_ATLANRA desde un equipo remoto en este caso seria SVR_NEWYORK: SELECT EMP_CLAVE,EMP_APAT,EMP_AMAT,EMP_NOM,EMP_FNAC,EMP_FING,PUE_CLAVE FROM dbo.T_EMPLEADO UNION SELECT EMP_CLAVE,EMP_APAT,EMP_AMAT,EMP_NOM,EMP_FNAC,EMP_FING,PUE_CLAVE FROM [DESKTOP\SVR_ATLANTA].BD_ATLANTA.dbo.T_EMPLEADO UNION SELECT EMP_CLAVE,EMP_APAT,EMP_AMAT,EMP_NOM,EMP_FNAC,EMP_FING,PUE_CLAVE FROM [DESKTOP\SVR_MIAMI].BD_MIAMI.dbo.T_EMPLEADO Nota: Hay que tener en cuenta que sin la especificacin correcta del esquema, en este caso dbo, al que pertenece la tabla no se podr tener acceso a ella como en versiones pasadas de SQL.
CAS O 3: L A B AS E DE DAT OS S O PO RT A T RANS PARE NCI A DE UBI CACI N LO CAL En la consulta deben especificarse los nombres de fragmento, ms no su ubicacin. En este primer ejemplo se obtienen datos de las instancias de servidor de SVR_ATLANTA y SVR_MIAMI desde el servidor de SVR_NEWYORK mediante el siguiente cdigo: SELECT * FROM T_EMPLEADO
UNION
SELECT * FROM OPENDATASOURCE( 'SQLOLEDB', 'Data Source= DESKTOP\SVR_ATLANTA; User ID=sa; Password=atlanta' ).BD_ATLANTA.dbo.T_EMPLEADO UNION
SELECT * FROM OPENDATASOURCE( 'SQLOLEDB', 'Data Source= DESKTOP\SVR_MIAMI; User ID=sa; Password=miami' ).BD_MIAMI.dbo.T_EMPLEADO
La instruccin UNION aplicara con diferentes servidores de SQL Server 2005, para este ejemplo puede ejecutar la consulta directamente sobre SQL Server 2005. De clic en el botn de Consulta de motor de base de datos al lado de Nueva consulta y pegue el cdigo anterior. Previamente configurado sp_configure
PRACTICA DE LABORATORIO No. 2

Esta prctica consistir en aplicar los conceptos de heterogeneidad de base de datos distribuidas, vinculando servidores de diversas plataformas y realizando consultas distribuidas sobre ambas. Escenario: Suponga usted que el servidor SVR_ATLANTA ha quedado momentneamente fuera de servicio, el ingeniero en Sistemas decide que los empleados que se den de alta durante el tiempo que el servidor no funciona se capturarn en una base de datos temporal en Access para luego ser exportados al servidor. Base de datos Access 2007 Ubicacin del archivo: C:\ Nombre: BD_TEMP Tablas: T_EMPLEADO Campos en T_EMPLEADO: EMP_CLAVE (Texto, 5) PK, EMP_APAT (Texto, 50), EMP_AMAT (Texto, 50), EMP_NOM (Texto, 50), EMP_FNAC (Fecha/Hora), EMP_FING (Fecha/Hora), PUE_CLAVE (Texto, 2) PK Capture los siguientes datos en la tabla T_EMPLEADO: EMP_CLAVE 018 019 020 EMP_APAT Gonzalez Pinilla Rivas EMP_AMAT Escolar Gallego Acevedo EMP_NOM Maria Pilar Humberto EMP_FNAC 09/11/1987 11/04/1980 19/05/1972 EMP_FING 15/12/2008 15/12/2008 15/12/2008 PUE_CLAVE CP DS DS
Nota: Una de las razones principales por las cuales se realiza una comprobacin antes de la mezcla de los datos, es que los capturistas desconocen la ltima clave ingresada en la tabla de empleados, llevando ellos solamente un consecutivo, por otro lado dado que esto es un trabajo emergente se omite un catalogo de empleados, aunque si se toma como un campo clave primario, por los detalles anteriores se deben hacer una serie de comprobaciones en ambas tablas. a) Realice una consulta que muestre los datos desde BD_TEMP en el analizador de SQL en SVR_ATLANTA.
SELECT * FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0', 'C:\BD_TEMP.accdb'; 'admin';'',T_EMPLEADO)
b) Realice una consulta que verifique que los datos a ingresar sean consistentes con la base de datos de
ATLANTA.
/**Script para seleccionar datos desde C:\BD_TEMP.accdb y comparar las claves con las existentes en T_EMPLEADOS b) Realice una consulta que verifique que los datos a ingresar no estn duplicados en BD_ATLANTA**/ /** PRIMER COMPROBACION (DUPLICIDAD) 1: Convierte a tipo de datos INT los tres caracteres que siguen a AT en la clave de un empleado p.e. AT001=1**/ /**2: Hace el mismo tipo de conversion que 1: pero trabaja con todos los caracteres de la cadena de access p.e. 018=18**/ /** SEGUNDA COMPROBACION (CATALOGO) 3: Selecciona las claves de puesto que no coincidan con el catalogo de puestos**/ /** TERCER COMPROBACION (FECHAS) 4: Obtiene las edades de los empleados a la fecha del ingreso las ordena y en base a la menor espera que sean mayores de 18**/ DECLARE @MENSAJE VARCHAR(100) SET @MENSAJE='' IF (SELECT TOP 1 CONVERT(INT,SUBSTRING(EMP_CLAVE,3,3)) AS CLAVE FROM T_EMPLEADO ORDER BY CLAVE DESC)/**1**/ >= (SELECT TOP 1 CONVERT(INT,SUBSTRING(EMP_CLAVE,1,3)) AS CLAVE FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0', 'C:\BD_TEMP.accdb'; 'admin';'',T_EMPLEADO) ORDER BY CLAVE DESC)/**2**/ SET @MENSAJE='CLAVES DUPLICADAS,' IF EXISTS (SELECT PUE_CLAVE FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0', 'C:\BD_TEMP.accdb'; 'admin';'',T_EMPLEADO) WHERE PUE_CLAVE NOT IN (SELECT PUE_CLAVE FROM TC_PUESTO)/** 3**/) SET @MENSAJE=@MENSAJE + 'CLAVES DE PUESTOS,' IF (SELECT TOP 1 DATEDIFF(YEAR,EMP_FNAC,EMP_FING) AS ANIOS FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0', 'C:\BD_TEMP.accdb'; 'admin';'',T_EMPLEADO) ORDER BY ANIOS ASC)/**4**/ <18 SET @MENSAJE=@MENSAJE + 'EDADES DE EMPLEADOS,' IF @MENSAJE='' PRINT 'TODAS LAS CARACTERISTICAS DE LA TABLA DE ACCESS FUERON SATISFACTORIAMENTE VERIFICADAS, PUEDE PROCEDER A IMPORTAR LOS DATOS' ELSE BEGIN IF SUBSTRING(@MENSAJE,LEN(@MENSAJE),1)=',' SET @MENSAJE=SUBSTRING(@MENSAJE,1,LEN(@MENSAJE)-1) PRINT 'VERIFIQUE LOS ERRORES EN: ' + @MENSAJE + ' ANTES DE IMPORTAR LOS DATOS' END
c)
Realice una consulta para enviar los datos desde BD_TEMP a BD_ATLANTA en SVR_ATLANTA.
/**Script para seleccionar datos desde C:\BD_TEMP.accdb c) Realice una consulta para enviar los datos desde BD_TEMP a BD_ATLANTA en SVR_ATLANTA**/ BEGIN TRAN T1 INSERT INTO T_EMPLEADO (EMP_CLAVE, EMP_APAT, EMP_AMAT,EMP_NOM,EMP_FNAC,EMP_FING, PUE_CLAVE) SELECT 'AT' + EMP_CLAVE, EMP_APAT, EMP_AMAT,EMP_NOM,EMP_FNAC,EMP_FING, PUE_CLAVE FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0', 'C:\BD_TEMP.accdb'; 'admin';'',T_EMPLEADO) SELECT * FROM T_EMPLEADO ROLLBACK COMMIT TRAN T1
Vista final de la tabla T_EMPLEADO EN SVR_ATLANTA
2.4 Fragmentacin de Datos

La fragmentacin de los datos permite dividir un objeto en dos o ms segmentos o fragmentos. El objeto podra ser una base de datos de usuario, una base de datos de sistema o una tabla. Cada fragmento puede guardarse en cualquier sitio en una red de computadoras. La informacin de la fragmentacin de los datos se guarda en un catalogo de datos distribuidos (DDC), desde donde es accesara por el procesador de transacciones para procesar las solicitudes de los usuarios. Las estrategias de fragmentacin de los datos como se analizan aqu, estn basadas a nivel de tabla y consisten en dividir una tabla en fragmentos lgicos. Podemos hablar de tres estrategias de fragmentacin de datos: horizontal, vertical y mezclada (Se debe tener en cuenta que una tabla fragmentada siempre puede recrearse con sus partes fragmentadas mediante una combinacin de uniones y articulaciones). La fragmentacin horizontal se refiere a la divisin de una relacin en subconjunto (fragmento) de tuplas (filas). Cada fragmento se guarda en un nodo diferente, y cada uno de ellos tiene filas nicas. Sin embargo, todas las filas nicas tienen los mismos atributos (columnas). En suma, cada fragmento equivale a una sentencia SELECT, con una combinacin de uniones y articulaciones. La fragmentacin vertical se refiere a la divisin de una relacin en subconjuntos de atributo (columna). Cada conjunto (fragmento) se guarda en un nodo diferente, y cada fragmento tiene columnas nicas, con la excepcin de la columna clave, la cual es comn a todos los fragmentos. Esto es el equivalente de la sentencia PROJECT. La fragmentacin mezclada se refiere a una combinacin de estrategias horizontales y verticales. En otras palabras, una tabla puede dividirse en varios subconjuntos horizontales (filas), y cada una tiene un subconjunto de los atributos (columnas). Para ilustrar las estrategias de fragmentacin, se utilizara la tabla CLIENTE de la compaa XYZ, ilustrada a continuacin, esta tabla contiene los atributos CLI_NUM, CLI_NOM, CLI_DIR, CLI_UBI, CLI_LIM,CLI_BAL, CLI_RAT, CLI_DUE
CLI_ NUM CLI_NOM CLI_DIR CLI_UBI CLI_LIM CLI_BAL CLI_RAT CLI_DUE
10 11 12 13 14 15
Sinex,Inc. Martin Corp. Mynux Corp. BTBC, Inc. Victory, Inc. NBCC Corp
12 Main St. 321 Sunset Blvd. 910 Eagle St. Rue du Monde 123 Maple St. 909 High Ave.
NY MI NY MI MI AT
$3500.0 0 $6000.0 0 $4000.0 0 $6000.0 0 $1200.0 0 $2000.0 0
$2700.0 0 $1200.0 0 $3500.0 0 $5890.0 0 $550.00 $350.00
3 1 3 3 1 2
$1245.0 0 $0.00 $3400.0 0 $1090.0 0 $0.00 $50.00
2.4.1 Fragmentacin Horizontal

Suponga que la gerencia corporativa de la XYZ Company requiere informacin sobre sus clientes en los tres estados, pero las ubicaciones de la compaa en cada estado (NY, MI y AT) solamente requieren datos con respecto a clientes locales. Con base en esos requerimientos, se decide distribuir los datos por estado. Por consiguiente, se Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic. Julio Ismael Gonzlez Tllez
definen los fragmentos horizontales de acuerdo con la estructura mostrada en la tabla siguiente:
NOMBRE DEL FRAGMENTO UBICACIN CONDICION NOMBRE DEL NODO NUMEROS DE CLIENTE NUMERO DE CUARTOS
CLI_H1 CLI_H2 CLI_H3
New York Atlanta Miami
CUS_STATE=NY CUS_STATE=AT CUS_STATE=MI
NYR ATL MIA
10,12 15 11,13,14
2 1 3
Cada fragmento horizontal puede tener un nmero diferente de filas, pero cada uno de ellos DEBE tener los mismos atributos. Los fragmentos resultantes producen las tres tablas que a continuacin se muestran:
Nombre del fragmento: CLI_H1
CLI_N UM CLI_NOM
Ubicacin: New York

CLI_DIR CLI_UBI CLI_LIM
Nodo: NYR
CLI_BAL CLI_RAT CLI_DUE
10 12
Sinex,Inc. Mynux Corp.
12 Main St. 910 Eagle St.
NY NY
$3500.0 0 $4000.0 0
$2700.0 0 $3500.0 0
3 3
$1245.0 0 $3400.0 0

CLI_N UM CLI_NOM
Ubicacin: Atlanta
Nodo: ATL
CLI_BAL CLI_RAT CLI_DUE
15
NBCC Corp
909 High Ave.
AT
$2000.0 0
$350.00 Nodo: MIA
$50.00

CLI_N UM CLI_NOM
Ubicacin: Miami
CLI_BAL
CLI_RAT
CLI_DUE
11 13 14
Martin Corp. BTBC, Inc. Victory, Inc.
321 Sunset Blvd. Rue du Monde 123 Maple St.
MI MI MI
$6000.0 0 $6000.0 0 $1200.0 0
$1200.0 0 $5890.0 0 $550.00
1 3 1
$0.00 $1090.0 0 $0.00
2.4.2 Fragmentacin Vertical

Tambin puede dividirse la relacin CLIENTE en fragmentos verticales compuestos de un conjunto de atributos. Por ejemplo, suponga que la compaa est dividida en dos departamentos, el de servicio y el de colecciones. Cada departamento est ubicado en un edificio distinto, y cada uno tiene inters solamente en unos cuantos de los atributos de la tabla CLIENTE. En este caso, los fragmentos se definen como se muestra a continuacin:
NOMBRE DEL FRAGMEN TO UBICACIN NOMBRE DEL NODO NOMBRES DE ATRIBUTO
CLI_V1 CLI_V2
Edif. de servicio Edif. de coleccin
SVC ARC
CLI_NUM, CLI_NOM, CLI_DIR, CLI_UBI CLI_NUM, CLI_LIM, CLI_BAL, CLI_RAT, CLI_DUE
Cada fragmento vertical debe tener el mismo nmero de filas, pero la inclusin de los diferentes atributos depende de la columna clave. Los resultados de la fragmentacin vertical se muestran a continuacin, observe que el atributo clave (CLI_NUM) es comn a ambos fragmentos CLI_V1 y CLI_V2. Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic. Julio Ismael Gonzlez Tllez
Nombre del fragmento: CLI_V1

CLI_NUM
Ubicacin: Edif. de servicio

CLI_DIR
Nodo: SVC
CLI_UBI
CLI_NOM
10 11 12 13 14 15
Sinex,Inc. Martin Corp. Mynux Corp. BTBC, Inc. Victory, Inc. NBCC Corp
12 Main St. 321 Sunset Blvd. 910 Eagle St. Rue du Monde 123 Maple St. 909 High Ave.
TN FL TN FL FL GA Nodo: ARC
CLI_DUE
Nombre del fragmento: CLI_V2

CLI_NUM CLI_LIM
Ubicacin: Edif. de coleccin

CLI_BAL CLI_RAT
10 11 12 13 14 15
$3500.00 $6000.00 $4000.00 $6000.00 $1200.00 $2000.00
$2700.00 $1200.00 $3500.00 $5890.00 $550.00 $350.00
3 1 3 3 1 2
$1245.00 $0.00 $3400.00 $1090.00 $0.00 $50.00
2.4.3 Fragmentacin Hibrida (de Mezcla)

La estructura de la XYZ Company requiere que los datos CLIENTE se fragmenten horizontalmente para acomodar las diferentes ubicaciones de la compaa; dentro de las ubicaciones, los datos deben ser fragmentados verticalmente para acomodar los diferentes departamentos (servicio y coleccin). En suma la tabla CLIENTE requiere una fragmentacin mezclada. La fragmentacin mezclada requiere un procedimiento de dos pasos. Primero, se introduce la fragmentacin horizontal por cada sitio, con base en la ubicacin dentro de un estado (CLI_UBI). La fragmentacin horizontal produce los subconjuntos de tuplas cliente (fragmentos horizontales) localizados en cada sitio. Como los departamentos estn localizados en edificios diferentes, se utiliza una fragmentacin vertical dentro de cada fragmento horizontal para dividir los atributos, con lo cual se satisfacen las necesidades de informacin de cada departamento en cada subsitio. La fragmentacin mezclada da los resultados ilustrados en la tabla siguiente:
NOMBRE DEL FRAGMEN TO UBICACIN CRITERIOS HORIZONTALES NOMBRE DEL NODO FILAS RESULTAN TES EN EL SITIO CRITERIOS VERTICALES Y ATRIBUTOS EN CADA FRAGMENTO
CLI_M1 CLI_M2 CLI_M3 CLI_M4 CLI_M5 CLI_M6
NY-Servicio NY-Coleccin AT-Servicio AT-Coleccin MI-Servicio MI-Coleccin
CLI_STATE=NY CLI_STATE=NY CLI_STATE=AT CLI_STATE=AT CLI_STATE=MI CLI_STATE=MI
NYR-S NYR-C ATL-S ATL-C MIA-S MIA-C
10,12 10,12 15 15 11,13,14 11,13,14
CLI_NUM, CLI_NOM, CLI_DIR, CLI_UBI CLI_NUM,CLI_LIM, CLI_BAL,CLI_RAT, CLI_DUE CLI_NUM, CLI_NOM, CLI_DIR, CLI_UBI CLI_NUM,CLI_LIM, CLI_BAL,CLI_RAT, CLI_DUE CLI_NUM, CLI_NOM, CLI_DIR, CLI_UBI CLI_NUM,CLI_LIM, CLI_BAL,CLI_RAT, CLI_DUE
Cada fragmento mostrado en la tabla anterior contiene datos de clientes por estado y, dentro de cada estado por ubicacin de departamento, para adaptarse a los requerimientos de datos de cada departamento. Las tablas correspondientes a los fragmentos de mezcla se muestran a continuacin:
Nombre del fragmento: CLI_M1
CLI_NUM
Ubicacin: NYServicio
CLI_DIR
Nodo: NYRS
CLI_UBI
CLI_NOM
10 12
Sinex,Inc. Mynux Corp.
12 Main St. 910 Eagle St.
NY NY Nodo: NYRC
CLI_DUE

CLI_NUM CLI_LIM
Ubicacin: NY-Coleccin
CLI_BAL CLI_RAT
10 12
$3500.00 $4000.00
$2700.00 $3500.00
3 3 Nodo: ATLS
CLI_UBI
$1245.00 $3400.00

CLI_NUM
Ubicacin: ATServicio
CLI_DIR
CLI_NOM
15
NBCC Corp
909 High Ave.
AT Nodo: ATLC
CLI_DUE

CLI_NUM CLI_LIM
Ubicacin: AT-Coleccin
CLI_BAL CLI_RAT
15
$2000.00
$350.00
2 Nodo: MIAS
CLI_UBI
$50.00

CLI_NUM
Ubicacin: MIServicio
CLI_DIR
CLI_NOM
11 13 14
Martin Corp. BTBC, Inc. Victory, Inc.
321 Sunset Blvd. Rue du Monde 123 Maple St.
MI MI MI Nodo: MIAC
CLI_DUE

CLI_NUM CLI_LIM
Ubicacin: MI-Coleccin
CLI_BAL CLI_RAT
11 13 14
$6000.00 $6000.00 $1200.00
$1200.00 $5890.00 $550.00
1 3 1
$0.00 $1090.00 $0.00
2.5 Distribucin de Datos

Los datos son tiles solo cuando llegan a los usuarios correctos en el momento adecuado. El DBA es responsable de que los datos sean distribuidos a las personas apropiadas en el momento apropiado y en el formato correcto. Las tareas de uso y distribucin de los datos del DBA pueden requerir mucho tiempo, en particular si la capacidad de entrega de los datos est basada en un ambiente tpico de programacin de aplicaciones, donde los usuarios dependen de programadores que suministran los programas para acceder a los datos guardados en la base de datos. Aunque la internet y sus extensiones intranet y extranet han abierto las bases de datos a los usuarios corporativos, su utilizacin tambin ha creado nuevos retos para el DBA. Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic. Julio Ismael Gonzlez Tllez
La actual filosofa de distribucin de datos permite que los usuarios autorizados accedan a la base de datos. Una forma de realizar esta tarea es facilitar el uso de una nueva generacin de herramientas de consulta ms complejas y los nuevos programas frontales de web internet. Estos permiten que el DBA ensee a los usuarios a producir la informacin requerida sin tener que depender de los programadores de aplicaciones. Naturalmente, el DBA debe asegurarse de que se sigan los procedimientos y estndares apropiados. Esta filosofa de distribucin es comn hoy en da, y es probable que llegue a ser ms comn conforme la tecnologa de base de datos avanza. Un ambiente como ese es ms flexible para el usuario. Esta claro, que si se permite que los usuarios se vuelvan relativamente autosuficientes en la adquisicin y uso de los datos, este ser ms eficiente en el proceso de toma de decisiones. Sin embargo, esta democracia de datos tambin produce algunos efectos colaterales problemticos. Al permitir que los usuarios micro manejen sus subconjuntos de datos, podra daarse sin querer la conexin entre los usuarios la funcin de la administracin de datos. El trabajo del DBA en estas circunstancias podra llegar a ser lo suficientemente complicado como para comprometer la eficiencia de la funcin de la administracin de datos. La duplicacin de datos podra florecer otra vez si no se realizan verificaciones a nivel organizacional para garantizar la singularidad de los elementos de datos. As pues, los usuarios que no entiendan a cabalidad la naturaleza y fuentes de los datos podran utilizar inapropiadamente los elementos de datos. Rol tcnico del DBA El rol tcnico del DBA requiere un amplio entendimiento de las funciones del DBMS, la configuracin, los lenguajes de programacin, el modelado de datos y metodologas de diseo y otros temas relacionados con el DBM. Por ejemplo, las actividades tcnicas del DBA incluyen la seleccin, instalacin, operacin, mantenimiento y actualizacin del DBMS y software utilitario, as como el diseo, desarrollo, ejecucin y mantenimiento de los programas de aplicacin que interactan con la base de datos. Muchas de las actividades tcnicas del DBA son una extensin lgica de sus actividades administrativas. Por ejemplo, el DBA se encarga de la seguridad e integridad, el respaldo y recuperacin, el entrenamiento y soporte de la base de datos. Por lo tanto, el rol doble del DBA podra ser conceptualizado como una capsula cuyo ncleo tcnico esta cubierto por una corteza claramente administrativa. Los aspectos tcnicos del trabajo del DBA estn enraizados en las siguientes reas de operacin: Evaluacin, seleccin e instalacin del DBMS y utileras Diseo y ejecucin de bases de datos y aplicaciones Pruebas y evaluaciones de bases de datos y aplicaciones Operacin del DBMS, utileras y aplicaciones Entrenamiento y soporte de los usuarios Mantenimiento del DBMS, utileras y aplicaciones
Niveles de distribucin de los datos y procesos Los sistemas de base de datos actuales se clasifican con base en como la distribucin de los procesos y datos son soportados. Por ejemplo, un DBMS puede guardar datos en un solo sitio (DB centralizada) o en mltiples sitios (DB distribuida) y puede soportar procesamientos de datos en un solo sitio o en varios. En la siguiente tabla se muestra Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic. Julio Ismael Gonzlez Tllez
una clasificacin de los sistemas de base de datos de acuerdo con la distribucin de los datos y con los procesos. DATOS EN UN SOLO SITIO Proceso en un solo sitio Proceso sitios en mltiples DBMS anfitrin mainframes Servidor de archivos DBMS Cliente/servidor (DBMS de LAN) DATOS EN SITIOS MULTIPLES No aplicable (requiere procesos mltiples) DDBMS Cliente/servidor totalmente distribuido
2.5.1 Algoritmos Distribucin Datos No Replicados

Debido al uso que se da a las redes de computadoras en la actualidad incluyendo Internet, cada vez es ms factible implementar Sistemas de Bases de Datos Distribuidas, sin embargo, esta tecnologa lleva a los desarrolladores a enfrentar un problema, la carencia de metodologas y herramientas de apoyo para su diseo que permitan decidir la ubicacin de los datos en cada uno de los diferentes sitios que componen la red de computadoras. Este problema se conoce como Diseo de la Distribucin y nace de la necesidad de especificar las unidades de almacenamiento adecuadas, ya sea fragmentos verticales, horizontales o mixtos, junto con su ubicacin dentro de la aplicacin. El Modelo FURD, ha sido desarrollado para resolver el problema del diseo de las Bases de Datos Distribuidas, el cual esta divido en dos etapas o fases: la fragmentacin y la ubicacin de fragmentos. Estas fases ya se concentran en el Modelo FURD. Una vez que se resuelve el Modelo FURD se puede dar solucin al problema del diseo. Sin embargo la dificultad radica precisamente en la forma de resolverlo, pues es un problema de optimizacin muy complejo que a medida que va creciendo su tamao, se va haciendo ms difcil la forma de resolverse. ModeladoFURD.pdf
2.5.2 Algoritmos Distribucin Datos Replicados

Al tratarse de algoritmos de distribucin replicados o no replicados la definicin de nuestro problema y variables ser diferente, es decir el problema se restringir de otra manera como se explica en el documento ModeladoFURD.pdf. Estas restricciones son: 1 Restriccin. Cada atributo se almacena solamente en un solo sitio (Para bases de datos distribuidas no replicadas) 2 Restriccin. Cada atributo m se ubica en un sitio i que al menos ejecute una consulta que involucre al atributo (Para bases de datos distribuidas replicadas)
3. Procesamiento de consultas distribuidas

Para adentrarse en este tema es recomendable tener conocimientos bsicos de algebra relacional. El xito creciente de la tecnologa de bases de datos relacionales en el procesamiento de datos se debe, en parte, a la disponibilidad de lenguajes no procedurales los cuales pueden mejorar significativamente el desarrollo de aplicaciones y la productividad del usuario final. Ocultando los detalles de bajo nivel acerca de la localizacin fsica de datos, los lenguajes de bases de datos relacionales permiten la expresin de consultas complejas en una forma concisa y simple. Particularmente, para construir la respuesta a una consulta, el usuario no tiene que especificar de manera precisa el procedimiento que se debe seguir. Este procedimiento es llevado a cabo por un mdulo del DBMS llamado el procesador de consultas (query processor). Una base de datos relacional consiste en muchas piezas, pero en su corazn estn dos componentes importantes: el motor de almacenaje y el procesador de consultas. El motor de almacenaje escribe y lee datos del disco. Maneja los expedientes, concurrencia de los controles, y mantiene ficheros de diario. El procesador de consultas acepta sintaxis de SQL, selecciona un plan para ejecutar la sintaxis, y despus ejecuta el plan elegido. El usuario o el programa obran recprocamente con el procesador de consultas, y el procesador de consultas obra recprocamente con el motor de almacenaje. El procesador de consultas asla al usuario de los detalles de la ejecucin: el usuario especifica el resultado y el procesador de consultas determina como se obtiene ese resultado. Dado que la ejecucin de consultas es un aspecto crtico en el rendimiento de un DBMS, el procesamiento de consultas ha recibido una gran atencin tanto para bases de datos centralizadas como distribuidas. Sin embargo, el procesamiento de consultas es mucho ms difcil en ambientes distribuidos que en centralizados, ya que existe un gran nmero de parmetros que afectan el rendimiento de las consultas distribuidas. El problema de procesamiento de consultas La funcin principal de un procesador de consultas relacionales es transformar una consulta en una especificacin de alto nivel, tpicamente en clculo relacional, a una consulta equivalente en una especificacin de bajo nivel, tpicamente alguna variacin del lgebra relacional (ver Figura 3.1). La consulta de bajo nivel implementada es de hecho la estrategia de ejecucin para la consulta. La transformacin debe ser correcta Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic. Julio Ismael Gonzlez Tllez
y eficiente. Es correcta si la consulta de bajo nivel tiene la misma semntica que la consulta original, esto es, si ambas consultas producen el mismo resultado. El mapeo bien definido que se conoce entre el clculo relacional y el lgebra relacional hace que la validez de la transformacin sea fcil de verificar. Sin embargo, producir una estrategia de ejecucin eficiente es mucho ms complicado. Una consulta en el clculo relacional puede tener muchas transformaciones correctas y equivalentes en el lgebra relacional. Ya que cada estrategia de ejecucin equivalente puede conducir a consumos de recursos de cmputo muy diferentes, la dificultad ms importante es seleccionar la estrategia de ejecucin que minimiza el consumo de recursos.
Figura 3.1. Procesamiento de consultas. Considere el siguiente subconjunto del esquema de la base de datos que se vio en el tema 2.3: E (ENO, ENOMBRE, TITULO) G (ENO, JNO, RESPONSABLE, JORNADA) Con la siguiente consulta de usuario: "Encuentre todos los nombres de empleados que manejan un proyecto" La expresin de la consulta en SQL se puede ver como SELECT ENOMBRE FROM E, G WHERE E.ENO = G.ENO AND RESPONSABLE = "ADMINISTRADOR" Dos consultas equivalentes en el lgebra relacional que son transformaciones correctas de la consulta en SQL son:
y Como es intuitivamente obvio, la segunda estrategia que evita calcular el producto cartesiano entre E y G, consume mucho menos recursos que la primera y, por lo tanto, es mejor.
En un contexto centralizado, las estrategias de ejecucin de consultas pueden ser bien expresadas como una extensin del lgebra relacional. Sin embargo, en sistemas distribuidos, el lgebra relacional no es suficiente para expresar la ejecucin de estrategias. Debe ser complementada con operaciones para el intercambio de datos entre nodos diferentes. Adems de elegir el orden de las operaciones del lgebra relacional, el procesador de consultas distribuidas debe seleccionar tambin los mejores sitios para procesar datos y posiblemente la forma en que ellos tienen que ser transformados. Ejemplo 3.1: Considere la siguiente consulta del ejemplo anterior:
Supongamos que E y G estn fragmentadas horizontalmente como sigue:
E1 = E2 = G1 = G2 =
ENO "E3" ENO > "E3" ENO "E3" ENO > "E3"
(E) (E) (G) (G)
Los fragmentos E1, E2, G1 y G2 estn almacenados en los nodos 1, 2, 3 y 4, respectivamente, y el resultado se quiere en el nodo 5. En la Figura 3.2 se presentan dos estrategias distribuidas de ejecucin diferentes para la misma consulta (se ha ignorado el operador de proyeccin por simplicidad del ejemplo). La estrategia A explota el hecho de que las relaciones E y G estn fragmentadas de la misma manera y ejecuta la operacin de seleccin y junta en paralelo. La estrategia B centraliza todos los datos en el nodo resultante antes de procesar la consulta. Para evaluar el consumo de recursos, se usar un modelo de costo simple:
Suponga que el costo de acceso a un tuplo (tupacc) es 1 unidad, y la transferencia de un tuplo (tuptrans) tiene un costo de 10 unidades. Suponga que E y G tienen 400 y 1000 tuplos, respectivamente, y que existen 20 administradores en la relacin G. Tambin, suponga que los datos estn uniformemente distribuidos entre los nodos. Finalmente, suponga que las relaciones G y E estn agrupadas localmente en los atributos RESP y ENO, respectivamente, de manera que, hay un acceso directo a los tuplos de G y E, respectivamente.
El costo de la estrategia A se puede derivar como sigue:
No. 1 2 3 4 5 6 7 8
Proceso Producir G1 seleccionando G1 Producir G2 seleccionando G2 Transferir G1 al nodo E1 Transferir G2 al nodo E2 Juntar G1 y E1 para obtener E1 Juntar G2 y E2 para obtener E2 Transferir E1 al nodo resultante Transferir E2 al nodo resultante
Clculo tuplas * tupacc=10*1 tuplas * tupacc=10*1 tuplas * tuptrans= 10*10 tuplas * tuptrans= 10*10 (tuplas E1 * tuplas G1) * tupacc=10*10*1 (tuplas E2 * tuplas G2) * tupacc=10*10*1 tuplas * 10=10 * 10 tuplas * 10=10 * 10
(unidades)
Costo
10 10 100 100 100 100 100 100 620
El costo de la estrategia B se puede derivar como sigue:
La estrategia A es mejor por un factor de 37, lo cual es significativo. La diferencia sera an mayor si se hubiera asumido un costo de comunicacin mayor y/o un grado de fragmentacin mayor. Objetivos de la optimizacin de consultas Como se estableci antes, el objetivo del procesamiento de consultas en un ambiente distribuido es transformar una consulta sobre una base de datos distribuida en una especificacin de alto nivel a una estrategia de ejecucin eficiente expresada en un lenguaje de bajo nivel sobre bases de datos locales. As, el problema de optimizacin de consultas es minimizar una funcin de costo tal que Funcin de costo total = costo de I/O + costo de CPU + costo de comunicacin
Los diferentes factores pueden tener pesos diferentes dependiendo del ambiente distribuido en el que se trabaje. Por ejemplo, en las redes de rea amplia (WAN), normalmente el costo de comunicacin domina dado que hay una velocidad de comunicacin relativamente baja, los canales estn saturados y el trabajo adicional requerido por los protocolos de comunicacin es considerable. As, los algoritmos diseados para trabajar en una WAN, por lo general, ignoran los costos de CPU y de I/O. En redes de rea local (LAN) el costo de comunicacin no es tan dominante, as que se consideran los tres factores con pesos variables. Caracterizacin de los procesadores de consultas Es difcil evaluar y comparar procesadores de consultas para sistemas centralizados y distribuidos dado que ellos difieren en muchos aspectos. En esta seccin se enumeran algunas caractersticas importantes de los procesadores de consultas que pueden ser usados como base para su comparacin. Tipo de optimizacin El problema de optimizacin de consultas es altamente demandante en tiempo de ejecucin y, en el caso general, es un problema de la clase NP. As existen dos estrategias para su solucin: bsqueda exhaustiva o el uso de heursticas. Los algoritmos de bsqueda exhaustiva tienen una complejidad combinatoria en el nmero de relaciones de la consulta. Obtienen la transformacin ptima, pero slo se aplican a consultas simples dado su tiempo de ejecucin. Por otro lado, los algoritmos heursticos obtienen solo aproximaciones a la transformacin ptima pero lo hacen en un tiempo de ejecucin razonable. Las heursticas ms directas a aplicar son el agrupamiento de expresiones comunes para evitar el clculo repetido de las mismas, aplicar primero las operaciones de seleccin y proyeccin, reemplazar una junta por una serie de semijuntas y reordenar operaciones para reducir el tamao de las relaciones intermedias. Granularidad de la optimizacin Existen dos alternativas: considerar slo una consulta a la vez o tratar de optimizar mltiples consultas. La primera alternativa no considera el uso de
resultados
comunes
intermedios.
En
el
segundo
caso
puede
obtener
transformaciones eficientes si las consultas son similares. Sin embargo, el espacio de decisin es mucho ms amplio lo que afecta grandemente el tiempo de ejecucin de la optimizacin. Tiempo de optimizacin Una consulta puede ser optimizada en tiempos diferentes con relacin a tiempo de ejecucin de la consulta. La optimizacin se puede realizar de manera esttica antes de ejecutar la consulta o de forma dinmica durante la ejecucin de la consulta. La optimizacin esttica se hace en tiempo de compilacin de la consulta. As, el costo de la optimizacin puede ser amortizada sobre mltiples ejecuciones de la misma consulta. Durante la optimizacin de consultas dinmica la eleccin de la mejor operacin siguiente se puede hacer basado en el conocimiento exacto de los resultados de las operaciones anteriores. Por tanto, se requiere tener estadsticas acerca del tamao de los resultados intermedios para aplicar esta estrategia. Un tercer enfoque, conocido como hbrido, utiliza bsicamente un enfoque esttico, pero se puede aplicar un enfoque dinmico cuando los tamaos de las relaciones estimados estn alejados de los tamaos actuales. Estadsticas La efectividad de una optimizacin recae en las estadsticas de la base de datos. La optimizacin dinmica de consultas requiere de estadsticas para elegir las operaciones que deben realizarse primero. La optimizacin esttica es an ms demandante ya que el tamao de las relaciones intermedias tambin debe ser estimado basndose en estadsticas. En bases de datos distribuidas las estadsticas para optimizacin de consultas tpicamente se relacionan a los fragmentos; la cardinalidad y el tamao de los fragmentos son importantes as como el nmero de valores diferentes de los atributos. Para minimizar la probabilidad de error, estadsticas ms detalladas tales como histogramas de valores de atributos se usan pagando un costo mayor por su manejo. Nodos de Decisin
Cuando se utiliza la optimizacin esttica, un solo nodo o varios de ellos pueden participar en la seleccin de la estrategia a ser aplicada para ejecutar la consulta. La mayora de los sistemas utilizan un enfoque centralizado para la toma de decisiones en el cual un solo lugar decide la estrategia a ejecutar. Sin embargo, el proceso de decisin puede ser distribuido entre varios nodos los cuales participan en la elaboracin de la mejor estrategia. El enfoque centralizado es simple, pero requiere tener conocimiento de la base de datos distribuida completa. El enfoque distribuido requiere solo de informacin local. Existen enfoques hbridos en donde un nodo determina una calendarizacin global de las operaciones de la estrategia y cada nodo optimiza las subconsultas locales. Topologa de la Red Como se mencion al principio, el tipo de red puede impactar severamente la funcin objetivo a optimizar para elegir la estrategia de ejecucin. Por ejemplo, en redes de tipo WAN se sabe que en la funcin de costo el factor debido a las comunicaciones es dominante. Por lo tanto, se trata de crear una calendarizacin global basada en el costo de comunicacin. A partir de ah, se generan calendarizaciones locales de acuerdo a una optimizacin de consultas centralizada. En redes de tipo LAN el costo de comunicacin no es tan dominante. Sin embargo, se puede tomar ventaja de la comunicacin "broadcast" que existe comnmente en este tipo de redes para optimizar el procesamiento de las operaciones junta. Por otra parte, se han desarrollado algoritmos especiales para topologas especficas, como por ejemplo, la topologa de estrella. 3.1.
Metodologa Procesamiento Consultas Distribuidas
El problema de procesamiento de consultas se puede descomponer en varios subproblems que corresponden a diferentes niveles. En la Figura 4.4, se presenta un esquema por niveles genrico para el procesamiento de consultas. Para simplificar la discusin, suponga que se tiene un procesador de consultas esttico semicentralizado en donde no se tienen fragmentos replicados. Cuatro capas principales estn involucradas en mapear una consulta a una base de datos distribuida en una secuencia optimizada de operaciones locales, cada una de ellas actuando en una base de datos local. Las cuatro capas principales son: descomposicin de consultas, localizacin de datos, optimizacin global de consultas y optimizacin local de consultas. Las primeras tres se realizan en un nodo central usando informacin global. La cuarta capa se realiza en cada nodo local.
Figura 4.4. Arquitectura en capas del procesamiento de consultas. Descomposicin de consultas La primera capa descompone una consulta en el clculo relacional en una consulta en el lgebra relacional que opera sobre relaciones globales. Consiste de cuatro partes: 1. Normalizacin. Involucra la manipulacin de los cuantificadores de la consulta y de los calificadores de la misma mediante la aplicacin de la prioridad de los operadores lgicos. 2. Anlisis. Se detecta y rechazan consultas semnticamente incorrectas. 3. Simplificacin. Elimina predicados redundantes. 4. Reestructuracin. Mediante reglas de transformacin una consulta en el clculo relacional se transforma a una en el lgebra relacional. Se sabe que puede existir ms de una transformacin. Por tanto, el enfoque seguido usualmente es empezar con una consulta algebraica y aplicar transformaciones para mejorarla. Localizacin de Datos La entrada a esta capa es una consulta algebraica definida sobre relaciones distribuidas. El objetivo de esta capa es localizar los datos de la consulta usando la informacin sobre la distribucin de datos. Esta capa determina cuales fragmentos estn involucrados en la consulta y transforma la consulta distribuida en una consulta sobre fragmentos. Optimizacin Global de Consultas Dada una consulta algebraica sobre fragmentos, el objetivo de esta capa es hallar una estrategia de ejecucin para la consulta cercana a la ptima. La estrategia de ejecucin para una consulta distribuida puede ser descrita con los operadores del lgebra relacional y con primitivas de comunicacin para transferir datos entre nodos. Para encontrar una buena transformacin se consideran las caractersticas de los fragmentos, tales como, sus cardinalidades. Un aspecto importante de la optimizacin de consultas es el ordenamiento de juntas, dado que algunas permutaciones de juntas dentro de la consulta pueden conducir a un mejoramiento de varios rdenes de magnitud. La salida de la capa de optimizacin global es una consulta algebraica optimizada con operacin de comunicacin incluidas sobre los fragmentos. Optimizacin Local de Consultas El trabajo de la ltima capa se efecta en todos los nodos con fragmentos involucrados en la consulta. Cada subconsulta que se ejecuta en un nodo, llamada consulta local, es optimizada usando el esquema local del nodo. Hasta este momento, se pueden eligen Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic. Julio Ismael Gonzlez Tllez
los algoritmos para realizar las operaciones relacionales. La optimizacin local utiliza los algoritmos de sistemas centralizados. 4.6 Descomposicin de consultas Como se dijo en la seccin anterior la descomposicin de consultas consiste de cuatro pasos: normalizacin, anlisis, simplificacin y reestructuracin. En esta seccin se abundar ms sobre cada uno de los pasos. 4.6.1 Normalizacin La consulta de entrada puede ser arbitrariamente compleja dependiendo de las facilidades provistas por el lenguaje. El objetivo de la normalizacin es transformar una consulta a una forma normalizada para facilitar su procesamiento posterior. La normalizacin consiste de dos partes: El anlisis lxico y sintctico. En esta parte se verifica la validez de la expresin que da origen a la consulta. Se verifica que las relaciones y atributos invocados en la consulta estn acordes con la definicin en la base de datos. Por ejemplo, se verifica el tipo de los operandos cuando se hace la calificacin. 4.6.2 Anlisis El anlisis de consultas permite rechazar consultas normalizadas para los cuales no se requiere mayor procesamiento. Una consulta se puede rechazar si alguno de sus atributos o nombres de relacin no estn definidas en el esquema global. Tambin se puede rechazar si las operaciones que se aplican a los atributos no son del tipo adecuado. Se puede hacer tambin un anlisis semntico. La consulta se puede rechazar si las componentes no contribuyen de ninguna forma a la generacin del resultado. Dentro del clculo relacional no es posible determinar la correctitud semntica de una consulta general. Sin embargo, es posible hacerlo para una clase importante de consultas relacionales, aquellas que no contienen disyunciones y negaciones. El anlisis anterior se basa en la representacin de la consulta como una grfica, llamada la grfica de la consulta o la grfica de conectividad. En una grfica de consulta, un nodo indica la relacin resultante, y cualquier otro nodo representa la relacin operante. Un arco entre dos nodos que no son resultados representa una junta, mientras que un arco cuyo nodo destino es una relacin resultante representa una proyeccin. Ms an, un nodo no resultado puede ser etiquetado por un predicado de seleccin o auto-junta. Una subgrfica importante de la grfica de conectividad es la grfica de juntas, en la cual nicamente se consideran las juntas. La grfica de juntas es particularmente importante durante la fase de optimizacin. SIMPLIFICACION La consulta en forma normal conjuntiva puede contener predicados redundantes. Una evaluacin directa de la consulta con redundancia puede llevarnos a realizar trabajo duplicado. REESTRUCTURACION El ltimo paso en la descomposicin de consultas reescribe la consulta en el lgebra relacional. Esto se hace tpicamente en los siguientes paso: 1. Una transformacin directa del clculo relacional en el lgebra relacional 2. Una reestructuracin de la consulta en el lgebra relacional para mejorar la eficiencia Por claridad es costumbre representar la consulta en el lgebra relacional por un rbol del lgebra relacional, el cual es un rbol en donde una hoja representa a una relacin almacenada en la base de datos y un nodo no hoja es una relacin intermedia producida por una operacin del lgebra relacional. La transformacin de una consulta en el clculo relacional en un rbol del lgebra relacional se puede hacer como sigue. Primero, se crea una hoja diferente para cada variable de tuplo diferente. En SQL, las hojas estn disponibles de forma inmediata en la clusula FROM. Segundo, el nodo raz se crea como una operacin de proyeccin Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic. Julio Ismael Gonzlez Tllez
involucrando a los atributos resultantes. Estos se encuentran en la clusula SELECT de una consulta en SQL. Tercero, la calificacin (WHERE) de una consulta se traduce a una secuencia apropiada de operaciones relacionales (select, join, union, etc.) yendo de las hojas a la raz. La secuencia se puede dar directamente por el orden de aparicin de los predicados y operadores.
3.1.
Estrategias Procesamiento Consultas Distribuidas
Reduccin para fragmentacin horizontal primaria La fragmentacin horizontal distribuye una relacin basada en predicados de seleccin. El ejemplo siguiente ser usado a lo largo de esta seccin. Ejemplo 4.9. La relacin E(ENO, ENOMBRE, TITULO) puede ser dividida en tres fragmentos horizontales E1, E2 y E3, definidos como sigue: E1 = s E2 = s E3 = s
ENO "E3"
(E) (E) (E)
"E3" < ENO "E6" ENO > "E6"
El programa de localizacin para fragmentacin horizontal es la unin de los fragmentos. Aqu se tiene que: E = E1 E2 E13 La relacin G puede ser dividida en dos fragmentos horizontales G1 y G2 definidos como sigue: G1 = s G2 = s
ENO "E3" ENO > "E3"
(G) (G)
El programa de localizacin para G es la unin de los fragmentos. Aqu se tiene que: G = G1 G2 El rbol genrico se presenta en la Figura 4.10.
Figura 4.10. Arbol genrico para el ejemplo 4.9. La fragmentacin vertical distribuye una relacin de acuerdo a los atributos de proyeccin. Dado que el operador de reconstruccin para la fragmentacin vertical es la junta, el programa de localizacin para una relacin fragmentada verticalmente consiste de la junta de los fragmentos sobre el atributo comn. Ejemplo 4.12. Considere la relacin E dividida en dos fragmentos verticales donde el atributo ENO sirve como atributo comn. E1 = P ENO,ENOMBRE (E) E2 = P ENO,TITULO (E) El programa de localizacin es E = E1 > < E2 La reduccin de consultas sobre fragmentos verticales se hace determinando relaciones intermedias intiles y eliminando los subrboles que las producen. Las proyecciones sobre fragmentos verticales que no tienen atributos en comn con los atributos de proyeccin (excepto la llave de la relacin) producen relaciones intiles aunque probablemente no vacas. Dada una relacin R definida sobre los atributos A = { A1, A2, ..., An }, la cual se fragmenta verticalmente como Ri = P A (R), donde A A, la regla para determinar relaciones intermedias intiles se puede formular como sigue: Regla 3: P D,K (R) es intil si el conjunto de atributos de proyeccin D no est en A. Ejemplo 4.13. Considere de nuevo la relacin E dividida en fragmentos verticales como en el Ejemplo 4.12. Considere tambin la siguiente consulta en SQL: SELECT ENAME
FROM E E1 = P ENO,ENOMBRE (E) E2 = P ENO,TITULO (E) La consulta genrica equivalente se presenta en la Figura 4.13a. Conmutando la proyeccin con la junta, se puede ver que la proyeccin sobre E2 es intil dado que ENOMBRE no est en E2. Por lo tanto, la proyeccin necesita aplicarse nicamente a E1, como se presenta en la Figura 4.13b.
3.1.1.Arboles de Consultas
3.1.2. Transformaciones Equivalentes Consultas Distribuidas 3.1.3. Mtodos Ejecucin del Join
3.2. Optimizacin de Consultas Distribuidas

3.2.1. Optimizacin Global Consultas Distribuidas 3.2.2. Optimizacin Local Consultas Distribuidas
4.
Manejo de transacciones
Las transacciones de base de datos reflejan transacciones reales promovidas por eventos como la compra de un producto, la inscripcin a un curso o la realizacin de un depsito en una cuenta de cheques.
4.1.
Transacciones Conceptos
4.1.1.Estructura de Transacciones
4.1.2.Ejecucin Transacciones Centralizada Distribuida 4.1.3.Estructura de transacciones 4.2. Control de Concurrencia

4.2.1. Serializacin de Transacciones
4.2.2.Algoritmos de Control de Concurrencia 4.2.2.1.Basados en Bloqueo. 4.2.2.2.Basados en Estampas de Tiempo

4.2.3. Pruebas Validacin Optimistas
4.2.4.Disciplinas del Interbloqueo prevencin deteccin eliminacin y recuperacin
4.3. Confiabilidad 4.3.1.Conceptos Bsicos de Confiabilidad

4.3.2. Protocolos Redo Undo 4.3.3. Puntos de Verificacin checkpoints
4.3.4.Protocolo 2PC de Confiabilidad Distribuida

SBD D

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

SBD D

Cargado por

Copyright:

Formatos disponibles

Manual para la materia de Bases de Datos Distribuidas. Elaborado por Lic.

Julio Ismael Gonzlez Tllez

Fundamentos Bases de Datos Distribuidas

1.1. Conceptos Bsicos

1 Fundamentos Bases de Datos Distribuidas 1.1Conceptos Bsicos

Sistemas de bases de datos distribuidas

Figura 1.2. Un sistema centralizado sobre una red.

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

1.2 Objetivos Bases de Datos Distribuidas

1.3 Disciplinas de Estudio de Bases de Datos Distribuidas

1.4 Arquitectura Bases de Datos Distribuidas

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

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

Figura 1.6 Definicin de una vista interna a partir de la relacin S.

Unidad 2 Diseo de bases de datos distribuidas

2.1 Consideraciones para el Diseo Bases de Datos Distribuidas

2.2 Diccionario de Datos

2.3 Niveles de Transparencia

LUGAR Monterr ey Mxico Puebla Mxico Monterr ey

Figura 2.4 Organizacin en capas de los niveles de transparencia.

2.3.1 Transparencia de Localizacin (de ubicacin)

2.3.2 Transparencia de Fragmentacin

2.3.3 Transparencia de Replica

DESKTOP\SVR_NEWYORK DESKTOP\SVR_ATLANTA DESKTOP\SVR_MIAMI DESKTOP\SVR_RECHUM

Segn el nivel de la transparencia de distribucin, pueden examinarse tres casos de consulta:

CASO 1: LA BASE DE DATOS SOPORTA TRANSPARENCIA DE FRAGMENTACIN

SQL Server 2005

As mismo en DESKTOP\SVR_ATLANTA la sintaxis ser la siguiente:

SQL Server 2000

Creacion de UPDATE, DELETE e INSERT Distribuidos

CASO 2: LA BASE DE DATOS SOPORTA TRANSPARENCIA DE UBICACIN

PRACTICA DE LABORATORIO No. 2

SELECT * FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0', 'C:\BD_TEMP.accdb'; 'admin';'',T_EMPLEADO)

Vista final de la tabla T_EMPLEADO EN SVR_ATLANTA

2.4 Fragmentacin de Datos

$3500.0 0 $6000.0 0 $4000.0 0 $6000.0 0 $1200.0 0 $2000.0 0

$2700.0 0 $1200.0 0 $3500.0 0 $5890.0 0 $550.00 $350.00

$1245.0 0 $0.00 $3400.0 0 $1090.0 0 $0.00 $50.00

2.4.1 Fragmentacin Horizontal

CLI_H1 CLI_H2 CLI_H3

New York Atlanta Miami

CUS_STATE=NY CUS_STATE=AT CUS_STATE=MI

NYR ATL MIA

Ubicacin: New York

Sinex,Inc. Mynux Corp.

12 Main St. 910 Eagle St.

Nombre del fragmento: CLI_H2

909 High Ave.

$350.00 Nodo: MIA

Nombre del fragmento: CLI_H3

Martin Corp. BTBC, Inc. Victory, Inc.

321 Sunset Blvd. Rue du Monde 123 Maple St.

$6000.0 0 $6000.0 0 $1200.0 0

$1200.0 0 $5890.0 0 $550.00

$0.00 $1090.0 0 $0.00

2.4.2 Fragmentacin Vertical

Edif. de servicio Edif. de coleccin

CLI_NUM, CLI_NOM, CLI_DIR, CLI_UBI CLI_NUM, CLI_LIM, CLI_BAL, CLI_RAT, CLI_DUE

Nombre del fragmento: CLI_V1

Ubicacin: Edif. de servicio

Nombre del fragmento: CLI_V2

Ubicacin: Edif. de coleccin

$3500.00 $6000.00 $4000.00 $6000.00 $1200.00 $2000.00