UNIVERSIDAD LAICA \"ELOY ALFARO\" DE MANABÍ FACULTAD DE CIENCIAS INFORMÁTICAS ASIGNATURA: INTEGRANTES

Autonomía de diseño


Autonomía de comunicación


Autonomía de ejecución






Distribución cliente / servidor


Distribución peer-to -peer


Concentra las funciones de gestión de datos en servidores , mientras que los clientes se centran en proporcionar el entorno de aplicación


No hay distinción de equipos cliente frente a los servidores.







UNIVERSIDAD LAICA "ELOY ALFARO" DE MANABÍ


FACULTAD DE CIENCIAS INFORMÁTICAS


ASIGNATURA:
BASES DE DATOS DISTRIBUIDAS

TEMA/TÍTULO DEL TRABAJO:
Arquitectura de los sistemas de bases de datos distribuidas
INTEGRANTES:
PALACIOS BARBERÁN ROLANDO
MOREIRA SANTANA ALEXIS
PAZ GUTIÉRREZ LUIS
Curso: SEXTO NIVEL "B"

Profesor:
ING. PATRICIA QUIROZ PALMA

MANTA-MANABÍ-ECUADOR
Octubre, 2014

Contenido
INTRODUCCIÓN 3
DESARROLLO DEL TEMA 3
ARQUITECTURAS DE SISTEMAS DISTRIBUIDOS 3
Arquitectura Cliente/Servidor 3
Arquitectura Peer-to-Peer (P2P) 4
Arquitectura Servidor Proxy 5
Arquitectura Agentes Móviles 7
ESTÁNDARES EN LOS DBMS 8
MODELOS ARQUITECTÓNICOS DE DDBMS 11
AUTONOMÍA 11
DISTRIBUCION 13
HETEROGENEIDAD 14
SISTEMAS CLIENTE / SERVIDOR 14
SISTEMAS PEER TO PEER 15
MULTI BASE DE DATOS ARQUITECTURA DEL SISTEMA 16
ALTERNATIVAS PARA DIRECTORIOS DE UN DDBMS 17
ALTERNATIVAS PARA LA IMPLEMENTACION DE SMBD 17
CONCLUSIONES 23
RECOMENDACIÓN 23
BIBLIOGRAFÍA 24








INTRODUCCIÓN

En este trabajo de investigación estudiaremos la arquitectura de los sistemas de base de datos distribuidos.
La arquitectura de un sistema define su estructura. Esto significa que se identifican los componentes del sistema, se especifica la función de cada componente, y las relaciones e interacciones entre estos componentes se definen. La especificación de la arquitectura de un sistema requiere la identificación de los distintos módulos, con sus interfaces e interrelaciones, en términos de los datos y el flujo de control a través del sistema.
DESARROLLO DEL TEMA

ARQUITECTURAS DE SISTEMAS DISTRIBUIDOS
Arquitectura Cliente/Servidor

El modelo cliente-servidor es el modelo más conocido y más ampliamente adoptado en la actualidad. En éste modelo hay dos tipos de procesos, los clientes son procesos que hacen peticiones de servicio y los servidores proveen esos servicios.


Funciones del Cliente
Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la
Comunicación.
Espera y recibe las respuestas del servidor.
Por lo general, puede conectarse a varios servidores a la vez.
Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario.
Funciones del Servidor
Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo).
Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente.
Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos casos el número máximo de peticiones puede estar limitado).
No es frecuente que interactúen directamente con los usuarios finales.

Ventajas
Sencillez, únicamente se necesita la ubicación del servidor.
Mejor aprovechamiento de la potencia de cómputo (Repartición del trabajo).
Reducción del tráfico en la red.
Opera bajo sistemas abiertos.
Facilita el uso de interfaces gráficas variadas y versátiles

Arquitectura Peer-to-Peer (P2P)

