Está en la página 1de 23

Ampliacin de BD

Bases de Datos Distribuidas 1. Introduccin


La tecnologa de los Sistemas de Gestin de BD Distribuidas (SGBDD) es la unin de lo que parece ser dos trminos opuestos: Sistemas de BD, por un lado, cuyo uso est motivado principalmente en el deseo de integrar los datos de una organizacin y proporcionar un acceso controlado centralizadamente a los datos. Y la tecnologa de Redes de ordenadores, por otra parte, que promociona un modo de trabajo que va contra los esfuerzos centralizados.

Estas dos aproximaciones pueden ser sintetizadas para producir una tecnologa que es ms poderosa y prometedora que cada una de ellas por separado. La clave consiste en pensar que el objetivo ms importante de la tecnologa de BD es la integracin, no la centralizacin. Las BDD aportan las ventajas de la computacin distribuida al dominio de la gestin de bases de datos. Un sistema de computacin distribuido consiste en un nmero de elementos autnomos de proceso (no necesariamente homogneos) que son interconectados por una red de ordenadores y que cooperan en la realizacin de ciertas tareas asignadas. Como objetivo general, estos sistemas dividen un problema grande en piezas ms pequeas y las resuleven eficientemente de forma coordinada. Una BDD es una coleccin de datos que pertenecen lgicamente al mismo sistema pero que estn distribuidos sobre diferentes ordenadores de la red. Esta definicin enfatiza dos aspectos importantes en una BDD: distribucin: los datos no residen en el mismo lugar. De este modo se puede distinguir una BDD de una BD centralizada. correlacin lgica, es decir, el hecho por el cual los datos tienen algunas propiedades o caractersticas que los relaciona. De este modo podemos distinguir una BDD de un conjunto de BD locales o ficheros residentes en diferentes lugares de una red de ordenadores.

Ejemplo: Consideremos un banco con 3 sucursales en diferentes localidades. En cada sucursal, un ordenador controla los terminales y una BD de cuentas de la sucursal. Cada ordenador con su BD local constituye una ubicacin de la BDD; los ordenadores estn conectados por una red de comunicacin. Durante las operaciones rutinarias, las aplicaciones que se ejecutan en las sucursales necesitan acceder a la BD propia. Estas aplicaciones son locales. Un ejemplo es una aplicacin de dbito o crdito realizada en una cuenta almacenada en la sucursal donde reside la aplicacin.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 1

Ampliacin de BD Desde un punto de vista tcnico, el aspecto realmente importante es la existencia de algunas aplicaciones que acceden o pueden acceder a datos de ms de una sucursal. As, cada lugar de la red debe tener capacidad de procesamiento autnomo y poder utilizar aplicaciones locales. Cada lugar tambin participa en la ejecucin de al menos una aplicacin global o distribuida, que requiere acceder a datos de varios lugares usando un subsistema de comunicaciones. La existencia de aplicaciones globales ser la caracterstica discriminante de una BDD con respecto a una BD centralizada.

Ejemplo: Para el caso anterior, una aplicacin tpica es la transferencia de fondos de una cuenta de una sucursal a otra. Esta aplicacin requiere actualizar las bases de datos de 2 sucursales diferentes. Para su correcto funcionamiento es necesario que se realicen las dos actualizaciones o ninguna. Asegurar este requerimiento para aplicaciones globales es una tarea difcil.

Ejemplo: Considerar el mismo banco del ejemplo anterior, con las mismas aplicaciones, pero con una configuracin del sistema como se muestra en la siguiente figura. Los mismos procesadores con sus BDs han sido movidos desde las sucursales a un edificio comn y estn ahora conectados con una red local. Las terminales de las sucursales estn conectadas a sus respectivos ordenadores por lnea telefnica. Cada procesador y su BD constituyen un ordenador local en la red.

Vemos que la estructura fsica de las conexiones ha cambiado con respecto al ejemplo anterior; sin embargo, los aspectos caractersticos de la arquitectura son los mismos. En particular, los ordenadores ejecutan las mismas aplicaciones accediendo a las mismas BDs. Una aplicacin que era local en el ejemplo previo es todava local, ya que el ser o no local no es una definicin con respecto a la distribucin geogrfica de los ordenadores que la ejecutan, sino con respecto al hecho que solamente un ordenador con su propia BD est implicado. Si hay aplicaciones globales, es conveniente considerar este ejemplo como una base de datos distribuida, porque la mayora de las caractersticas del ejemplo previo son vlidas.

Ejemplo: Considerar el mismo banco pero con una configuracin como la mostrada en la siguiente figura. Los datos de las diferentes sucursales estn distribuidos en 3 ordenadores de backend, que realizan funciones de gestin de bases de datos. Los programas de aplicacin son ejecutados por un ordenador diferente, que solicita servicios de acceso a los ordenadores backend cuando se necesita.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 2

Ampliacin de BD

Esto NO sera una BD Distribuida. La razn es que, aunque los datos estn fsicamente distribuidos en diferentes procesadores, su distribucin no es relevante desde el punto de vista de la aplicacin. Aqu se pierde la existencia de aplicaciones locales, en el sentido que la integracin del sistema ha alcanzado el punto donde ninguno de los ordenadores es capaz de ejecutar una aplicacin por s mismo.

Resumiendo, una BD Distribuida es una coleccin de datos que estn distribuidos sobre diferentes ordenadores de la red. Cada lugar de la red tiene capacidad de procesamiento autnomo y puede ejecutar aplicaciones locales. Cada lugar tambin participa en la ejecucin de al menos una aplicacin global, que requiere acceder a datos de varios lugares usando un subsistema de comunicaciones. En los ltimos aos, las BDD han llegado a ser un rea de importancia en el proceso de informacin, y es fcil prever que su importancia crecer rpidamente. Hay razones organizativas y tecnolgicas: Las BDD eliminan muchas de las carencias de las BD centralizadas y se acoplan mejor con las estructuras descentralizadas de muchas organizaciones.

1.1. Caractersticas de las BDD respecto a las BD centralizadas


1.1.1. Control centralizado
La posibilidad de proporcionar un control centralizado de la informacin fue una de las motivaciones ms fuertes para introducir las BD; fueron desarrolladas como evolucin de los Sistemas de Informacin en los que cada aplicacin tena sus propios ficheros privados. La funcin fundamental de un Administrador de BD (DBA) era garantizar la salud de los datos. En BDD la idea de control centralizado es mucho menos enfatizada. En general, en las BDD es posible identificar una estructura de control jerrquica basada en un DBA global, que tiene la responsabilidad de la BD en su totalidad, y DBA locales, que tendrn la responsabilidad de sus BD locales respectivas. Puede llegar a suceder que haya una total autonoma entre las distintas ubicaciones y que la coordinacin entre los distintos centros sea realizada por los administradores locales. Esto se llama autonoma local. Las BDD pueden diferir mucho segn el grado de autonoma.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 3

