INTRODUCCIN:

Originalmente se almacenaba la informacin de manera centralizada, pero con el paso del tiempo las necesidades aumentaron y esto produjo ciertos inconvenientes que no era posible solucionarlos o volverlos eficientes de la forma centralizada. Estos problemas impulsaron la creacin de almacenamiento distribuido, los cuales hoy en da proveen caractersticas indispensables en el manejo de informacin; es decir, la combinacin de las redes de comunicacin y las bases de datos. La cantidad de innovaciones tecnolgicas que ha habido en lo ltimos aos ha promovido un cambio en la forma de observar a los sistemas de informacin y, en general, a las aplicaciones computacionales. Existen avances tecnolgicos que se realizan continuamente en circuitos, dispositivos de almacenamientos, programas y metodologas. Sin embargo, los cambios tecnolgicos van de la mano con la demanda de los usuarios y programas para la explotacin exhaustiva de tales dispositivos mejorados. Por tanto, existe un continuo desarrollo de nuevos productos los cuales incorporan ideas nuevas desarrolladas por compaas e instituciones acadmicas. Aun cuando es posible que un usuario comn no perciba los desarrollos relevantes de nuevos productos, para las aplicaciones existe una demanda permanente por mayor funcionalidad, mayores nmeros de servicios, ms flexibilidad y mejor rendimiento. As al disear unos nuevos sistemas de informacin o al prolongar la vida de uno ya existente, se debe buscar siempre formas para enlazar las soluciones ofrecidas por la tecnologa disponible a las necesidades de las aplicaciones de los usuarios. Un rea en la cual las soluciones estn integrando tecnologa con nuevas arquitecturas o formas de hacer las cosas es, sin lugar a dudas, el rea de los sistemas distribuidos de informacin. Ellos se refieren al manejo de datos almacenados en facilidades de cmputo localizadas en muchos sitios ligados a travs de una red de comunicaciones. Un caso especfico de estos sistemas distribuidos es lo que se conoce como base de datos distribuidos.

Evolucin de las BDD

Hay varios factores que han hecho que las bases de datos evolucionen a bases de datos distribuidas. En el mundo de los negocios se ha dado una globalizacin y a la vez las operaciones de las empresas son cada vez ms descentralizadas geogrficamente. Tambin el poder de las computadoras personales aument y el costo de los Mainframes ya no tena sentido. Adems la necesidad de compartir datos ha hecho que crezca el mercado de las bases de datos distribuidas.

Definicin:

Es una coleccin de datos distribuidos en diferentes nodos de una red de computadoras. Cada sitio de la red es autnomo, puede ejecutar aplicaciones locales y al menos una aplicacin global, lo cual requiere acceso a datos ubicados en varios sitios. Es un conjunto de mltiples bases de datos lgicamente relacionadas que se encuentran distribuidas en diferentes lugares. En un sistema de base de datos distribuida, los datos se almacenan en varios computadores. Los computadores de un sistema distribuido, se comunican entre s a travs de diversos medios de comunicacin, tales como cables de alta velocidad o lneas telefnicas. La diferencia entre base de datos centralizados y los distribuidos es que, en los primeros, los datos residen en una sola localidad, mientras que, en los ltimos, se encuentran en varias localidades.

CARACTERSTICAS DE UNA BDD

Los datos deben estar fsicamente en ms de un ordenador (distintas sedes)

Las sedes deben estar interconectadas mediante una red (cada sede es un nodo de la red)

Los datos han de estar lgicamente integrados (recuperacin actualizacin) tanto en local como remoto (esquema lgico global y nico)

En una nica operacin se puede acceder (recuperar o actualizar) datos que se encuentran en ms de una sede (acceso a datos locales o remotos)

Todas las acciones que necesiten realizarse sobre ms de una sede sern transparentes al usuario (transparencia de distribucin para el usuario)

Los sitios distribuidos deben ser autnomos, es decir que todas las operaciones en un sitio dado se controlen en ese sitio.

No debe de existir dependencia de un sitio central para obtener un servicio.

CONSIDERACIONES AL DISTRIBUIR LOS DATOS:

Existen varias razones para construir sistemas distribuidos de bases de datos que incluyen compartir la informacin, fiabilidad y disponibilidad y agilizar el procesamiento de las consultas. Pero tambin tiene sus desventajas, como desarrollos de software ms costosos, mayor posibilidad de errores y costos extras de procesamiento.

VENTAJAS

La principal ventaja de los sistemas distribuidos es la capacidad de compartir y acceder a la informacin de una forma fiable y eficaz. Utilizacin compartida de los datos y distribucin del control. La ventaja principal de compartir los datos por medio de la distribucin es que cada localidad pueda controlar hasta cierto punto los datos almacenados localmente. En un sistema centralizado, el administrador de base de datos de la localidad central controla la base de datos. En un sistema distribuido existe un administrador global de la base de datos que se encarga de todo el sistema. Parte de esta responsabilidad se delega al administrador de base de datos de cada localidad. Dependiendo del diseo del sistema distribuido, cada administrador local podr tener un grado de autonoma diferente, que se conoce como autonoma local. La posibilidad de contar con autonoma local es en muchos casos una ventaja importante de las bases de datos distribuidas. Fiabilidad y disponibilidad: Si se produce un fallo en una localidad de un sistema distribuido, es posible que las dems localidades puedan seguir trabajando. En particular, si los datos se repiten en varias localidades, una transaccin que requiere un dato especfico puede encontrarlo en ms de una localidad. As, el fallo de una localidad no implica necesariamente la desactivacin del sistema. El sistema debe detectar cuando 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 mnimo de complicaciones. La disponibilidad es fundamental para los sistemas de bases de datos que se utilizan en aplicaciones de tiempo real. Por ejemplo, si una lnea area no puede tener acceso a la informacin, es posible que pierda clientes a favor de la competencia.