Un sistema de peer-to-peer se caracteriza por ser un sistema distribuido en el que todos los nodos tienen las mismas capacidades y responsabilidades, y en el que toda la comunicación es simétrica. Las redes peer-to-peer aprovechan, administran y optimizan el uso del ancho de banda de los demás usuarios de la red por medio de la conectividad entre los mismos, obteniendo más rendimiento en las conexiones y transferencias que con algunos métodos centralizados convencionales, donde una cantidad relativamente pequeña de servidores provee el total del ancho de banda y recursos compartidos para un servicio o aplicación.
Sus características son las siguientes: Escalabilidad, Robustez, Descentralización, Anonimato, Seguridad y Costes repartidos.







Ventajas
Los procesos tiene un rol similar, aunque pueden asumir un rol cliente/servidor en
ciertos momentos.
Mejora la tolerancia a fallos y la escalabilidad.

Desventajas
Difícil de coordinar.
Arquitectura Servidor Proxy

Un Proxy es un servidor intermediario que acepta peticiones http de clientes u otros intermediarios y genera a su vez peticiones hacia otros intermediarios o hacia el servidor web destino. Actúa como servidor del cliente y como cliente del servidor; realiza un cierto tipo de funciones a nombre de otros clientes en la red para aumentar el funcionamiento de ciertas operaciones, también sirve de seguridad, esto es, tiene un Firewall. Permite administrar el acceso a internet en una Red de computadoras permitiendo o negando el acceso a diferentes sitios Web.




Características principales
Compartir la conexión a Internet para todos los contenidos.
Almacenamiento de las páginas visitadas acelerando las conexiones a las páginas visitadas.
Conexiones compartidas equitativamente entre los usuarios reduciéndose así la
espera.
Ahorro de ancho de banda de Internet.
Control de contenidos visitados.
Establecimiento de listas negras de sitios de internet.
Bloqueo de direcciones IP.
Denegación de archivos no permitidos, posibles focos de infección de virus.
Control de usuarios que pueden acceder a Internet.
Evitar que los recursos de la empresa no sean usados para fines no profesionales.
El usar un Servidor Proxy aumenta la seguridad de nuestra red, protegiéndola contra posibles intrusiones.


Arquitectura Agentes Móviles

Los agentes móviles son programas de software capaces de viajar por redes de computadoras, como Internet, de interactuar con hosts, pedir información a nombre de un usuario y regresar a su lugar de origen una vez que ha realizado las tareas especificadas por un usuario. Creado en un ambiente de ejecución, el agente puede transportar su estado y código a otro contexto en donde reanudará la ejecución. Estos agentes aprovechan los recursos del nodo destino en beneficio del nodo que los envió, negociando y cerrando tratos en su nombre ó utilizando servicios remotos. Un agente móvil tiene capacidad para decidir a qué servidores moverse y puede moverse a uno o más servidores. Es una extensión del modelo cliente/servidor.
Algunos de los campos idóneos en donde se pueden aplicar los agentes móviles son los siguientes: procesamiento en paralelo, comercio electrónico, asistencia personal, recuperación de información distribuida, servicios de redes y telecomunicaciones, aplicaciones de software para grupos, monitoreo y notificación, y diseminación de información.




Ventajas
Permiten el cómputo asíncrono y autónomo.
Son naturalmente heterogéneos.
Proporcionan ambientes robustos y a prueba de fallas.
Reducen el tráfico de red.
Favorecen el procesamiento en paralelo.
Mantienen comunicación punto a punto.
Pueden operar sin conexión.
Ejecución asíncrona de tareas.
Desventajas
Cuestiones de seguridad.
Limitaciones en cuanto a los lenguajes de programación para su diseño.

Como productos de Base de Datos Distribuidas tenemos:
Microsoft SQL Server 2008
Oracle 11g
Apache Cassandra

ESTÁNDARES EN LOS DBMS

