You are on page 1of 16

INSTITUTO TECNOLOGICO DE PUEBLA

LIC. EN INFORMATICA

BASE DE DATOS DISTRIBUIDAS ACTUARIO: JOSE LOPEZ PONCIANO HORA: 13:00 – 15:00

DISEÑO DE BASE DE DATOS DISTRIBUIDAS

FECHA: 14/03/2013

HUGO FERNANDEZ GARCILAZO ADRIAN HUERTA SERRANO MOISES GABRIEL GUITIERREZ MORALES

2.1 Consideraciones del diseño de un sistema de bases de datos distribuidas. A los problemas que presentamos en el diseño de las Bases de Datos Centralizadas (BDC) se le añaden otros nuevos cuando diseñamos Bases de Datos Distribuidas (BDD) entre los cuales se destacan la distribución óptima de datos y de las aplicaciones en los diferentes sitios. El problema de diseño de bases de datos distribuidos se refiere, en general, a hacer decisiones acerca de la ubicación de datos y programas a través de los diferentes sitios de una red de computadoras. Este problema debería estar relacionado al diseño de la misma red de computadoras. La decisión de donde colocar a las aplicaciones tiene que ver tanto con el software del SMBDD como con las aplicaciones que se van a ejecutar sobre la base de datos. Cuando pensamos en el diseño de las bases de datos distribuidas debemos tener en cuenta la ubicación de los programas que accederán a las bases de datos y sobre los propios datos que constituyen la base de datos, en diferentes puntos de una red. Sobre la ubicación de los programas supondremos que tenemos una copia de ellos en cada máquina donde se necesite acceder a la base de datos. Sin embargo el problema radica en cómo ubicaremos los datos en la red, existen diferentes formas de repartir los datos: En solo una máquina que almacene todos los datos y se encargue de responder a todas las consultas del resto de la red (sistema centralizado),  Ubicaríamos la base de dato en cada máquina donde se utilice, o pensaríamos en repartir las relaciones por toda la red.

La organización de los sistemas de bases de datos distribuidos se ha clasificado tradicionalmente sobre el nivel de compartición, características de acceso y nivel de conocimiento de los datos: 1. Inexistencia. Los datos y programas se ejecutan en un ordenador sin que exista comunicación entre ellos. 2. Se comparten datos y no programas. Existe una réplica de los programas de aplicación en cada máquina y los datos viajan a través de la red. 3. Se comparten datos y programas. Los datos y programas se reparten por los diferentes sitios de la red, dado un programa ubicado en un determinado sitio puede acceder a un servicio a otro programa de segundo sitio solicitando acceder a los datos ubicados en un tercero.

Duplicación de los datos. La duplicación de los datos ocurre si el sistema mantiene varias copias de una relación R, con cada copia almacenada en un sitio diferente. Existen dos modelos básicos de replica: 1. Consistencia estrecha. Este modelo que garantiza que todas las réplicas sean constantemente idénticas a la original, requiere una red de alta velocidad, disminuye la disponibilidad de la base de datos. SINCRONO 2. Consistencia ancha. El modelo de consistencia ancha permite un retardo entre el momento en que los datos originales son modificados y las copias de los mismos son actualizadas, lo que permite que la base de datos esté disponible más tiempo que el modelo de consistencia estrecha. Permite conexiones tanto rápidas como lentas soportadas en WANs o LANs. ASINCRONO La duplicación se introduce para aumentar la disponibilidad del sistema:  Cuando una copia no está disponible debido a un fallo de un sitio sería posible tener acceso a otra copia.  Con la duplicación también se mejora el rendimiento puesto que las transacciones tienen mayor probabilidad de encontrar una copia localmente.  El inconveniente está en el costo extra del almacenamiento adicional y del mantenimiento de la consistencia mutua= SI NO SE ACTUALIZAN LAS COPIAS DE MANERA SINCRONA NO HAY CONSISTENCIA entre las copias cuando tenemos replicación. El diseño de una BDD involucra 4 pasos: 1. Diseño del esquema conceptual: donde se describe la BD integral (esto es, todos los datos que son utilizados por las aplicaciones que tienen acceso a las bases de datos). 2. Diseño de fragmentación: este se determina por la forma en que las relaciones globales se subdividen en fragmentos horizontales, verticales o mixtos. 3. Diseño de la asignación de los fragmentos: esto se determina en la forma en que los fragmentos se mapean* a las imágenes físicas, en esta forma, también se determina la solicitud de fragmentos. * Mapean o mapear: Representar las partes de un todo. Localizar y representar gráficamente la distribución relativa de las partes de un todo.