Agilizacin del procesamiento de consultas. Si una consulta comprende datos de varias localidades, puede ser posible dividir la consulta en varias subconsultas que se ejecuten en paralelo en distintas localidades. Sin embargo, en un sistema distribuido no se comparte la memoria principal, as que no todas las estrategias de interseccin se pueden aplicar en estos sistemas. En los casos en que hay repeticin de los datos, el sistema puede pasar la consulta a las localidades ms ligeras de carga. Los costos de las comunicaciones de datos son por lo general menores con bases de datos distribuidas, ya que el procesamiento se puede hacer a nivel local. Por ejemplo, con los registros de clientes alojados localmente, una sucursal no incurre en costos de telecomunicaciones para comunicarse con una computadora que alberga la sede de los datos de la sucursal. Si hay un problema de hardware y software en un centro de cmputos que almacena toda la informacin y los procesos de la sucursal, todas las sucursales pueden ser afectadas. Con bases de datos distribuidas, muchas sucursales pueden continuar el proceso por computadora sin esperar a que la ubicacin central funcione de nuevo.

DESVENTAJAS:

Si ests decidiendo si debes implementar una base de datos distribuida, no basta con ver las ventajas, ya que hay tambin algunas desventajas. Las bases de datos distribuidas requieren mayor gestin. Por ejemplo, uno debe sincronizar con precisin con una computadora central. Si algunos de los mismos datos se encuentran en varios lugares, uno debe asegurarse de que los controles adecuados estn en su lugar para asegurar que no haya discrepancia en la precisin de dos o ms instancias de datos. La desventaja principal de los sistemas distribuidos es la mayor complejidad que se requiere para garantizar una coordinacin adecuada entre localidades. El aumento de la complejidad se refleja en: Coste del desarrollo de software: es ms difcil estructura un sistema de bases de datos distribuidos y por tanto su coste es menor Mayor posibilidad de errores: puesto que las localidades del sistema distribuido operan en paralelo, es ms difcil garantizar que los algoritmos sean correctos. Mayor tiempo extra de procesamiento: el intercambio de mensajes y los clculos adicionales son una forma de tiempo extra que no existe en los sistemas centralizados.

ARQUITECTURA DE BDD
Con el aumento de la velocidad y potencia de las computadoras personales y el decremento en su precio, los sistemas se han ido distanciando de la arquitectura centralizada. Los terminales conectados a un sistema central han sido suplantados por computadoras personales. De igual forma, la interfaz de usuario, que sola estar gestionada directamente por el sistema central, est pasando a ser gestionada cada vez ms por las computadoras personales. Como consecuencia, los sistemas centralizados actan hoy como sistemas servidores que satisfacen las peticiones generadas por los sistemas clientes. La computacin cliente/servidor es la extensin lgica de la programacin modular. El supuesto principal de la programacin modular es la divisin de un programa grande en pequeos programas (llamados mdulos), siendo ms fciles el desarrollo y la mantenibilidad (divide y vencers). Cualquier LAN (red de rea local) puede ser considerada como un sistema cliente/servidor, desde el momento en que el cliente solicita servicios como datos, ficheros o imprimir desde el servidor. Cuando un usuario se conecta a Internet, interactua con otros computadores utilizando el modelo cliente/servidor. Los recursos de Internet son proporcionados a travs de computadores host, conocidos como servidores. El servidor es el computador que contiene informacin (bases de datos, ficheros de texto...). El usuario, o cliente, accede a esos recursos va programas cliente (aplicaciones) que usan TCP/IP para entregar la informacin a su computadora. Segn esta definicin, los sistemas cliente/servidor no estn limitados a aplicaciones de bases de datos. Cualquier aplicacin que tenga una interfaz de usuario (front-end, seccin frontal o parte cliente) que se ejecute localmente en el cliente y un proceso que se ejecute en el servidor (back-end, seccin posterior, o sistema subyacente) est en forma de computacin cliente/servidor.

Conceptualmente, las plataformas cliente/servidor son parte del concepto de sistemas abiertos, en el cual todo tipo de computadores, sistemas operativos, protocolos de redes y otros, software y hardware, pueden interconectarse y trabajar coordinadamente para lograr los objetivos del usuario. Sin embargo, en la prctica, los problemas de alcanzar tal variedad de sistemas operativos, protocolos de redes, sistemas de base de datos y otros, que trabajen conjuntamente pueden ser muchos. El objetivo de los sistemas abiertos consiste en lograr la interoperabilidad, que es el estado de dos o ms sistemas heterogneos comunicndose y contribuyendo cada uno a alguna parte del trabajo que corresponde a una tarea comn.

En cierto sentido, el enfoque cliente/servidor es la culminacin de una percepcin temprana de la potencia del clculo distribuida conjuntamente con el control y el acceso a los datos inherentes a un computador centralizado.

2. CARACTERSTICAS DE UN SISTEMA CLIENTE/SERVIDOR.

Un sistema cliente/servidor es aquel en el que uno o ms clientes y uno o ms servidores, conjuntamente con un sistema operativo subyacente y un sistema de comunicacin entre procesos, forma un sistema compuesto que permite cmputo distribuido, anlisis, y presentacin de los datos. Si existen mltiples servidores de procesamiento de base de datos, cada uno de ellos deber procesar una base de datos distinta, para que el sistema sea considerado un sistema cliente/servidor. Cuando dos servidores procesan la misma base de datos, el sistema ya no se llama un sistema cliente/servidor, sino que se trata de un sistema de base de datos distribuido. Los clientes, a travs de la red, pueden realizar consultas al servidor. El servidor tiene el control sobre los datos; sin embargo los clientes pueden tener datos privados que residen en sus computadoras. Las principales caractersticas de la arquitectura cliente/servidor son: - El servidor presenta a todos sus clientes una interfaz nica y bien definida. - El cliente no necesita conocer la lgica del servidor, slo su interfaz externa. - El cliente no depende de la ubicacin fsica del servidor, ni del tipo de equipo fsico en el que se encuentra, ni de su sistema operativo. - Los cambios en el servidor implican pocos o ningn cambio en el cliente.