TRANSPARENCIA
Se refiere a la división del nivel semántico y la implementación del sistema.
El objetivo es ocultar al usuario los detalles de diseño, es decir, el usuario no tiene que saber que se encuentra trabajando sobre un sistema distribuido, por ejemplo la independencia de los datos es una forma de transparencia
El propósito fundamental de la transparencia en el ambiente distribuido es la independencia de datos.
Al implementar una base de datos distribuida se tienen ciertas normas comunes:
Transparencia de ubicación. Permite a los usuarios tener acceso a los datos sin que tenga conocimiento de la ubicación de éstos. Se puede conseguir este nivel de transparencia al utilizar los administradores de transacciones distribuidas, los cuales son capaces de determinar la localización de los datos y de emitir acciones a los calendarizadores apropiados, lo cual puede ejecutarse cuando los administradores de transacciones distribuidas poseen acceso a los directorios de localizaciones de los datos.

Transparencia de duplicación. Para que la transparencia de duplicación sea posible, los administradores de transacciones deben traducir las solicitudes de procesamiento de transacción en acciones para el administrador de datos. Para las lecturas el administrador de transacciones selecciona uno de los nodos que almacena los datos y ejecuta la lectura. Para optimizar el proceso, el administrador de transacciones necesita información sobre el rendimiento de varios nodos respecto al sitio de consulta, así podrá seleccionar el nodo de mejor rendimiento. La actualización y escritura de datos duplicados suelen ser más complicadas, ya que el manejador de transacciones debe emitir una acción de escritura para cada uno de los calendarizadores que almacena una copia de los datos.

Transparencia de concurrencia. Cuando varias transacciones se ejecuten al mismo tiempo, los resultados de las transacciones no deberán afectarse. La transparencia de concurrencia se logra si los resultados de todas las transacciones concurrentes son consistentes de manera lógica con los resultados que se habrían obtenido si las transacciones se hubieran ejecutado una por una, en cualquier orden secuencial.

Transparencia de fallas. Significa que a pesar de fallas las transacciones sean procesadas de un modo correcto. Frente a una falla, las transacciones deben ser atómicas, significa que se procesen todas o ninguna de ellas. Para este tipo de problemas es importante tener resguardo de la base de datos, y así poder restaurarla cuando sea conveniente. El sistema debe detectar cuándo falla una localidad y tomar las medidas necesarias para recuperarse del fallo. El sistema no debe seguir utilizando la localidad que falló. Por último, cuando se recupere o repare esta localidad, debe contarse con mecanismos para reintegrarla al sistema con el mínimo de complicaciones.

Localidad del procesamiento. Los datos se deben distribuir lo más cerca posible de las aplicaciones que los usan para maximizar la localidad del procesamiento, este principio responde a minimizar el acceso remoto a los datos. Diseñar una distribución que maximice localidad del procesamiento puede hacerse añadiendo la cantidad de referencias locales y remotas correspondientes a cada fragmentación candidata y asignar la fragmentación eligiendo la mejor solución. Independencia de configuración. La independencia de configuración permite añadir o reemplazar hardware sin tener que cambiar componentes de software existentes en el sistema de base de datos distribuida.
Particionado de la Base de Datos. La base de datos se distribuye de modo que no haya solapamiento o duplicación de los datos mantenidos en las diferentes localidades, como no hay duplicaciones de los datos, se evitan los costos asociados con el almacenamiento y mantenimiento de datos redundantes. Si un mismo segmento de datos se usa en más de una localidad se ve limitada la disponibilidad de los datos. La fiabilidad también puede verse limitada cuando se produce un fallo en el sistema de cálculo de una localidad se afecta la disponibilidad de los datos de esa localidad no estén disponible para los usuarios en cualquier parte del sistema.

Fragmentación de datos. Consiste en subdividir las relaciones y distribuirlas entre los sitios de la red, tiene como objetivo buscar formas alternativas de dividir una las instancias (tablas) de relaciones en otras más pequeñas. La fragmentación se puede realizar por tuplas individuales (fragmentación horizontal), por atributos individuales fragmentación vertical) o una combinación de ambas (fragmentación híbrida). El principal problema de la fragmentación radica en encontrar la unidad apropiada de distribución. Una relación no es una buena unidad por muchas razones. Normalmente las vistas de una relación están formadas por subconjuntos de relaciones. Además, las aplicaciones acceden localmente a subconjuntos de relaciones. Por ello, es necesario considerar a los subconjuntos de relaciones como unidad de distribución. Al descomponer de una relación en fragmentos, tratados cada uno de ellos como una unidad de distribución, permite el proceso concurrente de las transacciones.

