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 ROLANDOMOREIRA SANTANA ALEXIS

PAZ GUTIÉRREZ LUISCurso: SEXTO NIVEL "B”

Profesor:ING. PATRICIA QUIROZ PALMA

MANTA-MANABÍ-ECUADOR

Octubre, 2014

ContenidoINTRODUCCIÓN................................................3DESARROLLO DEL TEMA.........................................3ARQUITECTURAS DE SISTEMAS DISTRIBUIDOS....................3Arquitectura Cliente/Servidor............................3Arquitectura Peer-to-Peer (P2P)..........................4Arquitectura Servidor Proxy..............................5Arquitectura Agentes Móviles.............................7

ESTÁNDARES EN LOS DBMS....................................8MODELOS ARQUITECTÓNICOS DE DDBMS.........................11AUTONOMÍA...............................................11DISTRIBUCION............................................13HETEROGENEIDAD..........................................14SISTEMAS CLIENTE / SERVIDOR.............................14SISTEMAS PEER TO PEER...................................15MULTI BASE DE DATOS ARQUITECTURA DEL SISTEMA............16

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

CONCLUSIONES...............................................23RECOMENDACIÓN..............................................23BIBLIOGRAFÍA...............................................24

INTRODUCCIÓN

En este trabajo de investigación estudiaremos la arquitecturade los sistemas de base de datos distribuidos.

La arquitectura de un sistema define su estructura. Estosignifica que se identifican los componentes del sistema, seespecifica la función de cada componente, y las relaciones einteracciones entre estos componentes se definen. Laespecificación de la arquitectura de un sistema requiere laidentificación de los distintos módulos, con sus interfaces einterrelaciones, en términos de los datos y el flujo decontrol 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ásampliamente adoptado en la actualidad. En éste modelo hay dostipos de procesos, los clientes son procesos que hacenpeticiones de servicio y los servidores proveen esosservicios.

Funciones del Cliente

Es quien inicia solicitudes o peticiones, tienen portanto un papel activo en laComunicació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 delos clientes, desempeñan entonces un papel pasivo en lacomunicación (dispositivo esclavo).

Tras la recepción de una solicitud, la procesan y luegoenvían la respuesta al cliente.

Por lo general, aceptan conexiones desde un gran númerode clientes (en ciertos casos el número máximo depeticiones puede estar limitado).

No es frecuente que interactúen directamente con losusuarios finales.

Ventajas

Sencillez, únicamente se necesita la ubicación delservidor.

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 sistemadistribuido en el que todos los nodos tienen las mismascapacidades y responsabilidades, y en el que toda lacomunicación es simétrica. Las redes peer-to-peer aprovechan,administran y optimizan el uso del ancho de banda de losdemás usuarios de la red por medio de la conectividad entrelos mismos, obteniendo más rendimiento en las conexiones ytransferencias que con algunos métodos centralizadosconvencionales, donde una cantidad relativamente pequeña deservidores provee el total del ancho de banda y recursoscompartidos para un servicio o aplicación.

Sus características son las siguientes: Escalabilidad,Robustez, Descentralización, Anonimato, Seguridad y Costesrepartidos.

Ventajas

Los procesos tiene un rol similar, aunque pueden asumirun 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 peticioneshttp de clientes u otros intermediarios y genera a su vezpeticiones hacia otros intermediarios o hacia el servidor webdestino. Actúa como servidor del cliente y como cliente delservidor; realiza un cierto tipo de funciones a nombre deotros clientes en la red para aumentar el funcionamiento deciertas operaciones, también sirve de seguridad, esto es,tiene un Firewall. Permite administrar el acceso a interneten una Red de computadoras permitiendo o negando el acceso adiferentes sitios Web.

Características principales

Compartir la conexión a Internet para todos loscontenidos.

Almacenamiento de las páginas visitadas acelerando lasconexiones a las páginas visitadas.

Conexiones compartidas equitativamente entre losusuarios reduciéndose así laespera.

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 denuestra red, protegiéndola contra posibles intrusiones.

Arquitectura Agentes Móviles