Como ejemplos de clientes pueden citarse interfaces de usuario para enviar comandos a un servidor, APIs (Aplication Program Interface) para el desarrollo de aplicaciones distribuidas, herramientas en el cliente para acceder a servidores remotos (por ejemplo, servidores de SQL) o aplicaciones que solicitan acceso a servidores para algunos servicios. Como ejemplos de servidores pueden citarse servidores de ventanas como Xwindows, servidores de archivos como NFS, servidores para el manejo de bases de datos (como los servidores de SQL), servidores de diseo y manufactura asistidos por computador, etc.

3. PARTES DE UN SISTEMA CLIENTE/SERVIDOR

Los principales componentes de un sistema cliente/servidor son: - El ncleo (back-end o seccin posterior). Es el SGBD propiamente (servidor). - El interfaz (front-end o seccin frontal). Aplicaciones que funcionan sobre el SGBD (cliente).

La diferencia entre la computacin cliente/servidor y la computacin centralizada multiusuario es que el cliente no es un terminal tonto. El computador cliente tiene su propio sistema operativo y puede manejar entradas (teclado, ratn, etc...) y salidas (pantalla, impresora local, sonido, etc...) sin el servidor.

El papel del servidor es esperar pasivamente la peticin de servicio del cliente. Esta distribucin del proceso permite al cliente ofrecer un ambiente de trabajo ms amigable que un terminal tonto (interfaz de usuario grfica, aplicaciones locales, ratn, etc...) y permite al servidor ser menos complejo y caro que los sistemas mainframe. El conjunto de la computacin cliente/servidor conduce a un ambiente flexible y dinmico. La parte cliente de la aplicacin maneja la entrada de datos, acepta consultas de los usuarios y muestra los resultados. La parte cliente no procesa las consultas. En su lugar, enva la consulta del usuario al computador servidor, donde la parte

servidor de la aplicacin procesa la consulta. El servidor devuelve los resultados al cliente, que es quien se las muestra al usuario.

3.1. La seccin frontal.

Las secciones frontales son las diversas aplicaciones ejecutadas dentro del SGBD, tanto las escritas por los usuarios como las integradas que son las proporcionadas por el proveedor del SGBD o bien por otros proveedores de programas (aunque para la seccin posterior no existe diferencia entre las aplicaciones escritas por los usuarios y las integradas, ya que todas utilizan la misma interfaz con la seccin posterior).

3.1.1. Funciones del cliente

Administrar la interfaz grfica de usuario. Aceptar datos del usuario. Procesar la lgica de la aplicacin. Generar las solicitudes para la base de datos. Transmitir las solicitudes de la base de datos al servidor. Recibir los resultados del servidor. Dar formato a los resultados.

3.1.2 Cmo trabaja la seccin frontal

La secuencia de eventos que tiene lugar cuando el usuario accede al servidor de la base de datos se puede generalizar en 6 pasos bsicos ilustrados en la figura. Para mayor simplicidad, el trmino consulta representa cualquier accin que el usuario pueda hacer en la base de datos, como actualizar, insertar, borrar o pedir datos de la base de datos.

Primero, el usuario crea la consulta. Puede ser una consulta creada en el instante o puede ser una consulta pre-programada o almacenada anteriormente. Despus la aplicacin cliente convierte la consulta al SQL usado por el servidor de la base de datos y la enva a travs de la red al servidor. El servidor verifica que el usuario tiene los derechos de seguridad apropiados a la consulta de datos requerida. Si es as, verifica la consulta y enva los datos apropiados de vuelta al cliente. La aplicacin cliente recibe la respuesta y le da formato para presentarlo al usuario. Finalmente, el usuario ve la respuesta en la pantalla y puede manipular los datos, o modificar la consulta y empezar el proceso de nuevo.

3.1.3. Tipos de aplicaciones cliente.

Las aplicaciones pueden dividirse en varias categoras ms o menos bien definidas:

En primer lugar, aplicaciones escritas por los usuarios. Casi siempre se trata de programas comunes de aplicacin, escritos (normalmente) en un lenguaje de programacin convencional (por ejemplo Cobol), o bien en algn lenguaje propio (como Focus), aunque en ambos casos el lenguaje debe acoplarse de alguna manera con un sublenguaje de datos apropiado. En segundo lugar, aplicaciones suministradas por los proveedores (herramientas). El objetivo general de estas herramientas es ayudar en el proceso de creacin y ejecucin de otras aplicaciones, o sea, aplicaciones hechas a la medida para alguna tarea especfica (aunque la aplicacin creada quiz no parezca una aplicacin en el sentido convencional; de hecho, la verdadera razn para utilizar herramientas es que los usuarios, sobre todo los finales, puedan crear aplicaciones sin tener que escribir programas convencionales). Por ejemplo, una de las herramientas suministradas por los proveedores sera un procesador de lenguaje de consulta, cuyo propsito es desde luego permitir a los usuarios finales hacer consultas al sistema. En esencia, cada una de esas consultas no es ms que una pequea aplicacin hecha a la medida para realizar alguna funcin de aplicacin especfica. A su vez, las herramientas suministradas por los proveedores se dividen en varias clases distintas: - Procesadores de lenguajes de consulta - Generadores de informes - Subsistemas de grficas para negocios - Hojas electrnicas de clculo - Procesadores de lenguajes naturales - Paquetes estadsticos - Herramientas para administrar copias - Generadores de aplicaciones (incluyendo procesador de lenguajes de cuarta generacin o 4GL) - Otras herramientas para desarrollar aplicaciones, incluyendo productos para ingeniera de software asistida por computador (CASE).

3.2 La seccin posterior.