El conjunto de estas relaciones, provocará la ejecución paralela de una consulta al ser dividida en una serie de subconsultas que operará sobre los fragmentos. Cuando las vistas definidas sobre una relación son consideradas como unidad de distribución que se ubican en diferentes sitios de la red, podemos optar por dos alternativas diferentes: La relación no estará replicada y se almacena en un único sitio, o existe réplica en todos o algunos de los sitios en los cuales reside la aplicación. Las consecuencias de esta estrategia son la generación de un volumen de accesos remotos que pueden ser innecesarios con un mal manejo de estas replicas. Además, las réplicas innecesarias pueden causar problemas en la ejecución de las actualizaciones y puede no ser deseable si el espacio de almacenamiento está limitado. Los inconvenientes de la fragmentación están dados en que si las pueden estar definidas por fragmentos mutuamente exclusivos y al recuperar los datos de dos fragmentos situados en sitios diferentes es necesario trasmitir los datos de un sitio a otro y realizar sobre ellos la operación de unión (Join), lo cual puede ser costoso. El control semántico cuando los atributos implicados en una dependencia una relación se descompone en diferentes fragmentos y estos se ubican en sitios diferentes puede ser muy costos porque es necesario hacer búsquedas en un gran número de sitios.

MODELOS ARQUITECTÓNICOS DE DDBMS

Utilizamos una clasificación que organiza los sistemas, que se caracteriza con respecto a (1) la autonomía de los sistemas locales, (2) su distribución, y (3) su heterogeneidad



AUTONOMÍA
La autonomía, en este contexto, se refiere a la distribución del control, no de los datos. Se indica el grado en que los DBMS individuales pueden funcionar de manera independiente. La autonomía es una función de un número de factores tales como si los sistemas de componentes (es decir, los DBMS individual) intercambio de información, si se puede ejecutar de forma independiente las operaciones, y si se le permite modificarlos. Requisitos de un sistema autónomo que se hayan especificado de la siguiente manera [Gligor y Popescu-Zeletin, 1986]:
1. Las operaciones locales de los DBMS individuales no se ven afectados por su participación en el sistema distribuido.
2. La manera en que las consultas proceso DBMS individuales y optimizarlas no deben verse afectados por la ejecución de consultas globales que tienen acceso a varias bases de datos.
3. Coherencia o la operación del sistema no debe verse comprometida cuando los DBMS individuales unirse o abandonar el sistema distribuido.
Por otra parte, las dimensiones de la autonomía se pueden especificar de la siguiente manera [Duand Elmagarmid, 1989]:

1. Autonomía de diseño: DBMS individuales son libres de utilizar los modelos de datos y técnicas de gestión de operaciones que ellos prefieren.
2. Autonomía Comunicación: Cada uno de los DBMS individuo es libre de tomar sus propias decisiones en cuanto a qué tipo de información que desea proporcionar a las otras bases de datos o el software que controla su ejecución global.
3. Autonomía de ejecución: Cada DBMS puede ejecutar las operaciones que se le presenten, en cualquier forma que desee.
Vamos a utilizar una clasificación que abarca los aspectos importantes de estas características.
Una alternativa es la estrecha integración, donde una sola imagen de la base de datos está disponible para cualquier usuario que quiera compartir la información, que puede residir en múltiples bases de datos. Desde la perspectiva de los usuarios, los datos se integran lógicamente en una base de datos. En estos sistemas fuertemente integrados, los gestores de datos se implementan de modo que uno de ellos es en el control del procesamiento de cada petición de usuario incluso si esa solicitud es atendida por más de un gestor de datos. Los gestores de datos no suelen funcionar como DBMS independientes a pesar de que por lo general tienen la funcionalidad para hacerlo.
A continuación se identifican los sistemas semiautónomos que constan de DBMS que pueden (y generalmente lo hacen) operar de forma independiente, pero hemos decidido participar en una federación para que sus datos locales compartible. Cada uno de estos DBMS determinar qué partes de su propia base de datos se harán accesibles a los usuarios de otras bases de datos. No son sistemas completamente autónomos, ya que deben ser modificados para que puedan intercambiar información entre sí.
La última alternativa que consideramos que es un aislamiento total, donde los sistemas individuales son DBMS independientes que no conocen ni la existencia de otras bases de datos, ni la forma de comunicarse con ellos. En tales sistemas, el procesamiento de transacciones de usuario que accede a varias bases de datos es especialmente difícil ya que no hay control global de la ejecución de los DBMS individuales.
DISTRIBUCION

