Objetivos de la Base de Datos distribuida

Autonomia Local: El servidor local de cada sede de la compaa debe responder por las actividades planteadas para l, no debe depender de ningn otro ni de un servidor en la nube, ya que si en algn caso alguno de estos fallase la informacin y el funcionamiento de la empresa se vera afectado. La administracin, cuestiones de almacenamiento e integridad de los datos deben estar bajo control de una instalacin local. No dependencia de un sitio central No abra un servidor central del cual dependan los dems, cada sede local tendr su informacin como tablas consultas, etc que necesite en dicha sede, sin necesidad de depender de una red central. Operacion continua Dentro de la compaia no habra necesidad alguna de apagar nunca el sistema para realizar cualquier actualizacion. Transparencia de fragmentacin: Deseable porque simplifica los programas de los usuarios y sus actividades en la terminal Independencia de Replica: La creacin y destruccin de rplicas debe hacerse transparente al usuario.
La rplica proporciona:
Ventajas, Mayor Prestacin: los datos son locales, Mayor disponibilidad: los datos son accesibles siempre, Desventajas: Hay que propagar las actualizaciones.

Proceso distribuido de consultas: Este objetivo nos permite varias maneras de trasladar los datos. Manejo Distribuido de Transacciones: Transaccin distribuida: varios agentes de la transaccin en varios lugares.
Control de recuperacin: una transaccin atmica. Todos los agentes avanzan o retroceden juntos. Control de concurrencia: Bloqueos mediante paso de mensajes. Independencia con respecto al Sistema Operativo: El sistema debe correr en cualquier sistema operativo sin que le genere problemas al usuario.

Independencia con respecto al DBMS: Se pueden manejar disitintas copias del DBMS si manejan la misma forma estandar de SQL.

Autonoma local El servidor local de cada sede de la compaa debe responder por las actividades planteadas para l, no debe depender de ningn otro ni de un servidor en la nube, ya que si en algn caso alguno de estos fallase la informacin y el funcionamiento de la empresa se vera afectado. La administracin, cuestiones de almacenamiento e integridad de los datos deben estar bajo control de una instalacin local.

No Dependencia de un sitio central: No abra un servidor central del cual dependan los dems, cada sede local tendr su informacin como tablas consultas, etc que necesite en dicha sede, sin necesidad de depender de una red central. Operacin Continua: El sistema no debe tener ningn apagado voluntario por ningn motivo puesto que esto conllevara a una prdida o una cabida a un ataque a la informacin almacenada en la base de datos. Transparencia de fragmentacin:

Independencia de Replica: Proceso distribuido de consultas: Manejo Distribuido de Transacciones: Independencia con respecto al Sistema Operativo: Independencia con respecto al DBMS:

2. No dependencia de un sitio central. La autonoma 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 administracin 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 autonoma local completa. Por ello vale la pena expresarlo como un objetivo separado. La dependencia de un sitio central sera indeseable al menos por las siguientes razones : en primer lugar, ese sitio central podr ser un cuello de botella; en segundo lugar, el sistema sera vulnerable ; si el sitio central sufriera un desperfecto, todo el sistema dejara de funcionar. 3. Operacin continua. En un sistema distribuido, lo mismo que en uno no distribuido, idealmente nunca debera haber necesidad de apagar a propsito el sistema . Es decir, el sistema nunca debera necesitar apagarse para que se pueda realizar alguna funcin, como aadirse un nuevo sitio o instalar una versin mejorada del DBMS en un sitio ya existente. 4. Independencia con respecto a la localizacin. La idea bsica de la independencia con respecto a la localizacin (tambin conocida como transparencia de localizacin) es simple : no debe ser necesario que los usuarios sepan dnde estn almacenados fsicamente los datos, sino que ms bien deben poder comportarse - al menos desde un punto de vista lgico - como si todos los datos estuvieran almacenados en su propio sitio local. La independencia con respecto a la localizacin es deseable porque simplifica los programas de los usuarios y sus actividades en la terminal. En particular, hace posible la migracin de datos de un sitio a otro sin anular la validez de ninguno de esos programas o actividades. Esta posibilidad de migracin es deseable pues permite modificar la distribucin de los datos dentro de la red en respuesta a cambios en los requerimientos de desempeo. 5. Independencia con respecto a la fragmentacin. Un sistema maneja fragmentacin de los datos si es posible dividir una relacin en partes o "fragmentos" para propsitos de almacenamiento fsico. La fragmentacin es deseable por razones de desempeo: los datos pueden almacenarse en la localidad donde se utilizan con mayor frecuencia, de manera que la mayor parte de las operaciones sean slo locales y se reduzca al trfico en la red. Por ejemplo, la relacin empleados EMP podra 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 fragmentacin, horizontal y vertical, correspondientes a las operaciones relacionales de restriccin y proyeccin; respectivamente. En trminos ms generales, un fragmento puede ser cualquier subrelacin arbitraria que pueda derivarse de la relacin original mediante operaciones de restriccin y proyeccin ( excepto que, en el caso de

la proyeccin es obvio que las proyecciones deben conservar la clave primaria de la relacin original ). La reconstruccin de la relacin original a partir de los fragmentos se hace mediante operaciones de reunin y unin apropiadas ( reunin en el caso de fragmentacin vertical, y la unin en casos de fragmentacin horizontal ).