Los agentes móviles son programas de software capaces deviajar por redes de computadoras, como Internet, deinteractuar con hosts, pedir información a nombre de unusuario y regresar a su lugar de origen una vez que harealizado las tareas especificadas por un usuario. Creado enun ambiente de ejecución, el agente puede transportar suestado y código a otro contexto en donde reanudará laejecución. Estos agentes aprovechan los recursos del nododestino en beneficio del nodo que los envió, negociando ycerrando tratos en su nombre ó utilizando servicios remotos.Un agente móvil tiene capacidad para decidir a qué servidoresmoverse y puede moverse a uno o más servidores. Es unaextensión del modelo cliente/servidor.

Algunos de los campos idóneos en donde se pueden aplicar losagentes móviles son los siguientes: procesamiento enparalelo, comercio electrónico, asistencia personal,recuperación de información distribuida, servicios de redes ytelecomunicaciones, 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 laimplementación del sistema.

El objetivo es ocultar al usuario los detalles de diseño, esdecir, el usuario no tiene que saber que se encuentratrabajando sobre un sistema distribuido, por ejemplo laindependencia de los datos es una forma de transparencia

El propósito fundamental de la transparencia en el ambientedistribuido es la independencia de datos.

Al implementar una base de datos distribuida se tienenciertas normas comunes:

Transparencia de ubicación. Permite a los usuarios teneracceso a los datos sin que tenga conocimiento de laubicación de éstos. Se puede conseguir este nivel detransparencia al utilizar los administradores detransacciones distribuidas, los cuales son capaces dedeterminar la localización de los datos y de emitiracciones a los calendarizadores apropiados, lo cualpuede ejecutarse cuando los administradores detransacciones distribuidas poseen acceso a losdirectorios de localizaciones de los datos.

Transparencia de duplicación. Para que la transparenciade duplicación sea posible, los administradores detransacciones deben traducir las solicitudes deprocesamiento de transacción en acciones para eladministrador de datos. Para las lecturas el

administrador de transacciones selecciona uno de losnodos que almacena los datos y ejecuta la lectura. Paraoptimizar el proceso, el administrador de transaccionesnecesita información sobre el rendimiento de variosnodos respecto al sitio de consulta, así podráseleccionar el nodo de mejor rendimiento. Laactualización y escritura de datos duplicados suelen sermás complicadas, ya que el manejador de transaccionesdebe emitir una acción de escritura para cada uno de loscalendarizadores que almacena una copia de los datos.

Transparencia de concurrencia. Cuando variastransacciones se ejecuten al mismo tiempo, losresultados de las transacciones no deberán afectarse. Latransparencia de concurrencia se logra si los resultadosde todas las transacciones concurrentes son consistentesde manera lógica con los resultados que se habríanobtenido si las transacciones se hubieran ejecutado unapor una, en cualquier orden secuencial.

Transparencia de fallas. Significa que a pesar de fallaslas transacciones sean procesadas de un modo correcto.Frente a una falla, las transacciones deben seratómicas, significa que se procesen todas o ninguna deellas. Para este tipo de problemas es importante tenerresguardo de la base de datos, y así poder restaurarlacuando sea conveniente. El sistema debe detectar cuándofalla una localidad y tomar las medidas necesarias pararecuperarse del fallo. El sistema no debe seguirutilizando la localidad que falló. Por último, cuando serecupere o repare esta localidad, debe contarse conmecanismos para reintegrarla al sistema con el mínimo decomplicaciones.

Localidad del procesamiento. Los datos se debendistribuir lo más cerca posible de las aplicaciones quelos usan para maximizar la localidad del procesamiento,este principio responde a minimizar el acceso remoto alos datos. Diseñar una distribución que maximicelocalidad del procesamiento puede hacerse añadiendo lacantidad de referencias locales y remotascorrespondientes a cada fragmentación candidata yasignar la fragmentación eligiendo la mejor solución.Independencia de configuración. La independencia deconfiguración permite añadir o reemplazar hardware sintener que cambiar componentes de software existentes enel sistema de base de datos distribuida.

Particionado de la Base de Datos. La base de datos sedistribuye de modo que no haya solapamiento oduplicación de los datos mantenidos en las diferenteslocalidades, como no hay duplicaciones de los datos, seevitan los costos asociados con el almacenamiento ymantenimiento de datos redundantes. Si un mismo segmentode datos se usa en más de una localidad se ve limitadala disponibilidad de los datos. La fiabilidad tambiénpuede verse limitada cuando se produce un fallo en elsistema de cálculo de una localidad se afecta ladisponibilidad de los datos de esa localidad no esténdisponible para los usuarios en cualquier parte delsistema.