Ampliacin de BD

1.1.2.

Independencia de datos

Esencialmente, la independencia de datos significa que la organizacin de los datos es transparente al programador. Los programas son escritos teniendo una visin conceptual de los datos, el llamado esquema conceptual. La principal ventaja de la independencia de datos es que los programas no son afectados por cambios en la estructura fsica de los datos. En las BDD la independencia de datos tiene la misma importancia que en las BD centralizadas. Sin embargo, hay un nuevo aspecto adicional a la nocin de independencia de datos y es la llamada transparencia de distribucin; ello quiere decir que los programas pueden ser escritos como si las BD no estuvieran distribuidas. De este modo la correccin de programas no se ve afectada por el movimiento de datos de un lugar a otro, aunque la velocidad de ejecucin s. La independencia de datos se soluciona en una BD tradicional a travs de la arquitectura ANSI. De manera similar, en BDD la transparencia de distribucin se obtiene introduciendo diferentes niveles y esquemas de datos que veremos ms adelante.

1.1.3.
a) b)

Reduccin de redundancia

En las BD tradicionales, la redundancia es reducida en lo posible por dos razones: inconsistencias entre varias copias de los mismos datos lgicos son eliminados automticamente al tener una sola copia de

el espacio de almacenamiento es ahorrado eliminando redundancia. La reduccin redundancia se obtiene al compartir datos. En BD Distribuidas hay razones para considerar la redundancia como caracterstica deseable: a) b)

La autonoma de las aplicaciones puede ser incrementada si los datos son reproducidos en los lugares en que la aplicacin los necesita y la disponibilidad del sistema puede aumentar, debido a que un fallo local no afecta a la ejecucin de las aplicaciones en otros lugares.

La evaluacin del grado ptimo de redundancia requiere un anlisis complejo. El elemento principal a considerar es el porcentaje entre:
nmero de accesos por recuperacin nmero de accesos por actualizacin

realizados por las aplicaciones. La redundancia favorece la recuperacin, ya que si tenemos varias copias de un tem, la recuperacin puede ser realizada rpidamente en una copia. Sin embargo, debe tenerse en cuenta que las actualizaciones deben ser realizadas consistentemente en todas las copias.

1.1.4.

Estructuras fsicas complejas y accesos eficientes

Estructuras de acceso, como los ndices, son un aspecto importante en las BD tradicionales para garantizar un acceso eficiente a los datos. En BDD, disponer de estructuras fsicas intercentro no es la herramienta adecuada para un acceso eficiente porque son muy difciles de construir y mantener. En caso de una BDD podemos hablar de la necesidad de realizar optimizacin global y optimizacin local. La optimizacin global consiste en determinar qu datos deben ser accedidos en qu lugares. El parmetro principal a considerar aqu es el coste de comunicacin, aunque el coste de acceder a las BD locales debera tenerse en cuenta tambin. La importancia relativa de esos factores depende del ratio entre:
costes de comunicacin costes de acceso a disco

que depende del tipo de red de comunicacin. La optimizacin local consiste en decidir cmo realizar los accesos a las BD en cada lugar; los problemas de optimizacin local son tpicos de las BD tradicionales.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 4

Ampliacin de BD

1.1.5.

Integridad, recuperacin y control de concurrencia

La solucin a estos problemas est ligada al trmino transaccin. Una transaccin es una secuencia de operaciones que o son realizadas en su totalidad o no son realizadas ninguna de ellas. Un ejemplo de transaccin es una transferencia de fondos. La atomicidad de las transacciones es el medio que permite obtener integridad en las BD centralizadas, porque asegura que todas las acciones modifican la BD pasando de un estado consistente a otro. Hay dos enemigos de la atomicidad de las transacciones: fallos y concurrencia. La recuperacin trata con el problema de preservar la atomicidad de transacciones en la presencia de fallos. El control de concurrencia trata con el hecho de asegurar la atomicidad de las transacciones en la ejecucin concurrente de transacciones. Este problema puede ser visto como un problema de sincronizacin.

1.1.6.

Privacidad y seguridad

El DBA en BDs tradicionales puede asegurar que solamente los usuarios autorizados accedan a los datos para que los tengan privilegios. En las BDDs, hay dos aspectos peculiares: 1. si hay una autonoma local muy alta, los dueos de los datos locales se sienten ms protegidos porque ellos mismos pueden reforzar sus propias protecciones sin depender de una DBA centralizado 2. los problemas de seguridad son intrnsecos a los sistemas distribuidos, porque las redes de comunicacin pueden representar un punto dbil con respecto a la proteccin.

1.2. Ventajas e inconvenientes de las BDD


1.2.1.
1)

Por qu BDD?
Razones econmicas y organizativas: Muchas organizaciones estn descentralizadas, y una aproximacin de BDD se acopla ms naturalmente a la estructura de la organizacin. Hoy en da, la motivacin de tener grandes ordenadores centrales est siendo cuestionada. Interconexin de BD existentes: Las BDD son la solucin natural cuando varias BD ya existen en la organizacin y aparece la necesidad de realizar aplicaciones globales. En este caso, las BDD son creadas de abajoarriba desde las BD preexistentes. El proceso puede requerir cierto grado de reestructuracin; sin embargo, el esfuerzo requerido para ello es mucho menor que el necesario para la creacin de una nueva BD centralizada. Crecimiento incremental: Si una organizacin crece aadiendo nuevas unidades organizativas autnomas (nuevas sucursales, nuevos almacenes, etc.) entonces la aproximacin de BDD soporta un crecimiento incremental con un mnimo grado de impacto en las unidades ya existentes. Con una aproximacin centralizada, o las dimensiones iniciales del sistema tienen en cuenta la futura expansin, lo cual es difcil de prever y caro de implementar, o el crecimiento tiene un impacto mayor no solamente en las nuevas aplicaciones sino tambin en las existentes. Reducida sobrecarga de comunicacin: En una BD distribuida geogrficamente, el hecho de que muchas aplicaciones sean locales claramente reduce la sobrecarga de comunicacin con respecto a las BD centralizadas. Mejora del rendimiento: La base de datos est fragmentada manteniendo los datos cerca de donde ms se necesitan. Adems, la existencia de varios procesadores autnomos resulta en un incremento del rendimiento debido a un alto grado de paralelismo. El paralelismo intraconsulta e interconsulta puede conseguirse ejecutando varias consultas en sitios diferentes, o descomponiendo una consulta en subconsultas que puedan ejecutarse en paralelo. Fiabilidad y disponibilidad: La aproximacin distribuida, especialmente con datos redundantes, puede ser usada para obtener un alto grado de veracidad y disponibilidad. La capacidad de procesamiento autnomo de los diferentes centros no garantiza por s mismo un nivel ms alto de exactitud en el sistema, pero el efecto de fallos en las aplicaciones es menor; un fallo del sistema completo es infrecuente.

