You are on page 1of 15

INSTITUTO TECNOLÓGICO DE PUEBLA

Profesor: Actuario José López Ponciano Materia: Base de Datos Distribuidas Hora: 13-15 hrs Integrantes: Adrián Huerta Serrano Hugo Alejandro Fernández Garcilazo Moisés Gabriel Gutiérrez Morales

cada sitio es un sistema de base de datos completo por derecho propio.Un sistema de base de datos distribuida consiste en una colección de sitios. los sitios han acordado trabajar juntos. exactamente como si los datos estuvieran guardados en el propio sitio del usuario. en el cual a. es la unión lógica de esas bases de datos reales). a fin de que un usuario de cualquier sitio pueda acceder a los datos desde cualquier lugar de la red. conectados por medio de algún tipo de red de comunicación. . pero b. De aquí deducimos que la llamada "base de datos distribuida" es en realidad un tipo de base de datos virtual cuyas partes componentes están almacenadas en varias bases de datos "reales" distintas que se encuentran en varios sitios distintos (de hecho.

Y lo que hace un sistema distribuido es proporcionar los puentes necesarios para conectar a esas islas entre sí. De hecho. En otras palabras. En particular. etcétera). desde una perspectiva de base de datos. registro en bitácora. sus propios usuarios locales. un usuario determinado puede realizar operaciones sobre los datos desde su propio sitio local. lo que constituye lo que generalmente llamamos sistema de administración de base de datos distribuida. 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. etcétera) y es muy probable que también lo estén de manera física (en plantas. Dos "sitios" pueden incluso coexistir en la misma máquina física (especialmente durante el período de la prueba inicial del sistema). Ventajas ¿Por qué son necesarias las bases de datos distribuidas? La respuesta básica a esta pregunta es que las empresas ya están generalmente distribuidas al menos de manera lógica (en divisiones. de esto deducimos que por lo general también los datos ya están distribuidos. cada sitio tiene sus propias bases de datos "reales". Las primeras investigaciones tendían a dar por hecho la distribución geográfica. fábricas. hay muy poca diferencia —ya que es necesario resolver prácticamente los mismos problemas técnicos (de la base de datos). así como su propio administrador CD (de comunicación de datos) local. permite que la estructura de la . Nos referiremos a esto como la suposición de homogeneidad estricta. Sin embargo. mientras no digamos otra cosa. recuperación. etcétera). observe que cada sitio es un sitio de sistema de base de datos por derecho propio. su propio DBMS local y software de administración de transacciones (incluyendo su propio software local para bloqueo. que el sistema es homogéneo en el sentido de que cada sitio está ejecutando una copia del mismo DBMS. ya que cada unidad organizacional dentro de la empresa mantendrá naturalmente los datos que son importantes para su propia operación. En otras palabras. laboratorios. un nuevo componente de software en cada sitio —de manera lógica. éste es un objetivo). sin embargo la mayoría de las primeras instalaciones comerciales involucraban la distribución local con (por ejemplo) varios "sitios" en el mismo edificio y conectados por medio de una LAN (red de área local). más recientemente la enorme proliferación de las WANs (redes de área amplia) ha revivido nuevamente el interés en la posibilidad de una distribución geográfica. y es la combinación de este nuevo componente y el DBMS existente. Entonces. tal como si ese sitio no participara nunca en el sistema distribuido (al menos. departamentos. una extensión del DBMS local— proporciona la funcionalidad de sociedad necesaria.Para repetir. el énfasis sobre los sistemas distribuidos ha ido y venido a lo largo del tiempo. En cualquier caso. Por lo tanto. el valor de la información total de la empresa está dividido en lo que a veces llamamos islas de información. grupos de trabajo. Nota: Para simplificar la explicación supondremos.

Un ejemplo le ayudará a aclarar lo anterior. aun cuando no haya nada malo en el propio sitio X. la seguridad. LOS DOCE OBJETIVOS 1. cualquier falla en el sitio y podría significar que el sitio X no pueda ejecutar operaciones. La autonomía local significa que todas las operaciones en un sitio dado están controladas por ese sitio. permite tener acceso a datos remotos cuando sea necesario. Las ventajas son claramente obvias: el arreglo distribuido combina la eficiencia de procesamiento (los datos se mantienen cerca del punto en donde se usan más frecuentemente) con una mayor accesibilidad (es posible acceder a una cuenta de Los Ángeles desde San Francisco y viceversa. el objetivo de autonomía local no es totalmente alcanzable. existen varias situaciones en las que un sitio X dado debe transferir un determinado grado de control a algún otro sitio y. ningún sitio X debe depender de algún otro sitio F para su operación satisfactoria (ya que de lo contrario. lo que es obviamente una situación indeseable). Los Ángeles y San Francisco. . Autonomía local Los sitios en un sistema distribuido deben ser autónomos. suponga que hay solamente dos sitios. también se acumulan muchos beneficios adicionales. La autonomía local también implica que los datos locales son poseídos y administrados localmente con contabilidad local: todos los datos pertenecen "realmente" a alguna base de datos local.base de datos refleje la estructura de la empresa —los datos locales son conservados localmente en el lugar donde pertenecen de manera más lógica— y al mismo tiempo. Por lo tanto. Por lo tanto. el objetivo de autonomía queda establecido con mayor precisión como: los sitios deben ser autónomos en el mayor grado posible. 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. Por supuesto. aun cuando estén accesibles desde otros sitios remotos. Probablemente. integridad y representación de almacenamiento de los datos locales permanecen bajo el control y jurisdicción del sitio local. Por razones de simplicidad. 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 medio de la red de comunicaciones). De hecho.

Primero. los apagados planeados nunca deberían ser requeridos. la probabilidad de que el sistema esté listo y funcionando en cualquier momento dado) mejora. no debe haber particularmente ninguna dependencia de un sitio "maestro" central para algún servicio central —por ejemplo. vea el cometario adicional en el número 6). Los usuarios no tienen que saber dónde están almacenados físicamente los datos. Por lo tanto. es decir. Pero "la no dependencia de un sitio central" es necesaria por sí misma. vale la pena mencionarlo como un objetivo independiente. Por lo tanto. el sistema sería vulnerable. sino que deben ser capaces de comportarse —al menos desde un punto de vista lógico— como si todos los datos estuvieran almacenados en su propio sitio local. Segundo y más importante. 4. Independencia de ubicación La idea básica de la independencia de ubicación (también conocida como transparencia de ubicación) es simple. La dependencia de un sitio central sería indeseable por las siguientes dos razones (como mínimo). la probabilidad de que el sistema esté listo y funcionando continuamente a lo largo de un período especificado) también mejora. tal como un sitio individual. el segundo también forzosamente). pueden continuar operando (en un nivel reducido) cuando hay alguna falla en algún componente independiente. si el sitio central falla. Por lo tanto. en parte por la misma razón y en parte debido a la posibilidad de replicación de datos (más adelante. . procesamiento centralizado de consultas. ¡pero es difícil evitarlos! Por el contrario. aunque no se logre la autonomía local completa. ■ La confiabilidad (es decir. La independencia de ubicación es necesaria debido a que simplifica los programas de usuario y las actividades terminales. este segundo objetivo es un corolario del primero (si el primero logra. nunca debería ser necesario apagar el sistema para realizar alguna tarea como la incorporación de un nuevo sitio o la actualización del DBMS a una nueva versión en un sitio existente. ya que los sistemas distribuidos no son una propuesta de todo o nada.2. ■ La disponibilidad (es decir. el sitio central puede ser un cuello de botella. Los apagados no planeados son obviamente indeseables. también fallará todo el sistema (el problema del "único punto de falla"). una ventaja de los sistemas distribuidos es que deben proporcionar mayor confiabilidad y mayor disponibilidad. Lo anterior se aplica al caso en el que ocurre un apagado no planeado (es decir. administración centralizada de transacciones o servicios centralizados de asignación de nombres— tal que todo el sistema dependa de ese sitio central. 3. No dependencia de un sitio central La autonomía local implica que todos los sitios deben ser tratados como iguales. una falla de algún tipo) en algún punto del sistema. Operación continua En general. es decir.

antes. De hecho —para adelantarnos por un momento— cada objetivo de nuestra lista que tenga "independencia" en su nombre. ya que permite mover los datos por la red en respuesta a los diferentes requerimientos de desempeño. . Tendremos un poco más que decir con relación a la independencia de ubicación específicamente en la sección 20. permite que los datos emigren de un sitio a otro sin invalidar ninguno de estos programas o actividades. se dará cuenta de que la independencia de ubicación es simplemente una extensión al caso distribuido del concepto familiar de la independencia de datos (física). un fragmento puede ser derivado mediante Cualquier combinación arbitraria de restricciones y proyecciones. es cierto que dicha fragmentación debe ser sin pérdida. y por lo tanto. En términos más generales. Nota: Sin duda alguna. El efecto neto de estas dos reglas es que todos los fragmentos de una varrel dada serán independientes. en el sentido de que ninguno de ellos puede ser derivado a partir de los otros ni tienen una restricción o proyección que puede ser derivada a partir de los otros. en el sentido que mencionamos en el capítulo 12 (sección 12. (Si en realidad queremos guardar la misma pieza de información en varios lugares diferentes. para efectos de almacenamiento físico. 5.6). observe que la facilidad de fragmentación y la facilidad de reconstrucción son dos . Dicha capacidad de emigración es necesaria.4 (en nuestra explicación del nombramiento de objetos dentro de la subsección titulada "Administración del catálogo"). vea la siguiente subsección. La fragmentación es necesaria por razones de rendimiento: los datos pueden estar almacenados en la ubicación donde son usados más frecuentemente para que la mayoría de las operaciones sean locales y se reduzca el tráfico en la red.) La reconstrucción de la varrel original a partir de los fragmentos es lograda por medio de las operaciones de junta y de unión adecuadas (junta para los fragmentos verticales y unión. arbitraria con excepción de que: ■ en el caso de la restricción. podemos usar el mecanismo de replicación del sistema. las proyecciones deben constituir una descomposición sin pérdida. Independencia de fragmentación Un sistema soporta la fragmentación de datos cuando una varrel dada puede ser dividida en partes o fragmentos. no será válida ya que la independencia de fragmentación significa que el usuario no está consciente de la Fragmentación en forma alguna. en el sentido que mencionamos en los capítulo 11 y 12. las restricciones deben constituir una descomposición ortogonal. como veremos más adelante. Además. puede ser considerado como una extensión a la independencia de datos.En particular. ■ en el caso de la proyección.

como si los datos en realidad estuvieran sin fragmentación alguna. tal como es percibida por el usuario. los usuarios deben ser capaces de comportarse. 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 expresión puede ser transformada todavía más en: ( N_EMP WHERE SALARIO > 40K AND DEPTO# = 'D1') . es decir.de las razones principales por las que los sistemas distribuidos son relaciónales. si el usuario hace la solicitud EMP WHERE SALARIO > 40K AND DEPT0# = ' D1 ' el optimizador sabrá. En particular. puede ser considerada (aproximadamente) como una vista de los fragmentos subyacentes N_EMP y L_EMP: VAR EMP VIEW N_EMP UNION L_EMP . Un sistema que soporta la fragmentación de datos también debe soportar la independencia de fragmentación (conocida también como transparencia de fragmentación). no hay necesidad de acceder al sitio de Londres.15]. Ahora llegamos al punto principal. por medio de las definiciones de fragmentos (guardadas en el catálogo.2. Examinemos este ejemplo un poco más a fondo. que el resultado completo puede ser obtenido desde el sitio de Nueva York. por supuesto). 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. Por ejemplo. La independencia de fragmentación implica que a los usuarios se les presentará una vista de los datos en la cual los fragmentos estarán recombinados lógicamente por medio de juntas y de uniones adecuadas. dada la fragmentación que muestra la figura 20. La varrel EMP. La independencia de fragmentación (al igual que la independencia de ubicación) es necesaria debido a que simplifica los programas de usuario y las actividades terminales. al menos desde un punto de vista lógico. sin invalidar ninguno de esos programas de usuario o actividades. Es responsabilidad del optimizador del sistema determinar cuáles fragmentos necesitan ser accedidos físicamente para satisfacer cualquier solicitud de usuario dada. el modelo relacional proporciona exactamente las operaciones necesarias para estas tareas [20.

el problema de la actualización de varrels fragmentadas es el mismo que el problema de la actualización de las vistas de junta y de unión (vea el capítulo 9). Ejercicio: Considere lo que está involucrado en el optimizador para que maneje la solicitud EMP WHERE SALARIO > 40K Como lo sugiere la parte anterior. Podemos deducir también que la actualización de una tupia dada (hablando de nuevo en términos generales) puede ocasionar que una tupia emigre de un fragmento hacia otro. (vea la figura 20. A partir de la definición del fragmento L_EMP en el catálogo. puede significar un . un fragmento dado de una varrel guardada— puede ser representada por muchas copias distintas. o réplicas. el optimizador sabe que el segundo de estos dos operandos de UNION da como resultado una relación vacía (la condición de la restricción DEPTO# = 'DI' AND DEPTO# = 'D2' nunca puede dar como resultado verdadero). guardadas en muchos sitios distintos. En particular. REPLICATE L_EMP AS NL_EMP AT SITE 'Nueva York' .3). Las réplicas son necesarias por dos razones (como mínimo). los dos problemas son uno mismo. Primero. en caso de que la tupia actualizada ya no satisfaga el predicado del fragmento al que pertenecía anteriormente. La expresión general puede entonces ser simplificada a sólo N_EMP WHERE SALARIO > 40K AND DEPTO# = 'D1' Ahora el optimizador sabe que necesita acceder solamente al sitio de Nueva York.UNION ( L_EMP WHERE SALARIO > 40K AND DEPT0# = 'D1') (ya que la restricción se distribuye sobre la unión). Por ejemplo: REPLICATE N_EMP AS LN_EMP AT SITE 'Londres' . sólo que están manifestados en puntos diferentes de la arquitectura general del sistema). el problema de manejar operaciones sobre varrels fragmentadas tiene determinados puntos en común con el problema de manejar operaciones sobre vistas de junta y de unión (de hecho. Observe los nombres de réplica internos del sistema NL_EMP y LN_EMP. 6. Independencia de replicación Un sistema soporta la replicación de datos cuando una varrel almacenada dada —o más generalmente.

Segundo. tal como explicamos en el capítulo 1.4 tendremos más que decir con relación a este problema. Comentamos de paso que la replicación en un sistema distribuido representa una aplicación específica de la idea de la redundancia controlada. Capítulo 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 .mejor rendimiento (las aplicaciones pueden operar sobre copias locales en lugar de tener que comunicarse con sitios remotos). Por supuesto. la principal desventaja de la replicación es que al actualizar un objeto replicado dado es necesario actualizar todas las copias de ese objeto: el problema de la propagación de la actualización. también puede significar una mejor disponibilidad (un objeto replicado dado permanece disponible para su procesamiento —al menos para su recuperación— mientras esté disponible al menos una copia). En la sección 20.

7. La independencia de replicación implica que es responsabilidad del optimizador del sistema determinar cuáles réplicas necesitan ser accedidas físicamente para satisfacer cualquier solicitud de usuario dada. es decir. Vea los comentarios adicionales sobre este tema en la sección 20. los usuarios deben ser capaces de comportarse —al menos desde un punto de vista lógico— como si los datos en realidad no estuvieran replicados. Si el sistema es relacional. Ahora bien (de manera ideal). ■ Primero.4. Procesamiento de consultas distribuidas Hay dos temas amplios a tratar bajo este encabezado. La independencia de replicación (al igual que la independencia de ubicación y la de fragmentación) es necesaria debido a que simplifica los programas de usuario y las actividades terminales. Cerramos esta subsección mencionando que muchos productos comerciales soportan actualmente una forma de replicación que no incluye la independencia de replicación plena (es decir. Suponga que el usuario está en el sitio de Nueva York y los datos están en el sitio de Londres. Aquí omitimos los puntos específicos de este tema. sin invalidar ninguno de esos programas de usuario o actividades. la consulta involucrará básicamente dos mensajes: uno para enviar la solicitud desde . considere la consulta "obtener los proveedores de partes rojas de Londres". Suponga también que hay n proveedores que satisfacen la solicitud.3 Un ejemplo de replicación. permite que las réplicas sean creadas y destruidas en cualquier momento en respuesta a los distintos requerimientos. en particular. al igual que la fragmentación. no es completamente "transparente ante el usuario"). dentro de la subsección sobre la propagación de la actualización. debe ser "transparente ante el usuario". la replicación. En otras palabras. un sistema que soporta la replicación de datos también debe soportar la independencia de replicación (también conocida como transparencia de replicación).DEPTO# D1 D1 D3 SALARIO 40K 42K 48K NL_EMP ( réplica de L_EMP ) LN_EMP ( réplica de N_EMP ) Figura 20.

la optimización es todavía más importante en un sistema distribuido que en uno centralizado. la consulta involucrará básicamente 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.4 presentamos una ilustración convincente de este punto. mientras que las no relaciónales no lo son). En la sección 20. una solicitud de (por decir algo) la unión de una relación Rx almacenada en el sitio X y una relación Ry almacenada en el sitio Y. analizamos seis estrategias diferentes para el procesamiento de la consulta bajo un conjunto determinado de suposiciones admisibles. y este hecho puede ser considerado a su vez como otra razón por la que los sistemas distribuidos siempre son relaciónales (donde el punto importante es que las peticiones relaciónales son optimizables. Administración de transacciones distribuidas Como usted sabe. o moviendo ambas hacia un tercer sitio Z (etcétera). Por otro lado. podría ser realizada moviendo Rx hacia Y o Ry hacia X. hay dos aspectos principales en la administración de transacciones: el control . si el sistema no es relacional. y mostramos que el tiempo de respuesta ¡varía desde el mínimo de un décimo de segundo hasta el máximo de casi seis horasl Por lo tanto. que involucra a la consulta que mencionamos anteriormente ("obtener los números de proveedor de los proveedores de partes rojas de Londres "). y es crucialmente importante que se encuentre una estrategia eficiente. 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.Nueva York a Londres y otro para regresar el conjunto resultante de n tupias desde Londres a Nueva York. sino que es un sistema de un registro a la vez. El punto básico 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. la optimización es claramente crucial. Por ejemplo. 8. Para resumir brevemente el ejemplo. Segundo.

En lo que se refiere al control de concurrencia. ICL. donde un agente es el proceso realizado en nombre de una transacción dada en un sitio dado. HP. PC y estaciones de trabajo de diversos tipos. En la sección 20. en la práctica el bloqueo convencional parece seguir siendo la técnica a escoger para la mayoría de los sistemas.4 trataremos este tema con mayor detalle. no se debe permitir que dos agentes que son parte de la misma transacción caigan en bloqueo mortal entre ellos. primero es necesario introducir un nuevo término. decimos que cada transacción consiste en varios agentes.de la recuperación y el control de la concurrencia. Independencia de hardware De hecho. el sistema debe por lo tanto asegurarse de que el conjunto de agentes para esa transacción sea confirmado o deshecho al unísono. Por lo tanto. una sola transacción puede involucrar la ejecución de código en muchos sitios. las instalaciones de computadoras involucran en la realidad una gran diversidad de máquinas diferentes —IBM. Para explicar ese tratamiento amplio. en la sección 20. por ejemplo. Para asegurarse de que una transacción dada sea atómica (todo o nada) en el ambiente distribuido. Este efecto puede lograrse por medio del protocolo de confírmación de dos fases que ya explicamos (aunque no en el contexto distribuido) en el capítulo 14. Continuemos específicamente con el control de la recuperación. Por lo general. En los sistemas distribuidos. puede involucrar actualizaciones en muchos sitios. Ambos requieren un tratamiento amplio en el ambiente distribuido. el agente.) De nuevo. en la mayoría de los sistemas distribuidos —al igual que los no distribuidos— el control de concurrencia está basado generalmente en el bloqueo. ya que el encabezado lo dice todo.4 tendremos más que decir con relación a la confirmación de dos fases para un sistema distribuido. sin embargo. no hay mucho que decir sobre este tema. (Varios productos recientes han comenzado a implementar controles multiversión [ 15. Y el sistema necesita saber cuándo dos agentes son parte de la misma transacción. etcétera— y . en particular. Capítulo 20 I Bases de datos distribuidas 663 9.1 ].

una versión UNIX y una versión NT participando en el mismo sistema distribuido. 11. 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 también una variedad de redes de comunicación distintas. 12. Independencia de red De nuevo no hay mucho que decir sobre este punto. aunque no tienen que ser necesariamente copias del mismo software DBMS. si Ingres y Oracle soportan el estándar de SQL oficial. sería posible que el sistema distribuido fuera heterogéneo. Por ejemplo. sino que muy frecuentemente. 10. es necesario tener la posibilidad de ejecutar el mismo DBMS en diferentes plataformas de hardware y. sena posible tener un sitio Ingres y un sitio Oracle comunicándose entre sí en el contexto de un sistema distribuido. El soporte para la heterogeneidad es definitivamente necesario. Por lo tanto. Obviamente es necesario no sólo tener la posibilidad de ejecutar el mismo DBMS en diferentes plataformas de hardware. Esta suposición es —discutiblemente— un poco más fuerte. Independencia de sistema operativo En parte. todo lo que en realidad necesitamos es que todos los ejemplares del DBMS en sitios diferentes soporten la misma interfaz. también DBMSs diferentes. En otras palabras. Independencia de DBMS Bajo este encabezado consideramos lo que está involucrado al flexibilizar la suposición de homogeneidad estricta. hacer que esas máquinas diferentes participen como socios igualitarios en un sistema distribuido. al menos en cierto grado. . El hecho es que por lo general las instalaciones de computación en la realidad emplean no sólo muchas máquinas diferentes y muchos sistemas operativos diferentes.existe una necesidad real de poder integrar los datos en todos estos sistemas y presentar al usuario una "imagen de sistema único". además. este objetivo es un corolario del anterior y tampoco requiere de mucha explicación aquí. sino también ejecutarlo en diferentes plataformas de sistema operativo —incluyendo diferentes sistemas operativos en el mismo hardware— y tener (por ejemplo) una versión MVS.

el sistema distribuido ideal debe proporcionar independencia de DBMSs. En otras palabras. . Sin embargo.y sería muy bueno si esos DBMS diferentes pudieran participar de alguna forma en un sistema distribuido. éste es un tema grande (y uno muy importante en la práctica) al que le dedicamos una sección aparte.