Fragmentación de datos. Consiste en subdividir lasrelaciones y distribuirlas entre los sitios de la red,tiene como objetivo buscar formas alternativas dedividir una las instancias (tablas) de relaciones enotras más pequeñas. La fragmentación se puede realizarpor tuplas individuales (fragmentación horizontal), poratributos individuales fragmentación vertical) o una

combinación de ambas (fragmentación híbrida). Elprincipal problema de la fragmentación radica enencontrar la unidad apropiada de distribución. Unarelación no es una buena unidad por muchas razones.Normalmente las vistas de una relación están formadaspor subconjuntos de relaciones. Además, las aplicacionesacceden localmente a subconjuntos de relaciones. Porello, es necesario considerar a los subconjuntos derelaciones como unidad de distribución. Al descomponerde una relación en fragmentos, tratados cada uno deellos como una unidad de distribución, permite elproceso concurrente de las transacciones.

El conjunto de estas relaciones, provocará la ejecuciónparalela de una consulta al ser dividida en una serie desubconsultas que operará sobre los fragmentos. Cuandolas vistas definidas sobre una relación son consideradascomo unidad de distribución que se ubican en diferentessitios de la red, podemos optar por dos alternativasdiferentes: La relación no estará replicada y sealmacena en un único sitio, o existe réplica en todos oalgunos de los sitios en los cuales reside laaplicación. Las consecuencias de esta estrategia son lageneración de un volumen de accesos remotos que puedenser innecesarios con un mal manejo de estas replicas.Además, las réplicas innecesarias pueden causarproblemas en la ejecución de las actualizaciones y puedeno ser deseable si el espacio de almacenamiento estálimitado. Los inconvenientes de la fragmentación estándados en que si las pueden estar definidas porfragmentos mutuamente exclusivos y al recuperar losdatos de dos fragmentos situados en sitios diferentes esnecesario trasmitir los datos de un sitio a otro yrealizar sobre ellos la operación de unión (Join), lo

cual puede ser costoso. El control semántico cuando losatributos implicados en una dependencia una relación sedescompone en diferentes fragmentos y estos se ubican ensitios diferentes puede ser muy costos porque esnecesario hacer búsquedas en un gran número de sitios.

MODELOS ARQUITECTÓNICOS DE DDBMS

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

AUTONOMÍALa autonomía, en este contexto, se refiere a la distribucióndel control, no de los datos. Se indica el grado en que losDBMS individuales pueden funcionar de manera independiente.

La autonomía es una función de un número de factores talescomo si los sistemas de componentes (es decir, los DBMSindividual) intercambio de información, si se puede ejecutarde forma independiente las operaciones, y si se le permitemodificarlos. Requisitos de un sistema autónomo que se hayanespecificado de la siguiente manera [Gligor y Popescu-Zeletin, 1986]:

1. Las operaciones locales de los DBMS individuales no se venafectados por su participación en el sistema distribuido.

2. La manera en que las consultas proceso DBMS individuales yoptimizarlas no deben verse afectados por la ejecución deconsultas globales que tienen acceso a varias bases de datos.

3. Coherencia o la operación del sistema no debe versecomprometida cuando los DBMS individuales unirse o abandonarel sistema distribuido.

Por otra parte, las dimensiones de la autonomía se puedenespecificar de la siguiente manera [Duand Elmagarmid, 1989]:

1. Autonomía de diseño: DBMS individuales son libres deutilizar los modelos de datos y técnicas de gestión deoperaciones que ellos prefieren.

2. Autonomía Comunicación: Cada uno de los DBMS individuo eslibre de tomar sus propias decisiones en cuanto a qué tipo deinformación que desea proporcionar a las otras bases de datoso el software que controla su ejecución global.

Autonomía de diseño

Autonomía de

comunicación

Autonomía de

ejecución

3. Autonomía de ejecución: Cada DBMS puede ejecutar lasoperaciones que se le presenten, en cualquier forma quedesee.

Vamos a utilizar una clasificación que abarca los aspectosimportantes de estas características.

