BASES DE DATOS DISTRIBUIDAS.

...

INCONVENIENTES DE LA BASES DE DATOS DISTRIBUIDAS

•Costo 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.

•Seguridad.- Se incrementa la posibilidad de fallas de seguridad, considerando que los datos se encuentran en varios sitios, repartiéndose la responsabilidad de manejo de los datos en varios sitios.

•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.

•Altos costos de entrenamiento. -Son más elevados de lo que pudiese ser un modelo distribuido de lo que sería un modelo centralizado.

•Complejidad de manejo y de control. El manejo de datos los cuales se encuentren distribuidos es más complejo.

•Mayor sobrecarga de procesamiento. El intercambio de mensajes y ejecución de algoritmos para el mantenimiento de la coordinación entre nodos.

COMPONENTES

Un sistema de administración de de bases de datos distribuidas, debería incluir por lo menos lo siguiente:

- Estaciones de trabajo que formen el sistema de red

- Componentes de software y hardware residentes en cada estación de trabajo

- Medios de comunicación que transporten los datos de una estación de trabajo a otra.

- El procesador de transacciones, el cual es el componente de software que solicita los datos y este se encuentra en cada computadora

- El Procesador de datos Es un componente de software que se encarga de guardar y recuperar los datos localizados en el sitio.

LAS DOCE REGLAS DE LAS BASES DE DATOS DISTRIBUIDAS

- Independencia del sitio Loca: Los sitios distribuidos deben ser autónomos, es decir que todas las operaciones en un sitio dado se controlan en ese sitio, lo cual implica que cada sitio local puede actuar como un DBMS local.

- Independencia de sitio central: No debe de haber dependencia de un sitio central para obtener un servicio. Todos los sitios deben ser tratados como iguales bajo esta premisa. La dependencia de un sitio central es indeseable por lo siguiente: este se puede volver un cuello de botella, y el sistema seria vulnerable ya que si falla el central, todos fallan. Según Date, 2001.

- Operación Continua: Nunca debería apagarse para que se pueda realizar alguna función, como añadir un nuevo sitio. Esto permite tener mayor disponibilidad y confiabilidad.

- Independencia de ubicación: No debe de ser necesario que los usuarios sepan dónde están almacenados físicamente los datos, sino que más el usuario lo debe de ver como si solo existiera un sitio local, no es necesario saber donde están para recuperarlos.

- Transparencia de fragmentación: La fragmentación es deseable por razones de desempeño, los datos, pueden almacenarse en la localidad donde se utilizan con mayor frecuencia de manera que la mayor parte de las operaciones sean sólo locales y se reduzca el tráfico en la red. El usuario solo ve una base a nivel lógico, estando la base dividida en partes para efecto de almacenamiento físico.

- Independencia de réplica: Si una relación dada (es decir, un fragmento dado de una relación) se puede presentar en el nivel físico mediante varias copias almacenadas o réplicas, en muchos sitios distintos.

- Procesamiento Distribuido de Consultas: El objetivo es convertir transacciones de usuario en instrucciones para manipulación de datos, la consulta puede ser ejecutada en barios sitios diferentes de procesamiento de DATOS.

- Procesamiento Distribuido de Transacciones: Tiene dos aspectos principales, el control de recuperación y el control de concurrencia, cada uno de los cuales requiere un tratamiento más amplio en el ambiente distribuido. Una transacción puede actualizar datos en varios sitios diferentes, esto de manera transparente para el usuario.

- Independencia de hardware: El SGBDD debe ser ejecutable en cualquier plataforma de hardware.

- Independencia con respecto al Sistema Operativo: El sistema debe ser ejecutable en los diferentes SO.

- Independencia con respecto a la red: El sistema debe poder ejecutarse en diferentes redes.

- Independencia de la base de datos. Debe ser posible ejecutar diferentes SGBDD locales que utilicen distintos modelos de datos.

TIPOS DE FRAGMENTACIÓN DE DATOS

Existen tres tipos de fragmentación:

1. Fragmentación horizontal

2. Fragmentación vertical

3. Fragmentación híbrida

FRAGMENTACIÓN HORIZONTAL

Consiste en el particionamiento en tuplas de una relación global en subconjuntos, donde cada subconjunto puede contener datos que tienen propiedades comunes y se puede definir expresando cada fragmento como una operación de selección sobre la relación global.

FRAGMENTACIÓN VERTICAL

Una fragmentación vertical de una relación R produce fragmentos R1, R2, ..., Rr, cada uno de los cuales contiene un subconjunto de los atributos de R así como la llave primaria de R. El objetivo de la fragmentación vertical es particionar una relación en un conjunto de relaciones más pequeñas de manera que varias de las aplicaciones de usuario se ejecutarán sobre un fragmento. En este contexto, una fragmentación "óptima" es aquella que produce un esquema de fragmentación que minimiza el tiempo de ejecución de las consultas de usuario.

La fragmentación vertical ha sido estudiada principalmente dentro del contexto de los sistemas de manejo de bases de datos centralizados como una herramienta de diseño, la cual permite que las consultas de usuario traten con relaciones más pequeñas haciendo, por tanto, un número menor de accesos a páginas.

FRAGMENTACIÓN HIBRIDA

En muchos casos una fragmentación horizontal o vertical de un esquema de una base de datos