Los sistemas de bases de datos multiusuarios están soportados por diversas arquitecturas de sistemas distintos; anteriormente los más comunes eran los sistemas de teleprocesamiento, y conforme los costos de los equipos de cómputo han ido disminuyendo ha sido más factible la utilización de más de una computadora, lo cual ha producido alternativas de bases de datos multiusuarios.
Por tal motivo, antes de comenzar a hablar del concepto de bases de datos distribuidas hay que conocer los conceptos relacionados con el esquema cliente-servidor.
El esquema cliente-servidor se puede definir, desde el punto de vista funcional, como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información en forma transparente, aún en entornos multiplataforma.
Pero antes de empezar a profundizar en el esquema cliente-servidor hay que definir qué es un cliente y qué es un servidor. En términos conceptuales, cliente es aquella entidad en la que se formula un requerimiento y valida los datos indispensables para solicitarlo al servidor; el servidor es una entidad que recibe requerimientos por parte del cliente, los procesa, genera los resultados y los envía al cliente, éste recibe los resultados del servidor y los utiliza para mostrarlos al usuario para que, a su vez, éste disponga de ellos (ver Figura 1).
Figura 1. Esquema cliente-servidor.
Para que los clientes y los servidores puedan comunicarse, se requiere una infraestructura de comunicaciones que proporcione los mecanismos básicos de direccionamiento y transporte.
La mayoría de los sistemas cliente-servidor actuales se basan en redes locales y, por lo tanto, utilizan protocolos no orientados a conexión, lo cual implica que las aplicaciones deben hacer las verificaciones. La red debe tener características adecuadas de desempeño, confiabilidad, transparencia y administración.
Teniendo ya las bases sobre el esquema cliente-servidor, iniciaremos con el concepto de base de datos distribuida.
Una base de datos distribuida es en realidad una especie de objeto virtual, cuyas partes componentes se almacenan físicamente en varias bases de datos reales distintas ubicadas en diferentes sitios, es la unión lógica de esas bases de datos.” (Date, C. 2001)
Al hablar de bases de datos distribuidas nos referimos a la base de datos la cual está distribuida, es decir, la base de datos o una porción de ella está almacenada en varias computadoras. Por lo anterior, podemos definir a una base de datos distribuida (BDD) como un conjunto de múltiples bases de datos lógicamente relacionadas, las cuales se encuentran distribuidas entre diferentes sitios interconectados por una red de comunicaciones (ver Figura 1.2).
Figura 2. Representación general de sistemas de bases de datos distribuidas.
Ventajas de las bases de datos distribuidasAutonomía local: Cuando las organizaciones tienen varias localidades, pudiera haber un conjunto de datos para una localidad dada que se use con más frecuencia y quizás exclusivamente.
Mejoramiento de la performance: Permitir que cada sitio almacene y mantenga su propia base de datos, facilita el acceso inmediato y eficaz a los datos que se usan con más frecuencia.
Mejoramiento de la confiabilidad/disponibilidad: Si un sitio falla, los sitios restantes pueden continuar operando. Si los datos están duplicados en más de un sitio, los datos pueden estar disponibles en otro lugar.
Satisfacción de los usuarios: Permitir el control local de los datos que se usan con más frecuencia en un sitio puede mejorar el grado de satisfacción de los usuarios.
Acceso compartido: Los usuarios de un sitio pueden acceder a los datos que residen en otros sitios.
En situaciones de gran cantidad de comunicación entre los sitios, el sobrecosto de las coordinaciones y las tareas de control puede degradar severamente el rendimiento.
El procesamiento de las transacciones y la recuperación de datos es más complejo, puede significar un requisito de leer y actualizar datos en los diferentes sitios y en transmitir los mensajes respectivos entre ellos.
Después de terminar una transacción, el gestor de BD debe asegurarse que todos los sitios relevantes hayan completado su procesamiento.
Desde el punto de vista del usuario, un sistema distribuido debe ser idéntico a un sistema no distribuido.
Autonomía local: Los sitios distribuidos deben ser autónomos, es decir, que todas las operaciones en un sitio dado se controlan en ese sitio.
No dependencia de un sitio central: No debe haber dependencia de un sitio central para obtener un servicio, ya que implicaría cuello de botella.
Caída del servicio operación continua: El sistema nunca debería apagarse para que se pueda realizar alguna función, como añadir un nuevo sitio.
Independencia respecto de la localización: El usuario desconoce dónde están físicamente los datos.
Independencia respecto de la fragmentación: La fragmentación de datos se refiere a la forma en la cual las relaciones se pueden subdividir y distribuir entre los sitios de la red.
En 1987 uno de los más importantes y conocidos teóricos de las bases de datos relacionales, C. J. Date, propuso 12 objetivos que debían alcanzar los diseñadores en sus BDD junto con sus SGBDD. Con ellas se pretende lograr que, para el usuario, un sistema distribuido (SD) funcione exactamente igual que si no fuera distribuido. Las 12 reglas son las siguientes:
- Autonomía local: Los nodos de un SD deben ser autónomos en el mayor grado posible, lo que permite una mayor seguridad, control de concurrencia y copias de seguridad. Esto quiere decir que los datos deben ser gestionados localmente, las operaciones son locales y todas las operaciones en un puesto son controladas por ese puesto.
- Independencia de un sitio central: Cada nodo debe actuar independientemente de un nodo central y del resto de nodos. Cada nodo debe tener las mismas capacidades y ser tratado igual al resto. Por lo tanto, no debe existir ningún sitio maestro central del cual dependa el resto. Esto es así por dos razones fundamentales:
- Puede ser un cuello de botella.
- Puede ser vulnerable: si éste falla también fallará todo el sistema.
- Independencia de fallos (operación continua): Un fallo en uno de los nodos no debe afectar al sistema. Tampoco si se añaden nuevos nodos. Así, un SD mejorará las siguientes características.
- Fiabilidad (o confiabilidad): probabilidad de que el sistema esté listo y funcionando en cualquier momento dado.
- Disponibilidad: probabilidad de que el sistema esté listo y funcionando continuamente a lo largo de un periodo especificado. Podemos decir que nunca debería ser necesario apagar el sistema para realizar tareas como: añadir un sitio, creación dinámica de fragmentos, actualización de versiones, etcétera.
- Independencia de localización: Para el usuario la localización física de los datos debe ser transparente; no necesita saber dónde está el dato para utilizarlo.
- Independencia de fragmentación: Los usuarios no necesitan conocer los fragmentos físicos en que está dividida cada colección lógica de datos.
- Independencia de replicación: A nivel lógico, los usuarios no necesitan tener en cuenta si los datos tienen réplicas o no. La replicación es necesaria por las siguientes razones:
- Un mayor rendimiento, puesto que disponemos de copias locales.
- Una mayor disponibilidad, puesto que los datos son accesibles siempre al tenerse varias copias. La principal desventaja, es que hay que mantener actualizadas todas las copias de ese objeto o dato replicado.
Esto nos lleva al problema de la “propagación de las actualizaciones”.
- Procesamiento de consultas distribuidas: El SD debe disponer de mecanismos para optimizar las consultas y, en especial, para reducir la carga de tráfico necesaria. Este hecho puede ser considerado como otra razón por la que los sistemas distribuidos siempre son relacionales (las peticiones relacionales son optimizables, mientras que las no relacionales no lo son).
- Gestión de transacciones distribuidas: El SD debe disponer de mecanismos (protocolos) adecuados para el control de concurrencia y la recuperación de transacciones distribuidas. Una transacción puede acceder y modificar datos en diferentes nodos sin que el usuario se entere de que múltiples sitios se están viendo afectados por la transacción.
- Independencia del hardware: El SD se debe poder implementar en cualquier plataforma válida, es decir, ordenadores con recursos hardware suficientes.
- Independencia del sistema operativo: El SD se debe poder implementar en sitios con cualquier sistema operativo multiusuario.
- Independencia de la red: El SD se debe poder implementar en cualquier red de comunicaciones.
- Independencia del SGBD: Debe permitirse la heterogeneidad, es decir, que cada sitio pueda funcionar con un SGBD diferente, incluso basado en un modelo de datos diferente, siempre y cuando compartan un interfaz común.
En el diseño de una base de datos distribuida podremos optar principalmente por dos tipos de estrategias: la estrategia ascendente y la estrategia descendente.
La estrategia ascendente podría aplicarse en aquel caso donde haya que proceder a un diseño a partir de un número de pequeñas bases de datos existentes, con el fin de integrarlas en una sola. En este caso se partiría de los esquemas conceptuales locales y se trabajaría para llegar a conseguir el esquema conceptual global. Aunque este caso se pueda presentar con facilidad en la vida real, se prefiere pensar en el caso donde se parte de cero y se avanza en el desarrollo del trabajo siguiendo la estrategia descendente.
La estrategia descendente, debería resultar familiar a la persona que posea conocimientos sobre el diseño de bases de datos, exceptuando la fase del diseño de la distribución.