Una alternativa es la estrecha integración, donde una solaimagen de la base de datos está disponible para cualquierusuario que quiera compartir la información, que puederesidir en múltiples bases de datos. Desde la perspectiva delos usuarios, los datos se integran lógicamente en una basede datos. En estos sistemas fuertemente integrados, losgestores de datos se implementan de modo que uno de ellos esen el control del procesamiento de cada petición de usuarioincluso si esa solicitud es atendida por más de un gestor dedatos. Los gestores de datos no suelen funcionar como DBMSindependientes a pesar de que por lo general tienen lafuncionalidad para hacerlo.

A continuación se identifican los sistemas semiautónomos queconstan de DBMS que pueden (y generalmente lo hacen) operarde forma independiente, pero hemos decidido participar en unafederación para que sus datos locales compartible. Cada unode estos DBMS determinar qué partes de su propia base dedatos se harán accesibles a los usuarios de otras bases dedatos. No son sistemas completamente autónomos, ya que debenser modificados para que puedan intercambiar informaciónentre sí.

La última alternativa que consideramos que es un aislamientototal, donde los sistemas individuales son DBMSindependientes que no conocen ni la existencia de otras basesde datos, ni la forma de comunicarse con ellos. En talessistemas, el procesamiento de transacciones de usuario queaccede a varias bases de datos es especialmente difícil ya

que no hay control global de la ejecución de los DBMSindividuales.

DISTRIBUCION

La distribución cliente / servidor y la distribución peer-to-peer (o distribución total). Junto con la opción de nodistribuido, la taxonomía identifica tres arquitecturasalternativas.

La distribución cliente / servidor concentra las funciones degestión de datos en servidores, mientras que los clientes secentran en proporcionar el entorno de aplicación como lainterfaz de usuario. Las funciones de comunicación secomparten entre los equipos cliente y servidores. DBMScliente / servidor representan un compromiso práctico paradistribuir la funcionalidad. Hay una variedad de formas deestructuración de ellos, cada uno proporcionando un niveldiferente de la distribución. Lo que es importante en estepunto 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 equiposcliente frente a los servidores.

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.

Cada máquina tiene toda la funcionalidad DBMS y puedecomunicarse con otras máquinas para realizar consultas ytransacciones. La mayoría de los muy primeros trabajos sobrelos sistemas de bases de datos distribuidas han asumido laarquitectura peer-to -peer. Por lo tanto, en los sistemaspeer-to -peer (también llamado completamente distribuida) , apesar de que muchas de las técnicas que llevan a los sistemascliente / servidor

HETEROGENEIDAD

La heterogeneidad se puede producir en diversas formas en lossistemas distribuidos, que van desde la heterogeneidad dehardware y diferencias en los protocolos de redes a lasvariaciones en los administradores de datos. Enrepresentación de los datos con diferentes herramientas demodelado crea heterogeneidad debido a los poderes expresivosinherentes y limitaciones de los modelos de datosindividuales.

SISTEMAS CLIENTE / SERVIDOR

DBMS cliente / servidor entraron en la escena informática aprincipios de 1990 y han tenido un impacto significativotanto en la tecnología DBMS y la forma de hacer el cálculo.La idea general es muy simple y elegante: distinguir lafuncionalidad que debe ser proporcionado y dividir estasfunciones en dos clases: las funciones de servidor y lasfunciones del cliente. Esto proporciona una arquitectura dedos niveles que hace que sea más fácil de manejar la

complejidad de los DBMS modernos y la complejidad de ladistribución.

Como con cualquier término muy popular, cliente / servidor seha abusado mucho y ha llegado a significar cosas diferentes.Si se toma una vista centrado en el proceso, entoncescualquier proceso que solicita los servicios de otro procesoes su cliente y viceversa. Sin embargo, es importante teneren cuenta que " cliente / servidor " y "cliente / servidorDBMS ", ya que se utiliza en nuestro contexto, no se refierena los procesos, pero a las máquinas reales. Por lo tanto, noscentramos en lo que software se ejecutará en los equiposcliente y qué software se debe ejecutar en el servido

Dicho de esta manera, la cuestión es más clara y podemosempezar a estudiar las diferencias en el cliente y lafuncionalidad del servidor. La asignación de funcionalidadentre los clientes y sirve diferir en diferentes tipos deDBMS distribuidos (por ejemplo, frente a relacional orientadoa objetos ) .