4. Diseño de la BD física (transformar los esquemas locales en áreas de almacenamiento y determinar métodos de acceso apropiados): mapear el esquema conceptual a las áreas de almacenamiento y determinar los métodos de acceso a las bases de datos. La fragmentación y asignación de los datos caracterizan el diseño de BDD. La fragmentación: se ocupa fundamentalmente de los criterios lógicos que motivan la división de relaciones globales en fragmentos. Mientras que la asignación: se ocupa de los aspectos físicos de su ubicación y réplicas en sitios. Aunque hay una diferencia entre ambos procesos, su interrelación es importante para obtener un diseño óptimo. En caso que también se distribuyan las aplicaciones debemos tener en cuenta el diseño de los esquemas, los requerimientos más importantes de las aplicaciones tenemos las siguientes: 1. Sitio que comparte una aplicación. 2. Frecuencia de activación de la aplicación. 3. Cantidad, tipo y distribución estadística de los accesos de cada aplicación a cada dato requerido. En el diseño de un sistema de bases de datos distribuidas debemos tener en cuenta algunas estrategias y objetivos y se deben en paralelo tomar decisiones sobre cómo hay que distribuir los datos entre los sitios de la red. Objetivos del Diseño de la Distribución de los Datos. En el diseño de la distribución de los datos, se deben de tomar en cuenta los siguientes objetivos: Procesamiento local. La distribución de los datos, para maximizar el procesamiento local corresponde al principio simple de colocar los datos tan cerca como sea posible de las aplicaciones que los utilizan. Se puede realizar el diseño de la distribución de los datos para maximizar el procesamiento local agregando el número de referencias locales y remotas que le corresponden a cada fragmentación candidata y la localización del fragmento, que de esta forma se seleccione la mejor solución de ellas.

Distribución de la carga de trabajo. La distribución de la carga de trabajo sobre los sitios, es una característica importante de los sistemas de cómputo distribuidos. Esta distribución de la carga se realiza para tomar ventaja de las diferentes características (potenciales) o utilizaciones de las computadoras de

cada sitio, y maximizar el grado de ejecución de paralelismo de las aplicaciones. Sin embargo, la distribución de la carga de trabajo podría afectar negativamente el procesamiento local deseado. Costo de almacenamiento y disponibilidad. La distribución de la base de datos refleja el costo y disponibilidad del almacenamiento en diferentes sitios. Para esto, es posible tener sitios especializados en la red para el almacenamiento de datos. Sin embargo el costo de almacenamiento de datos no es tan relevante si éste se compara con el del CPU, I/O y costos de transmisión de las aplicaciones.

Enfoques al problema de diseño de bases de datos distribuidas Existen dos estrategias generales para abordar el problema de diseño de bases de datos distribuidas: 1. El diseño de abajo hacia arriba (bottom-up). Se utiliza particularmente a partir de bases de datos existentes, generando con esto bases de datos distribuidas. En forma resumida, el diseño bottom-up de una base de datos distribuida requiere de la selección de un modelo de bases de datos común para describir el esquema global de la base de datos. Esto es posible que se utilicen diferentes SMBD. Después se hace la traducción de cada esquema local en el modelo de datos común y finalmente se hace la integración del esquema local en un esquema global común. 2. El enfoque de arriba hacia abajo (top-down). Este enfoque es más apropiado para aplicaciones nuevas y para sistemas homogéneos. Consiste en partir desde el análisis de requerimientos para definir el diseño conceptual y las vistas de usuario. A partir de ellas se define un esquema conceptual global y los esquemas externos necesarios. Se prosigue con el diseño de la fragmentación de la base de datos, y de aquí se continúa con la localización de los fragmentos en los sitios, creando las imágenes físicas. Esta aproximación se completa ejecutando, en cada sitio, "el diseño físico" de los datos, que se localizan en éste. En la figura de abajo se presenta un diagrama con la estructura general del enfoque top-down. Proceso de Diseño Top – Down. Un esquema de este proceso puede observarse en la siguiente figura:

El diseño de una base de datos distribuida, cualquiera que sea el enfoque que se siga, debe responder satisfactoriamente a las siguientes preguntas:
• • • • • •

¿Por qué hacer una fragmentación de datos? ¿Cómo realizar la fragmentación? i. e. tanto se debe fragmentar. ¿Cómo probar la validez de una fragmentación? ¿Cómo realizar la asignación de fragmentos? ¿Cómo considerar los requerimientos de la información?

2.2 Diccionario de datos. Un diccionario de datos es un conjunto de metadatos que contiene las características lógicas de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización.

• • • • •

DICCIONARIO DE DATOS CENTRALIZADO Nombre, tipo y tamaño de los datos. Nombre de las relaciones entre los datos. Restricciones de integridad sobre los datos. Nombre de los usuarios autorizados a acceder a la base de datos. Esquemas externos, conceptuales e internos, y correspondencia entre los esquemas. Estadísticas de utilización, tales como la frecuencia de las transacciones y el número de accesos realizados a los objetos de la base de datos.

• •




• •

DICCIONARIO DE DATOS DISTRIBUIDO El diccionario de datos de las bases de datos distribuidos contienen información sobre las fragmentación, réplica y distribución de los datos El diccionario de datos del SGBDD puede proporcionar la información requerida sobre la localidad y la duplicación mientras asegura que las actualizaciones se propagan por todas las localidades apropiadas. El diccionario esta integrado a la base de datos a la cual define, e incluye por tanto su propia definición. Puede realizar una copia completa del diccionario de datos que puede obtenerse haciendo la unión de los subconjuntos distribuidos. Guardará información sobre la Ubicación de los datos. Guardará información Sobre los fragmentos de cada relación. Guardar información Sobre la duplicación de los datos. Se almacena la definición de las estructuras de datos globales y su ubicación en los nodos de la red de comunicaciones. Muestra qué programas utilizan qué partes de la base de datos. Qué usuarios necesitan qué informes. Es una técnica de especificación formal que sirve para representar los requerimientos de una aplicación.

Oracle posee un diccionario de datos; es decir la manera de extraer el catálogo de objetos de una base de datos, nos referiremos a: tablas, usuarios, roles, vistas, columnas de las tablas, secuencias, constraint’s, sinónimos, índices, triggers, funciones etc.., esta información se encuentra contenida en tablas y vistas del sistema.

2.3 Niveles de transparencia. En un sistema de base de datos distribuidos, los datos se accedan sobre una red de computadoras, pero las aplicaciones no deben notar que existen. Desde el punto de vista del usuario de la base de datos distribuida, los detalles de cómo y dónde se encuentran almacenados físicamente los datos. A la capacidad de ocultar estos detalles por parte del sistema distribuido se le denomina transparencia de la red. La transparencia de la red tiene que apoyarse en los siguientes aspectos: - La denominación de los elementos de datos. - La réplica de los elementos de datos. - La fragmentación de los elementos de datos. - La ubicación de los fragmentos y las réplicas. Primer nivel. Se soporta la transparencia de red. Segundo nivel. Se permite la transparencia de replicación de datos.

Tercer nivel. Se permite la transparencia de la fragmentación. Cuarto nivel. Se permite transparencia de acceso (por medio de un lenguaje de manipulación de datos).

2.3.1 Transparencia de localización. Una vez definidas las cantidades de réplicas y fragmentos que se requieren para un sistema distribuido, es importante decidir en qué localidades de la red conviene ubicarlas, para ello se toman en cuenta diferentes aspectos, tales como las capacidades de cómputo de los nodos, la cantidad y tipo de conexiones que hay hacia ellos, sus necesidades de acceso a datos del sistema y si su ubicación pudiera considerarse estratégica dentro de la red, es decir, que sean nodos cercanos a otros con necesidades similares o bien, que no sean nodos terminales de la red y que, preferente, no funjan como un nodo puente entre diferentes sectores de la misma. Todo este trabajo corresponde al diseñador de la BD y se lo debe informar al programador del sistema, para que, finalmente, entre los dos definan la manera en la que esta información pueda quedar oculta a los usuarios finales. Lo anterior es posible siempre que todas las reglas para la definición de las réplicas y fragmentos queden únicamente en archivos cuyo acceso sea de carácter restringido y, además, en términos de programación es conveniente utilizar un archivo adicional a los códigos fuente, que contenga las rutas específicas de acceso a los datos.