La seccin posterior es el SGBD en s. Permite llevar a cabo todas las funciones bsicas de un SGBD: definicin de datos, manipulacin de datos, seguridad, integridad, etc... En particular, permite establecer todos los aspectos de los niveles externo, conceptual e interno (arquitectura ANSI/SPARC)

3.2.1 Funciones del servidor

Aceptar las solicitudes de la base de datos de los clientes. Procesar dichas solicitudes. Dar formato a los resultados y transmitirlos al cliente. Llevar a cabo la verificacin de integridad. Mantener los datos generales de la base de datos. Proporcionar control de acceso concurrente. Llevar a cabo la recuperacin. Optimizar el procesamiento de consultas y actualizacin.

3.2.2 Tipos de servidores

Podemos dividir los servidores en dos clases: iterativos y concurrentes. Un servidor iterativo realiza los siguientes pasos: 1.- Espera que llegue una consulta de un cliente. 2.- Procesa la consulta. 3.- Enva la respuesta al cliente que envi la consulta. 4.- Vuelve al estado inicial. El problema del servidor iterativo es el paso 2. Durante el tiempo en el que el servidor est procesando la consulta, ningn otro cliente es servido. Un servidor concurrente realiza los siguientes pasos: 1.- Espera que llegue la consulta de un cliente. 2.- Cuando le llega una nueva consulta, comienza un nuevo proceso para manejar esta consulta (cmo se realiza este paso depende del sistema operativo). El nuevo servidor maneja la totalidad de la consulta. Cuando se ha procesado completamente, este nuevo proceso termina.

3.- Se vuelve al primer paso. La ventaja del servidor concurrente es que el servidor ejecuta un nuevo proceso para manejar cada consulta. Cada cliente tiene su "propio" servidor. Asumiendo que el sistema operativo permite la multiprogramacin, clientes mltiples y servicio concurrente. Tambin podemos dividir los servidores en servidores de transacciones y servidores de datos.

Los sistemas servidores de transacciones, tambin llamados sistemas servidores de consultas, proporcionan una interfaz a travs de la cual los clientes pueden enviar peticiones para realizar una accin que el servidor ejecutar y cuyos resultados se devolvern al cliente. Los usuarios pueden especificar sus peticiones con SQL o mediante la interfaz de una aplicacin utilizando un mecanismo de llamadas a procedimientos remotos (RPC: Remote Procedure Call). Los sistemas servidores de datos permiten que los clientes puedan interaccionar con los servidores realizando peticiones de lectura o modificacin de datos en unidades tales como archivos o pginas. Por ejemplo, los servidores de archivos proporcionan una interfaz de sistema de archivos a travs de la cual los clientes pueden crear, modificar, leer y borrar archivos. Los servidores de datos de los sistemas de bases de datos ofrecen muchas ms funcionalidades; soportan unidades de datos de menor tamao que los archivos, como pginas, tuplas u objetos. Proporcionan facilidades de indexacin de los datos, as como facilidades de transaccin, de modo que los datos nunca se quedan en un estado inconsistente si falla una mquina cliente o un proceso.

3.2.2.1 Servidores de transacciones

En los sistemas centralizados, un solo sistema ejecuta tanto la parte visible al usuario como el sistema subyacente. Sin embargo, la arquitectura del servidor de transacciones responde a la divisin funcional entre la parte visible al usuario y el sistema subyacente. Las computadoras personales gestionan la funcionalidad de la parte visible al usuario debido a las grandes necesidades de procesamiento que requiere el cdigo de la interfaz grfica, ya que la creciente potencia de las computadoras personales permite responder a esas necesidades. Los sistemas servidores tienen almacenado un gran volumen de datos y soportan la funcionalidad del sistema subyacente, mientras que las computadoras personales actan como clientes suyos. Los clientes envan transacciones a los sistemas servidores, que se encargan de ejecutar aquellas transacciones y enviar los resultados de vuelta a los clientes, que se encargan a su vez de mostrar los datos en pantalla. Se han desarrollado distintas normas como ODBC (Open Database Connectivity, Conectividad abierta de bases de datos), para la interaccin entre clientes y servidores. ODBC es una interfaz de aplicacin que permite que los clientes generen instrucciones SQL para enviarlas al servidor en donde se ejecutan. Cualquier cliente que utilice la interfaz ODBC puede conectarse a cualquier servidor que proporcione dicha interfaz. Los sistemas de bases de datos de generaciones anteriores, al no haber tales normas, necesitaban que la parte visible al usuario y el sistema subyacente fueran proporcionados por el mismo fabricante.

Con el crecimiento de las normas de interfaz, las herramientas de la parte visible al usuario y los servidores del sistema subyacente son administrados cada vez por ms marcas. Gupta SQL y Power-Builder son ejemplos de sistemas visibles al usuario independientes de los servidores del sistema subyacente. Es ms, ciertas aplicaciones, como algunas hojas de clculo o algunos paquetes de anlisis estadstico, utilizan directamente la interfaz cliente-servidor para acceder a los datos desde un servidor del sistema subyacente. Como resultado, proporcionan un sistema visible al usuario especializado en tareas concretas. Algunos sistemas de procesamiento de transacciones utilizan, adems de ODBC, otras interfaces cliente-servidor. stas se definen por medio de una interfaz de programacin de aplicaciones y son utilizadas por los clientes para realizar llamadas a procedimientos remotos de transacciones sobre el servidor. Para el programador, estas llamadas son como las llamadas normales a procedimientos, pero en realidad todas las llamadas a procedimientos remotos desde un cliente se engloban en una nica transaccin en el servidor. De esta forma, si la transaccin aborta, el servidor puede deshacer los efectos de las llamadas a procedimientos remotos individuales. El hecho de que adquirir y mantener una mquina pequea sea ahora ms barato, ha desembocado en una tendencia hacia el fraccionamiento de costes cada vez ms extendida en la industria. Muchas compaas estn reemplazando sus grandes sistemas por redes de estaciones de trabajo o computadoras personales conectadas a mquinas servidoras del sistema subyacente. Entre las ventajas, destacan una mejor funcionalidad respecto del coste, una mayor flexibilidad para localizar recursos y facilidades de expansin, mejores interfaces de usuario y un mantenimiento ms sencillo.