2)

3)

4)

5)

6)

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 5

Ampliacin de BD

1.2.2.

Desventajas de un SGBDD

Falta de experiencia: En la actualidad existen pocos SGBDD y no son usados comnmente. Lo que existen son prototipos o sistemas construidos para lneas areas o entidades bancarias. Complejidad: Los problemas de un SGBDD son mayores que los de los gestores centralizados. Coste: Los SGBDD requieren hardware adicional (mecanismos de comunicacin, etc.). Sin embargo la tendencia en los costes de hardware no hace que sea un aspecto importante. Otra fraccin importante de coste es el referente al software, ya que se requiere un software ms complejo. Pero quizs el componente de coste ms importante es el debido a la necesidad de mano de obra. Al estar distribuidos los datos y procesos, se necesita gente para mantenerlos. Ello implica un aumento de personal en operaciones de proceso de datos. Por lo tanto, se debe analizar la relacin entre el beneficio debido a un proceso ms eficiente y una informacin oportuna y los aumentos de coste de personal de operaciones. Distribucin del control: Aunque puede ser una ventaja tambin es una desventaja. La distribucin crea problemas de sincronizacin y coordinacin. Hay que adoptar polticas adecuadas para que la distribucin del control no sea una desventaja. Seguridad: Las BD centralizadas proporcionan un elevado grado de control de acceso a los datos. En un entorno distribuido est una red implicada, que es un medio que tiene sus propios requerimientos de seguridad. Hay muchos problemas de seguridad en redes. Dificultad de cambio de las BD centralizadas en BDD: No existen herramientas ni metodologas que ayuden a los usuarios a convertir sus BD en BDD.

1.3. Funciones adicionales de las BDD


La distribucin conlleva un incremento de la complejidad en el diseo e implementacin del sistema. As, el SGBDD deben proporcionar las siguientes funciones, adems de las propias de los SGBD centralizados: Mantenimiento de la ubicacin de los datos: la capacidad para seguir la pista a la distribucin de datos, la fragmentacin y la rplica expandiendo su catlogo. Procesamiento de consultas distribuidas: la capacidad para acceder a sitios remotos y transmitir consultas y datos a travs de varios sitios utilizando una red de comunicacin. Gestin de transacciones distribuidas: la capacidad de idear estrategias de ejecucin para consultas y transacciones que acceden a datos desde ms de un sitio y de sincronizar el acceso a datos distribuidos y mantener integridad sobre toda la BD. Gestin de datos replicados: la capacidad de decidir a qu copia de un elemento de datos replicado acceder y mantener la consistencia de copias de los elementos de datos replicados.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 6

Ampliacin de BD

2. Transparencia de distribucin
Este apartado trata los diferentes niveles en que un programador de aplicaciones puede ver una Base de Datos Distribuida, dependiendo del nivel de transparencia que proporcione el SGBD. Se denomina transparencia de distribucin a la independencia del programa de aplicacin respecto a la distribucin de los datos. La siguiente figura muestra una arquitectura de referencia para una BD distribuida:

NIVEL TRANSPARENCIA Esquema Global FRAGMENTACIN ----------------> Esquema de Fragmentacin UBICACIN-----------------------------> Esquema de Ubicacin MAPAS LOCALES------------------> = {fragmentos (datos sin solape) por relacin global} = {nodos de ubicacin por fragmento} = {datos} = relacin global

Esquema de mapas locales Gestor 1

Esquema de mapas locales

= imagen fsica = {objetos SGBD}

Gestor 2

BD Local 1

BD Local 2

Arquitectura de referencia para una BDD

Veamos cada uno de los elementos que forman la arquitectura: Esquema global define todos los datos que estn contenidos en la BDD como si la BD no fuese distribuida. Por esta razn, el esquema global puede ser definido exactamente de la misma manera que una BD no distribuida. Refirindose a un modelo relacional, tendramos relaciones globales. Fragmentos: cada relacin global puede ser dividida en porciones que no se solapen llamados fragmentos. El mapa resultante se denomina esquema de fragmentacin. Una relacin global puede dividirse en n fragmentos y un fragmento slo puede pertenecer a una relacin global. Los fragmentos se referencian por un nombre de relacin global y un subndice. Por ejemplo Ri indica el fragmento i de la relacin R. Los fragmentos son porciones lgicas de relaciones globales que pueden estar fsicamente ubicadas en uno o varios nodos de la red. El esquema de ubicacin define en qu nodos va a ser almacenado un fragmento. El tipo de mapa definido en el esquema de ubicacin determina si la BDD es redundante o no. Todos los fragmentos que corresponden a la misma relacin global R y estn ubicados en un nodo j constituyen la imagen fsica de R en el nodo j, y se denota como Rj.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 7

Ampliacin de BD
Ejemplo: En la figura se muestra una relacin global R dividida en 4 fragmentos R1, R2, R3 y R4. Los fragmentos estn ubicados redundantemente en 3 nodos de una red de ordenadores, constituyendo 3 imgenes fsicas.

Por ltimo, se denomina copia de fragmento a la informacin de un fragmento en un nodo determinado, y se denota usando el nombre de la relacin global, un subndice y un superndice. Ejemplo: R32 indica copia del fragmento R2 que est ubicado en el nodo 3.

En un nivel ms bajo, es necesario construir un mapa que relacione las imgenes fsicas con los objetos que son manipulados por los gestores locales. Este mapa se llama esquema de mapas locales y depende del tipo de SGBD local. Por lo tanto, en un sistema heterogneo tenemos diferentes tipos de mapas locales en los diferentes nodos. Esta arquitectura proporciona un marco conceptual de comprensin de las BDDs. Los tres objetivos ms importantes de esta arquitectura son: Separar el concepto de fragmentacin de datos del de ubicacin de datos: Esta separacin permite distinguir dos niveles diferentes de transparencia de la distribucin llamados transparencia de fragmentacin y transparencia de ubicacin. La transparencia de fragmentacin es el grado ms alto de transparencia y quiere decir que el usuario o programador de aplicaciones trabaja sobre relaciones globales. La transparencia de ubicacin es un grado inferior de transparencia y requiere que el usuario o programador de aplicaciones trabaje con fragmentos en lugar de relaciones globales; sin embargo, no es necesario saber donde se localizan los fragmentos. La separacin entre el concepto de fragmentacin y ubicacin es muy conveniente en diseo de BDD. Control explcito de redundancia: Una arquitectura de referencia proporciona un control de redundancia explcito al nivel de fragmento. Dado que los fragmentos son disjuntos podemos referirnos nicamente a sus replicaciones. Independencia de gestores locales: Esta caracterstica, denominada transparencia de mapas locales, permite estudiar varios problemas de gestin de BD Distribuidas sin necesidad de tener en cuenta los modelos de datos de los gestores locales. Claramente, en un sistema homogneo es posible definir los modelos de datos para los mismos gestores, reduciendo la complejidad de los mapas.