La distribución cliente / servidor y la distribución peer-to -peer (o distribución total). Junto con la opción de no distribuido, la taxonomía identifica tres arquitecturas alternativas.
La distribución cliente / servidor concentra las funciones de gestión de datos en servidores, mientras que los clientes se centran en proporcionar el entorno de aplicación como la interfaz de usuario. Las funciones de comunicación se comparten entre los equipos cliente y servidores. DBMS cliente / servidor representan un compromiso práctico para distribuir la funcionalidad. Hay una variedad de formas de estructuración de ellos, cada uno proporcionando un nivel diferente de la distribución. Lo que es importante en este punto es que los sitios en la red se distinguen como "clientes " y " servidores " y su funcionalidad es diferente.
En los sistemas peer-to -peer, no hay distinción de equipos cliente frente a los servidores.
Cada máquina tiene toda la funcionalidad DBMS y puede comunicarse con otras máquinas para realizar consultas y transacciones. La mayoría de los muy primeros trabajos sobre los sistemas de bases de datos distribuidas han asumido la arquitectura peer-to -peer. Por lo tanto, en los sistemas peer-to -peer (también llamado completamente distribuida) , a pesar de que muchas de las técnicas que llevan a los sistemas cliente / servidor

HETEROGENEIDAD

La heterogeneidad se puede producir en diversas formas en los sistemas distribuidos, que van desde la heterogeneidad de hardware y diferencias en los protocolos de redes a las variaciones en los administradores de datos. En representación de los datos con diferentes herramientas de modelado crea heterogeneidad debido a los poderes expresivos inherentes y limitaciones de los modelos de datos individuales.

SISTEMAS CLIENTE / SERVIDOR

DBMS cliente / servidor entraron en la escena informática a principios de 1990 y han tenido un impacto significativo tanto en la tecnología DBMS y la forma de hacer el cálculo. La idea general es muy simple y elegante: distinguir la funcionalidad que debe ser proporcionado y dividir estas funciones en dos clases: las funciones de servidor y las funciones del cliente. Esto proporciona una arquitectura de dos niveles que hace que sea más fácil de manejar la complejidad de los DBMS modernos y la complejidad de la distribución.
Como con cualquier término muy popular, cliente / servidor se ha abusado mucho y ha llegado a significar cosas diferentes. Si se toma una vista centrado en el proceso, entonces cualquier proceso que solicita los servicios de otro proceso es su cliente y viceversa. Sin embargo, es importante tener en cuenta que " cliente / servidor " y "cliente / servidor DBMS ", ya que se utiliza en nuestro contexto, no se refieren a los procesos, pero a las máquinas reales. Por lo tanto, nos centramos en lo que software se ejecutará en los equipos cliente y qué software se debe ejecutar en el servido
Dicho de esta manera, la cuestión es más clara y podemos empezar a estudiar las diferencias en el cliente y la funcionalidad del servidor. La asignación de funcionalidad entre los clientes y sirve diferir en diferentes tipos de DBMS distribuidos (por ejemplo, frente a relacional orientado a objetos ) .
En los sistemas relacionales, el servidor hace la mayoría del trabajo de gestión de datos. Esto significa que todos los de procesamiento de consultas y optimización, gestión de transacciones y de gestión de almacenamiento se realiza en el servidor. El cliente, además de la aplicación y la interfaz de usuario , tiene un módulo de cliente que DBMS es responsable de la gestión de los datos que se almacenan en caché en el cliente y (a veces ) la gestión de los bloqueos de transacciones que pueden haber sido almacenado en caché también. También es posible colocar comprobación de la coherencia de las consultas del usuario en el lado del cliente , pero esto no es común ya que requiere la replicación del catálogo del sistema en las máquinas cliente . Por supuesto, no es el sistema operativo y el software de comunicación que se ejecuta en el cliente y en el servidor, pero que sólo se centran en la funcionalidad relacionada DBMS. En otras palabras, el cliente pasa consultas SQL al servidor sin tratar de entender o optimizarlos. El servidor hace la mayor parte del trabajo y devuelve la relación resultado al cliente.