3.2.2.2 Servidores de datos

Los sistemas servidores de datos se utilizan en redes de rea local en las que se alcanza una alta velocidad de conexin entre los clientes y el servidor, las mquinas clientes son comparables al servidor en cuanto a poder de procesamiento y se ejecutan tareas de cmputo intensivo. En este entorno, tiene sentido enviar los datos a las mquinas clientes, realizar all todo el procesamiento (que puede durar un tiempo) y despus enviar los datos de vuelta al servidor. Ntese que esta arquitectura necesita que los clientes posean todas las funcionalidades del sistema subyacente. Las arquitecturas de los servidores de datos se han hecho particularmente populares en los sistemas de bases de datos orientadas a objetos.

En esta arquitectura surgen algunos aspectos interesantes, ya que el coste en tiempo de comunicacin entre el cliente y el servidor es alto comparado al de acceso a una memoria local (milisegundos frente a menos de 100 nanosegundos)

Envo de pginas o envo de elementos La unidad de comunicacin de datos puede ser de grano grueso (como una pgina), o de grano fino (como una tupla). Si la unidad de comunicacin de datos es una nica tupla, la sobrecarga por la transferencia de mensajes es alta comparada con el nmero de datos transmitidos. En vez de hacer esto, cuando se necesita una tupla, cobra sentido la idea de enviar junto a aquella otras tuplas que probablemente vayan a ser utilizadas en un futuro prximo. Se denomina preextraccin a la accin de buscar y enviar tuplas antes de que sea estrictamente necesario. Si varias tuplas residen en una pgina, el envo de pginas puede considerarse como una forma de preextraccin, ya que cuando un procese desee acceder a una nica tupla de la pgina, se enviarn todos las tuplas de esa pgina.

Bloqueo La concesin del bloqueo de las tuplas de datos que el servidor enva a los clientes la realiza habitualmente el propio servidor. Un inconveniente del envo de pginas es que los clientes pueden recibir bloqueos de grano grueso (el bloqueo de una pgina bloquea implcitamente a todas las tuplas que residan en ella). El cliente adquiere implcitamente bloqueos sobre todas las tuplas preextradas, incluso aunque no est accediendo a alguno de ellos. De esta forma, puede detenerse innecesariamente el procesamiento de otros clientes que necesitan bloquear esos elementos. Se han propuesto algunas tcnicas para la liberacin de bloqueos, en las que el servidor puede pedir a los clientes que le devuelvan el control sobre los bloqueos de las tuplas preextradas. Si el cliente no necesita la tupla preextrada, puede devolver los bloqueos sobre esa tupla al servidor para que stos puedan ser asignados a otros clientes.

Cach de datos Los datos que se envan al cliente a favor de una transaccin se pueden alojar en una cach del cliente, incluso una vez completada la transaccin, si dispone de suficiente espacio de almacenamiento libre. Las transacciones sucesivas en el mismo cliente pueden hacer uso de los datos en cach. Sin embargo, se presenta el problema de la coherencia de la cach: si una transaccin encuentra los datos en la cach, debe asegurarse de que esos datos estn al da, ya que despus de haber sido almacenados en la cach pueden haber sido modificados por otro cliente.

As, debe establecerse una comunicacin con el servidor para comprobar la validez de los datos y poder adquirir un bloqueo sobre ellos.

Cach de bloqueos Los bloqueos tambin pueden ser almacenados en la memoria cach del cliente si la utilizacin de los datos est prcticamente dividida entre los clientes, de manera que un cliente rara vez necesita datos que estn siendo utilizados por otros clientes. Supngase que se encuentran en la memoria cach tanto el elemento de datos que se busca como el bloqueo requerido para acceder al mismo. Entonces, el cliente puede acceder al elemento de datos sin necesidad de comunicar nada al servidor.

No obstante, el servidor debe seguir el rastro de los bloqueos en cach; si un cliente solicita un bloqueo al servidor, ste debe comunicar a todos los bloqueos sobre el elemento de datos que se encuentran en las memorias cach de otros clientes. La tarea se vuelve ms complicada cuando se tienen en cuenta los posibles fallos de la mquina. Esta tcnica se diferencia de la liberacin de bloqueos en que la cach de bloqueo se realiza a travs de transacciones; de otra forma, las dos tcnicas seran similares.

4. TIPOS DE ARQUITECTURAS CLIENTE/SERVIDOR.

4.1. Arquitectura de 2 capas La arquitectura cliente/servidor tradicional es una solucin de 2 capas. La arquitectura de 2 capas consta de tres componentes distribuidos en dos capas: cliente (solicitante de servicios) y servidor (proveedor de servicios). Los tres componentes son: - Interfaz de usuario. - Gestin del procesamiento. - Gestin de la base de datos.

Hay 2 tipos de arquitecturas cliente servidor de dos capas:

- Clientes obesos (thick clients): La mayor parte de la lgica de la aplicacin (gestin del procesamiento) reside junto a la lgica de la presentacin (interfaz de usuario) en el cliente, con la porcin de acceso a datos en el servidor. - Clientes delgados (thin clients): solo la lgica de la presentacin reside en el cliente, con el acceso a datos y la mayora de la lgica de la aplicacin en el servidor. Es posible que un servidor funcione como cliente de otro servidor. Esto es conocido como diseo de dos capas encadenado.

Limitaciones - El nmero usuarios mximo es de 100. Ms all de este nmero de usuarios se excede la capacidad de procesamiento. - No hay independencia entre la interfaz de usuario y los tratamientos, lo que hace delicada la evolucin de las aplicaciones. - Dificultad de relocalizar las capas de tratamiento consumidoras de clculo. - Reutilizacin delicada del programa desarrollado bajo esta arquitectura.