Otro tipo de transparencia relacionada con la transparencia de mapas locales es la transparencia de replicacin. Significa que el usuario no se da cuenta de la replicacin de los fragmentos. As, es posible, en ciertos casos, que el usuario no tenga transparencia de ubicacin pero tenga transparencia de replicacin. Es decir, puede que el usuario conozca los fragmentos y dnde se ubican sus diferentes copias, pero que no se encargue de actualizar dichas copias si se realiza alguna modificacin (de esta manera, cuando alguien actualiza una copia particular, el sistema local toma las acciones oportunas sobre las restantes copias). Se pueden usar sin distincin una de la otra.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 8

Ampliacin de BD

3. Diseo de BD Distribuidas
Disear una BD Distribuida no es una tarea sencilla. Desde el punto de vista tcnico surgen problemas nuevos tales como la interconexin entre nodos por una red de ordenadores y la distribucin ptima de datos y aplicaciones para alcanzar los requerimientos de estas. Desde el punto de vista organizativo, el tema de descentralizacin es crucial, ya que los sistemas distribuidos sustituyen a los sistemas centralizados, y distribuir una aplicacin tiene un importante impacto en la organizacin. Los pasos a realizar en el diseo de BD centralizadas son: 1. Disear el esquema conceptual y lgico que describe la BD 2. Disear fsicamente la BD En una BD Distribuida surgen dos problemas adicionales: 3. Disear el esquema de fragmentacin; es decir, determinar en qu fragmentos se subdivide el esquema global. 4. Disear la ubicacin de los fragmentos; es decir, determinar las imgenes fsicas y la replicacin de fragmentos. Para realizar un diseo adecuado, es necesario conocer una serie de parmetros que afectarn a la eficiencia de la aplicacin: El lugar donde se activa cada proceso de la aplicacin La frecuencia de activacin de cada proceso (nmero de peticiones por unidad de tiempo). En general, si los procesos pueden ser activados en mltiples lugares se necesita conocer la frecuencia de activacin de cada uno de ellos en cada lugar. El nmero y tipo de accesos por parte de cada proceso a cada dato.

3.1. Objetivos del diseo de Distribucin de datos


PROCESO LOCAL: Se debe intentar situar los datos tan cerca como sea posible a las aplicaciones que los usan, para conseguir con ello una mayor productividad, mejor tiempo de respuesta y mayor seguridad. La idea es disear la distribucin de datos para minimizar las referencias remotas. Esto puede hacerse contando el nmero de referencias locales y remotas que corresponden a cada candidato de fragmentacin y a cada candidato de ubicacin, y seleccionar la mejor solucin. Una extensin a este simple criterio es tener en cuenta cuando una aplicacin es de proceso local completo (aplicaciones que se ejecutan enteramente en sus lugares de origen). La ventaja del proceso local total no es solamente la reduccin de accesos, sino tambin la simplicidad en el control de la ejecucin de la aplicacin. DISPONIBILIDAD y FIABILIDAD DE LOS DATOS DISTRIBUIDOS: Esto se alcanza almacenando mltiples copias de la misma informacin, ya que as ser posible recuperar copias alternativas en caso de destruccin fsica de aquella que se pretenda utilizar. No obstante, hay que considerar el coste de actualizacin de cada copia para mantener la fiabilidad. DISTRIBUCIN DE LA CARGA DE TRABAJO: Hay que aprovecharse de la potencia de clculo de los ordenadores en cada lugar, y maximizar el paralelismo de ejecucin de aplicaciones. COSTES DE ALMACENAMIENTO Y DISPONIBILIDAD: Generalmente el coste de almacenamiento no es relevante comparado con el coste de CPU, I/O y transmisin, pero las limitaciones de almacenamiento en cada lugar deben ser consideradas.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 9

Ampliacin de BD

3.2. Aproximaciones al diseo de BD Distribuidas


DISEO TOP-DOWN: Bajo aproximacin top-down se empieza por disear el esquema global, despus el esquema de fragmentacin y el de ubicacin de los fragmentos, creando las imgenes fsicas en cada nodo. Por ltimo se realiza el diseo fsico de los datos de cada nodo. Esta aproximacin es til cuando se crean nuevos sistemas. DISEO BOTTOM-UP: Cuando la BD Distribuida se desarrolla por agregacin de BD ya existentes es necesario realizar un compromiso entre las descripciones originales de los datos. La aproximacin bottom-up se basa en la integracin de varios esquemas de datos para construir un nico esquema global. Se entiende por integracin la fusin de definiciones de datos comunes y la resolucin de conflictos entre las diferentes representaciones dadas a los mismos datos. Cuando diferentes BDs se agregan a una BD Distribuida es posible que se utilicen diferentes gestores de BD. Un sistema heterogneo aade complejidad a la integracin por necesitar una traduccin entre diferentes representaciones.

3.3. Diseo del esquema de fragmentacin


El diseo del esquema de fragmentacin es el primer problema a resolver en el diseo de BD Distribuidas, segn la aproximacin top-down. El propsito es disear fragmentos sin solapamientos llamados unidades lgicas de ubicacin. Disear fragmentos consiste en agrupar las tuplas (fragmentacin horizontal) o atributos (fragmentacin vertical) que tienen las mismas propiedades desde el punto de vista lgico y de ubicacin. Cada grupo de tuplas o atributos que poseen las mismas propiedades constituirn un fragmento. La idea bsica es que si dos elementos cualesquiera del mismo fragmento tienen las mismas propiedades desde el punto de vista de su ubicacin, cualquier mtodo para ubicar los datos los situar juntos. En todos los tipos de fragmentacin, un fragmento puede ser definido por una expresin en un lenguaje relacional que, sobre unos operadores (que son las relaciones globales), producen un resultado.
Ejemplo: Si una relacin global contiene datos sobre los empleados, un fragmento podra ser aquel que contiene solamente datos sobre los empleados que trabajan en el departamento D1.

A la hora de realizar la fragmentacin, hay algunas reglas que deben ser seguidas: Condicin de completitud: Todos los datos de una relacin global deben de estar contenidos en los fragmentos; es decir, no puede suceder que un tem de datos de una relacin global no pertenezca a ningn fragmento. Condicin de reconstruccin: Debe ser siempre posible reconstruir una relacin global desde sus fragmentos. Condicin de fragmentos disjuntos: Es conveniente que los fragmentos sean disjuntos, de modo que la replicacin de datos pueda ser controlada explcitamente en el nivel de ubicacin. Esta condicin es til, especialmente con fragmentacin horizontal.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 10