SISTEMAS PEER TO PEER

Si el término "cliente / servidor " está lleno de diferentes interpretaciones, " peer-to -peer " es aún peor ya que su significado ha cambiado y evolucionado a lo largo de los años. Como se señaló anteriormente, los primeros trabajos sobre los DBMS distribuidos todos enfocados en las arquitecturas peer-to -peer , donde no había distinción entre la funcionalidad de cada sitio en el sistema4
.
Después de una década de la popularidad de la computación cliente / servidor, peer-to -peer han hecho una reaparición en los últimos años (impulsado principalmente por las aplicaciones de intercambio de archivos), y algunos incluso han posicionado gestión de datos peer-to -peer como alternativa a distribuir DBMS. Si bien esto puede ser un tramo, sistemas peer-to -peer modernos tienen dos diferencias importantes de sus parientes anteriores. El primero es la distribución masiva en los sistemas actuales. Mientras que en los primeros días nos hemos centrado en unos pocos (tal vez en la mayoría de los cientos de sitios) , los sistemas actuales consideran que miles de sitios . La segunda es la heterogeneidad inherente de todos los aspectos de los sitios y su autonomía. Si bien esto ha sido siempre una preocupación de bases de datos distribuidas, como se explicó anteriormente, junto con la distribución masiva , heterogeneidad de los sitios y la autonomía tener un significado añadido, rechazando algunos de los enfoques de consideración.

MULTI BASE DE DATOS ARQUITECTURA DEL SISTEMA

Sistemas multi base de datos (CMBD) representa el caso en que los DBMS individuales (sean distribuidos o no) son totalmente autónomos y no tienen idea de la cooperación, sino que pueden incluso no "sabe" de la existencia del otro o cómo hablar el uno al otro. Nuestro objetivo es, por supuesto, en MDBSs distribuidos, que es lo que el término se referirá en el resto.
En la literatura más reciente, se encuentra el término sistema de integración de datos utilizado en su lugar.
Evitamos el uso de ese término ya que los sistemas de integración de datos consideran las fuentes de datos que no son de base de datos también. Nuestra atención se centra estrictamente en las bases de datos.

ALTERNATIVAS PARA DIRECTORIOS DE UN DDBMS
ALTERNATIVAS PARA LA IMPLEMENTACION DE SMBD

Dimensiones a considerar al integrar múltiples bases de datos.

En la Figura de arriba se presentan las diferentes dimensiones (factores) que se deben considerar para la implementación de un sistema manejador de base de datos. Las dimensiones son tres:
Distribución. Determina si las componentes del sistema están localizadas en la misma computadora o no.
Heterogeneidad. La heterogeneidad se puede presentar a varios niveles: hardware, sistema de comunicaciones, sistema operativo o SMBD. Para el caso de SMBD heterogéneos ésta se puede presentar debido al modelo de datos, al lenguaje de consultas o a los algoritmos para manejo de transacciones.
Autonomía. La autonomía se puede presentar a diferentes niveles:
Autonomía de diseño. La habilidad de un componente del SMBD para decidir cuestiones relacionadas a su propio diseño.
Autonomía de comunicación. La habilidad de un componente del SMBD para decidir como y cuando comunicarse con otros SMBD.
Autonomía de ejecución. La habilidad de un componente del SMBD para ejecutar operaciones locales de la manera que él quiera.