4.2. Arquitectura de 3 capas

La arquitectura de 3 capas surgi para superar las limitaciones de la arquitectura de 2 capas. La tercera capa (servidor intermedio) est entre el interfaz de usuario (cliente) y el gestor de datos (servidor). La capa intermedia proporciona gestin del procesamiento y en ella se ejecutan las reglas y lgica de procesamiento. Permite cientos de usuarios (en comparacin con slo 100 usuarios de la arquitectura de 2 capas). La arquitectura de 3 capas es usada cuando se necesita un diseo cliente/servidor que proporcione, en comparacin con la arquitectura de 2 capas, incrementar el rendimiento, flexibilidad, mantenibilidad, reusabilidad y escalabilidad mientras se esconde la complejidad del procesamiento distribuido al usuario.

Limitaciones Construir una arquitectura de 3 capas es una tarea complicada. Las herramientas de programacin que soportan el diseo de arquitecturas de 3 capas no proporcionan todos los servicios deseados que se necesitan para soportar un ambiente de computacin distribuida. Un problema potencial en el diseo de arquitecturas de 3 capas es que la separacin de la interfaz grfica de usuario, la lgica de gestin de procesamiento y la lgica de datos no es siempre obvia. Algunas lgicas de procesamiento de transacciones pueden aparecer en las 3 capas. La ubicacin de una funcin particular en una capa u otra debera basarse en criterios como los siguientes:

- Facilidad de desarrollo y comprobacin - Facilidad de administracin. - Escalabilidad de los servidores. - Funcionamiento (incluyendo procesamiento y carga de la red)

El middleware Como hemos visto, las capas estn localizadas en mquinas diferentes que estn conectadas a travs de la red. El middleware es el software que proporciona un conjunto de servicios que permite el acceso transparente a los recursos en una red. El middleware es un mdulo intermedio que acta como conductor entre dos mdulos de software. Para compartir datos, los dos mdulos de software no necesitan saber cmo comunicarse entre ellos, sino cmo comunicarse con el mdulo de middleware. Es el encargado del acceso a los datos: acepta las consultas y datos recuperados directamente de la aplicacin y los transmite por la red. Tambin es responsable de enviar de vuelta a la aplicacin, los datos de inters y de la generacin de cdigos de error.

DISEO DE BASE DE DATOS DISTRIBUIDAS

1. El problema de diseo
El problema de diseo de base de datos distribuidas se refiere, en general, a hacer decisiones acerca de la ubicacin de datos y programas a travs de los diferentes sitios de una red de computadoras. Este problema debera estar relacionado al diseo de la misma red de computadoras. Sin embargo, en este informe se tomara en cuenta nicamente el diseo de la base de datos. La decisin 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 El diseo de las bases de datos centralizadas contempla los dos puntos siguientes: Diseo del esquema conceptual el cual describe la base de datos integrada

 Diseo fsico de la base de datos, esto es, mapear el esquema conceptual a las reas de almacenamiento y determinar los mtodos de acceso a la base de datos En el caso de las bases de datos distribuidas se tienen que considerar los dos problemas siguientes: Diseo de la fragmentacin, esto se determina por la forma en que las relaciones globales se subdividen en fragmentos horizontales, verticales o mixtos Diseo de la asignacin de los fragmentos, esto se determina en la forma en que los fragmentos se mapean a las imgenes fsicas, en esta forma, tambin se determina la solicitud de fragmentos

2. Objetivos del diseo de la distribucin de los datos

En el diseo de la distribucin de los datos, se deben tomar en cuenta los siguientes objetivos: Procesamiento local. La distribucin 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 diseo de la distribucin de los datos para maximizar el procesamiento local agregando el numero de referencias locales y remotas que le corresponden a cada fragmentacin candidata y la localizacin del fragmento, que de esta forma se seleccione la mejor solucin de ellas Distribucin de la carga de trabajo. La Distribucin de la carga de trabajo sobre los sitios, es una caracterstica importante de los sistemas de cmputo distribuidos. Esta distribucin de la carga se realiza para tomar ventaja de las diferentes caractersticas (potenciales) o utilizaciones de las computadoras de cada sitio, y maximizar el grado de ejecucin de paralelismo de las aplicaciones. Sin embargo, la distribucin de la carga de trabajo podra afectar negativamente el procesamiento local deseado Costo de almacenamiento y disponibilidad. La distribucin 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 transmisin de las aplicaciones

3. Enfoques al problema de diseo de bases de datos distribuidas

Existen dos estrategias generales para abordar el problema de diseo de bases de datos distribuidas: El enfoque de arriba hacia abajo (top-down). Este enfoque es mas apropiado para aplicaciones nuevas y para sistemas homogneos. Consiste en partir desde el anlisis de requerimientos para definir el diseo 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 diseo de la fragmentacin de la base de datos, y de aqu se continua con la localizacin de los fragmentos en los sitios, creando las imgenes fsicas. Esta aproximacin se completa ejecutando, en cada sitio, el diseo fsico de los datos, qu e se localizan en este El diseo de abajo hacia arriba (botton-up). Se utiliza particularmente a partir de bases de datos existentes, generando con esto bases de datos distribuidas. En forma resumida, el diseo botton-up de una base de datos distribuida requiere de la seleccin de un modelo de bases de datos comn para describir el esquema global de la base de datos. Esto se debe a que es posible que se utilicen diferentes SMBD. Despus se hace la traduccin de cada esquema local en el modelo de datos comn y finalmente se hace integracin del esquema local en un esquema global comn