Ampliacin de BD

3.3.1.

Fragmentacin horizontal

La fragmentacin horizontal consiste en particionar las tuplas de una relacin global en subconjuntos. Se define cada fragmento con una operacin de seleccin () sobre la relacin global.
Ejemplo: Supongamos la siguiente relacin global: PROV (nupro, nopro, nolocpro) La fragmentacin horizontal puede ser definida de la siguiente forma: PROV1 = PROV2 =

nolocpro = Madrid (PROV) nolocpro = Barcelona (PROV)

Comprobacin de las reglas: Completitud: la fragmentacin satisface esta condicin si Madrid y Barcelona son los nicos valores posibles del atributo nolocpro; de otra forma no podramos conocer a qu fragmento pertenecen las tuplas con otros valores en nolocpro. Reconstruccin: esta condicin se verifica fcilmente, ya que siempre es posible reconstruir la relacin global PROV con la operacin UNION:
PROV = PROV1 PROV2

Fragmentos disjuntos: trivial

El predicado que es usado en la operacin de seleccin que define un fragmento se llama predicado de cualificacin.
Ejemplo: Para el ejemplo anterior los predicados de cualificacin son: q1: PROV.nolocpro = Madrid q2: PROV.nolocpro = Barcelona

La fragmentacin horizontal requiere que cada tupla de la relacin global sea seleccionada en uno y slo uno de los fragmentos. Por lo tanto, determinar la fragmentacin horizontal de una relacin global requiere determinar un conjunto de predicados de cualificacin disjuntos y completos. La propiedad que se requiere para cada fragmento es que cada uno de sus elementos debe ser referenciado homogneamente por todas las aplicaciones. De forma general, sea R la relacin global para la que queremos producir una fragmentacin horizontal primaria. Introducimos las siguientes definiciones: 1. Un predicado simple pi es un predicado de la forma: Atributo = valor 2. Un predicado de cualificacin q para un conjunto P de predicados simples es la conjuncin (AND) de todos los predicados simples que aparecen en P, en su forma natural o negada, siempre que no sea una contradiccin: q = ^p*i pi P donde p*i es (pi) (NOT pi) y q no es falso 3. Un fragmento es el conjunto de todas las tuplas para las que se cumple un predicado de cualificacin. 4. Un predicado simple pi es relevante con respecto a un conjunto P de predicados simples si existen al menos 2 predicados de cualificacin cuyas expresiones difieren solamente en el predicado pi (el cual aparece en la forma natural en un caso y negada en el otro) de forma que los fragmentos correspondientes son referenciados de una forma diferente por al menos una aplicacin. Es decir, si un predicado causa que un fragmento f sea dividido en dos (fi y fj) debera haber al menos una aplicacin que accediese de forma diferente a ambos fragmentos.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 11

Ampliacin de BD Las definiciones anteriores no son constructivas; no sabemos cmo construir fragmentacin. Desafortunadamente, la seleccin de predicados no puede hacerse con reglas precisas, y juega un papel importante la intuicin del diseador de la BD. Sin embargo, se pueden definir algunas propiedades que caracterizan una fragmentacin adecuada: Sea P={p1, p2,..., pn} un conjunto de predicados simples. Para que P represente una fragmentacin correcta y eficiente, P debe ser completo y mnimo: 1. Se dice que P es completo si y slo si cualquier tupla que pertenezca al mismo fragmento se referencia con la misma probabilidad por cualquier aplicacin. 2. Se dice que P es mnimo si todos los predicados pi son relevantes.

3.3.2.

Fragmentacin horizontal derivada

La fragmentacin horizontal derivada de una relacin global R no est basada en propiedades de sus propios atributos, sino que es derivada de la fragmentacin horizontal de otra relacin. Es usada para facilitar las operaciones de join entre fragmentos.
Ejemplo: Consideremos la relacin: PED (nuped, nupro, nupieza, nudep, qped) Si quisiramos dividir esta relacin para que cada fragmento tenga las tuplas de los proveedores que son de una ciudad dada, como el atributo localidad pertenece a la relacin PROV, se necesita una operacin de semi-join para determinar qu tuplas de PED corresponden a proveedores de una localidad determinada. La fragmentacin derivada de PROV puede definirse as: PED1 = PED

PED.nupro = PROV1.nupro PROV1

PED2 = PED PED.nupro = PROV2.nupro PROV2 El efecto de la operacin de semi-join es seleccionar de PED las tuplas que satisfacen la condicin de join entre PROV1 PROV2 y PED.

Cuando una relacin global R tiene una fragmentacin derivada, las cualificaciones de sus fragmentos no pueden ser expresadas como predicados que utilizan atributos de R. La condicin para una tupla t de pertenecer a un fragmento dado Ri de R es de existencia, en algn otro fragmento de Si de S, de una tupla t tal que t y t satisface la especificacin de semi-join de la fragmentacin derivada.
Ejemplo: Considerando el ejemplo anterior, representamos esta condicin de la siguiente manera: q1: PED.nupro = PROV.nupro AND PROV.nulocpro = Madrid q2: PED.nupro = PROV.nupro AND PROV.nulocpro = Barcelona

Comprobacin de las reglas: Completitud: la completitud requiere que no haya nmeros de proveedores en PED que no estn contenidos en PROV. Esto se garantiza por la restriccin de integridad referencial. Reconstruccin: la reconstruccin de la relacin global PED puede ser realizada por la operacin de UNION.
PED = PED1 PED2

Fragmentos disjuntos: esta condicin se cumple si una tupla de la relacin PED no se corresponde con dos tuplas de PROV que pertenezcan a dos fragmentos diferentes.
Ejemplo: En este caso, la condicin es fcilmente verificada, porque el atributo nupro es clave en la relacin PROV.

En general no resulta tan fcil probar que se mantiene esta condicin.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 12

Ampliacin de BD

3.3.3.

Join Distribuido

Un join distribuido es un join entre relaciones fragmentadas horizontalmente. Cuando una aplicacin requiere un join entre dos relaciones globales R y S, todas las tuplas de R y S necesitan ser comparadas. As, en principio, es necesario comparar todos los fragmentos Ri de R con todos los fragmentos Sj de S. Algunas veces es posible deducir que algunos de los joins parciales Ri Sj estn vacos. Esto sucede cuando, para una distribucin de datos dada, los valores del atributo de join en Ri y Sj son disjuntos. Los joins distribuidos se pueden representar utilizando grafos de join. Un grafo de join del join distribuido R S es un grafo donde los nodos representan fragmentos de R y S, y los ejes entre nodos representan joins entre fragmentos que no estn vacos. Se dice que un grafo de join es total cuando contiene todos los posibles ejes entre los fragmentos de R y S. Sin embargo, por simplicidad generalmente no se incluyen los ejes entre fragmentos de R y S que dan lugar a un join vaco. En este caso, el grafo de join se denomina reducido. Hay dos tipos de grafos de join reducidos que son particularmente relevantes: 1. Un grafo de join reducido es particionado si el grafo est compuesto de 2 o ms subgrafos sin ejes entre ellos. 2. Un grafo de join reducido es simple si es particionado y cada subgrafo tiene slo un eje.
Ejemplo:

Determinar que un join tiene un grafo de join simple es muy importante en el diseo. Dado que, en este caso, los fragmentos se conectan por un nico eje (y tienen un conjunto de valores comunes para los atributos de join) pueden ubicarse fsicamente en el mismo lugar. Entonces el join puede ser realizado de forma distribuida, por join de pares de fragmentos locales y obtener de esa manera los resultados de esos joins parciales. Es importante disear la BD de forma que los joins realizados frecuentemente tengan un grafo de join simple. Consideremos una relacin global R cuyos fragmentos Ri sean derivados de la fragmentacin de S por un semijoin: R Si. Cumpliendo las condiciones de conjuntos disjuntos y completitud, este join es simple. La idea es considerar la fragmentacin derivada como una alternativa a la fragmentacin primaria.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 13

Ampliacin de BD

3.3.4.

Fragmentacin vertical

La fragmentacin vertical de una relacin global es la subdivisin de sus atributos en conjuntos de modo que sean referenciados de la misma manera por las aplicaciones. Los fragmentos son obtenidos proyectando () la relacin global en cada grupo. Esto puede ser til en BDDs cuando cada conjunto de atributos puede contener datos que tienen propiedades geogrficas comunes y con tratamientos diferenciados.
Ejemplo: Consideremos la siguiente relacin: EMP (nuemp, noemp, isalemp, itasaemp, nudep) Una fragmentacin vertical de esta relacin puede definirse como: EMP1 = nuemp, noemp, nudep (EMP) EMP2 = nuemp, isalemp, itasaemp (EMP) Esta fragmentacin podra, por ejemplo, reflejar una organizacin en la que los salarios y tasas son gestionados separadamente.

Comprobacin de las reglas: Completitud: Es trivial siempre que todos los atributos de la relacin global aparezcan en al menos uno de los fragmentos. Reconstruccin: La reconstruccin de la relacin global se realiza mediante un join de los fragmentos.
Ejemplo: La reconstruccin de la relacin EMP puede ser obtenida de la siguiente forma: EMP = EMP1 EMP1.nuemp = EMP2.nuemp EMP2 siendo nuemp clave de EMP.

En general, la inclusin de una clave de la relacin global en cada fragmento es la mejor forma de garantizar que la reconstruccin a travs de un join es posible. Un camino alternativo es generar identificadores de tuplas que son usados como claves. Ello puede ser conveniente para eliminar la reproduccin de claves muy grandes. Los identificadores de tuplas no pueden ser modificados por los usuarios. Fragmentos disjuntos: En general, en la fragmentacin vertical no es tan importante mantener conjuntos disjuntos como en la fragmentacin horizontal. De hecho, si se incluyen los mismos atributos (denominados rplicas) en diferentes fragmentos verticales, sabemos exactamente que los datos reproducidos son los que se corresponden a dicho atributo.
Ejemplo: Si diseamos los fragmentos verticales: EMP1 = EMP2 =
nuemp, noemp, nudep

(EMP) (EMP)

nuemp, noemp, isalemp, itasaemp

El atributo noemp est reproducido en los dos fragmentos. Se puede explcitamente eliminar este atributo al reconstruir la relacin global EMP, de la siguiente forma: EMP = EMP1 EMP1.nuemp = t.nuemp t (
nuemp, isalemp, itasaemp

(EMP2))

Determinar una fragmentacin para una relacin global R no es fcil, ya que el nmero de posibles particiones crece combinatoriamente con el nmero de atributos de R, y el nmero de posibles agrupamientos es an mayor. En el caso de una relacin con muchos atributos, son necesarias aproximaciones heursticas para determinar las particiones o grupos. Como veremos, la replicacin de atributos tiene efectos diferentes en aplicaciones de slo lectura de las que involucran actualizacin. Las de slo lectura se aprovechan de la replicacin, porque posibilitan mejor los accesos locales. Para aplicaciones de actualizacin no es conveniente, ya que se deben actualizar todas las copias para preservar la consistencia.
Ejemplo: Consideremos que dos fragmentos R1 y R2 se solapan; es decir, existe un conjunto de atributos l que pertenecen a ambos fragmentos. Asumir que dichos fragmentos estn en los nodos 1 y 2. Las aplicaciones de lectura del nodo 1 usan los atributos l junto con otros atributos de R1, y son locales; de la misma manera las aplicaciones de lectura del nodo 2 usan los atributos l junto con otros atributos de R2 y son locales. Sin embargo, las aplicaciones de actualizacin que cambien los valores de l necesitan referenciar ambos nodos. Por lo tanto, cuando se evala la conveniencia de replicar atributos, es importante que los atributos que se solapan no tengan una carga pesada de actualizacin.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 14

Ampliacin de BD

3.3.5.

Fragmentacin mixta

Los fragmentos que se obtienen en las operaciones de fragmentacin anteriores son relaciones en s mismas, por lo que es posible aplicar operaciones de fragmentacin de forma recursiva, siempre y cuando se satisfagan las reglas. Sin embargo, no se deberan definir fragmentos intermedios innecesarios. La reconstruccin se obtiene aplicando las reglas de reconstruccin en orden inverso.
Ejemplo: Consideremos la relacin EMP anterior: EMP (nuemp, noemp, isalemp, itasaemp, nudep) Consideremos las fragmentaciones siguientes: EMP1 = EMP2 = EMP3 =

nudep < 10 ( nuemp, noemp, nudep (EMP)) 10<= nudep <= 20 ( nuemp, noemp, nudep (EMP)) nudep > 20 ( nuemp, noemp, nudep (EMP))

EMP4 = nuemp, noemp, isalemp, itasaemp (EMP)

Es posible representar la fragmentacin mediante un rbol de fragmentacin, donde la raz corresponde a la relacin global, las hojas a los fragmentos y los nodos intermedios corresponden a los resultados intermedios de las expresiones que definen los fragmentos. El conjunto de nodos hijo de un nodo dado representan la descomposicin de dicho nodo por una operacin de fragmentacin.
EMP

vert. EMP4 horiz. EMP1 EMP2 EMP3

La reconstruccin de la relacin EMP se define por la siguiente expresin: EMP =

t1(EMP1 EMP2 EMP3) t1.nuemp = t2.nuemp t2 ( nuemp, isalemp, itasaemp EMP4)

