Bases De Datos Distribuidas

Diseño de bases de datos distribuidas

En este trabajo no nos vamos a basar en el diseño de los sistemas distribuidos ni en la arquitectura de las redes ya que partiremos de que estos ya están creados o que se crearan posteriormente conforme a las necesidades de las bases de datos.

Se ha sugerido que la organización de sistemas distribuidos puede ser investigada a lo largo de tres dimensiones ortogonales según Levin & Morgan.

Estos tres niveles son:

1. Nivel de distribución 2. Comportamiento de los patrones de acceso. 3. Nivel de conocimiento en el comportamiento del patrón de acceso.

La imagen representa los tres niveles a lo largo de las dimensiones. En términos del nivel de distribución hay tres posibilidades.

dinámico

Estático

Datos

Datos + Programas

Patrones de acceso

Distribución

Nivel de conocimiento

Información completa

Información parcial

Montes de Oca Olguín Antonio de Jesús Base de datos distribuidas UNAM-FES Acatlan.

Primero: Que no haya distribución; cada aplicación y sus datos se ejecutan en un sitio y no hay comunicación con algún otro programa o acceso a algún archivo de datos de otro sitio. Esto caracterizaba a los primeros días de trabajo en red pero ya no es tan común en nuestros tiempos.

Segundo: Distribución de datos; Todos los programas son replicados en todos los sitios pero no los archivos de datos por consiguiente las peticiones de los usuarios son manejadas en el sitio donde fueron originados y solo los archivos de datos necesarios son movidos alrededor de la red.

Datos + programas: los archivos de datos y los programas pueden ser compartidos.

En el diagrama se muestra una distinción entre la distribución de datos y la distribución de datos + programas ilustrando las diferencias entre sistemas de computadora distribuidos homogéneos y heterogéneos. Indica correctamente que en un ambiente heterogéneoes más difícil e incluso imposible ejecutar un programa dado en diferente hardware bajo un diferente sistema operativo.

A lo largo de la segunda dimensión del comportamiento de los patrones de acceso es posible identificar dos alternativas. Los patrones de acceso de peticiones de usuarios puede ser estático, es decir que no cambian en el tiempo, o dinámico.

A lo largo de la tercera dimensión tenemos el nivel de conocimiento del comportamiento de los patrones de acceso. Podemos plantear la opción de que el desarrollador no conozca nada acerca de estos patrones pero sería difícil construir un DBMS que cubriera esta cuestión sin información previa por eso, y para que sea mas fácil es necesario que el diseñador o desarrollador tenga la información completa.

Estrategias de diseño alternativos

Se consideraran estrategias para el diseño de base de datos que se usan comúnmente son principalmente dos enfoques. El enfoque Up-Down y el enfoque Bottom-Up que como su nombre lo indica son enfoques muy diferentes para el proceso de diseño pero como la mayoría de los diseñadores de software saben es muy raro que sea suficiente que una aplicación se ajuste perfectamente a uno de estos dos enfoques.

Proceso dediseño Top-Down

La actividad para este proceso de diseño comienza con el análisis de requerimientos que define el ambiente del sistema y determina tanto las necesidades de los datos como las del proceso. Con respecto al DBMS este es definido en base al desempeño, la confiabilidad y disponibilidad, economía y flexibilidad.

El documento resultante de el análisis de requerimientos es la entrada para el desarrollo de dos actividades paralelas que son el diseño conceptual y el diseño visual.

Montes de Oca Olguín Antonio de Jesús Base de datos distribuidas UNAM-FES Acatlan.

El diseño visual se encarga de definir las interfaces para el usuario final, mientras que el diseño conceptual es el proceso por el cual la empresa es examinada para determinar los tipos de entidades y las relaciones entre esas entidades. En ambas actividades de diseño el usuario necesita especificar las entidades de datos y debe determinar la aplicación que correrá en a base de datos así como la información estática acerca de la aplicación.

El esquema conceptual global y la información de los patrones de acceso recopilados como resultado del diseño visual son entradas para el diseño de la distribución. El objetivo en esta etapa es diseñar el esquema local conceptual distribuyendo las entidades sobre los sitios del sistema distribuido. Las relaciones distribuidas son comúnmente divididas en sub-relaciones llamadas fragmentos los cuales estarán distribuidos. Así entonces la actividad de diseño de distribución consiste en dos pasos: Fragmentación y asignación.

El último paso en este proceso de diseño es el diseño físico, en el cual mapeamos los esquemas conceptuales locales con los dispositivos de almacenamiento físicos disponibles en los sitios correspondientes.

Proceso de diseño Bottom-Up

Este tipo de proceso es conveniente cuando las bases de datos ya existen y las tareas delproceso de diseño involucran integrarlas en una sola base de datos. El punto de inicio de este proceso son los esquemas conceptuales locales individuales; el proceso consiste en integrar esos esquemas en un esquema conceptual global.

Problemas en el diseño de la distribución

Ya se había mencionado anteriormente la necesidad de fragmentar pero no tenemos una idea clara de cómo y para qué hacerlo. Para comenzar sería bueno que contestáramos las siguientes preguntas con respecto a la fragmentación las cuales están interrelacionadas.

¿Por qué fragmentar?, ¿Cómo deberíamos fragmentar?, ¿Qué tanto deberíamos fragmentar?, ¿Hay alguna forma de probar las correcciones de la descomposición?, ¿Cómo deberíamos asignar?, ¿Cuál es la información necesaria para la fragmentación y la asignación?

La fragmentación

Razones para la fragmentación

Desde el punto de vista de la distribución de datos no hay realmente una razón para la fragmentación después de todo en sistemas distribuidos la distribución es realizada en la base delos archivos completos.

Montes de Oca Olguín Antonio de Jesús Base de datos distribuidas UNAM-FES Acatlan.

Pero con respecto a la fragmentación es necesaria debido a tres aspectos:

1. Encontrar la unidad de relación apropiada; ya que el acceso a la aplicación no se hace en la totalidad de las relaciones de la base pero si de un subconjunto de ellas. 2. Si tenemos las sub-relaciones como unidades de relación cuando tratemos de accesar a datos que estén en otros sitios será mas conveniente hacer la replicación de los datos que están en las sub- relaciones en lugar

...