Ahora llegamos a un punto principal : un sistema que maneja la fragmentacin de los datos deber ofrecer tambin una independencia con respecto a la fragmentacin (llamada tambin transparencia de fragmentacin). La independencia con respecto a la fragmentacin ( al igual que la independencia con respecto a la independencia con respecto a la localizacin) es deseable porque simplifica los programas de los usuarios y sus actividades en la terminal. 6. Independencia de rplica. Un sistema maneja rplica de datos si una relacin dada ( en trminos ms generales, un fragmento dado en una relacin) se puede representar en el nivel fsico mediante varias copias almacenadas o rplicas , en muchos sitios distintos.

La rplica es deseable al menos por dos razones : en primer lugar, puede producir un mejor desempeo (las aplicaciones pueden operar sobre copias locales en vez de tener que comunicarse con sitios remotos) ; en segundo lugar, tambin puede significar una mejor disponibilidad (un objeto estar disponible para su procesamiento en tanto est disponible por lo menos una copia, al menos para propsitos de recuperacin). La desventaja principal de las rplicas es desde luego que cuando se pone al da un cierto objeto copiado, deben ponerse al da todas las rplicas de ese objeto : el problema de la propagacin de actualizaciones. La rplica como la fragmentacin, debe ser "transparente para el usuario". En otras palabras , un sistema que maneja la rplica de los datos deber ofrecer tambin una independencia de rplica (conocida tambin como transparencia de rplica); es decir, los usuarios debern poder comportarse como si slo existiera una copia de los datos. La independencia de rplica es buena porque simplifica los programas de los usuarios y sus actividades en la terminal. En particular, permite la creacin y eliminacin dinmicas de las rplicas 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 instalacin de Nueva York y los datos estn en el sitio de Londres. Supongamos tambin que son n</I< los registros proveedor que satisfacen solicitud. Si sistema es relacional, consulta implicar en esencia dos mensajes : uno transmitir la solicitud Nueva York a Londres, y otro para devolver el conjunto resultante de 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 ese siguiente registro. As, el ejemplo ilustra el punto de que un sistema relacional tendr con toda probabilidad un mejor desempeo que uno no relacional (para cualquier consulta que solicite varios registros), quiz en varios rdenes de magnitud. En segundo lugar, la optimizacin es todava ms importante en un sistema distribuido que en uno centralizado. Lo esencial es que, en una consulta como la anterior, donde estn 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 unin de una relacin Rx almacenada en el sitio X y una relacin Ry almacenada en el sitio Y podra 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 transacciones tiene dos aspectos principales, el control de recuperacin y el control de concurrencia, cada uno de los cuales requiere un tratamiento ms amplio en el ambiente distribuido. Para explicar ese tratamiento ms amplio es preciso introducir primero un trmino nuevo, "agente". En un sistema distribuido, una sola transaccin puede implicar la ejecucin de cdigo en varios sitios ( en particular puede implicar a actualizaciones en varios sitios ). Por tanto, se dice que cada transaccin est compuesta de varios agentes, donde un agente es el proceso ejecutado en nombre de una transaccin dada en determinado sitio. Y el sistema necesita saber cundo dos agentes son parte de la misma transaccin; por ejemplo,

