Está en la página 1de 15

INSTITUTO TECNOLGICO DE PUEBLA

Profesor: Actuario Jos Lpez Ponciano Materia: Base de Datos Distribuidas Hora: 13-15 hrs Integrantes: Adrin Huerta Serrano Hugo Alejandro Fernndez Garcilazo Moiss Gabriel Gutirrez Morales

Un sistema de base de datos distribuida consiste en una coleccin de sitios, conectados por medio de algn tipo de red de comunicacin, en el cual a. cada sitio es un sistema de base de datos completo por derecho propio, pero b. los sitios han acordado trabajar juntos, a fin de que un usuario de cualquier sitio pueda acceder a los datos desde cualquier lugar de la red, exactamente como si los datos estuvieran guardados en el propio sitio del usuario. De aqu deducimos que la llamada "base de datos distribuida" es en realidad un tipo de base de datos virtual cuyas partes componentes estn almacenadas en varias bases de datos "reales" distintas que se encuentran en varios sitios distintos (de hecho, es la unin lgica de esas bases de datos reales).

Para repetir, observe que cada sitio es un sitio de sistema de base de datos por derecho propio. En otras palabras, cada sitio tiene sus propias bases de datos "reales", sus propios usuarios locales, su propio DBMS local y software de administracin de transacciones (incluyendo su propio software local para bloqueo, registro en bitcora, recuperacin, etctera), as como su propio administrador CD (de comunicacin de datos) local. En particular, un usuario determinado puede realizar operaciones sobre los datos desde su propio sitio local, tal como si ese sitio no participara nunca en el sistema distribuido (al menos, ste es un objetivo). Entonces, el sistema de base de datos distribuida puede ser considerado como un tipo de sociedad entre los DBMSs locales en cada uno de los sitios locales; un nuevo componente de software en cada sitio de manera lgica, una extensin del DBMS local proporciona la funcionalidad de sociedad necesaria, y es la combinacin de este nuevo componente y el DBMS existente, lo que constituye lo que generalmente llamamos sistema de administracin de base de datos distribuida. Dos "sitios" pueden incluso coexistir en la misma mquina fsica (especialmente durante el perodo de la prueba inicial del sistema). De hecho, el nfasis sobre los sistemas distribuidos ha ido y venido a lo largo del tiempo. Las primeras investigaciones tendan a dar por hecho la distribucin geogrfica; sin embargo la mayora de las primeras instalaciones comerciales involucraban la distribucin local con (por ejemplo) varios "sitios" en el mismo edificio y conectados por medio de una LAN (red de rea local). Sin embargo, ms recientemente la enorme proliferacin de las WANs (redes de rea amplia) ha revivido nuevamente el inters en la posibilidad de una distribucin geogrfica. En cualquier caso, desde una perspectiva de base de datos, hay muy poca diferencia ya que es necesario resolver prcticamente los mismos problemas tcnicos (de la base de datos). Nota: Para simplificar la explicacin supondremos, mientras no digamos otra cosa, que el sistema es homogneo en el sentido de que cada sitio est ejecutando una copia del mismo DBMS. Nos referiremos a esto como la suposicin de homogeneidad estricta.

Ventajas Por qu son necesarias las bases de datos distribuidas? La respuesta bsica a esta pregunta es que las empresas ya estn generalmente distribuidas al menos de manera lgica (en divisiones, departamentos, grupos de trabajo, etctera) y es muy probable que tambin lo estn de manera fsica (en plantas, fbricas, laboratorios, etctera); de esto deducimos que por lo general tambin los datos ya estn distribuidos, ya que cada unidad organizacional dentro de la empresa mantendr naturalmente los datos que son importantes para su propia operacin. Por lo tanto, el valor de la informacin total de la empresa est dividido en lo que a veces llamamos islas de informacin. Y lo que hace un sistema distribuido es proporcionar los puentes necesarios para conectar a esas islas entre s. En otras palabras, permite que la estructura de la