4. El problema de fragmentacin
El problema de fragmentacin se refiere al particionamiento de la informacin para distribuir cada parte a los diferentes sitios de la red. Inmediatamente aparece la siguiente pregunta: Cul es la unidad razonable de distribucin?. Se puede considerar que una relacin completa es lo adecuado ya que las vistas de usuario son subconjuntos de las relaciones. Sin embargo, el uso completo de relaciones no favorece las cuestiones de eficiencia sobre todo aquellas relacionadas con el procesamiento de consultas. La otra posibilidad es usar fragmentos de relaciones (sub-relaciones) lo cual favorece la ejecucin concurrente de varias transacciones que accesan porciones diferentes de una relacin. Sin embargo, el uso de sub-relaciones tambin presentan inconvenientes. Por ejemplo, las vistas de usuario que no se pueden definir sobre un solo fragmento necesitaran un procesamiento adicional a fin de localizar todos los fragmentos de una vista. Aunado a estos, el control semntico de datos es mucho mas complejo ya que, por

ejemplo, el manejo de llaves nicas requiere considerar todos los fragmentos e los que se distribuyen todos los registros de la relacin. En resumen, el objetivo de la fragmentacin es encontrar un nivel de particionamiento adecuado en el rango que va desde tuplas o atributos hasta relaciones completas.

Ejemplo de fragmentacin vertical

Alternativas sobre replicacin para el asignamiento de fragmentos

La replicacin de informacin es de utilidad para obtener un mejor rendimiento y para ofrecer un mayor grado de confiabilidad (tolerancia a fallas). La replicacin se complica cuando es necesario hacer actualizaciones a las copias mltiples de un dato. Por tanto, respecto a la replicacin, en el asignamiento de fragmentos se tienen tres estrategias: No soportar replicacin. Cada fragmento reside en un solo sitio Soportar replicacin completa. Cada fragmento en cada uno de los sitios Soportar replicacin parcial. Cada fragmento en alguno de los sitios Como regla general se debe considerar que la replicacin de fragmentos es de utilidad cuando el nmero de consultas de solo lectura es (mucho) mayor que el nmero de consultas para actualizaciones. Requerimientos de informacin Con el fin de realizar una fragmentacin adecuada es necesario proporcionar informacin que ayude a realizarla. Esta informacin normalmente debe ser proporcionada por el usuario y tiene que ver con cuatro tipos Informacin sobre el significado de los datos Informacin sobre las aplicaciones que los usan Informacin acerca de la red de comunicaciones Informacin acerca de los sistemas de computo

5. Tipos de fragmentacin de datos:

Existen tres tipos de fragmentacin: Fragmentacin horizontal Fragmentacin vertical Fragmentacin hibrida

Fragmentacin horizontal
La fragmentacin horizontal est relacionada a la particin a lo largo de las tuplas; as cada fragmento tiene un subconjunto de las tuplas de la relacin. Fragmentacin horizontal primaria: esta es llevada a cabo usando predicados que estn definidos en la relacin. Fragmentacin horizontal derivada: es la particin de las relaciones que resulta de predicados que han sido definidos en otras relaciones. Requerimientos de informacin de una fragmentacin horizontal Informacin acerca de la base de datos: Concierne a la informacin del esquema conceptual global de la base de datos, en este contexto es importante notar cmo estn conectadas las relaciones de la base de datos una con otra. Las conexiones entre los objetos de la base de datos en este caso llamadas relaciones deben ser absolutamente familiares para los que han manejado modelos de sistemas de bases de datos. La relacin al final de la conexin es llamada propietario de la conexin y la relacin que esta en la cabeza de la conexin es llamada miembro.

Fragmentacin vertical
La fragmentacin vertical produce fragmentos los cuales contienen un subconjunto de los atributos as como la clave principal de la relacin. El objetivo de este tipo de fragmentaciones es particionar una relacin en un conjunto de relaciones ms pequeas tal que otras de las aplicaciones de los usuarios corrern en solo un fragmento. El particionamiento vertical es inherentemente ms complicado que el horizontal ya que en el horizontal si el nmero total de predicados simples es n hay 2n posibles predicados minterms que pueden ser definidos en ellos. Sin embargo para la fragmentacin vertical si una relacin tiene m atributos que no sean claves primarias el nmero de posibles fragmentos es igual a B(m) el cual es el nmero de BELL. Existen dos tipos de enfoques heursticos para la fragmentacin vertical de relaciones globales:

 Agrupacin: comienza con la asignacin de cada atributo a un fragmento y en cada paso se unen algunos de los fragmentos hasta que los criterios se satisfagan. Particionamiento: comienza con una relacin y se decide realizar particionamientos benficos en base al comportamiento de acceso de las aplicaciones hacia los atributos. Requerimientos de informacin de una fragmentacin vertical. La informacin principal requerida por una fragmentacin vertical es la relacionada a las aplicaciones. Ya que el particionamiento vertical coloca en un fragmento aquellos atributos los cuales son accesados juntos. Los principales datos requeridos relacionados a las aplicaciones son sus frecuencias de acceso.

Fragmentacin hibrida
Respecto a la fragmentacin hibrida, esta consiste en aplicar la fragmentacin vertical seguida de la fragmentacin horizontal o viceversa En muchos casos la fragmentacin vertical u horizontal del esquema de la base de datos no ser suficiente para satisfacer los requisitos de las aplicaciones. Como ya se cit al comienzo de este documento podemos combinar ambas, utilizando por ello la denominada fragmentacin mixta. Cuando al proceso de fragmentacin vertical le sigue una horizontal, es