2.3.2 Transparencia de fragmentación. Ofrecer transparencia en la definición de réplicas o fragmentos de una BDD implica un mayor esfuerzo para su diseñador y sobre todo para el programador del sistema que la va a manipular; el primero de ellos porque debe definir ciertas reglas que de alguna manera oculten las especificaciones de las réplicas y fragmentos establecidas, mientras que el programador del sistema debe trabajar directamente en las líneas de código referentes a la apertura de la BD, el nombre y la ubicación de los archivos de datos requeridos, incluso los nombres y ubicaciones de los archivos que fungen como respaldo de los datos ante el posible fallo de la ubicación por default, lo que significa un riesgo de perder transparencia al momento en que el programador muestra sus códigos fuente a alguien más. Como solución a esto existe la posibilidad de controlar los accesos a los archivos de datos a través de un archivo adicional a los códigos fuente, que es el único que contiene el nombre y ubicación de las BD. Este nivel de transparencia refiere únicamente al nombramiento de las réplicas y fragmentos, así como la definición de los criterios contemplados para la definición de dichos fragmentos o réplicas, no respecto a su ubicación física de la red.

2.3.3 Transparencia de réplica. La réplica proporciona:

• VENTAJAS: •Mayor Prestación: los datos son locales. •Mayor disponibilidad: los datos son accesibles siempre.

• DESVENTAJAS •Hay que propagar las actualizaciones •La creación y destrucción de réplicas debe hacerse transparente al usuario.

2.4 Fragmentación de datos. Fragmentación es el proceso a través del cual se realiza la lectura de ciertos datos de una BD (Ya sea ciertos campos y/o registros), con el objetivo de crear un nuevo archivo de datos que contendrá los datos de la consulta, provocando que la BD original se quede sin ellos. Se puede decir que este tema tiene el aproximada de fragmentos. objetivo de identificar la cantidad

Para empezar a definir la necesidad de fragmentación se tiene que conocer lo siguiente: Datos específicos que contienen las consultas que usualmente demandan los usuarios. Estructura interna de la BD, es decir, en qué tablas se encuentran los datos mayormente demandados por los usuarios. Relaciones que existen entre las tablas de la BD y que deberán cuando se haga distribuida. respetarse

Se debe conocer si las salidas de datos que demanda el usuario son para consulta o para operaciones de escritura, porque, al igual que en el punto anterior, si las operaciones comunes son de escritura, los fragmentos posibles seguramente serían menos que los efectuados si la mayoría de las veces sólo son consultas las que llevan a cabo. La fragmentación de los datos permite dividir en 2 o más segmentos o fragmentos. El objeto podría ser una base de datos de usuario, una base de datos de sistema o una tabla. Cada fragmento puede guardarse en cualquier sitio en una red de computadoras. La información de la fragmentación de datos se guarda en un catálogo de datos distribuidos (DDC, por sus siglas en Ingles), desde donde es accesada por el procesador de transacciones para procesar las solicitudes de los usuarios. Alternativas sobre replicación para el asignamiento de fragmentos La replicación de información es de utilidad para obtener un mejor rendimiento y para ofrecer un mayor grado de confiabilidad (tolerancia a fallas). La replicación se complica cuando es necesario hacer actualizaciones a las copias múltiples de un dato. Por tanto, respecto a la replicación, en el asignamiento de fragmentos se tienen tres estrategias: • No soportar replicación. Cada fragmento reside en un solo sitio. • Soportar replicación completa. Cada fragmento en cada uno de los sitios.