base de datos refleje la estructura de la empresa los datos locales son conservados localmente en el lugar donde pertenecen de manera ms lgica y al mismo tiempo, permite tener acceso a datos remotos cuando sea necesario. Un ejemplo le ayudar a aclarar lo anterior. Por razones de simplicidad, suponga que hay solamente dos sitios, Los ngeles y San Francisco, y suponga que es un sistema bancario donde los datos de las cuentas de Los ngeles son conservados en Los ngeles y los datos de las cuentas de San Francisco son conservados en San Francisco. Las ventajas son claramente obvias: el arreglo distribuido combina la eficiencia de procesamiento (los datos se mantienen cerca del punto en donde se usan ms frecuentemente) con una mayor accesibilidad (es posible acceder a una cuenta de Los ngeles desde San Francisco y viceversa, por medio de la red de comunicaciones). Probablemente, el mayor beneficio de los sistemas distribuidos es que permiten que la estructura de la base de datos refleje la estructura de la empresa (como acabamos de explicar). Por supuesto, tambin se acumulan muchos beneficios adicionales.

LOS DOCE 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 F para su operacin satisfactoria (ya que de lo contrario, cualquier falla en el sitio y podra significar que el sitio X no pueda ejecutar operaciones, aun cuando no haya nada malo en el propio sitio X, lo que es obviamente una situacin indeseable). La autonoma local tambin implica que los datos locales son posedos y administrados localmente con contabilidad local: todos los datos pertenecen "realmente" a alguna base de datos local, aun cuando estn accesibles desde otros sitios remotos. Por lo tanto, la seguridad, integridad y representacin de almacenamiento de los datos locales permanecen bajo el control y jurisdiccin del sitio local. De hecho, el objetivo de autonoma local no es totalmente alcanzable; existen varias situaciones en las que un sitio X dado debe transferir un determinado grado de control a algn otro sitio y. Por lo tanto, el objetivo de autonoma queda establecido con mayor precisin como: los sitios deben ser autnomos en el mayor grado posible.

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 por ejemplo, procesamiento centralizado de consultas, administracin centralizada de transacciones o servicios centralizados de asignacin de nombres tal que todo el sistema dependa de ese sitio central. Por lo tanto, este segundo objetivo es un corolario del primero (si el primero logra, el segundo tambin forzosamente). Pero "la no dependencia de un sitio central" es necesaria por s misma, aunque no se logre la autonoma local completa. Por lo tanto, vale la pena mencionarlo como un objetivo independiente. La dependencia de un sitio central sera indeseable por las siguientes dos razones (como mnimo). Primero, el sitio central puede ser un cuello de botella. Segundo y ms importante, el sistema sera vulnerable; es decir, si el sitio central falla, tambin fallar todo el sistema (el problema del "nico punto de falla"). 3. Operacin continua En general, una ventaja de los sistemas distribuidos es que deben proporcionar mayor confiabilidad y mayor disponibilidad. La confiabilidad (es decir, la probabilidad de que el sistema est listo y funcionando en cualquier momento dado) mejora, ya que los sistemas distribuidos no son una propuesta de todo o nada; pueden continuar operando (en un nivel reducido) cuando hay alguna falla en algn componente independiente, tal como un sitio individual. La disponibilidad (es decir, la probabilidad de que el sistema est listo y funcionando continuamente a lo largo de un perodo especificado) tambin mejora, en parte por la misma razn y en parte debido a la posibilidad de replicacin de datos (ms adelante, vea el cometario adicional en el nmero 6). Lo anterior se aplica al caso en el que ocurre un apagado no planeado (es decir, una falla de algn tipo) en algn punto del sistema. Los apagados no planeados son obviamente indeseables, pero es difcil evitarlos! Por el contrario, los apagados planeados nunca deberan ser requeridos; es decir, nunca debera ser necesario apagar el sistema para realizar alguna tarea como la incorporacin de un nuevo sitio o la actualizacin del DBMS a una nueva versin en un sitio existente. 4. Independencia de ubicacin La idea bsica de la independencia de ubicacin (tambin conocida como transparencia de ubicacin) es simple. Los usuarios no tienen que saber dnde estn almacenados fsicamente los datos, sino que deben ser capaces de comportarse al menos desde un punto de vista lgico como si todos los datos estuvieran almacenados en su propio sitio local. La independencia de ubicacin es necesaria debido a que simplifica los programas de usuario y las actividades terminales.