decir, se fragmentan horizontalmente los fragmentos verticales resultantes, se habla de la fragmentacin mixta HV. En el caso contrario, estaremos ante una fragmentacin VH. Una caracterstica comn a ambas es la generacin de rboles que representan la estructura de fragmentacin No se desea entrar en excesivos detalles sobre las reglas y condiciones para efectuar la fragmentacin mixta. Entre otras razones porque, tanto a la fragmentacin HV como la fragmentacin VH, se le pueden aplicar los mismos criterios y reglas que a la fragmentacin horizontal y vertical. Es decir, volviendo al ejemplo anterior, al cual le practicamos la fragmentacin HV, al realizar la fragmentacin horizontal tal como se ha expuesto, lo que se obtienen no son ms que subrelaciones, la unin de las cuales da lugar a la relacin PROVINC. Por tanto, para fragmentar cada subrelacin sera perfectamente viable aplicarle el mtodo de fragmentacin vertical que se ha desarrollado. Como, en este caso, se han querido generar dos fragmentos verticales por cada uno horizontal, simplemente deberamos confeccionar la matriz de grupos afines (a travs del algoritmo BEA) para cada fragmento horizontal y aplicarle, posteriormente, el algoritmo de fragmentacin binaria PARTICIN. Tambin debe tenerse en cuenta el nmero de niveles arbreos que se generen, es decir, nadie impide que tras realizar una fragmentacin VH, podamos aplicar a los fragmentos resultantes una nueva fragmentacin vertical, y a esto ltimo una nueva fragmentacin horizontal, etc. Dicho nmero puede ser grande, pero tambin ser ciertamente finito. En el caso horizontal, el nivel mximo de profundidad se alcanzar cuando cada fragmento albergue una nica tupla, mientras que en el caso vertical el final llegar cuando cada fragmento contenga un nico atributo. Sin embargo, aunque no deba tomarse como dogma, el nmero de niveles no debera superar el par (VH y HV). El porqu de esta afirmacin es bien sencillo, piense, por ejemplo, en el coste que supondra realizar la unin o el yunto de una relacin con fragmentacin nivel 7. Evidentemente, el coste sera muy elevado y ese aumento de rendimiento que se persigue al aplicar estas tcnicas, quizs, no se produzca. Antes de pasar a estudiar el problema de la asignacin se desea comentar la tcnica de fragmentacin mixta basada en celdas [2]. Esta tcnica se basa en la generacin de celdas de rejilla. Qu es una celda de rejilla, podramos definirla como un fragmento horizontal y vertical simultneo. La tcnica aplica un algoritmo de fragmentacin vertical y otro horizontal de manera concurrente sobre la relacin. Los algoritmos realizan una fragmentacin mxima, es decir, se persigue que en cada celda nicamente

haya un atributo y una tupla. Quiz el lector pueda encontrar el mtodo contradictorio con lo citado anteriormente respecto a la eficiencia, dada la gran cantidad de fragmentos generados, el nmero es, efectivamente, el mximo. Sin embargo, este slo es el primer paso del proceso. Una vez generadas las celdas se aplica un mtodo para optimizar la rejilla mediante fusin o desfragmentacin, de acuerdo, fundamentalmente, a las aplicaciones que acten sobre esos fragmentos. El mtodo, por tanto, persigue una fragmentacin lo ms especfica posible acorde con las aplicaciones y los sitios existentes en la red.

CONCLUSIONES:
A lo largo de este documento se ha intentado dar una visin global y genrica de los problemas y caractersticas que contiene el diseo de una base de datos distribuida. Se ha hecho especial hincapi en las tcnicas de fragmentacin horizontal y vertical a travs de mtodos y algoritmos muy frecuentes en la literatura referida al tema. Se espera que el lector no haya tenido demasiados problemas para su comprensin, las tcnicas son sencillas y se ha procurado incluir distintos ejemplos para facilitar el entendimiento. Igualmente, la puesta en prctica de los algoritmos, es decir, su codificacin, no es un proceso complicado si se poseen nociones en el desarrollo de algoritmos. Piense, por ejemplo, que los dos algoritmos de particin vertical presentados, no hacen ms que manipular matrices. Tambin debera tenerse presente la existencia de enfoques de fragmentacin distintos y, posiblemente, ms complejos, pero se debe pensar que ms eficientes. Sean, por ejemplo, las tcnicas de fragmentacin vertical basadas en grafos, como el algoritmo de Navathe y Ra que genera en un solo pas fragmentos verticales. Adems, estn apareciendo mtodos de fragmentacin mixta como el que se ha comentado. Si bien, estos mtodos son enfoques formales ms que prcticos, desarrollados por insignes investigadores en universidades, por tanto, lejos todava de su desarrollo comercial. Pese a la aparicin de los mtodos de bases de datos distribuidas hace ya aos, parece que el salto de lo centralizado a lo distribuido a escala comercial est por venir. Todava no se ha extendido suficientemente el esquema distribuido, pero se espera que prximamente se produzca el avance definitivo. Considere los dos componentes bsicos de los sistemas de bases de datos distribuidos (la propia base de datos y la red de ordenadores) y piense en la situacin actual de la informtica. Si las bases de datos es una de las ramas ms antiguas e importantes de la informtica, muchas empresas compran ordenadores para dedicarlos exclusivamente a la gestin de sus datos (pienso que, prcticamente, en el 100% de las PYMES se produce este hecho) y, como parece ser que se ha asumido por parte de todo tipo de empresarios los beneficios que acarrea la conexin de los ordenadores, la instalacin de una red, se puede concluir diciendo que el terreno ya est abonado para su extensin comercial. Slo falta que determinadas multinacionales decidan apostar ms fuerte por este enfoque a travs de sus famosos sistemas gestores de bases de datos y que se produzca la consolidacin de la resolucin de los problemas que el enfoque distribuido acarrea.

Bibliografa:
http://www.monografias.com/trabajos82/base-datos-distribuidas/base-datosdistribuidas.shtml http://www.youtube.com/watch?v=r_niGkgJfUc http://html.rincondelvago.com/bases-de-datos-distribuidas_1.html http://bdi2011bddistribuidas.blogspot.com/2011/10/caracteristicas-de-las-basesde-datos.html http://tododistribuido.files.wordpress.com/2008/10/disdabe_design.pdf cdigital.uv.mx/bitstream/123456789/28569/1/alejandra_zavala.pdf http://html.rincondelvago.com/bases-de-datos-distribuidas_1.html