Este documento presenta una introducción a las bases de datos distribuidas. Explica que surgieron para reflejar la estructura distribuida de las empresas y conectar "islas de información". Describe los tipos principales de bases de datos distribuidas, incluyendo centralizadas, replicadas, fragmentadas e híbridas. También resume los objetivos clave de un sistema de gestión de bases de datos distribuidas, como la autonomía local, la transparencia de ubicación y la administración de transacciones distribuidas.

1. Bases de Datos
Distribuidas
Presentado Por:
Jonathan Pérez…2008-0821
Renso Díaz…2009-0133
Juan Castillo…2009-0161
Luis Collado…2009-0452

2. HISTORIA DE LAS BASES DE DATOS DISTRIBUIDAS
La necesidad de almacenar datos de forma masiva dio
paso a la creación de los sistemas de bases de datos. En
1970 Edgar Frank Codd escribió un artículo con nombre:
"A Relational Model of Data for Large Shared Data
Banks" ("Un modelo relacional para grandes bancos de
datos compartidos"). Con este artículo y otras
publicaciones, definió el modelo de bases de datos
relacionales y reglas para poder evaluar un
administrador de bases de datos relacionales.

3. Inicialmente podemos decir que las SBDD surgen como
respuesta a la distribución que las empresas ya tienen, al
menos de manera lógica (divisiones, departamentos, etc…) y
que en ocasiones también tiene de manera física (plantas,
fábricas, etc…). Todo esto nos lleva a que posiblemente los
datos también estén distribuidos, ya que cada unidad
organizacional mantendrá los datos con los que normalmente
opere.

4. A cada uno de estas subdivisiones se les llama “islas de información”
(sitios), y lo que hace un sistema distribuido es establecer los “puentes”
necesarios para conectar a esas islas entre si.
En definitiva lo que pretende es que la estructura de la base de datos
refleje la estructura de la empresa (principal beneficio de los sistemas
distribuidos). Es en realidad una BD virtual compuesta de varias BDs
“reales” distintas que se encuentran en varios sitios distintos.

5. Otra de las principales motivaciones para el desarrollo de sistemas de bases de
datos es el deseo de integrar los datos operacionales de una organización y
proporcionar un acceso controlado a esos datos. Aunque la integración y el acceso
controlado pueden implicar la necesidad de utilizar mecanismos de centralización,
el objetivo en realidad no es ese. De hecho, el desarrollo de redes informáticas
promueve el modo descentralizado de trabajo.
Los SGBD distribuidos deberían ayudarnos a resolver el problema de las islas de
información. Esto puede ser resultado de la separación geográfica, de la
incompatibilidad de las arquitecturas informáticas, de los protocolos de
comunicaciones, etc. Si se consigue integrar las bases de datos en un todo lógico
coherente, podemos resolver el problema.

6. DEFINICIÓN DE BASES DE DATOS DISTRIBUIDAS
Podemos ver las BDD Como una colección de múltiples bases
de datos interrelacionadas lógicamente y distribuidas por una
red de computadores, formando una única gran base de
datos.

7. TIPOS DE BASE DE DATOS DISTRIBUIDAS (I)
Una de las decisiones más importantes que el
diseñador de bases de datos distribuidas debe tomar
es el posicionamiento de la data en el sistema y el
esquema bajo el cual lo desea hacer. Para esto
existen cuatro alternativas principales: centralizada,
replicada, fragmentada, e híbrida.

8. TIPOS DE BASE DE DATOS DISTRIBUIDAS (II)
• Centralizada: Es muy similar al modelo de Cliente/Servidor en el sentido
que la BDD está centralizada en un lugar y los usuarios están
distribuidos. Este modelo solo brinda la ventaja de tener el
procesamiento distribuido ya que en sentido de disponibilidad y
fiabilidad de los datos no se gana nada.
• Replicadas: El esquema de BDD de replicación consiste en que cada
nodo debe tener su copia completa de la base de datos. Es fácil ver que
este esquema tiene un alto costo en el almacenamiento de la
información. Debido a que la actualización de los datos debe ser
realizada en todas las copias, también tiene un alto costo de escritura,
pero todo esto vale la pena si tenemos un sistema en el que se va a
escribir pocas veces y leer muchas, y dónde la disponibilidad y fiabilidad
de los datos sea de máxima importancia.

9. TIPOS DE BASE DE DATOS DISTRIBUIDAS (III)
• Particionadas: Este modelo consiste en que solo hay una copia de cada
elemento, pero la información está distribuida a través de los nodos. En
cada nodo se aloja uno o más fragmentos disjuntos de la base de datos.
Como los fragmentos no se replican esto disminuye el costo de
almacenamiento, pero también sacrifica la disponibilidad y fiabilidad de los
datos. Algo que se debe tomar en cuenta cuando se desea implementar
este modelo es la granularidad de la fragmentación. La fragmentación se
puede realizar también de tres formas:
• Horizontal
• Vertical
• Mixto
• Híbrida: Este esquema simplemente representa la combinación del
esquema de partición y replicación. Se particiona la relación y a la vez los
fragmentos están selectivamente replicados a través del sistema de BDD.

10. LOS OBJETIVOS DE UN SGBDD
1. Autonomía local: Los sitios en un sistema distribuido deben ser autónomos.
 La autonomía local significa que todas las operaciones en un sitio dado están
controladas por ese sitio; ningún sitio X debe depender de algún otro sitio Y para
su operación satisfactoria.
 La seguridad, integridad y representación de almacenamiento de los datos
locales permanecen bajo el control y jurisdicción del sitio local.
2. Independencia de un sitio central: La autonomía local implica que todos los
sitios deben ser tratados como iguales.
 Por lo tanto, no debe haber particularmente ninguna dependencia de un sitio