es obvio que no puede permitirse un bloqueo mutuo entre dos agentes que sean parte de la misma transaccin. La cuestin especifica del control de recuperacin; : para asegurar, pues que una transaccin dada sea atmica ( todo o nada ) en el ambiente distribuido, el sistema debe asegurarse de que todos los agentes correspondientes a esa transaccin se comprometan al unsono o bien que retrocedan al unsono. Este efecto puede lograrse mediante el protocolo de compromiso en dos fases. En cuanto al control de concurrencia, esta funcin 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 ttulo lo dice todo. Las instalaciones de cmputo en el mundo real por lo regular incluyen varias mquinas diferentes mquinas 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 adems 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 slo de poder ejecutar el mismo DBMS en diferentes equipos, sino tambin poder ejecutarlo en diferentes sistemas operativos y lograr que una versin 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 mltiples sitios diferentes, con equipo distinto y diferentes sistemas operativos, resulta obvia la conveniencia de poder manejar tambin varias redes de comunicacin distintas. 12. Independencia con respecto al DBMS Bajo este ttulo consideramos las implicaciones de relajar la suposicin de homogeneidad estricta. Puede alegarse que esa suposicin es quiz demasiado rgida. 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.

.Consideraciones para el respaldo Es importante realizar copias de respaldo de las Bases de Datos, para ello se deben tener en cuenta las siguientes consideraciones: Plan de Respaldo: El plan de respaldo debe ser dado a conocer a cada uno de los interesados en esta informacin (directivos, administradores de las bases de datos). Definir los datos a incluir en el respaldo:

Se realizara copia de toda la informacin almacenada en la base de datos. Medios de soporte a utilizar: Se guardaran las copias de respaldo una en medio magntica, otra en el servidor y otra en la nube. Tipos de respaldo: se realizara un respaldo global o full, es decir se guardar toda la informacin que se encuentre almacenada al momento de realizar el respaldo.

Cantidad de copias: Es importante definir cuantas copias se deben realizar de los tipos definidos en el punto anterior, debemos tener en cuenta que es conveniente tener copia en la oficina y fuera de ella. Cuando Realizarlo: La actividad de respaldo ser realizada al finalizar el dia cuando todos los usuarios estn por fuera de la base de datos. Se establecer un horario que ser entre las 11 y 12 de la noche.

Periodicidad: Como el volumen de informacin que se va a almacenar en la base de datos de Coca-cola Company se realizarn copias de respaldo diariamente, 3 veces por semana y una al finalizar el cada mes, esto es lo mas conveniente para tener certeza que se tiene un buen respaldo de dicha informacin. Herramientas a utilizar: A la hora de realizar una copia de respaldo de la base de datos hay que tener en cuenta que la informacin es un recurso muy valioso que tiene toda empresa y ms la que nos compete en este momento The Coca-cola Company, por esto se debe elegir la mejor herramienta disponible para ello. Tenemos una serie de alternativas; uranium Backup, cobian Backup, etc,.

Donde almacenarlos: Se guardara una copia de respaldo dentro de una caja fuerte en cada una de las oficinas donde quedara cada servidor, otra copia se guardar en un lugar en la nube (se pagara un hosting para almacenarla). Personas encargadas de realizar y manejar el respaldo: se encargara de estas labores a profesionales en el tema y a efinir la persona encargada de realizar el respaldo y las recuperaciones, se puede delegar a la misma persona o por seguridad una que realice el respaldo y la otra las recuperaciones.

Verificacin del respaldo: Esto conlleva tiempo, pero es importante realizar revisiones peridicas para verificar que la copia de respaldo este correcta.

Registro: se recomienda llevar un registro de los respaldos y de las recuperaciones realizadas, esto permite tener un historial de lo sucedido en los procesos de cambios y/o actualizaciones y de recuperaciones realizadas.