Aunque se pueden generar rboles de fragmentacin muy complejos, normalmente debe ser suficiente con dos niveles. La segunda fragmentacin puede ser aplicada a subconjuntos de fragmentos producidos por la primera.

3.4. Diseo del esquema de ubicacin


Es importante distinguir entre ubicacin redundante y no redundante.

3.4.1.

Ubicacin no redundante

El mtodo ms simple es aplicar una medida del beneficio que supone ubicar cada uno de los fragmentos en los diferentes nodos, y seleccionar aquella opcin cuya medida sea la mejor. El problema de esta aproximacin es que descuida el efecto mutuo de situar un fragmento en un lugar determinado si un fragmento relacionado ya est en el mismo lugar.

3.4.2.

Ubicacin redundante

La replicacin introduce complejidad en el diseo, porque el grado de replicacin es un problema en s mismo, y modelar aplicaciones de slo lectura es complicado por el hecho de que las aplicaciones pueden elegir diferentes lugares de acceso a los fragmentos.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 15

Ampliacin de BD Para determinar una ubicacin redundante de los fragmentos, se pueden usar dos mtodos: 1. Determinar el conjunto de todos los lugares donde el beneficio para ubicar una copia del fragmento sea mayor que el coste, y ubicar una copia del fragmento en cada uno de estos lugares; este mtodo selecciona los sitios que se benefician. Determinar primero la solucin al problema de no replicacin, y entonces progresivamente introducir copias comenzando con los sitios que ms se beneficien. El proceso se termina cuando no haya beneficio adicional para la replicacin.

2.

Ambos mtodos tienen desventajas. En el primero, cuantificar costes y beneficios para cada fragmento de ubicacin individual es ms critico que en el caso de no redundancia, porque descuida el efecto mutuo de ubicar diferentes copias del mismo fragmento. El segundo mtodo es una aproximacin heurstica. Con este mtodo es posible tener en cuenta que el incremento en el grado de redundancia es progresivamente menos beneficioso. La fiabilidad y disponibilidad del sistema se incrementan si hay dos o tres copias del fragmento, pero muchas copias producen un incremento menor.

4. Transparencia de distribucin
4.1. Transparencia de distribucin en aplicaciones de lectura

Ejemplo: Supongamos la siguiente relacin global: PROVEEDOR (nupro, nopro, nolocpro) dividida horizontalmente de la siguiente forma: PROVEEDOR1 = PROVEEDOR2 =

nolocpro = Madrid (PROVEEDOR) nolocpro = Barcelona (PROVEEDOR)

y que los fragmentos se encuentran ubicados segn se muestra en la figura:

Supongamos que se desea aceptar un nmero de proveedor por terminal y visualizar, si existe, su nombre

Veamos lo que sucede segn los diferentes niveles de transparencia que pueden ofrecernos los gestores distribuidos: Nivel 1: Transparencia de fragmentacin
Read (terminal, $vnum); select nopro from PROVEEDOR where PROVEEDOR.nupro = $vnum;

Desde el punto de vista de transparencia de fragmentacin, el ejemplo se refiere a la relacin global PROVEEDOR, ignorando completamente el hecho de que la BD es distribuida. Los programas desarrollados para este nivel de transparencia son independientes de cambios en la fragmentacin, en la ubicacin y replicacin de fragmentos e incluso en el nombre de los ficheros locales.

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 16

Ampliacin de BD

Nivel 2: Transparencia de ubicacin Si el gestor proporciona transparencia de ubicacin pero no de fragmentacin, el mismo ejemplo podra ser escrito de la siguiente forma:
Read (terminal, $vnum); select nopro from PROVEEDOR1 where PROVEEDOR1.nupro = $vnum; If not FOUND then select nopro from PROVEEDOR2 where PROVEEDOR2.nupro = $vnum;

Hay otras variaciones posibles a esta solucin. Una de ellas es ejecutar ambas select en paralelo para explotar el paralelismo del sistema distribuido. Sin embargo, ello no cambia las caractersticas de la transparencia de la distribucin. El ejemplo es independiente de los cambios en el esquema de ubicacin, pero no en los cambios del esquema de fragmentacin, porque la estructura de fragmentacin est incorporada en la aplicacin. Sin embargo, la transparencia de ubicacin es til ya que permite que la aplicacin ignore qu copias existen de cada fragmento, permitiendo que las copias sean movidas de un nodo a otro, y permitiendo la creacin de nuevas copias sin que afecte a las aplicaciones.

Nivel 3: Transparencia de mapas locales En este nivel, asumimos que la aplicacin se refiere a objetos cuyos nombres son independientes de los sistemas locales individuales; sin embargo, se tiene que especificar en qu lugares residen los objetos. Los lugares se especifican con la clusula at. En este caso, cada acceso a la BD es encaminado por el gestor distribuido al nodo especfico. Sin embargo, los nombres de fragmento son independientes del nodo. Si este mapa no fuera proporcionado, el programa tendra que incorporar directamente los nombres de los ficheros usados por los sistemas locales.

Read (terminal, $vnum); select nopro from PROVEEDOR1 at lugar1 where PROVEEDOR1.nupro = $vnum; If not FOUND then select nopro from PROVEEDOR2 at lugar3 where PROVEEDOR2.nupro = $vnum;

En este caso, si el gestor en el nodo1 fuese relacional y el gestor local en el nodo3 fuese objetual, por ejemplo, para poder proporcionar este nivel de transparencia, el gestor distribuido tiene que transformar la sentencia anterior a las correspondientes en SQL y OQL, respectivamente. Incluso aunque se tratase de un sistema homogneo (es decir, que los gestores locales fuesen del mismo tipo) habra que realizar igualmente la traduccin porque la sintaxis del programa global no es igual a la de un modelo concreto (relacional, objetual, etc.).

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 17

Ampliacin de BD

4.1.1.

Un ejemplo ms complejo

Ejemplo: Supongamos las siguientes relaciones globales: PROVEEDOR (nupro, nopro, nolocpro) PEDIDO (nuped, nupro, nupieza, nudep, qped) divididas horizontalmente de la siguiente forma: PROVEEDOR1 = PROVEEDOR2 =

nolocpro = Madrid (PROVEEDOR) nolocpro = Barcelona (PROVEEDOR)


nupro = nupro PROVEEDOR1 nupro = nupro PROVEEDOR2

PEDIDO1 = PEDIDO PEDIDO2 = PEDIDO

Y que se desea aceptar un nmero de pieza por terminal y visualizar, si existe, el nombre del proveedor que lo suministra

Nivel 1: Transparencia de fragmentacin

Nivel 2: Transparencia de ubicacin

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 18

Ampliacin de BD

Nivel 3: Transparencia de mapas locales

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 19

Ampliacin de BD