• Soportar replicación parcial. Cada fragmento en algunos de los sitios. Requerimientos de información. Con el fin de realizar una fragmentación adecuada es necesario proporcionar información que ayude a realizarla. Esta información normalmente debe ser proporcionada por el usuario y tiene que ver con cuatro tipos:
• • • •

Información sobre el significado de los datos. Información sobre las aplicaciones que los usan. Información acerca de la red de comunicaciones. Información acerca de los sistemas de cómputo.

Las estrategias de fragmentación de los datos, están basadas a nivel de tabla y consiste en dividir una tabla en fragmentos lógicos. Se explorarán 3 tipos de estrategias de fragmentación: HORIZONTAL, VERTICAL Y MEZCLADA (Híbrida o Heterogénea).

2.4.1 Fragmentación horizontal. Fragmentación horizontal primaria. Consiste del 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 horizontal derivada. La fragmentación derivada horizontal se define partiendo de una fragmentación horizontal. En esta operación se requiere de Semi-junta (Semi-Join) el cual nos sirve para derivar las tuplas o registros de dos relaciones. Una fragmentación horizontal de una relación lo constituye un subconjunto de tuplas de dicha relación. Las tuplas que pertenecen al fragmento horizontal se especifican por una condición en uno o más atributos de la relación. PRODUCTO O JOIN 2.4.2 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. NO IMPORTAN LAS LLAVES La fragmentación vertical es inherentemente más complicada que particionamiento horizontal ya que existe un gran número de alternativas para realizarla. Por lo tanto, se utilizan heurísticas para hacer el particionamiento. Los dos enfoques básicos son: Agrupamiento. Inicia asignando cada atributo a un fragmento, y en cada paso, algunos de los fragmentos satisfaciendo algún criterio se unen para formar un solo fragmento.
1.

2. División. Inicia con una sola relación realizar un particionamiento basado en el comportamiento de acceso de las consultas sobre los atributos.

Nos concentraremos aquí al estudio del enfoque divisional ya que, por un lado, su aplicación es más natural al enfoque de diseño "top-down". Además, el enfoque divisional genera fragmentos que no se traslapan mientras que el agrupamiento típicamente resulta en fragmentos traslapados. Por supuesto, la no traslapación no incluye a las llaves primarias. Requerimientos de información para la fragmentación vertical. Como en el caso de la fragmentación horizontal, es necesario proporcionar información para poder realizar una adecuada fragmentación vertical. Ya que el particionamiento vertical coloca en un fragmento aquellos atributos que se accesan juntos, se presenta la necesidad de una medida que relacione la afinidad de los atributos, la cual indica qué tan relacionados están los atributos. Esta medida se obtiene por datos primitivos. Un fragmento vertical de una relación contiene solo ciertos atributos de la relación que están relacionados entre sí de alguna forma.

2.4.3 Fragmentación híbrida. En muchos casos una fragmentación horizontal o vertical de un esquema de una base de datos no será suficiente para satisfacer los requerimientos de aplicaciones de usuario. En este caso, una fragmentación vertical puede ser seguida de uno horizontal, o viceversa, produciendo un árbol de particionamiento estructurado. Ya que los dos tipos de particionamiento se aplican uno después del otro, esta alternativa se le conoce como fragmentación híbrida.

2.5 Distribución de datos. La distribución de los datos se realiza sobre tres dimensiones: un primer nivel de compartición, un segundo nivel, que muestra las características de acceso a los datos y el último nivel de conocimiento de esas características de acceso.

En el nivel de compartición se encuentran tres alternativas: una primera es la inexistencia, es decir, cada aplicación y sus datos se ejecutan en un ordenador con ausencia total de comunicación con otros programas u otros datos; una segunda alternativa es que se comparten sólo los datos y no los programas, en tal caso existe una réplica de las aplicaciones en cada máquina y los datos viajan por la red; y una tercera y última alternativa se reparten datos y programas dado un programa ubicado en un determinado sitio, éste puede solicitar un servicio a otro programa. Respecto a las características de acceso a los datos existen dos alternativas principalmente: el modo de acceso a los datos que solicitan los usuarios puede ser estático, es decir, no cambiará a lo largo del tiempo, o bien, dinámico. El lector podrá comprender fácilmente la dificultad de encontrar sistemas distribuidos reales que puedan clasificarse como estáticos. Sin embargo, lo realmente importante radica, estableciendo el dinamismo como base, cómo de dinámico es, cuántas variaciones sufre a lo largo del tiempo. Esta dimensión establece la relación entre el diseño de bases de datos distribuidas y el procesamiento de consultas. La tercera clasificación es el nivel de conocimiento de las características de acceso. Una posibilidad es, evidentemente, que los diseñadores carezcan de información alguna sobre cómo los usuarios acceden a la base de datos. Es una