Figura 2.9. Arquitectura de un SMBDD homogéneo.
Desde el punto de vista funcional y de organización de datos, los sistemas de datos distribuidos están divididos en dos clases separadas, basados en dos filosofía totalmente diferentes y diseñados para satisfacer necesidades diferentes:
Sistemas de manejo de bases de datos distribuidos homogéneos
Sistemas de manejo de bases de datos distribuidos heterogéneos
Un SMBDD homogéneo tiene múltiples colecciones de datos; integra múltiples recursos de datos como se muestra en la Figura 2.9. Los sistemas homogéneos se parecen a un sistema centralizado, pero en lugar de almacenar todos los datos en un solo lugar, los datos se distribuyen en varios sitios comunicados por la red. No existen usuarios locales y todos ellos accesan la base de datos a través de una interfaz global. El esquema global es la unión de toda las descripciones de datos locales y las vistas de los usuarios se definen sobre el esquema global.
Para manejar los aspectos de la distribución, se deben agregar dos niveles a la arquitectura estándar ANSI-SPARC, como se muestra en la Figura 2.10. El esquema de fragmentación describe la forma en que las relaciones globales se dividen entre las bases de datos locales. La Figura 2.11 presenta el ejemplo de una relación, R, la cual se divide en cinco fragmentos. El esquema de asignamiento especifica el lugar en el cual cada fragmento es almacenado. De aquí, los fragmentos pueden migrar de un sitio a otro en respuesta a cambios en los patrones de acceso.

Figura 2.10. Arquitectura de los esquemas de un SMBDD homogéneo.
 

Figura 2.11. Fragmentación de una relación global.

Figura 2.12. Arquitectura de un sistema multi-bases de datos.
 
La clase de sistemas heterogéneos es aquella caracterizada por manejar diferentes SMBD en los nodos locales. Una subclase importante dentro de esta clase es la de los sistemas de manejo multi-bases de datos. Un sistema multi-bases de datos (Smulti-BD) tiene múltiples SMBDs, que pueden ser de tipos diferentes, y múltiples bases de datos existentes. La integración de todos ellos se realiza mediante subsistemas de software. La arquitectura general de tales sistemas se presenta en la Figura 2.12. En contraste con los sistemas homogéneos, existen usuarios locales y globales. Los usuarios locales accesan sus bases de datos locales sin verse afectados por la presencia del Smulti-BD.
En algunas ocasiones es importante caracterizar a los sistemas de bases de datos distribuidas por la forma en que se organizan sus componentes. En la Figura 2.13 se presenta la arquitectura basada en componentes de un SMBD distribuido. Consiste de dos partes fundamentales, el procesador de usuario y el procesador de datos. El procesador de usuario se encarga de procesar las solicitudes del usuario, por tanto, utiliza el esquema externo del usuario y el esquema conceptual global. Así también, utiliza un diccionario de datos global. El procesador de usuario consiste de cuatro partes: un manejador de la interfaz con el usuario, un controlador semántico de datos, un optimizador global de consultas y un supervisor de la ejecución global. El procesador de datos existe en cada nodo de la base de datos distribuida. Utiliza un esquema local conceptual y un esquema local interno. El procesador de datos consiste de tres partes: un procesador de consultas locales, un manejador de recuperación de fallas locales y un procesador de soporte para tiempo de ejecución.

