Bases de Datos Distribuidas: Principios y Reglas

¿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 mostrada en la figura. La información en diferentes sucursales está distribuida en tres computadoras ("backend computers"), que realizan el control de funciones de la base de datos. Las aplicaciones son ejecutadas por diferentes computadoras.

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 relevante desde el punto de vista de la aplicación. Lo que perdemos aquí 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 sí mismo.

¿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 dentro 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

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.

Las 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 trabajar 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á por 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, ese sitio central podría ser un cuello de botella.
• 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.