MUSICA MIENTRAS NAVEGAS CON REAL AUDIO
Qué musica quieres oir? 1,2,3 (El Simbolo) Algo natural (Alejandra Guzman) A fuego lento (Rosana) Believe (Cher) El talisman (Rosana) I don't want to miss a thing (Aerosmith) Inevitable (Shakira) Levantando las manos (El Simbolo) Mambo #5 (Lou Vega) O tu o ninguna (Luis Miguel) Si no te has ido, vete (Alejandra Guzman) Soy yo (Luis Miguel) Suavemente (Elvis Crespo) Tu (Shakira) With or without you (U2)
ESTE SITIO SE VE MEJOR EN 800 X 600
9066 PERSONAS QUE NOS VISITAN
INFORMACION DE BASES DE DATOS DISTRIBUIDAS POR RUBI #ICQ 44323906
Ejemplo 1.1
Considere un banco que tiene tres sucursales, en cada sucursal, un computador controla las terminales de la misma y el sistema de cuentas. Cada computador con su sistema de cuentas local en cada sucursal constituye un "sitio" de la BDD; las computadoras estan conectadas por la red. Durante las operaciones normales, las aplicaciones en las terminales de la sucursal necesitan solo accesar la BD de la misma. Como solo accesan la misma red local,se les llaman aplicaciones locales .
Desde el punto de vista tecnológico, aparentemente lo importante es la existencia de algunas transacciones que accesen información en más de una sucursal. Éstas transacciones son llamadas transacciones globales o transacciones distribuidas.
La existencia de transacciones globales será considerada como una característica que nos ayude a discriminar entre las BDD y un conjunto de base de datos locales.
Una típica transacción global sería una transferencia de fondos de una sucursal a otra. Esta aplicación requiere de actualizar datos en dos diferentes sucursales y asegurarse de la real actualización en ambos sitios o en ninguno. Asegurar el buen funcionamiento de aplicaciones globales es una tarea difícil. En el ejemplo 1.1 las computadoras estaban geogr´ficamente en diferentes puntos; tambien, BDD pueden ser construidas en una red local.
Ejemplo 1.2
Considere el mismo banco del ejemplo previo, con las mismas aplicaciones, pero con un sistema configurado como en la figura 1.2. Los mismos procesadores con sus bases de datos han sido movidos de sus sucursales a un edificio común y ahora están conectados entre si en un radio con un amplio ancho de banda. Las terminales de las sucursales est´n conectadas a sus respectivos computadores por líneas telefónicas. Cada procesador y su base de datos contituye un sitio de la red local.
Vemos que la estructura física de las conexiones a cambiado con respecto al ejemplo 1.1, pero las características de la arquitectura son las mismas. En particular, los mismos computadores ejecutan las mismas aplicaciones, accesando las mismas bases de datos. La transacción local del ejemplo anterior aún es local, no por el hecho geográfico, si no por el hecho de que solo un computador por bases de datos está envuelto en el proceso.
Si hay aplicaciones globales, es conveniente considerar este ejemplo como BDD, ya que muchas características que el ejemplo previo presentó son aún válidas. Apesar de todo, el hecho de que la BDD sea implementada en una red local o en una gráficamente distribuida, cambian muchas veces el tipo de solución que se busca para un problema.
Ejemplo 1.3
¿Qué no es una Base de Datos Distribuida?
Un caso de sistema NO considerado BDD : Considere el mismo banco del ejemplo anterior, pero con la configuración del sistema mostrado en la figura 1.3. La información en diferentes sucursales esta distribuida en tres computadores ( "backend" computers ), que realizan el control de funciones de la base de datos. Las aplicaciones son ejecutadas por diferentes computadores.
[BDD, sistema multiproceso]
La razón para no considerar esta una base de datos distribuida: aún cuando la información se encuentra físicamente distribuida en diferentes procesadores, su distribución, no es reelevante desde el punto de vista de la apliación. Lo que perdemos aqui es la existencia de aplicaciones locales, en el sentido de que la integración del sistema ha alcanzado el punto donde ninguno de los computadores será capaz de ejecutar una transacción por si mismo.
II. Bases de Datos Distribuidas
2.1 Un principio fundamental de los sistemas de bases de datos distribuidos
2.2 Las doce reglas
Ventajas :
2.3 Fiabilidad y disponibilidad
2.4 Agilización del procesamiento de consultas
2.5 Ejemplos de sistemas
2.6 Utilización compartida de datos y distribución de control
¿Por qué son deseables las bases de datos distribuidas?
La respuesta básica a esta pregunta es que por lo regular las empresas ya están distribuidas, por lo menos desde el punto de vista lógico ( en divisiones, departamentos, proyectos, etc ) y muy probablemente en el sentido físico también ( en plantas, talleres, laboratorios, y demás ), de lo cual se desprende que en general la información ya está también distribuida, porque cada unidad de organización dentreo de la empresa mantendrá por fuerza los datos pertinentes a su propio funcionamiento. Así pues, un sistema distribuido permite que la estructura de la base de datos refleje la estructura de la empresa : los datos locales se pueden mantener en forma local, donde por lógica deben estar, pero al mismo tiempo es posible obtener acceso a datos remotos en caso necesario. Un principio fundamental de los sistemas de bases de datos distribuidos
El principio fundamental de las bases de datos distribuidas : · Desde el punto de vista del usuario, un sistema distribuido deberá ser idéntico a un sistema no distribuido. En otras palabras, los usuarios de un sistema distribuido deberán comportarse exactamente como si el sistema no estuviera distribuido. Todos los problemas de los sistemas distribuidos son (o deberían ser ) internos o a nivel de realización, no externos o a nivel del usuario. Llamaremos al principio fundamental recién identificado la "regla cero" de los sistemas distribuidos. La regla cero conduce a varios objetivos o reglas secundarios - doce en realidad- siguientes : 1. Autonomía local. 2. No dependencia de un sitio central. 3. Operación continua. 4. Independencia con respecto a la localización. 5. Independencia con respecto a la fragmentación. 6. Independencia de réplica. 7. Procesamiento distribuido de consultas. 8. Manejo distribuido de transacciones. 9. Independencia con respecto al equipo. 10. Independencia con respecto al sistema operativo. 11. Independencia con respecto a la red. 12. Independencia con respecto al DBMS. Estas doce reglas no son todas independientes entre sí, ni son por fuerza exhaustivas, ni tienen todas la misma importancia ( diferentes usuarios darán diferentes grados de importancia a diferentes reglas en diferentes ambientes ). Sin embargo, sí son útiles como fundamento para entender la tecnología distribuida y como marco de referencia para caracterizar la funcionalidad de sistemas distribuidos específicos. Un último punto introductorio: es importante distinguir los sistemas distribuidos de bases de datos verdaderos, generalizados, de los sistemas que tan solo ofrecen algún tipo de acceso remoto a los datos ( llamados a veces sistemas de procesamiento distribuido o sistemas de red ). En un " sistema de acceso remoto a los datos ", el usuario podría ser capaz de trabjar con datos de un sitio remoto, o aun con datos de varios sitios remotos al mismo tiempo, pero " se notan las costuras" ; el usuario definitivamente está consciente ( en mayor o menor grado ) de que los datos son remotos, y debe comportarse de manera acorde. En cambio, en un sistema distribuido verdadero, las costuras son invisibles. Las doce reglas.
1. Autonomía Local.Los sitios de un sistema distribuido deben ser autónomos . La autonomía local significa que todas las operaciones en un sitio dado se controlan en ese sitio; ningún sitio X deberá depender de algún otro sitio Y para su buen funcionamiento (pues de otra manera el sitio X podría ser incapaz de trabajar, aunque no tenga en sí problema alguno, si cae el sitio Y, situación a todas luces indeseable). La autonomía local implica también un propietario y una administración locales de los datos, con responsabilidad local : todos los datos pertenecen " en realidad" a una base de datos local, aunque sean accesibles desde algún sitio remoto. Por tanto, las cuestiones de seguridad, integridad y representación en almacenamiento de los datos locales permanecen bajo el control de la instalación local.
2. No dependencia de un sitio central. La autonomía local implica que todos los sitios deben tratarse igual; no debe haber dependencia de un sitio central "maestro" para obtener un servicio central, como por ejemplo un procesamiento centralizado de las consultas o una administración centralizada de las transacciones, de modo que todo el sistema dependa de ese sitio central. Este segundo objetivo es por tanto un corolario del primero ( si se logra el primero, se logrará pro fuerza el segundo ) . Pero la "no dependencia de un sitio central" es deseable por sí misma, aun si no se logra la autonomía local completa. Por ello vale la pena expresarlo como un objetivo separado. La dependencia de un sitio central sería indeseable al menos por las siguientes razones : en primer lugar, eses sitio central podrí ser un cuello debotella; en segundo lugar, el sistema sería vulnerable ; si el sitio central sufriera un desperfecto, todo el sistema dejaría de funcionar. 3. Operación continua. En un sistema distribuido, lo mismo que en uno no distribuido, idealmente nunca debería haber necesidad de apagar a propósito el sistema Es decir, el sistema nunca debería necesitar apagarse para que se pueda realizar alguna función, como añadirse un nuevo sitio o instalar una versión mejorada del DBMS en un sitio ya existente.
4. Independencia con respecto a la localización. La idea básica de la independencia con respecto a la localización (también conocida como transparencia de localización) es simple : no debe ser necesario que los usuarios sepan dónde están almacenados físicamente los datos, sino que más bien deben poder comportarse - al menos desde un punto de vista lógico - como si todos los datos estuvieran almacenados en su propio sitio local. La independencia con respecto a la localización es deseable porque simplifica los programas de los usuarios y sus actividades en la terminal. En particular, hace posible la migración de datos de un sitio a otro sin anular la validez de ninguno de esos programas o actividades. Esta posibilidad de migración es deseable pues permite modificar la distribución de los datos dentro de la red en respuesta a cambios en los requerimientos de desempeño.
5. Independencia con respecto a la framentación. Un sistema maneja fragmentación de los datos si es posible dividir una relación en partes o "fragmentos" para propónsitos de almacenamiento físico. La fragmentación es deseable por razones de desempeño: los datos pueden almacenarse en la localidad donde se utilizan con mayor frecuencia, de manera que la mayor parte de las operaciones sean sólo locales y se reduzca al tráfico en la red. Por ejemplo, la relación empleados EMP podría fragmentarse de manera que los registros de los empleados de Nueva York se almacenen en el sitio de Nueva York, en tanto que los registros de los empleados de Londres se almacenan en el sitio de Londres. Existen en esencia dos clases de fragmentación, horizontal y vertical, correspondientes a las operaciones relacionales de restricción y proyección; respectivamente. En términos más generales, un fragmento puede ser cualquier subrelación arbitraria que pueda derivarse de la relación original mediante operaciones de restricción y proyección ( excepto que, en el caso de la proyección es obvio que las proyecciones deben conservar la clave primaria de la relación original ). La reconstrucción de la relación origianl a partir de los fragmentos se hace mediante operciones de reunión y unión apropiadas ( reunión en el caso de fragmentación vertical,y la unión en casos de fragmentación horizontal ). Ahora llegamos a un punto principal : un sistema que maneja la fragmentación de los datos deberá ofrecer también una independencia con respecto a la fragmentación (llamada también transparencia de fragmentación). La independencia con respecto a la fragmentación ( al igual que la independencia con respecto a la independencia con respecto a la localización) es deseable porque simplifica los programas de los usuarios y sus actividades en la terminal. 6. Independencia de réplica. Un sistema maneja réplica de datos si una relación dada (ó en términos más generales, un fragmento dado en una relación) se puede representar en el nivel físicio mediante varias copias réplicas, en muchos sitios distintos. La réplica es deseable al menos por dos razones : en primer lugar, puede producir un mejor desempeño (las aplicaciones pueden operar sobre copias locales en vez de tener que comunicarse con sitios remotos) ; en segundo lugar, también puede significar una mejor disponibilidad (un objeto estará disponible para su procesamiento en tanto esté disponible por lo menos una copia, al menos para propósitos de recuperación). La desventaja principal de las réplicas es desde luego que cuando se pone al día un cierto objeto copiado, deben ponerse al dia todas las réplicas de ese objeto : el problema de la propagación de actualizaciones. La réplica como la fragmentació, debe ser "transparente para el usuario". En otras palabras , un sistema que maneja la réplica de los datos deberá ofrecer también una independencia de réplica (conocida también como transparencia de réplica); es decir, los usuarios deberán poder comportarse como si sólo exitiera una copia de los datos. La independencia de réplica es buena porque simplifica los programas de los usuarios y sus actividades en la terminal. En particualr, permite la creación y eliminación dinámicas de las réplicas en cualquier momento en respuesta a cambios en los requerimientos, sin anular la validez de esos programas o actividades de los usuarios. 7. Procesamiento distribuido de consultas. En este aspecto debemos mencionar dos puntos amplios. Primero consideremos la consulta "obtener los proveedores de partes rojas en Londres". Supongamos que el usuario está en la instalación de Nueva York y los datos están en el sitio de Londres. Supongamos también que son n/ n registros de Londres a Nueva York. Si, por otro lado, el sistema no es relacional, sino de un registro a la vez, la consulta implicará en esencia 2n mensajes : n de Nueva York a Londres solicitando el siguiente registro, y n de Londres a Nueva York para devolver eses siguiente registro. Así, el ejemplo ilustra el punto de que un sistema relacional tendrá con toda probabilidad un mejor desempeño que uno no relacional (para cualquier consulta que solicite varios registros), quizá en varios órdenes de magnitud. En segundo lugar, la optimización es todavía más importante en un sistema distribuido que en uno centralizado. Lo esencial es que, en una consulta como la anterior, donde están implicados varios sitios, habrá muchas maneras de trasladar los datos en al red para satisfacer la solicitud, y es crucial encontrar una estrategia suficiente. Por ejemplo, una solicitud de unión de una relación Rx almacenada en el sitio X y una relación Ry almacenada en el sitio Y podría llevarse a cabo trasladando Rx a Y o trasladando Ry a X, o trasladando las dos a un tercer sitio Z . 8. Manejo distribuido de transacciones.
El manejo de transaccioens tiene dos aspectos principales, el control de recuperación y el control de concurrencia, cada uno de los cuales requiere un tratamiento más amplio en el ambiente distribuido. Para explicar eses tratamiento más amplio es preciso introducir primero un término nuevo, "agente". En un sistema distribuido, una sola transacción puede implicar la ejecución de código en varios sitios ( en particular puede implicar a actualizaciones en varios sitios ). Por tanto, se dice que cada transacción está compuesta de varios agentes, donde un agente es el proceso ejecutado en nombre de una transacción dada en determinado sitio. Y el sistema necesita saber cuándo dos agentes son parte de la misma transacción; por ejemplo, es obvio que no puede permitirse un bloqueo mutuo entre dos agentes que sean parte de la misma transacción. La cuestión especifica del control de recuperación; : para asegurar, pues que una transacción dada sea atómica ( todo o nada ) en el ambiente distribuido, el sistema debe segurarse de que todos los agentes correspondientes a esa transacción se comprometan al unísono o bien que retrocedan al unísono. Este efecto puede lograrse mediante el protocolo de compromiso en dos fases. En cuanto al control de concurrencia, esta función en un ambiente distribuido estará basada con toda seguridad en el bloqueo, como sucede en los sistemas no distribuidos. 9. Independencia con respecto al equipo. En realidad, no hay mucho que decir acerca de este tema, el título lo dice todo. Las instalaciones de cómputo en el mundo real por lo regular incluyen varias máquinas diferentes -máquinas IBM, DEC, HP, UNISYS, PC etc- y existe una verdadera necesidad de poder integrar los datos en todos esos sistemas y presentar al usuario "una sola imagen del sistema". Por tanto conviene ejecutar el mismo DBMS en diferentes equipos, y ademáS lograr que esos diferentes equipos participen como socios iguales en un sistema distribuido. 10. Independencia con respecto al sistema operativo. Este objetivo es un corolario del anterior. Es obvia la conveniencia no sólo de poder ejecutar el mismo DBMS en diferentes equipos, sino también poder ejecutarlo en diferentes sistemas operativos y lograr que una versión MVS y una UNIX y una PC/DOS participen todas en el mismo sistema distribuido.
11. Independencia con respecto a la red. Si el sistema ha de poder manejar múltiples sitios diferentes, con equipo distinto y diferentes sistemas operativos, resulta obvia la conveniencia de pdoer manejar también varias redes de comunicación distintas.
12. Independencia con respecto al DBMS Bajo este título consideramos las implicaciones de relajar la suposición de homogeneidad estrictia. Puede alegarse que esa suposición es quizá demasiado rígida. En realidad, no se requiere sino que los DBMS en los diferentes sitios manejen todos la misma interfaz ; no necesitan ser por fuerza copias del mismo sistema.
SACBEOB TE REGALA ESTOS SERVICIOS
BOLSA DE TRABAJO
SOCIEDAD DE ALUMNOS DE SISTEMAS