“maestro” central para algún servicio central, tal que todo el sistema dependa de
ese sitio central.
 Razones por las cuales no debería haber un sitio central:
 El sitio central puede ser un cuello de botella
 El sistema sería vulnerable; es decir, si el sitio central falla, también fallará
todo el sistema

11. 3. El sistema debe estar en continua operación: Una ventaja de los sistemas distribuidos es
que deben proporcionar mayor confiabilidad y mayor disponibilidad.
Confiabilidad. La probabilidad de que el sistema esté listo y funcionando en cualquier
momento dado. Los SD no son una propuesta de todo o nada; pueden continuar
operando cuando hay alguna falla en algún componente independiente.
Disponibilidad: probabilidad de que el sistema esté listo y funcionando continuamente a lo
largo de un período 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.
4. Transparencia de ubicació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.
5. Transparencia de fragmentación: Un sistema soporta la fragmentación de datos cuando
puede ser dividida en o partes o fragmentos, para efectos de almacenamiento físico.
 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.
 Los usuarios deben comportarse como si los datos en realidad estuvieran sin
fragmentación alguna.

12. 6. Transparencia en la replicación: El sistema soporta replicación de datos cuando
un fragmento puede ser representado por muchas copias distintas, o réplicas,
guardadas en muchos sitios distintos.
Las réplicas son necesarias por dos razones principales:
 Significan un mejor rendimiento (las aplicaciones pueden operar sobre las copias
locales en lugar de tener que comunicarse con sitios remotos).
 Pueden significar una mejor disponibilidad (un objeto replicado permanece
disponible para su procesamiento, mientras esté disponible al menos una copia).
Por supuesto, la principal desventaja de las réplicas es que al actualizarlas es
necesario actualizar todas: el problema de la propagación de la actualización.
7. Procesamiento de consultas distribuidas: El sistema debe ser capaz de procesar
consultas que afecten a datos de más de un sitio y hacerlo de forma
optimizada. 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).

13. 8. Administración de transacciones distribuidas: Existen dos aspectos principales en la
administración de transacciones: control de recuperación y control de la concurrencia.
 Ambos aspectos requieren un tratamiento amplio en el ambiente distribuido.
 Ya que una sola transacción puede involucrar la ejecución de código en muchos sitios.
 Puede involucrar actualizaciones en muchos sitios y se debe de cuidar que la
transacción no caiga en un bloqueo mortal (basado en el bloqueo).
 Para el control de la recuperación, es necesario asegurarse que una transacción
dada sea atómica en el ambiente distribuido, el sistema debe por lo tanto asegurarse
de que la transacción sea confirmada o deshecha (se puede utilizar el protocolo de
confirmación de dos fases).
9. Independencia del hardware: Es necesario tener la posibilidad de ejecutar el mismo
SGBDD en diferentes plataformas de hardware (IBM, ICL, HP, PC, SUN) y, además, hacer
que esas máquinas diferentes participen de igual forma en un sistema distribuido.
10. Independencia del sistema operativo: Una vez más, es necesario tener la posibilidad
de ejecutar el mismo SGBDD, en diferentes plataformas de sistema operativo (UNIX,
Windows XP …) bajo un mismo sistema distribuido.

14. 11. Independencia de la red: El sistema debe tener la posibilidad de soportar
también, una variedad de redes de comunicación distintas.
12. Independencia del SGBD: Lo que se necesita es que todos los ejemplares de
DBMS en sitios diferentes soporten la misma interfaz.
 Aunque no tienen que ser necesariamente copias del mismo software DBMS.
 En otras palabras, sería posible que el sistema distribuido fuera heterogéneo, al
menos en cierto grado.
 Sería muy bueno si diferentes DBMS pudieran participar de alguna forma en un
sistema distribuido.

15. VENTAJAS (I)
• La principal ventaja de los sistemas distribuidos es la capacidad de compartir y
acceder a la información de una forma fiable y eficaz.
• Flexibilidad, acceso desde distintos lugares y por distintas personas a la vez
• Autonomía, Cada nodo tiene cierto grado de control sobre sus datos, en un
sistema centralizado, hay un administrador del sistema responsable de los datos
a nivel global. En base de datos distribuidas, cada administrador local puede
tener un nivel de autonomía.
• Agilización del procesamiento de consultas. Si una consulta comprende datos de
varias localidades, puede ser posible dividir la consulta en varias subconsultas
que se ejecuten en paralelo en distintas localidades.

16. VENTAJAS (II)
• Mejora del rendimiento, BD más pequeñas, operaciones de menor
volumen. Los datos son localizados en lugar más cercano, por tanto, el
acceso es más rápido, logrando esto un mejor rendimiento.
• Fiabilidad y disponibilidad. Si se produce un fallo en una localidad de un
sistema distribuido, es posible que las demás localidades puedan seguir
trabajando. En particular, si los datos se repiten en varias localidades,
una transacción que requiere un dato específico puede encontrarlo en
más de una localidad. Así, el fallo de una localidad no implica
necesariamente la desactivación del sistema.

17. VENTAJAS (III)
• Modularidad, se pueden modificar, agregar o quitar sistemas de la base
de datos distribuida sin afectar a los demás sistemas (módulos).

18. DESVENTAJAS
• Coste de desarrollo del software. La complejidad añadida que es
necesaria para mantener la coordinación entre nodos hace que el
desarrollo de software sea más costoso.
• Dificultad de diseño.
• Mayor probabilidad de errores. Como los nodos que constituyen el
sistema funcionan en paralelo, es más difícil asegurar el funcionamiento
correcto de los algoritmos, así como de los procedimientos de
recuperación de fallos del sistema.
• Mayor dificultad para la administración de la base de datos, y un mayor
coste a nivel de implementación.