En los sistemas relacionales, el servidor hace la mayoría deltrabajo de gestión de datos. Esto significa que todos los deprocesamiento de consultas y optimización, gestión detransacciones y de gestión de almacenamiento se realiza en elservidor. El cliente, además de la aplicación y la interfazde usuario , tiene un módulo de cliente que DBMS esresponsable de la gestión de los datos que se almacenan encaché en el cliente y (a veces ) la gestión de los bloqueosde transacciones que pueden haber sido almacenado en cachétambién. También es posible colocar comprobación de lacoherencia de las consultas del usuario en el lado delcliente , pero esto no es común ya que requiere lareplicación del catálogo del sistema en las máquinascliente . Por supuesto, no es el sistema operativo y elsoftware de comunicación que se ejecuta en el cliente y en el

servidor, pero que sólo se centran en la funcionalidadrelacionada DBMS. En otras palabras, el cliente pasaconsultas SQL al servidor sin tratar de entender ooptimizarlos. El servidor hace la mayor parte del trabajo ydevuelve la relación resultado al cliente.

SISTEMAS PEER TO PEER

Si el término "cliente / servidor " está lleno de diferentesinterpretaciones, " peer-to -peer " es aún peor ya que susignificado ha cambiado y evolucionado a lo largo de losaños. Como se señaló anteriormente, los primeros trabajossobre los DBMS distribuidos todos enfocados en lasarquitecturas peer-to -peer , donde no había distinción entrela funcionalidad de cada sitio en el sistema4

.

Después de una década de la popularidad de la computacióncliente / servidor, peer-to -peer han hecho una reapariciónen los últimos años (impulsado principalmente por lasaplicaciones de intercambio de archivos), y algunos inclusohan posicionado gestión de datos peer-to -peer comoalternativa a distribuir DBMS. Si bien esto puede ser untramo, sistemas peer-to -peer modernos tienen dos diferenciasimportantes de sus parientes anteriores. El primero es ladistribución masiva en los sistemas actuales. Mientras que enlos primeros días nos hemos centrado en unos pocos (tal vezen la mayoría de los cientos de sitios) , los sistemasactuales consideran que miles de sitios . La segunda es laheterogeneidad inherente de todos los aspectos de los sitiosy su autonomía. Si bien esto ha sido siempre una preocupaciónde bases de datos distribuidas, como se explicóanteriormente, junto con la distribución masiva ,

heterogeneidad de los sitios y la autonomía tener unsignificado añadido, rechazando algunos de los enfoques deconsideración.

MULTI BASE DE DATOS ARQUITECTURA DEL SISTEMA

Sistemas multi base de datos (CMBD) representa el caso en quelos DBMS individuales (sean distribuidos o no) son totalmenteautónomos y no tienen idea de la cooperación, sino que puedenincluso no "sabe" de la existencia del otro o cómo hablar eluno al otro. Nuestro objetivo es, por supuesto, en MDBSsdistribuidos, que es lo que el término se referirá en elresto.

En la literatura más reciente, se encuentra el términosistema de integración de datos utilizado en su lugar.

Evitamos el uso de ese término ya que los sistemas deintegración de datos consideran las fuentes de datos que noson de base de datos también. Nuestra atención se centraestrictamente 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 dedatos.

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:

1. Distribución. Determina si las componentes del sistema están localizadas en la misma computadora o no.

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

3. 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 componentedel 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:

1. Sistemas de manejo de bases de datos distribuidos homogéneos

2. 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 SMBDDhomogé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 desoftware. 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 usuarioslocales 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 esquemalocal 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 SMBDdistribuido.

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 ono replicado. Como se puede ver en la Figura 2.15, existen combinaciones, en estas tres dimensiones, que no tienen mayorrelevancia. 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 laArquitectura para saber como implementarlo y quefunciones dentro de una empresa.

BIBLIOGRAFÍAcs.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 SistemasDistribuidos [en línea].

Recuperado el 07 de febrero de 2010, dehttp://www.luisbernal.es/descargas/f/INFasd.pdf.

Griselda Alejandra Chevalier Dueñas (2000, 23 de mayo). Agentesmó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 defebrero). 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, dehttp://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, dehttp://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.