Figura 2.13. Arquitectura basada en componentes de un SMBD distribuido.
En la Figura 2.14, se presenta la arquitectura basada en componentes de un sistema multi-bases de datos. Consiste un sistema de manejo de bases datos para usuarios globales y de sistemas de manejo de bases de datos para usuarios locales. Las solicitudes globales pasan al procesador global el cual consiste de un procesador de transacciones, una interfaz de usuario, un procesador de consultas, un optimizador de consultas, un esquema y un administrador de recuperación de fallas, todos ellos actuando de manera global.
En cada sitio existe un SMBD completo el cual consiste de la interfaz con el usuario, el procesador y optimizador de consultas, el manejador de transacciones, el despachador de operaciones, el manejador de recuperación de fallas y el sistema de soporte para tiempo de ejecución, todos ellos actuando de manera local. Para comunicar el sistema global con los sistemas locales se define una interfaz común entre componentes mediante la cual, las operaciones globales se convierten en una o varias acciones locales.
El manejo de directorio de datos es de una importancia mayor en bases de datos distribuidas. Por un lado, puede haber directorios locales o un solo directorio global. Por otra parte, su manejo puede ser local o distribuido. Finalmente, desde otro punto de vista el directorio puede ser replicado o no replicado. Como se puede ver en la Figura 2.15, existen combinaciones, en estas tres dimensiones, que no tienen mayor relevancia. Sin embargo, en varios de los vértices del cubo en tres dimensiones aparecen las combinaciones importantes para bases de datos distribuidas.












CONCLUSIONES
Un SMBDD homogéneo tiene múltiples colecciones de datos; integra múltiples recursos de datos.
La clase de sistemas heterogéneos es aquella caracterizada por manejar diferentes SMBD en los nodos locales.
La Transparencia se refiere a la división del nivel semántico y la implementación del sistema.
RECOMENDACIÓN
Qué las empresas, negocios y en este caso los mismos estudiantes deben de adquirir un conocimiento de la Arquitectura para saber como implementarlo y que funciones dentro de una empresa.
















BIBLIOGRAFÍA
cs.cinvestav.mx. (s.f.). Recuperado el sabado de octubre de 2013, de http://www.cs.cinvestav.mx/SC/prof_personal/adiaz/Disdb/Cap_1.html
M. Tamer Ozsu – Patrick Valduriez, P. H. (2011). Principles of distributed database systems. En Principles of distributed database systems.
Fundación Wikimedia, Inc. (23 de septiembre de 2013). Wikipedia. Recuperado el 30 de septiembre de 2013, de Wikipedia: https://www.wikipedia.com/Base de Datos Distribuidas.html
Prof. José A. Rodríguez Mondéjar. Arquitectura de Sistemas Distribuidos [en línea].
Recuperado el 07 de febrero de 2010, de
http://www.dea.icai.upcomillas.es/jarm/Asignaturas/Doc_SistemasDistribuidos/3SDArquite
ctura.pdf.
Luis Bernal (2008, 24 de mayo). Arquitectura de Sistemas Distribuidos [en línea].
Recuperado el 07 de febrero de 2010, de http://www.luisbernal.es/descargas/f/INFasd.pdf.
Griselda Alejandra Chevalier Dueñas (2000, 23 de mayo). Agentes móviles para
recuperación personalizada de información. [En línea]. Puebla, México. Recuperado el 07
de febrero de 2010, de
http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/chevalier_d_ga/
LinuxCentro.net. Software Libre y GNU/Linux. (2007, 22 de febrero). Servidor PROXY. [En
línea]. Recuperado el 08 de febrero de 2010, de
http://www.linuxcentro.net/linux/staticpages/index.php?page=ServidorPROXY.
WIKIPEDIA, La enciclopedia libre (2010, 02 de febrero). Cliente ± Servidor. [En línea].
Recuperado el 08 de febrero de 2010, de http://es.wikipedia.org/wiki/Cliente-servidor.
WIKIPEDIA, La enciclopedia libre (2010, 29 de enero). Peer ± to - Peer. [En línea].
Recuperado el 08 de febrero de 2010, de http://es.wikipedia.org/wiki/Peer-to-peer.
WIKIPEDIA, La enciclopedia libre (2010, 24 de enero). Servidor. [En línea]. Recuperado el
08 de febrero de 2010, de http://es.wikipedia.org/wiki/Servidor.







Distribución cliente / servidor
Distribución peer-to -peer
Concentra las funciones de gestión de datos en servidores , mientras que los clientes se centran en proporcionar el entorno de aplicación
No hay distinción de equipos cliente frente a los servidores.
Autonomía de diseño
Autonomía de comunicación
Autonomía de ejecución