Objetivos de las BDD

1. Autonoma local: Los sitios de un sistema distribuido deben ser autnomos 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.
2. Independencia de un sitio central: El anterior objetivo implica que todos los sitios deben ser
tratados como iguales, por lo tanto no debe existir ningn sitio maestro central del cual
dependan el resto. Esto es as por das razones fundamentales:

Puede ser un cuello de botella.

Puede ser vulnerable, si ste falla tambin fallar todo el sistema.
3. El sistema debe estar en continua operacin: Un fallo en uno de los nodos no debe afectar
al sistema. Tampoco si se aaden nuevos nodos. As, un SD deber proporcionar las
siguientes caractersticas.

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 perodo especificado. Podemos decir que nunca
debera ser necesario apagar el sistema para realizar tareas como: aadir un sitio,
creacin dinmica de fragmentos, actualizacin de versiones, etc.
4. Transparencia de ubicacin: Para el usuario la localizacin fsica de los datos debe ser
transparente. No necesita saber dnde est el dato para utilizarlo.
5. Transparencia de fragmentacin: Los usuarios deben comportarse, como si los datos en
realidad no tuvieran fragmentacin alguna, la cual es necesaria por razones de rendimiento.
Este objetivo es deseable, como el anterior, porque simplifica los programas de los usuarios
y sus actividades en el sitio.
6. Transparencia en la replicacin: Consiste en que el usuario no debe tener conciencia de la
replicacin de los datos, as como de su destruccin La replicacin 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 propagacin de las actualizaciones.
7. Procesamiento de consultas distribuidas: El sistema debe ser capaz de procesar consultas
que afecten a datos de ms de un sitio y hacerlo de forma optimizada. Este hecho puede ser

considerado como otra razn por la que los sistemas distribuidos siempre son relacionales
(las peticiones relacionales son optimizables, mientras que las no relacionales no lo son).
8. Administracin de transacciones distribuidas: El sistema distribuido debe disponer de
mecanismos (protocolos) adecuados para el control de concurrencia y la recuperacin de
transacciones distribuidas. Una transaccin puede acceder y modificar datos en diferentes
nodos sin que el usuario se entere de que mltiples sitios se estn viendo afectados por la
transaccin.
9. Independencia del hardware: Es necesario tener la posibilidad de ejecutar el mismo SGBDD
en diferentes plataformas de hardware (IBM, PC) y, adems, hacer que esas mquinas
diferentes participen de igual forma en un sistema distribuido.
10. Independencia del sistema operativo: Un vez ms, es necesario tener la posibilidad de
ejecutar el mismo SGBDD, en diferentes plataformas de sistema operativo (UNIX, Windows
7 ) bajo un mismo sistema distribuido.
11. Independencia de la red: El sistema debe tener la posibilidad de soportar tambin, una
variedad de redes de comunicacin distintas.
12. Independencia del SGBD: Lo que en realidad se pretende es que todos los ejemplares del
SGBDD locales en sitios diferentes soporten la misma interface, que en este caso sera el
estndar SQL oficial. Con esto conseguiremos que el sistema distribuido fuera heterogneo,
al menos en cierta medida ya que en realidad los fabricantes solo cumplen determinadas
caractersticas de este estndar, que suelen ser distintas de unos a otros.