posibilidad teórica, pero sería muy laborioso abordar el diseño de la base de datos con tal ausencia de información. Lo más práctico sería conocer con detenimiento la forma de acceso de los usuarios o, en el caso de su imposibilidad, conformarnos con una información parcial de ésta. El problema del diseño de bases de datos distribuidas podría enfocarse a través de esta trama de opciones. En todos los casos, excepto aquel en el que no existe compartición, aparecerán una serie de nuevos problemas que son irrelevantes en el caso centralizado.

A la hora de abordar el diseño de una base de datos distribuida podremos optar principalmente por dos tipos de estrategias: la estrategia ascendente y la estrategia descendente. Ambos tipos no son excluyentes, y no resultaría extraño a la hora de abordar un trabajo real de diseño de una base de datos que se pudiesen emplear en diferentes etapas del proyecto una u otra estrategia. 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. Pese a todo, se resumirán brevemente las etapas por las que se transcurre. Estrategia descendente. Todo comienza con un análisis de los requisitos que definirán el entorno del sistema en aras a obtener tanto los datos como las necesidades de procesamiento de todos los posibles usuarios del banco de datos. Igualmente, se deberán fijar los requisitos del sistema, los objetivos que debe cumplir respecto a unos grados de rendimiento, seguridad, disponibilidad y flexibilidad, sin olvidar el importante aspecto económico. Como puede observarse, los resultados de este último paso sirven de entrada para dos actividades que se realizan de forma paralela. El diseño de las vistas trata de definir las interfaces para el usuario final y, por otro lado, el diseño conceptual se encarga de examinar la empresa para determinar los tipos de entidades y establecer la relación entre ellas. Existe un vínculo entre el diseño de las vistas y el diseño conceptual. El diseño conceptual puede interpretarse como la integración de las vistas del usuario, este aspecto es de vital importancia ya que el modelo conceptual debería soportar no sólo las aplicaciones

existentes, sino que debería estar preparado para futuras aplicaciones. En el diseño conceptual y de las vistas del usuario se especificarán las entidades de datos y se determinarán las aplicaciones que funcionarán sobre la base de datos, así mismo, se recopilarán datos estadísticos o estimaciones sobre la actividad de estas aplicaciones. Dichas estimaciones deberían girar en torno a la frecuencia de acceso, por parte de una aplicación, a las distintas relaciones de las que hace uso, podría afinarse más anotando los atributos de la relación a la que accede. Desarrollado el trabajo hasta aquí, se puede abordar la confección del esquema conceptual global. Este esquema y la información relativa al acceso a los datos sirven de entrada al paso distintivo: el diseño de la distribución. El objetivo de esta etapa consiste en diseñar los esquemas conceptuales locales que se distribuirán a lo largo de todos los puestos del sistema distribuido. Sería posible tratar cada entidad como una unidad de distribución; en el caso del modelo relacional, cada entidad se corresponde con una relación. Resulta bastante frecuente dividir cada relación en sub-relaciones menores denominadas fragmentos que luego se ubican en uno u otro sitio. De ahí, que el proceso del diseño de la distribución conste de dos actividades fundamentales: la fragmentación y la asignación. El último paso del diseño de la distribución es el diseño físico, el cual proyecta los esquemas conceptuales locales sobre los dispositivos de almacenamiento físico disponibles en los distintos sitios. Las entradas para este paso son los esquemas conceptuales locales y la información de acceso a los fragmentos. Por último, se sabe que la actividad de desarrollo y diseño es un tipo de proceso que necesita de una monitorización y un ajuste periódico, para que si se llegan a producir desviaciones, se pueda retornar a alguna de las fases anteriores.