En particular, permite que los datos emigren de un sitio a otro sin invalidar ninguno de estos programas o actividades. Dicha capacidad de emigracin es necesaria, ya que permite mover los datos por la red en respuesta a los diferentes requerimientos de desempeo. Nota: Sin duda alguna, se dar cuenta de que la independencia de ubicacin es simplemente una extensin al caso distribuido del concepto familiar de la independencia de datos (fsica). De hecho para adelantarnos por un momento cada objetivo de nuestra lista que tenga "independencia" en su nombre, puede ser considerado como una extensin a la independencia de datos, como veremos ms adelante. Tendremos un poco ms que decir con relacin a la independencia de ubicacin especficamente en la seccin 20.4 (en nuestra explicacin del nombramiento de objetos dentro de la subseccin titulada "Administracin del catlogo"). 5. Independencia de fragmentacin Un sistema soporta la fragmentacin de datos cuando una varrel dada 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. . En trminos ms generales, un fragmento puede ser derivado mediante Cualquier combinacin arbitraria de restricciones y proyecciones; arbitraria con excepcin de que: en el caso de la restriccin, las restricciones deben constituir una descomposicin ortogonal, en el sentido que mencionamos en el captulo 12 (seccin 12.6); en el caso de la proyeccin, las proyecciones deben constituir una descomposicin sin prdida, en el sentido que mencionamos en los captulo 11 y 12. El efecto neto de estas dos reglas es que todos los fragmentos de una varrel dada sern independientes, en el sentido de que ninguno de ellos puede ser derivado a partir de los otros ni tienen una restriccin o proyeccin que puede ser derivada a partir de los otros. (Si en realidad queremos guardar la misma pieza de informacin en varios lugares diferentes, podemos usar el mecanismo de replicacin del sistema; vea la siguiente subseccin.) La reconstruccin de la varrel original a partir de los fragmentos es lograda por medio de las operaciones de junta y de unin adecuadas (junta para los fragmentos verticales y unin. antes, es cierto que dicha fragmentacin debe ser sin prdida, y por lo tanto, no ser vlida ya que la independencia de fragmentacin significa que el usuario no est consciente de la Fragmentacin en forma alguna. Adems, observe que la facilidad de fragmentacin y la facilidad de reconstruccin son dos

de las razones principales por las que los sistemas distribuidos son relacinales; el modelo relacional proporciona exactamente las operaciones necesarias para estas tareas [20.15]. Ahora llegamos al punto principal. Un sistema que soporta la fragmentacin de datos tambin debe soportar la independencia de fragmentacin (conocida tambin como transparencia de fragmentacin); es decir, los usuarios deben ser capaces de comportarse, al menos desde un punto de vista lgico, como si los datos en realidad estuvieran sin fragmentacin alguna. La independencia de fragmentacin (al igual que la independencia de ubicacin) es necesaria debido a que simplifica los programas de usuario y las actividades terminales. En particular, permite que los datos sean fragmentados en cualquier momento (y los fragmentos sean redistribuidos en cualquier momento) en respuesta a los diferentes requerimientos de rendimiento, sin invalidar ninguno de esos programas de usuario o actividades. La independencia de fragmentacin implica que a los usuarios se les presentar una vista de los datos en la cual los fragmentos estarn recombinados lgicamente por medio de juntas y de uniones adecuadas. Es responsabilidad del optimizador del sistema determinar cules fragmentos necesitan ser accedidos fsicamente para satisfacer cualquier solicitud de usuario dada. Por ejemplo, dada la fragmentacin que muestra la figura 20.2, si el usuario hace la solicitud EMP WHERE SALARIO > 40K AND DEPT0# = ' D1 ' el optimizador sabr, por medio de las definiciones de fragmentos (guardadas en el catlogo, por supuesto), que el resultado completo puede ser obtenido desde el sitio de Nueva York; no hay necesidad de acceder al sitio de Londres. Examinemos este ejemplo un poco ms a fondo. La varrel EMP, tal como es percibida por el usuario, puede ser considerada (aproximadamente) como una vista de los fragmentos subyacentes N_EMP y L_EMP: VAR EMP VIEW N_EMP UNION L_EMP ; El optimizador transforma entonces la solicitud original del usuario en lo siguiente: ( N_EMP UNION L_EMP ) WHERE SALARIO > 40K AND DEPTO# = 'D 1 1 660 Parte V / Temas adicionales Esta expresin puede ser transformada todava ms en: ( N_EMP WHERE SALARIO > 40K AND DEPTO# = 'D1')

UNION ( L_EMP WHERE SALARIO > 40K AND DEPT0# = 'D1') (ya que la restriccin se distribuye sobre la unin). A partir de la definicin del fragmento L_EMP en el catlogo, el optimizador sabe que el segundo de estos dos operandos de UNION da como resultado una relacin vaca (la condicin de la restriccin DEPTO# = 'DI' AND DEPTO# = 'D2' nunca puede dar como resultado verdadero). La expresin general puede entonces ser simplificada a slo N_EMP WHERE SALARIO > 40K AND DEPTO# = 'D1' Ahora el optimizador sabe que necesita acceder solamente al sitio de Nueva York. Ejercicio: Considere lo que est involucrado en el optimizador para que maneje la solicitud EMP WHERE SALARIO > 40K Como lo sugiere la parte anterior, el problema de manejar operaciones sobre varrels fragmentadas tiene determinados puntos en comn con el problema de manejar operaciones sobre vistas de junta y de unin (de hecho, los dos problemas son uno mismo; slo que estn manifestados en puntos diferentes de la arquitectura general del sistema). En particular, el problema de la actualizacin de varrels fragmentadas es el mismo que el problema de la actualizacin de las vistas de junta y de unin (vea el captulo 9). Podemos deducir tambin que la actualizacin de una tupia dada (hablando de nuevo en trminos generales) puede ocasionar que una tupia emigre de un fragmento hacia otro, en caso de que la tupia actualizada ya no satisfaga el predicado del fragmento al que perteneca anteriormente. 6. Independencia de replicacin Un sistema soporta la replicacin de datos cuando una varrel almacenada dada o ms generalmente, un fragmento dado de una varrel guardada puede ser representada por muchas copias distintas, o rplicas, guardadas en muchos sitios distintos. Por ejemplo: REPLICATE N_EMP AS LN_EMP AT SITE 'Londres' ; REPLICATE L_EMP AS NL_EMP AT SITE 'Nueva York' ; (vea la figura 20.3). Observe los nombres de rplica internos del sistema NL_EMP y LN_EMP. Las rplicas son necesarias por dos razones (como mnimo). Primero, puede significar un

mejor rendimiento (las aplicaciones pueden operar sobre copias locales en lugar de tener que comunicarse con sitios remotos). Segundo, tambin puede significar una mejor disponibilidad (un objeto replicado dado permanece disponible para su procesamiento al menos para su recuperacin mientras est disponible al menos una copia). Por supuesto, la principal desventaja de la replicacin es que al actualizar un objeto replicado dado es necesario actualizar todas las copias de ese objeto: el problema de la propagacin de la actualizacin. En la seccin 20.4 tendremos ms que decir con relacin a este problema. Comentamos de paso que la replicacin en un sistema distribuido representa una aplicacin especfica de la idea de la redundancia controlada, tal como explicamos en el captulo 1. Captulo 20 I Bases de datos distribuidas 661 Nueva York Londres N EMP L EMP EMP# DEPTO# SALARIO E1 E2 E5 D1 D1 D3 40K 42K 48K EMP# DEPTO# SALARIO E3 E4 D2 D2 30K 35K EMP# DEPTO# SALARIO E3 E4 D2 D2 30K 35K EMP# E1 E2 E5

DEPTO# D1 D1 D3 SALARIO 40K 42K 48K NL_EMP ( rplica de L_EMP ) LN_EMP ( rplica de N_EMP ) Figura 20.3 Un ejemplo de replicacin. Ahora bien (de manera ideal), la replicacin, al igual que la fragmentacin, debe ser "transparente ante el usuario". En otras palabras, un sistema que soporta la replicacin de datos tambin debe soportar la independencia de replicacin (tambin conocida como transparencia de replicacin); es decir, los usuarios deben ser capaces de comportarse al menos desde un punto de vista lgico como si los datos en realidad no estuvieran replicados. La independencia de replicacin (al igual que la independencia de ubicacin y la de fragmentacin) es necesaria debido a que simplifica los programas de usuario y las actividades terminales; en particular, permite que las rplicas sean creadas y destruidas en cualquier momento en respuesta a los distintos requerimientos, sin invalidar ninguno de esos programas de usuario o actividades. La independencia de replicacin implica que es responsabilidad del optimizador del sistema determinar cules rplicas necesitan ser accedidas fsicamente para satisfacer cualquier solicitud de usuario dada. Aqu omitimos los puntos especficos de este tema. Cerramos esta subseccin mencionando que muchos productos comerciales soportan actualmente una forma de replicacin que no incluye la independencia de replicacin plena (es decir, no es completamente "transparente ante el usuario"). Vea los comentarios adicionales sobre este tema en la seccin 20.4, dentro de la subseccin sobre la propagacin de la actualizacin. 7. Procesamiento de consultas distribuidas Hay dos temas amplios a tratar bajo este encabezado. Primero, considere la consulta "obtener los proveedores de partes rojas de Londres". Suponga que el usuario est en el sitio de Nueva York y los datos estn en el sitio de Londres. Suponga tambin que hay n proveedores que satisfacen la solicitud. Si el sistema es relacional, la consulta involucrar bsicamente dos mensajes: uno para enviar la solicitud desde

Nueva York a Londres y otro para regresar el conjunto resultante de n tupias desde Londres a Nueva York. Por otro lado, si el sistema no es relacional, sino que es un sistema de un registro a la vez, la consulta involucrar bsicamente 2 mensajes: n desde Nueva York 662 Parte V / Temas adicionales hacia Londres solicitando al "siguiente" proveedor y n desde Londres hacia Nueva York para regresar ese "siguiente" proveedor. El ejemplo ilustra entonces el hecho de que es probable que un sistema relacional supere a uno que no lo es por varios rdenes de magnitud posibles. Segundo, la optimizacin es todava ms importante en un sistema distribuido que en uno centralizado. El punto bsico es que en una consulta como la anterior 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. Por ejemplo, una solicitud de (por decir algo) la unin de una relacin Rx almacenada en el sitio X y una relacin Ry almacenada en el sitio Y, podra ser realizada moviendo Rx hacia Y o Ry hacia X, o moviendo ambas hacia un tercer sitio Z (etctera). En la seccin 20.4 presentamos una ilustracin convincente de este punto, que involucra a la consulta que mencionamos anteriormente ("obtener los nmeros de proveedor de los proveedores de partes rojas de Londres "), Para resumir brevemente el ejemplo, analizamos seis estrategias diferentes para el procesamiento de la consulta bajo un conjunto determinado de suposiciones admisibles, y mostramos que el tiempo de respuesta vara desde el mnimo de un dcimo de segundo hasta el mximo de casi seis horasl Por lo tanto, la optimizacin es claramente crucial, y este hecho puede ser considerado a su vez como otra razn por la que los sistemas distribuidos siempre son relacinales (donde el punto importante es que las peticiones relacinales son optimizables, mientras que las no relacinales no lo son). 8. Administracin de transacciones distribuidas Como usted sabe, hay dos aspectos principales en la administracin de transacciones: el control

de la recuperacin y el control de la concurrencia. Ambos requieren un tratamiento amplio en el ambiente distribuido. Para explicar ese tratamiento amplio, primero es necesario introducir un nuevo trmino, el agente. En los sistemas distribuidos, una sola transaccin puede involucrar la ejecucin de cdigo en muchos sitios; en particular, puede involucrar actualizaciones en muchos sitios. Por lo tanto, decimos que cada transaccin consiste en varios agentes, donde un agente es el proceso realizado en nombre de una transaccin dada en un sitio dado. Y el sistema necesita saber cundo dos agentes son parte de la misma transaccin; por ejemplo, no se debe permitir que dos agentes que son parte de la misma transaccin caigan en bloqueo mortal entre ellos. Continuemos especficamente con el control de la recuperacin. Para asegurarse de que una transaccin dada sea atmica (todo o nada) en el ambiente distribuido, el sistema debe por lo tanto asegurarse de que el conjunto de agentes para esa transaccin sea confirmado o deshecho al unsono. Este efecto puede lograrse por medio del protocolo de confrmacin de dos fases que ya explicamos (aunque no en el contexto distribuido) en el captulo 14. En la seccin 20.4 tendremos ms que decir con relacin a la confirmacin de dos fases para un sistema distribuido. En lo que se refiere al control de concurrencia, en la mayora de los sistemas distribuidos al igual que los no distribuidos el control de concurrencia est basado generalmente en el bloqueo. (Varios productos recientes han comenzado a implementar controles multiversin [ 15.1 ]; sin embargo, en la prctica el bloqueo convencional parece seguir siendo la tcnica a escoger para la mayora de los sistemas.) De nuevo, en la seccin 20.4 trataremos este tema con mayor detalle. Captulo 20 I Bases de datos distribuidas 663 9. Independencia de hardware De hecho, no hay mucho que decir sobre este tema, ya que el encabezado lo dice todo. Por lo general, las instalaciones de computadoras involucran en la realidad una gran diversidad de mquinas diferentes IBM, ICL, HP, PC y estaciones de trabajo de diversos tipos, etctera y

existe una necesidad real de poder integrar los datos en todos estos sistemas y presentar al usuario una "imagen de sistema nico". Por lo tanto, es necesario tener la posibilidad de ejecutar el mismo DBMS en diferentes plataformas de hardware y, adems, hacer que esas mquinas diferentes participen como socios igualitarios en un sistema distribuido. 10. Independencia de sistema operativo En parte, este objetivo es un corolario del anterior y tampoco requiere de mucha explicacin aqu. 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 incluyendo diferentes sistemas operativos en el mismo hardware y tener (por ejemplo) una versin MVS, una versin UNIX y una versin NT participando en el mismo sistema distribuido. 11. Independencia de red De nuevo no hay mucho que decir sobre este punto; si el sistema va a tener la posibilidad de soportar muchos sitios distintos con hardware distinto y sistemas operativos distintos es obviamente necesario tener la posibilidad de soportar tambin una variedad de redes de comunicacin distintas. 12. Independencia de DBMS Bajo este encabezado consideramos lo que est involucrado al flexibilizar la suposicin de homogeneidad estricta. Esta suposicin es discutiblemente un poco ms fuerte; todo lo que en realidad necesitamos es que todos los ejemplares del DBMS en sitios diferentes soporten la misma interfaz, aunque no tienen que ser necesariamente copias del mismo software DBMS. Por ejemplo, si Ingres y Oracle soportan el estndar de SQL oficial, sena posible tener un sitio Ingres y un sitio Oracle comunicndose entre s en el contexto de un sistema distribuido. En otras palabras, sera posible que el sistema distribuido fuera heterogneo, al menos en cierto grado. El soporte para la heterogeneidad es definitivamente necesario. El hecho es que por lo general las instalaciones de computacin en la realidad emplean no slo muchas mquinas diferentes y muchos sistemas operativos diferentes, sino que muy frecuentemente, tambin DBMSs diferentes;

y sera muy bueno si esos DBMS diferentes pudieran participar de alguna forma en un sistema distribuido. En otras palabras, el sistema distribuido ideal debe proporcionar independencia de DBMSs. Sin embargo, ste es un tema grande (y uno muy importante en la prctica) al que le dedicamos una seccin aparte.

También podría gustarte