4.2. Transparencia actualizacin

de

distribucin

para

aplicaciones

de

Consideraremos un ejemplo de actualizacin desde el punto de vista de transparencia de la distribucin. Una actualizacin requiere que sea realizada en todas las copias del elemento de datos que se modifica, mientras que una operacin de consulta se realiza sobre una sola copia. Esto significa que si el gestor distribuido no proporciona transparencia de ubicacin y replicacin, el programador es el responsable de realizar todas las operaciones de actualizacin. Existe otro problema aadido:
Ejemplo: Supongamos el ejemplo anterior. Consideremos que un proveedor cambia de localidad. Ello significa que la tupla debe ser movida de un fragmento a otro y las tuplas de PEDIDO que se refieren al proveedor modificado tambin cambian de fragmento, porque la relacin PEDIDO tiene una fragmentacin derivada.

Cambiar el valor de un atributo que es usado en la definicin de un esquema de fragmentacin puede traer efectos complejos.
Ejemplo: Consideremos la relacin EMP: EMP (nuemp, noemp, isalemp, itasaemp, nudep) fragmentada del siguiente modo: EMP1 = EMP2 = EMP3 =

EMP

nudep < 10 ( nuemp, noemp, nudep (EMP)) 10<= nudep <= 20 ( nuemp, noemp, nudep (EMP)) nudep > 20 ( nuemp, noemp, nudep (EMP))
horiz. EMP1 EMP2

vert. EMP4

EMP4 = nuemp, noemp, isalemp, itasaemp (EMP) y supongamos que queremos actualizar el atributo nudep.

EMP3

El efecto de un cambio de un valor de un atributo est limitado a los fragmentos hoja de su subrbol de actualizacin. Ejemplo: el cambio de nudep afecta slo a EMP1, EMP2 y EMP3, pero no a EMP4.
Ejemplo: Supongamos que la relacin EMP tiene el siguiente esquema de fragmentacin: EMP1 = nudep <= 10 ( EMP2 = nudep <= 10 ( EMP3 = nudep > 10 ( EMP4 = nudep > 10 (
nuemp, noemp, isalemp, itasaemp

(EMP))

EMP

nuemp, nudep

(EMP)) (EMP)) (EMP))

nuemp, noemp, nudep

horiz. vert.

vert.

nuemp, isalemp, itasaemp

EMP1

EMP2

EMP3

EMP4

El efecto de cambiar el valor de nudep de 3 a 15 para el empleado 100 implica que una tupla, originalmente almacenada en los fragmentos que pertenecan al subrbol izquierdo, pasa a formar parte del subrbol derecho. No solamente ha habido cambio de fragmento sino que tambin la tupla ha sido descompuesta de una forma distinta: a) Antes de actualizar: EMP1 nuemp 100 noemp Garca isalemp 10000 itasaemp 10 nuemp 100 EMP2 nudep 3

b) Despus de actualizar: EMP3 nuemp 100 noemp Garca nudep 15 nuemp 100 EMP4 isalemp 10000 itasaemp 10

El conjunto de operaciones a realizar son:

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 20

Ampliacin de BD
seleccin de informacin en EMP1 insercin en EMP3 y EMP4 borrado de EMP1 y EMP2

Nivel 1: Transparencia de fragmentacin

Nivel 2: Transparencia de ubicacin

Nivel 3: Transparencia de mapas locales


Supongamos que los fragmentos de la relacin EMP estn ubicados de la siguiente manera: EMP1 EMP2 EMP3 EMP4 lugares 1 y 5 lugares 2 y 6 lugares 3 y 7 lugares 4 y 8

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 21

Ampliacin de BD

5. Ejemplo de diseo de una BD Distribuida


Utilizando las relaciones que se reflejan en el siguiente diagrama E-R y cuyos atributos se detallan a continuacin:

DPTO (ndep, nomdep) -> n y nombre de departamento EMP (nemp, nomemp, ndep, faltaemp, isalemp, itasaemp, njob) -> n de empleado, nombre y apellidos del empleado, n de departamento al que pertenece, fecha de alta del empleado en la empresa, importe de haberes anuales, importe de tasas anuales y puesto que ocupa. PROYECTO (npro, nompro, ctiproy, iprproy, ndep) -> n de proyecto, nombre del proyecto, cdigo del tipo de proyecto, importe presupuestado, n de departamento responsable del proyecto. PLANPROY (npro, nemp, qhppp, qhrpp) -> n de proyecto, n empleado, cantidad de horas plan del empleado en el proyecto, cantidad de horas reales realizadas por el empleado en el proyecto.

Supongamos que cada departamento es un nodo de la BD Distribuida. Un departamento est compuesto por n empleados. Un Departamento puede tener proyectos bajo su responsabilidad. Cada proyecto debe tener un plan de trabajo en el que se especifique qu empleados se requieren; por lo tanto, se precisa informacin de los empleados que son miembros de sus proyectos. Un empleado puede participar en ms de un proyecto. a) Disear el esquema de fragmentacin teniendo en cuenta: Todas las aplicaciones departamentales acceden de modo similar a la informacin total de la relacin global Departamento Cada Departamento tiene acceso a la informacin de los empleados de toda la empresa, exceptuando a los datos de Coste (isalemp, itasaemp). Las aplicaciones del Departamento de Recursos Humanos utilizan todos los datos, y son los responsables de su actualizacin. La frecuencia de utilizacin de las aplicaciones contables es pequea, mientras que los departamentos acceden con una frecuencia alta a los datos de empleados. Algunos departamentos de la empresa realizan proyectos. Cualquier departamento puede requerir informacin sobre los empleados que son miembros de proyectos; sin embargo, cada departamento referencia las tuplas de sus empleados y los proyectos bajo su responsabilidad con una probabilidad mayor que otros empleados o proyectos. Los departamentos que no son responsables de proyectos slo pueden referenciar de la relacin PROYECTO los atributos (npro, nompro, ctiproy,ndep) y no pueden referenciar tuplas sobre la relacin PLANPROY. Los departamentos responsables de proyectos son: 1 = departamento de Organizacin 2 = departamento de Informtica 3 = departamento de Investigacin Empresarial Adems, la empresa cuenta con el Departamento de Recursos Humanos, antes mencionado. b) Especificar el esquema de ubicacin c) Construir las relaciones globales desde los fragmentos

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 22

Ampliacin de BD

BIBLIOGRAFA
Ceri, S.; Pelagatti, G. Distributed Databases. Principles & Systems. McGraw-Hill, 1985 Elmasri, R.; Navathe, S. Fundamentos de Sistemas de Bases de Datos (3 edicin). Addison-Wesley, 2002 [cap. 24]

BD Distribuidas. Eva L. Iglesias. E.S.E.I. Universidade de Vigo

pg: 23