Bases de datos cliente-servidorIntroduccion:La arquitectura cliente/servidor es un modelo para el desarrollo de sistemas de informacin, en el que las transacciones se dividen en procesos independientes que cooperan entre s para intercambiar informacin, servicios o recursos.Se denomina cliente al proceso que inicia el dilogo o solicita los recursos y servidor, al proceso que responde a las solicitudes. Es el modelo de interaccin ms comn entre aplicaciones en una red.Por otro lado los clientes suelen ser estaciones de trabajo que solicitan varios servicios al servidor. Ambas partes deben estar conectadas entre s mediante una red.Beneficios.1.- Mejor aprovechamiento de la potencia de cmputo (Reparte el trabajo).2. -Reduce el trfico en la Red. (Viajan requerimientos).3.- Opera bajo sistemas abiertos.4.- Permite el uso de interfaces grficas variadas y verstiles.Este tipo de arquitectura es la ms utilizada en la actualidad, debido a que es la ms avanzada y la que mejor ha evolucionado en estos ltimos aos.Podemos decir que esta arquitectura necesita tres tipos de software para su correcto funcionamiento:Software de gestin de datos: Este software se encarga de la manipulacin y gestin de los datos almacenados y requeridos por las diferentes aplicaciones. Normalmente este software se aloja en el servidor.Software de desarrollo: este tipo de software se aloja en los clientes y solo en aquellos que se dedique al desarrollo de aplicaciones.Software de interaccin con los usuarios: Tambin reside en los clientes y es la aplicacin grfica de usuario para la manipulacin de datos, siempre claro a nivel usuario (consultas principalmente).Los Clientes interactan con el usuario, usualmente en forma grfica. Frecuentemente se comunican con procesos auxiliares que se encargan de establecer conexin con el servidor, enviar el pedido, recibir la respuesta, manejar las fallas y realizar actividades de sincronizacin y de seguridad.Caractersticas: El Cliente oculta al Servidor y la Red. Detecta e intercepta peticiones de otras aplicaciones y puede re direccionarlas. Dedicado a la cesin del usuario (IniciaTermina). El mtodo ms comn por el que se solicitan los servicios es a travs de RPC (Remote Procedure Calls).Funciones comunes del cliente: Mantener y procesar todo el dialogo con el usuario. Manejo de pantallas. Mens e interpretacin de comandos. Entrada de datos y validacin. Procesamiento de ayudas. Recuperacin de errores. Generacin de consultas e informes sobre las bases de datos.El servidor:Conjunto de Hardware y Software que responde a los requerimientos de un cliente. Los Servidores proporcionan un servicio al cliente y devuelven los resultados.Normalmente el servidor es una mquina bastante potente que acta de depsito de datos y funciona como un sistema gestor de base de datos (SGBD).Tipos comunes de servidor:Servidor de Archivos (FTP, Novell). Servidor de Bases de Datos (SQL, CBASE, ORACLE, INFORMIX). Servidor de Comunicaciones Servidor de Impresin. Servidor de Terminal. Servidor de Aplicaciones (Windows NT, Novell).Funciones comunes del servidor: Acceso, almacenamiento y organizacin de datos. Actualizacin de datos almacenados. Administracin de recursos compartidos. Ejecucin de toda la lgica para procesar una transaccin.Procesamiento comn de elementos del servidor (Datos, capacidad de CPU, almacenamiento en disco, capacidad de impresin, manejo de memoria y comunicacin). Gestin de perifricos compartidos. Control de accesos concurrentes a bases de datos compartidas. Enlaces de comunicaciones con otras redes de rea local o extensa

Caractersticas principales de este tipo de arquitectura de cara a base de datos.Esta arquitectura se divide en dos partes claramente diferenciadas, la primera es la parte del servidor y la segunda la de un conjunto de clientes.

Normalmente el servidor es una mquina bastante potente que acta de depsito de datos y funciona como un sistema gestor de base de datos (SGBD).

Por otro lado los clientes suelen ser estaciones de trabajo que solicitan varios servicios al servidor.

Ambas partes deben estar conectadas entre s mediante una red.Una representacin grfica de este tipo de arquitectura sera la siguiente.

Este tipo de arquitectura es la ms utilizada en la actualidad, debido a que es la ms avanzada y la que mejor ha evolucionado en estos ltimos aos.

Podemos decir que esta arquitectura necesita tres tipos de software para su correcto funcionamiento: Software de gestin de datos: Este software se encarga de la manipulacin y gestin de los datos almacenados y requeridos por las diferentes aplicaciones. Normalmente este software se aloja en el servidor. Software de desarrollo: este tipo de software se aloja en los clientes y solo en aquellos que se dedique al desarrollo de aplicaciones. Software de interaccin con los usuarios: Tambin reside en los clientes y es la aplicacin grfica de usuario para la manipulacin de datos, siempre claro a nivel usuario (consultas principalmente).

En los SGBD que tienen laarquitecturade varios niveles es necesario ampliar el catlogo odiccionario, de modo que incluyainformacinsobre cmo establecer la correspondencia entre las peticiones de los usuarios y losdatos, entre los diversos niveles. El SGBD utiliza una serie deprocedimientosadicionales para realizar estas correspondencias haciendo referencia a la informacin de correspondencia que se encuentra en el catlogo. Laindependenciade datos se consigue porque al modificarse el esquema en algn nivel, el esquema del nivel inmediato superior permanece sin cambios, slo se modifica la correspondencia entre los dos niveles. No es preciso modificar losprogramasde aplicacin que hacen referencia al esquema del nivel superior.Por lo tanto, la arquitectura de tres niveles puede facilitar la obtencin de la verdadera independencia de datos, tantofsicacomolgica. Sin embargo, los dos niveles de correspondencia implican un gasto extra durante la ejecucin de una consulta o de unprograma, lo cual reduce laeficienciadel SGBD. Es por esto que muy pocos SGBD han implementado esta arquitectura completa.

Sistemacliente-servidorUnsistemadecomputacinque se compone de dos partes lgicas: unservidor, que proporcionaserviciosy un cliente, lo que les pide.Las dos partes se pueden ejecutar enmquinasseparadas enuna red, permitiendo a los usuarios acceso al servidor poderososrecursosde suscomputadoraspersonales Lossistemascliente-servidor no se limitan a los ordenadores tradicionales.Un ejemplo es un sistema automatizado decajeromquina (ATM).Losclientessuelen utilizar los cajeros automticos como clientes a la interfaz a un servidor que gestiona todas lascuentasde unbanco.Este servidor puede a su vez con losservidoresde otrosbancos(por ejemplo, al retirarel dineroen un banco en el que el usuario no tiene una cuenta).Los cajeros automticos proporcionan una interfaz de usuario y los servidores de prestacin de servicios, tales como la comprobacin de saldos de cuentas y transferirdineroentre cuentas.Para facilitar el acceso a servidores no se ejecutan en la misma mquina que el cliente,el middlewarese utiliza generalmente.Middleware sirve como la conexin enredentre los componentes de un sistema cliente-servidor, sino que se debe ejecutar en el cliente y el servidor. Se proporciona todo lo necesario para obtener una solicitud de un cliente a un servidor y recibir la respuesta del servidor al cliente.Middleware menudo facilita lacomunicacinentre los diferentes tipos de sistemas informticos.Esta comunicacin se hace la cruz-plataforma de computacin cliente-servidor y permite que muchos tipos de clientes para acceder a los mismos datos.La parte de servidor casi siempre contiene los datos y el cliente es casi siempre responsable de la interfaz de usuario.La lgica de la aplicacin, que determina cmo los datos debe ponerse en prctica, se pueden distribuir entre el cliente y el servidor.La parte de un sistema con una cantidad desproporcionadamente grande de la lgica de aplicacin que se llama "gordo", un "fino" parte de un sistema es una parte con menos responsabilidadque le sean delegadas. servidor de los sistemas de grasa, tales comotrabajoengrupode sistemas y servidoresweb, delegar ms responsabilidad por la lgica de la aplicacin en el servidor, mientras que los sistemas cliente de grasa, como la mayora de sistemas de bases de datos, el lugar ms responsabilidad en el cliente.Elmodelocannico del servidor de cliente asume dos participantes en el sistema.Esto se llama un sistema de dos niveles, la lgica de la aplicacin debe estar en el cliente o el servidor, o compartida entre los dos.Tambin es posible tener la lgica de la aplicacin reside en una tercera capa separada de la interfaz de usuario y los datos, convirtiendo el sistema en un sistema de tres niveles.La separacin total es poco comn en los sistemas reales, por lo general la mayor parte de la lgica de la aplicacin es en el nivel intermedio, pero porciones selectas de la misma, son responsabilidad del cliente o el servidor.El modelo de tres niveles es ms flexible que el modelo de dos niveles debido a la separacin de la lgica de la aplicacin desde el cliente y el servidor da lgica de la aplicacin procesa un nuevo nivel de autonoma.Losprocesosse hacen ms slidas, ya que pueden funcionar independientemente de los clientes y servidores.Por otra parte, la disociacin de la lgica de la aplicacin de los datos permite que los datos de mltiplesfuentespara su uso en una sola transaccin sin una ruptura en el modelo cliente-servidor.Este avance en la arquitectura cliente-servidor es responsable en gran medida elconceptode datos distribuidos.Norma aplicaciones web son los ejemplos ms comunes de los sistemas de tres niveles.El primer nivel es la interfaz de usuario, siempre a travs de lainterpretacinde Hyper Text Markup Language (HTML) mediante un navegador web.Los componentes integrados que semuestraen el navegador residen en el nivel intermedio, y proporcionar la lgica de la aplicacin correspondienteal sistema.El ltimo nivel est los datos de un servidor web.Muy a menudo se trata de un sistema debase de datosde estilo, pero podra ser una dealmacnde depsito o groupware sistema de datos.3.- Arquitectura Cliente/Servidor Caractersticas funcionales Caractersticasfsicas Caractersticas lgicas Ventajas einconvenientes Fases deimplantacin Criterios deutilizacinCon la proliferacin de ordenadores personales de bajo coste en elmercado, los recursos de sistemas de informacin existentes en cualquierorganizacinse pueden distribuir entre ordenadores de diferentes tipos: ordenadores personales de gama baja, media y alta, estaciones de trabajo, miniordenadores o incluso grandes ordenadores.El concepto decliente/servidorproporciona una forma eficiente de utilizar todos estos recursos de mquina de tal forma que laseguridady fiabilidad que proporcionan los entornosmainframese traspasa a la red de rea local. A esto hay que aadir la ventaja de lapotenciay simplicidad de los ordenadores personales.La arquitecturacliente/servidores un modelo para eldesarrollodesistemas de informacinen el que las transacciones se dividen en procesos independientes que cooperan entre s para intercambiar informacin, servicios o recursos. Se denomina cliente alprocesoque inicia eldilogoo solicita los recursos y servidor al proceso que responde a las solicitudes.En este modelo las aplicaciones se dividen de forma que el servidor contiene la parte que debe ser compartida por varios usuarios, y en el cliente permanece slo lo particular de cada usuario.Los clientes realizan generalmentefuncionescomo: Manejo de la interfaz de usuario. Captura y validacin de los datos de entrada. Generacin de consultas einformessobre lasbases de datos. Por su parte los servidores realizan, entre otras, las siguientes funciones: Gestin deperifricoscompartidos. Control de accesos concurrentes a bases de datos compartidas. Enlaces decomunicacionescon otrasredesde rea local o extensa.Siempre que un cliente requiere unserviciolo solicita al servidor correspondiente y ste le responde proporcionndolo. Normalmente, pero no necesariamente, el cliente y el servidor estn ubicados en distintosprocesadores. Los clientes se suelen situar en ordenadores personales y/o estaciones de trabajo y los servidores en procesadores departamentales o de grupo.Entre las principales caractersticas de la arquitecturacliente/servidorse pueden destacar las siguientes: 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 ningncambioen el cliente.3.1.- Caractersticas funcionalesEsta arquitectura se puede clasificar en cinco niveles, segn las funciones que asumen el cliente y el servidor, tal y como se puede ver en el siguientediagrama:

En el primer nivel el cliente asume parte de las funciones de presentacin de la aplicacin, ya que siguen existiendo programas en el servidor dedicados a esta tarea. Dichadistribucinse realiza mediante el uso deproductospara el "maquillaje" de las pantallas del mainframe. Esta tcnica no exige el cambio en las aplicaciones orientadas a terminales, pero dificulta sumantenimiento. Adems, el servidor ejecuta todos los procesos y almacena la totalidad de los datos. En este caso se dice que hay una presentacin distribuida o embellecimiento.En el segundo nivel la aplicacin est soportada directamente por el servidor, excepto la presentacin que es totalmente remota y reside en el cliente. Los terminales del cliente soportan la captura de datos, incluyendo una validacin parcial de los mismos y una presentacin de las consultas. En este caso se dice que hay una presentacin remota.En el tercer nivel la lgica de los procesos se divide entre los distintos componentes del cliente y del servidor. El diseador de la aplicacin debe definir los servicios y las interfaces del sistema de informacin de forma que los papeles de cliente y servidor sean intercambiables, excepto en elcontrolde los datos que es responsabilidad exclusiva del servidor. En este tipo de situaciones se dice que hay un proceso distribuido o cooperativo.En el cuarto nivel el cliente realiza tanto las funciones de presentacin como los procesos. Por su parte, el servidor almacena y gestiona los datos que permanecen en una base de datos centralizada. En esta situacin se dice que hay unagestinde datos remota.En el quinto y ltimo nivel, el reparto de tareas es como en el anterior y adems el gestor de base de datos divide sus componentes entre el cliente y el servidor. Las interfaces entre ambos estn dentro de las funciones del gestor de datos y, por lo tanto, no tienen impacto en el desarrollo de las aplicaciones. En este nivel se da lo que se conoce como bases de datos distribuidas.3.2.- Caractersticas fsicasEl diagrama del punto anterior da una idea de laestructurafsica de conexin entre las distintas partes que componen una arquitectura cliente / servidor. La idea principal consiste en aprovechar la potencia de los ordenadores personales para realizar sobre todo los servicios de presentacin y, segn el nivel, algunos procesos o incluso algn acceso a datos locales. De esta forma se descarga al servidor de ciertas tareas para que pueda realizar otras ms rpidamente.Tambin existe una plataforma de servidores que sustituye al ordenador central tradicional y que da servicio a los clientes autorizados. Incluso a veces el antiguo ordenador central se integra en dicha plataforma como un servidor ms. Estos servidores suelen estar especializados por funciones (seguridad,clculo, bases de datos, comunicaciones, etc.), aunque, dependiendo de las dimensiones de la instalacin se pueden reunir en un servidor una o varias de estas funciones.

Lasunidades de almacenamientomasivo en esta arquitectura se caracterizan por incorporar elementos de proteccin que evitan la prdida de datos y permiten multitud de accesos simultneos (altavelocidad, niveles RAID, etc.).Parala comunicacinde todos estos elementos se emplea un sistema de red que se encarga de transmitir la informacin entre clientes y servidores. Fsicamente consiste en un cableado (coaxial, par trenzado,fibra ptica, etc.) o en conexiones mediantesealesderadioo infrarrojas, dependiendo de que la red sea local (RAL), metropolitana (MAN) o de rea extensa (WAN).Para la comunicacin de los procesos con la red se emplea un tipo de equipo lgico denominadomiddlewareque controla las conversaciones. Sufuncines independizar ambos procesos (cliente y servidor). La interfaz que presenta es la estndar de los servicios de red que hace que los procesos "piensen" en todo momento que se estn comunicando con una red.3.3.- Caractersticas lgicasUna de las principales aportaciones de esta arquitectura a los sistemas de informacin es la interfaz grfica de usuario. Gracias a ella se dispone de un manejo ms fcil e intuitivo de las aplicaciones mediante el uso de un dispositivo tipo ratn. En esta arquitectura los datos se presentan, editan y validan en la parte de la aplicacin cliente.En cuanto a los datos, cabe sealar que en la arquitecturacliente/servidorse evitan las duplicidades (copias y comparaciones de datos), teniendo siempre unaimagennica y correcta de los mismos disponible en lnea para su uso inmediato.Todo esto tiene como fin que el usuario de un sistema de informacin soportado por una arquitecturacliente/servidortrabaje desde su estacin de trabajo con distintos datos y aplicaciones, sin importarle dnde estn o dnde se ejecuta cada uno de ellos.3.4.- Ventajas e inconvenientesVentajas Aumento de laproductividad: Los usuarios pueden utilizarherramientasque le son familiares, comohojas de clculoy herramientas de acceso a bases de datos. Mediante laintegracinde las aplicacionescliente/servidorcon las aplicaciones personales de uso habitual, los usuarios pueden construirsolucionesparticularizadas que se ajusten a sus necesidades cambiantes. Una interfaz grfica de usuario consistente reduce eltiempodeaprendizajede las aplicaciones. Menores costes de operacin: Permiten un mejor aprovechamiento de los sistemas existentes, protegiendo lainversin. Por ejemplo, la comparticin de servidores (habitualmente caros) ydispositivos perifricos(comoimpresoras) entre mquinas clientes permite un mejor rendimiento del conjunto. Proporcionan un mejor acceso a los datos. La interfaz de usuario ofrece una forma homognea de ver el sistema, independientemente de los cambios o actualizaciones que se produzcan en l y de la ubicacin de la informacin. Elmovimientode funciones desde un ordenador central hacia servidores o clientes locales origina el desplazamiento de los costes de ese proceso hacia mquinas ms pequeas y por tanto, ms baratas. Mejora en el rendimiento de la red: Las arquitecturascliente/servidoreliminan la necesidad de mover grandes bloques de informacin por la red hacia los ordenadores personales o estaciones de trabajo para su proceso. Los servidores controlan los datos, procesan peticiones y despus transfieren slo los datos requeridos a la mquina cliente. Entonces, la mquina cliente presenta los datos al usuario mediante interfaces amigables. Todo esto reduce el trfico de la red, lo que facilita que pueda soportar un mayor nmero de usuarios. Tanto el cliente como el servidor pueden escalarse para ajustarse a las necesidades de las aplicaciones. Las UCPs utilizadas en los respectivos equipos pueden dimensionarse a partir de las aplicaciones y el tiempo de respuesta que se requiera. La existencia de varias UCPs proporciona una red ms fiable: un fallo en uno de los equipos no significa necesariamente que el sistema deje de funcionar. En una arquitectura como sta, los clientes y los servidores son independientes los unos de los otros con lo que pueden renovarse para aumentar sus funciones y capacidad de forma independiente, sin afectar al resto del sistema. La arquitectura modular de los sistemascliente/servidorpermite el uso de ordenadores especializados (servidores de base de datos, servidores de ficheros, estaciones de trabajo paraCAD, etc.). Permite centralizar el control de sistemas que estaban descentralizados, como por ejemplo la gestin de los ordenadores personales que antes estuvieran aislados.Inconvenientes Hay una alta complejidad tecnolgica al tener que integrar una gran variedad de productos. Requiere un fuerte rediseo de todos los elementos involucrados en los sistemas de informacin (modelosde datos, procesos, interfaces, comunicaciones,almacenamientode datos, etc.). Adems, en la actualidad existen pocas herramientas que ayuden a determinar la mejor forma de dividir las aplicaciones entre la parte cliente y la parte servidor. Es ms difcil asegurar un elevado grado de seguridad en una red de clientes y servidores que en un sistema con un nico ordenador centralizado. A veces, losproblemasde congestin de la red pueden degradar el rendimiento del sistema por debajo de lo que se obtendra con una nica mquina (arquitectura centralizada). Tambin la interfaz grfica de usuario puede a veces ralentizar el funcionamiento de la aplicacin. El quinto nivel de esta arquitectura (bases de datos distribuidas) es tcnicamente muy complejo y en la actualidad hay muy pocas implantaciones que garanticen un funcionamiento totalmente eficiente.3.5.- Fases de implantacinUna arquitecturacliente/servidordebe mostrar los sistemas de informacin no como un cliente que accede a un servidor corporativo, sino como un entorno que ofrece acceso a una coleccin de servicios. Para llegar a esteestadopueden distinguirse las siguientes fases deevolucindel sistema: Fase de IniciacinEsta etapa se centra sobre todo en la distribucin fsica de los componentes entre plataformas. Los dos tipos de plataforma son: Una plataforma cliente para la presentacin (generalmente un ordenadorpersonalde sobremesa). Una plataforma servidora (como por ejemplo el servidor de una base de datos relacional) para la ejecucin de procesos y la gestin de los datos.Un ejemplo sera el de una herramienta de consulta que reside en un ordenador personal a modo de cliente y que genera peticiones de datos que van a travs de la red hasta el servidor de base de datos. Estas peticiones se procesan, dando como resultado un conjunto de datos que se devuelven al cliente.En esta fase pueden surgir los siguientes problemas: Cmo repartir la lgica de la aplicacin entre las plataformas cliente y servidor de la forma ms conveniente. Cmo gestionar la arquitectura para que permita que cualquier cliente se conecte con cualquier servidor. Fase de ProliferacinLa segunda etapa de una arquitecturacliente/servidorse caracteriza por la proliferacin de plataformas clientes y servidoras. Ahora, el entorno para lainteraccinentre clientes y servidores se hace mucho ms complejo. Puede hacerse una distincin entre: Datos de servidores a los que se accede a travs de una red de rea extensa (WAN) y Datos a los que se accede a travs de una red de rea local (RAL).Los mecanismos de conexin son muy variados y suelen ser incompatibles.En esta fase los problemas que se pueden plantear son: La gestin de accesos se convierte encrticay compleja debido a la estructura del organismo donde se est implantando la arquitectura. El mercado ofrece algunas soluciones que mejoran la interoperabilidad y que se basan en conexiones modulares que utilizan entre otros: Driversen la parte cliente Pasarelas (gateways) a bases de datos Especificaciones deprotocoloscliente/servidor, etc. Los requisitos de actualizacin de datos pasan a formar parte de los requisitos solicitados al sistemacliente/servidor. Ahora no slo se consultan datos, sino que se envan peticiones para actualizar, insertar y borrar datos. Fase de ControlEn esta fase se consolidan los caminos de acceso desde una plataforma cliente particular a una plataforma servidora particular.Los conceptos en los que se debe poner especial nfasis son los siguientes: Transparencia en la localizacin. Significa que la aplicacin cliente no necesita saber nada acerca de la localizacin (fsica o lgica) de los datos o los procesos. La localizacin de los recursos debe estar gestionada por servidores y estar representada en las plataformas adecuadas de forma que se facilite su uso por parte de las plataformas cliente. Gestin de copias. El sistema se debe configurar de forma que se permita copiar la informacin (datos o procesos) de los servidores. Especializacin de los equipos servidores en servidores de bases de datos o en servidores de aplicaciones. Los servidores de bases de datos continan ofreciendo servicios orientados a datos a travs de llamadasSQLo a travs de procedimientos almacenados. En cualquier caso, los servicios se orientan a mantener la integridad de los datos. Por otro lado, los servidores de aplicaciones se centran en los procesos implementando partes de la lgica de la aplicacin en la parte servidora. Fase de IntegracinEsta etapa se caracteriza por el papel conjunto que juegan la gestin de accesos, la gestin de copias y la gestin de recursos. La gestin de la informacin se debe realizar de forma que se pueda entregar la informacin controlada por los servidores que contienen los datos a las plataformas clientes que los requieran. El concepto en que se basa este tipo de gestin es la distincin entre dostipos de datos: datos de operacin y datos de informacin. Para ajustarse a los posibles cambios en los procesos, los datos de operacin varan continuamente mientras que los datos de informacin son invariables porque son denaturalezahistrica y se obtienen tomando muestras en el tiempo de los datos de operacin. Fase de MadurezEsta es la etapa final de una arquitecturacliente/servidor. Se caracteriza por una visin ms flexible de las plataformas fsicas del sistema que se contemplan como una nica unidad lgica. Este estado tambin se caracteriza porque latecnologacliente/servidor se ha generalizado enla empresa. Ya no es un problema saber qu componentes se distribuyen en qu plataformas, porque los recursos se pueden redistribuir para equilibrar la carga de trabajo y para compartir los recursos de informacin. Lo fundamental aqu es saber quin ofrece qu servicios. Para ello es necesario distinguir qu tipo de servicios y recursos se demandan y conocer las caractersticas de esta arquitectura basada en servicios.En la fase de integracin veamos que se estableca una distincin entre datos de operacin y datos de informacin histrica. Por contra, en un entorno de operacin cliente/servidor que se encuentre en la fase de madurez, lo interesante es distinguir entre dos nuevos trminos: organismo y grupo de trabajo. Esta distincin se establece basndose en sus diferencias organizativas. El grupo de trabajo es el entorno en el quegrupos organizados de personas se centran en tareas especficas de la actividad del organismo al que pertenecen. Estos equipos de personas requieren una informacin propia y unas reglas de trabajo particulares, que pueden ser diferentes de las del organismo en su globalidad.Una arquitectura basada en servicios es la que se contempla como una coleccin de consumidores de servicios poco relacionados entre s y los productores de dichos servicios. La utilizacin de este tipo de arquitectura permite pensar en nuevos retos dediseo: Desarrollo de componentes reutilizables entre distintas aplicaciones y distintos grupos de trabajo Desarrollo de aplicaciones distribuidas Gestin del desarrollo de aplicaciones entre distintos equipos, etc.3.6.- Criterios de utilizacinEl mercado de los sistemascliente/servidorest marcando nuevos caminos porque: La informacin puede ahora residir en redes de ordenadores personales. Los usuarios pueden tener un mayor acceso a los datos y a la capacidad de proceso.Elmarketingtambin juega un papel importante. Muchos sistemas que se denominancliente/servidoren realidad distan bastante de serlo y muchas aplicaciones aseguran ser tan fiables como sus homlogas en elhost.En realidad, el cambio hacia tecnologas cliente/servidor est an en sus comienzos, pero de ninguna manera debe ignorarse.La forma de asegurar la futura utilizacin productiva de sistemas cliente/servidor, asumiendo un bajoriesgo, debe considerar: Comenzar por eldownsizing: utilizar redes de rea local y familiarizar a los usuarios con el uso de ordenadores personales. Estudiar las herramientas cliente/servidor que se encuentren disponibles y aquellas que se encuentren en fase de desarrollo; la mayora estn basadas en algn sistema de gestin de base de datos en red local. Permitir el acceso de los usuarios a los datos de la organizacin conectando las redes locales entre s. Aadir interfaces de usuario amigables al equipo lgico del ordenador central y desarrollar prototipos.Una organizacin tiene que decidir cundo y cmo debe migrar en su caso, hacia un entorno cliente/servidor, teniendo en cuenta la evolucin de las herramientas cliente/servidor y desarrollando unaestrategiaque se base en los estndares predominantes en el mercado.Sistemas paralelosLa mayor parte de los sistemas hasta ahora han sido sistemas monoprocesador; es decir han tenido una solaCPU. Sin embargo, la tendencia actual es hacia los sistemas multiprocesador. Tales sistemas tienen ms de unprocesadoren comunicacin ntima, los cuales comparten elbusdelcomputador, el reloj y a vecesla memoriay los dispositivos perifricos. Decimos que estos sistemas estn fuertemente acoplados.Hay varias razones para construir este tipo de sistemas. Una ventaja es el aumento en el rendimiento. Al incrementar el nmero de procesadores, esperamos realizar ms trabajo en un tiempo ms corto. Sin embargo, la proporcin de aumento de la velocidad con n procesadores no es n, sino ms bien menor que n. Cuando varios procesadores cooperan para llevar a cabo una tarea, se incurre en cierto "gasto extra" para mantener todos los componentes funcionando correctamente. Este gasto extra, aunado a la contencin por 105 recursos compartidos, reduce la ganancia que cabra esperar de los procesadores adicionales. De forma anloga, un grupo de n programadores que trabajan en ntima colaboracin no produce n veces la cantidad de trabajo que realiza uno solo.Los multiprocesadores tambin pueden ahorrar dinero en comparacin con varios sistemas monoprocesador porque los procesadores pueden compartir perifricos, gabinetes y fuentes de potencia. Si varios programas deben operar con el mismo conjunto de datos, es ms econmico guardar esos datos en un disco y hacer que todos los procesadores los compartan, en vez de tener muchos computadores con discos locales y hacer copias de los datos.Otra razn para tener sistemas multiprocesador es que mejoran la confiabilidad. Si es posible distribuir las funciones correctamente entre varios procesadores, el fa-lo de un procesador no detendr el sistema, slo lo har ms lento. Si tenemos 10 procesadores y uno falla, cada uno de los nueve procesadores restantes deber asumir una porcin del trabajo del que fall. As el sistema operar al 90% de su velocidad normal, en lugar de pararse. Esta capacidad para seguir dando un servicio proporcional al nivel dehardwareque sobrevive se denomina degradacin gradual. Los sistemas diseados para degradarse gradualmente tambin se conocen como tolerantes a fallos ault-tolerant).El funcionamiento continuado en presencia de ellos requiere un mecanismo para detectar, diagnosticar y corregir (si es posible) el fallo. FI sistema Tandem utiliza duplicacin tanto de hardware como desoftwarepara asegurar una operacin continuada a pesar de los fallos. El sistema consiste en dos procesadores idnticos, cada uno con su propiamemorialocal. Los procesadores se conectan con un bus. Un procesador es el primario, y el otro es el de ?espalda. Se mantienen dos copias de cada proceso; una en la mquina primaria y otra en el respaldo. En puntos de verificacin (checkpoints) fijos durante la ejecucin del sistema, la informacin de estado de cada trabajo (incluida una copia de la imagen de memoria> se copia de la mquina primaria a la de respaldo. Si se detecta un fallo, se activa la copia de respaldo, y se reinicia a partir del punto de verificacin ms reciente. Esta solucin obviamente es costosa, ya que hay mucha duplicacin de hardware.Los sistemas de mltiple procesador ms comunes en la actualidad siguen el modelo de multiprocesamiento simtrico, en el que cada procesador ejecuta una copia idntica delsistema operativo, y estas copias se comunican entre s cuando es necesario. Algunos sistemas utilizan multiprocesamiento asimtrico, en el que a cada procesador se asigna una tarea especfica. Un procesador maestro controla el sistema; los dems procesadores obtienen sus instrucciones del maestro o bien tienen tareas predefinidas. Este esquema define una relacin maestro-esclavo. El procesador maestro planifica y asigna trabajo a los procesadores esclavos.Un ejemplo de sistema con multiprocesamiento simtrico es la versin Encore deUNIXpara el computador Multimax. Este computador puede configurarse de modo que utilice docenas de procesadores, todos los cuales ejecutan una copia de UNIX. La ventaja de este modelo es que muchos procesos pueden ejecutarse simultneamente (N procesos si hay N CPU) sin que haya deterioro deldesempeo. Sin embargo, es preciso controlar cuidadosamente la E! 5 para asegurar que los datos lleguen al procesador apropiado. Adems, dado que las CPU son independientes, una podra estar ociosa mientras otra est sobrecargada, con la consiguiente ineficiencia. A fin de evitar esto, los procesadores pueden compartir ciertasestructurasde datos. Un sistema multiprocesador de este tipo permite compartir dinmicamente trabajos y recursos entre los distintos procesadores, y puede reducir la varianza entre los sistemas. Por otro lado, tales sistemas deben escribirse con mucha cuida-do, como veremos en el captulo 6.El multiprocesamiento asimtrico es ms comn en los sistemas extremadamente grandes, donde una de las actividades que ms tiempo consume es el procesamiento de El 5. En los sistemas por lotes ms antiguos, se utilizaban procesadores pequeos, situados a cierta distancia de la CPU principal7 para operar los lectores detarjetase impresoras de lneas y transferir estos trabajos a y del computador principal. Estos puntos se denominan sitios de entrada remota de trabajos (RJE, remote-Job-entry). En un sistema de tiempo compartido, una de las principales actividades de El 5 es procesar la El 5 de caracteres entre las terminales y el computador Si es preciso interrumpir la CPU principal cada vez que se transfiere uncarctera o de una terminal, la CPU Podra pasar todo su tiempo procesando caracteres. Para evitar esta situacin, la mayor parte de los sistemas cuenta con un procesador de extremo frontal front-end) aparte que se encarga de toda la El 5 de terminales. Por ejemplo, un sistema IBM grande Podra usar un minicomputador IBM Series! 1 como front-end. El front-end acta como buffer entre las terminales y la CPU principal, y permite a esta ltima manejar lneas y Moques de caracteres, en lugar de caracteres individuales. La confiabilidad de tales sistemas se reduce a causa de su mayor especializacin.Es importante darse cuenta de que la diferencia entre multiprocesamiento simtrico y asimtrico puede deberse al hardware o al software. Podra existir hardware especial para diferenciar los mltiples procesadores, o podra escribirse software que permita un solo maestro y varios esclavos. Por ejemplo, el sistema operativo de Sun, SunOS versin 4, ofrece multiprocesamiento asimtrico, mientras que la versin 5 (Solaris 2) es simtrica.A medida que baja elprecioy aumenta la potencia de losmicroprocesadores, ms y ms funciones del sistema operativo se delegan a procesadores esclavos, tambin llamados back-ends o procesadores de servicio. Por ejemplo, es fcil aadir un procesador con su propia memoria para administrar un sistema de disco. ElmicroprocesadorPodra recibir una secuencia de solicitudes de la CPU principal e implementar su propia cola de disco yalgoritmodeplanificacin. Esta organizacin evita a la CPU principalel trabajoextra que implica la planificacin de disco. Los PC contienen un microprocesador en eltecladoque convierte las digitaciones en cdigos que se envan a la CPU. De hecho, este uso de los microprocesadores se ha vuelto tan comn que ya no se considera como multiprocesamiento.Sistemas distribuidos Concepto, caractersticas y factores que han afectado un Sistema Distribuido. Ventajas y Desventajas de Sistemas Distribuidos. Categoras de los Sistemas Distribuidos. Sistema Operativo Distribuido y sus caractersticas. Complejidad y aspectos que intervienen en el diseo de un Sistema Operativo Distribuido. Modelo deConstruccin.Concepto de Sistemas Distribuidos. Es un concepto poco claro de definir. Coleccin de elementos de cmputo autnomo que se encuentran fsicamente separados y no comparten una memoria comn, se comunican entre s a travs del intercambio de mensajes utilizando un medio de comunicacin.Los sistemas autnomos pueden tener caractersticas no homogneas.Caractersticas de los Sistemas Distribuidos. Cada elemento de cmputo tiene su propia memoria y su propio Sistema Operativo. Control de recursos locales y remotos. Sistemas Abiertos (Facilidades de cambio y crecimiento). Plataforma no standard (Unix, NT, Intel, RISC, Etc.). Medios de comunicacin(Redes, Protocolos, Dispositivos, Etc.). Capacidad de Procesamiento en paralelo. Dispersin y parcialidad.Factores que han afectado el desarrollo de los Sistemas Distribuidos. Avances Tecnolgicos. Nuevos requerimientos. Globalizacin Aspectos Externos (Culturales, Polticos, Econmicos). Integracin.

Ventajas y Desventajas de los Sistemas DistribuidosVentajas:Procesadores ms poderosos y a menos costos Desarrollo de Estaciones con ms capacidades Las estaciones satisfacen las necesidades de los usuarios. Uso de nuevas interfaces.Avances en la Tecnologa de Comunicaciones. Disponibilidad de elementos de Comunicacin. Desarrollo de nuevastcnicas.Comparticin de Recursos. Dispositivos (Hardware). Programas (Software).Eficiencia y Flexibilidad. Respuesta Rpida. Ejecucin Concurrente de procesos (En varias computadoras). Empleo de tcnicas de procesamiento distribuido.Disponibilidad y Confiabilidad. Sistema poco propenso a fallas (Si un componente no afecta a la disponibilidad del sistema). Mayores servicios que elevan la funcionalidad (Monitoreo, Telecontrol, Correo Elctrico, Etc.).Crecimiento Modular. Es inherente al crecimiento. Inclusin rpida de nuevos recursos. Los recursos actuales no afectan.Desventajas: Requerimientos de mayores controles de procesamiento. Velocidad de propagacin de informacin (Muy lenta a veces). Servicios de replicacin de datos y servicios con posibilidades de fallas. Mayores controles de acceso y proceso ( Commit ). Administracinms compleja. Costos.Categoras de los sistemas Distribuidos.Modelo de Minicomputadoras.Varias computadoras que soportan diferentes usuarios cada una y provee acceso a recursos remotos.

Por lo menos un usuario por cadacomputadora( CPU < Usuarios ).Modelo de Estacin de Trabajo.Varias estaciones (Por lo general cientos), donde cada usuario cuenta con una estacin de trabajo (ET) y realiza en ella todo su trabajo. Requiere de un Sistema Operativo que soporte funciones de acceso y control remoto. Un microprocesador por cada usuario ( CPU = Usuarios). Las estaciones de trabajo cuentan con InterfacesGrficas, CPU potentes yMemoriaspropias.

Modelo microprocesadores en Pooling.Trata de utilizar uno o ms microprocesadores dependiendo de las necesidades de los usuarios.Primero los procesadores completan su tarea y posteriormente regresan a esperar una nueva asignacin. El nmero de microprocesadores normalmente es mayor a uno por usuario (CPU > Usuarios).

Sistema Operativo DistribuidoExtiende elconcepto de administracinde recursos e interfaces con el usuario hacia computadoras de memoria compartida para formar un sistema Operativo Distribuido, el cual consiste en varias computadoras autnomas conectadas por una red de comunicaciones.Caractersticas: Para cada uno de los usuarios debe de ser similar al trabajo en el Sistema Centralizado. Se ejecuta en mltiples Computadoras. Tiene varias copias del mismo Sistema Operativo o de diferentesSistemas Operativosque proveen los mismos servicios. Transparencia (El uso de mltiples procesadores y el acceso remoto debe de ser invisible)

Modelo de Construccin.Cliente/Servidor

Arquitectura Cliente/Servidor:Una arquitectura es un conjunto de reglas, definiciones, trminos y modelos que se emplean para producir unproducto.La arquitectura Cliente/Servidor agrupaconjuntosde elementos que efectan procesos distribuidos y computo cooperativo.

Beneficios: Mejor aprovechamiento de la potencia de cmputo (Reparte el trabajo). Reduce el trfico en la Red. (Viajan requerimientos). Opera bajo sistemas abiertos. Permite el uso de interfaces grficas variadas y verstiles.Segmentacin de Aplicaciones:

Qu es el Cliente?Conjunto de Software y Hardware que invoca los servicios de uno o varios servidores.Caractersticas: El Cliente oculta al Servidor y la Red. Detecta e intercepta peticiones de otras aplicaciones y puede re direccionarlas. Dedicado a la cesin del usuario (Inicia...Termina). Elmtodoms comn por el que se solicitan los servicios es a travs de RPC (Remote Procedure Calls).Funciones Comunes del Cliente: Mantener y procesar todo eldialogocon el usuario. Manejo de pantallas. Mens e interpretacin decomandos. Entrada de datos y validacin. Procesamiento de ayudas. Recuperacin de errores. Qu es el Servidor?Conjunto de Hardware y Software que responde a los requerimientos de un cliente.Tipos Comunes de Servidores: Servidor deArchivos(FTP,Novell). Servidor de Bases de Datos (SQL, CBASE,ORACLE, INFORMIX). Servidor de Comunicaciones Servidor de Impresin. Servidor de Terminal. Servidor de Aplicaciones (Windows NT, Novell).Funciones Comunes del Servidor: Acceso, almacenamiento y organizacin de datos. Actualizacin de datos almacenados. Administracin de recursos compartidos. Ejecucin de toda la lgica para procesar una transaccin. Procesamiento comn de elementos del servidor (Datos, capacidad de CPU, almacenamiento en disco, capacidad de impresin, manejo de memoria y comunicacin).Red de comunicacin.Es todo aquel conjunto de elementos basados en hardware y software que permite establecer un enlace entre los clientes y los servidores, se clasifican por su tamaoLAN, MAN y WAN.Caractersticas de la comunicacin: A travs de este medio, el cliente debe localizar e iniciar la comunicacin con el servidor. No se utiliza lametodologade comparticin de archivos, ya que todos los accesos a la informacin se llevan a cabo a travs de peticiones por medio de comunicacin. Debido a que los programas de manejo y control de informacin (Archivos y bases de datos solo se envan y reciben los resultados de lasoperaciones(Trfico igual a Datos ledos o escritos). Debido a la flexibilidad de establecer sesiones con mltiples servidores y manejo de informacin en varias bases de datos (en sitios remotos es requerido el uso de estilos transaccionales y cooperativos).Estilo de Bases de Datos con arquitectura Cliente/Servidor.

Modelos o Tcnicas de Procesamiento y Protocolos comnmente utilizados. Llamadas a procedimientos remotos (RPC). Interacciones SQL Cliente/Servidor. Memoria compartida. Paso de Mensajes. SPX/IPX NETBEUI (NETBIOS) NAME PIPES TCP/IP UDP SOCKETS

Distribucin entre Cliente y Servidor.Dentro de los procesos que son manejados en una arquitectura Cliente/Servidor, se tiene 3 elementos bsicos que deben de distribuirse entre el cliente y el servidor, estos elementos son: El manejo de Datos. La aplicacin. La presentacin.

Conclusin Personal:

Las bases de datos de cliente servidor es el concepto ms utilizado en la actualidad para la gestin de datos de usuario de una red, las bases de datos pueden almacenar cualquier tipo de informacin en la nube y hablamos de cualquier tipo de formato incluyendo multimedia, programas, msica entre otras cosas, de manera regular o diaria nos conectamos a los servicios de una red como el Facebook, o YouTube estos nos presentan los datos que requerimos segn nuestras preferencias estos acomodan los datos de manera dinmica y por medio de algoritmo recibimos comunicacin que es preferible a nosotros, as como estos grandes servidores de datos tambin tenemos otras maneras de ejemplificar la comunicacin de cliente servidor como los datos que almacenamos en bancos o cuentas de correo electrnico, todo este tipo de informacin debe de pasar de forma segura y cifrada por las distintas capas de las redes que la componen lo cual hace que la informacin sea confidencial y segura

Base de datos en la nube

Arquitectura y caractersticas en comn La mayora de los servicios de bases de datos ofrecenconsolasweb, que el usuario final puede utilizar para aprovisionar y configurar las instancias de la base de datos. Por ejemplo, la consola web deAmazon Web Servicespermite a los usuarios lanzar instancias de bases de datos, crear instantneas (similar a las copias de seguridad) de bases de datos y realizar un seguimiento de las estadsticas de la base de datos.1 Los servicios de las bases de datos consisten en un componente de administracin que controla las instancias de cada base de datos subyacente utilizando unaAPI de servicios. La API de servicios se expone al usuario final, y permite a los usuarios realizar operaciones de mantenimiento y ampliar sus instancias de la base de datos. Por ejemplo, el servicio deAmazon Relational Databaseprovee una API que permite crear una instancia de una base de datos, modificar los recursos disponibles de cada instancia, eliminar una instancia, la creacin de una instantnea (similar a una copia de seguridad) de una base de datos y restauracin de una base de datos a partir de una instantnea.2 Los servicios de las bases de datos mantienen la pila del software subyacente, transparente al usuario - la pila normalmente incluye elsistema operativo, base de datos y el software de terceros utilizado por la base de datos. El proveedor de servicios es responsable de la instalacin, parches y actualizacin de la pila de software subyacente. Los servicios de las bases de datos cuidan laescalabilidady laalta disponibilidadde la base de datos. Caractersticas de escalabilidad difieren entre los proveedores - algunos ofrecen auto-escala, mientras que otros permiten al usuario ampliar mediante una API, pero no escalar automticamente. Normalmente hay un compromiso para un cierto nivel de alta disponibilidad (por ejemplo, 99,9% o 99,99%).Modelo de datosTambin es importante diferenciar entre bases de datos en la nube que son relacionales en oposicin a las no relacionales (NoSQL): Bases de datos SQL, son un tipo de base de datos que se puede ejecutar en la nube (ya sea como una imagen de mquina virtual o como un servicio, dependiendo del proveedor). Las bases de datos SQL poseen baja escalabilidad, ya que no fueron nativamente diseadas para entornos en la nube, aunque los servicios en la nube de base de datos basado en SQL estn tratando de hacer frente a este desafo.3 Bases de datos NoSQL, son otro tipo de base de datos que puede ejecutarse en la nube. Las bases de datos NoSQL estn diseados para servir cargas pesadas de lecto-escritura y son capaces de escalar hacia arriba y hacia abajo con facilidad.4y por lo tanto son ms adecuadas para funcionar de forma nativa en la nube. Sin embargo, la mayora de las aplicaciones actuales se construyen en torno a un modelo de datos SQL, as que trabajar con bases de datos NoSQL con frecuencia requiere una reescritura completa del cdigo de la aplicacin.ProveedoresLa siguiente tabla muestra los principales proveedores base de datos en la nube, clasificada por su modelo de implementacin y el modelo de datos. Vase las referencias para ms informacin de cada proveedor o[3]para ver ms proveedores y comparacin de servicios.Proveedores de base de datos en la nube por implementacin del modelo y modelo de datos

Mquina virtualBase de datos como servicio

Modelo de datos SQL Oracle Database67 IBM DB28 Ingres (Base de datos)9 PostgreSQL10 MySQL11 NuoDB12 GaianDB13 Amazon Relational Database Service(MySQL) Microsoft SQL Azure(MS SQL)14 HerokuPostgreSQL como servicio (compartido o dedicado)15 ClustrixBase de datos como servicio16 XeroundCloud Database - MySQL front-end17 EnterpriseDBPostgres Plus Cloud Database18 GaianDB19

Modelo de datos NoSQL CouchDBen Amazon EC220 Hadoopen Amazon EC221 Apache Cassandraen Amazon EC222 Neo4Jen Amazon EC223or Microsoft Azure24 MongoDBen Amazon EC225o Microsoft Azure26 Amazon DynamoDB Amazon SimpleDB Cloudant Data Layer27(CouchDB) Database.com porSalesForce28 Google App EngineAlmacenamiento de datos MongoDBBase de datos como servicio29

4.1 ODBC

INTRODUCCION

Es un estndar de acceso a las bases de datos desarrollado por SQL Access Group en 1992. El objetivo de ODBC es hacer posible el acceder a cualquier dato desde cualquier aplicacin, sin importar qu sistema de gestin de bases de datos (DBMS) almacene los datos. ODBC logra esto al insertar una capa intermedia (CLI) denominada nivel de Interfaz de Cliente SQL, entre la aplicacin y el DBMS. El propsito de esta capa es traducir las consultas de datos de la aplicacin en comandos que el DBMS entienda. Para que esto funcione tanto la aplicacin como el DBMS deben ser compatibles con ODBC, esto es que la aplicacin debe ser capaz de producir comandos ODBC y el DBMS debe ser capaz de responder a ellos. Desde la versin 2.0 el estndar soporta SAG y SQL.

El software funciona de dos modos, con un software manejador en el cliente, o una filosofa cliente-servidor. En el primer modo, el driver interpreta las conexiones y llamadas SQL y las traduce desde el API ODBC hacia el DBMS. En el segundo modo para conectarse a la base de datos se crea una DSN dentro del ODBC que define los parmetros, ruta y caractersticas de la conexin segn los datos que solicite el creador o fabricante.

SIGNIFICADOOpen Database Connectivity (ODBC) es la interfaz estratgica de Microsoft para obtener acceso a datos en un entorno heterogneo de relacionales y no - relacionales sistemas de administracin de la base de datos.Basado en la especificacin de interfaz de nivel de llamada del grupo de acceso de SQL, ODBC proporciona una forma abierta, independiente del proveedor de acceso a datos almacenados en una gran variedad de propietario equipo personal, minicomputadoras y las bases de datos de mainframe.

ODBC alivia la necesidad de aprender mltiples interfaces de programacin de aplicaciones para los programadores corporativos y fabricantes independientes de software.ODBC proporciona ahora una interfaz de acceso de datos universal.Con ODBC, los desarrolladores de aplicaciones pueden permitir que una aplicacin al mismo tiempo tener acceso, ver y modificar los datos procedentes de mltiples bases de datos diferentes.

ODBC es un componente bsico de la arquitectura de servicios abiertos de Microsoft Windows. Apple ha respaldado ODBC como una clave de habilitacin de la tecnologa de anuncio de soporte en Sistema 7 en el futuro.Con soporte de la industria cada vez ms, ODBC est rpidamente emergiendo como un sector importante estndar para el acceso a datos para las aplicaciones de Windows y Macintosh.

REQUERIMIENTOS

Para utilizar ODBC, se requieren los tres componentes siguientes:

Ejemplos de cliente - un ODBC front-end (tambin llamado ODBC cliente habilitado) - ODBC: Microsoft Access, una aplicacin creada con Access, una aplicacin creada con Microsoft Visual Basic, una aplicacin creada con C + Win SDK + ODBC SDK o las aplicaciones basadas en ODBC de otros proveedores (como Lotus).

CONTROLADOR ODBC - un controlador ODBC para el servidor ODBC.El catlogo decontroladores ODBC contiene una lista extensa de los controladores ODBC.Por ejemplo,MicrosoftODBC Driver Pack es una coleccin de los siete controladores ODBC listo para su uso o se incluye con los clientes ODBC.Uncontrolador de ODBC de SQL Server se incluye con Access y Informix est trabajando en un controlador ODBC para Informix.

EJEMPLOS:

Front-end al tener acceso a datos de Access desde un fondo Oracle utilizando el controlador ODBC para Oracle, que se suministra con Access 1.1. Acceso de Visual Basic front-end a los datos de un back-end dBASE usando el controlador de ODBC, que forma parte del paquete de controladores de base de datos de MS ODBC dBASE. Escrito con C + ODBC SDK de SDK + ganar acceso a datos desde un sistema Autnomo de aplicacin de C / 400 mediante el AS / 400 de Rochester Software de controlador de ODBC

4.2 ADO.NET

INTRODUCCION

ADO.NET es un conjunto de clases que exponen servicios de acceso a datos para el programador de .NET. ADO.NET ofrece abundancia de componentes para la creacin de aplicaciones de uso compartido de datos distribuidas. Constituye una parte integral de .NET Framework y proporciona acceso a datos relacionales, XML y de aplicaciones. ADO.NET satisface diversas necesidades de desarrollo, como la creacin de clientes de base de datos de aplicaciones para usuario y objetos empresariales de nivel medio que utilizan aplicaciones, herramientas, lenguajes o exploradores de Internet.ADO .NET es la nueva versin delmodelode objetos ADO (ActiveX Data Objects), es decir, laestrategiaque ofreceMicrosoftpara el acceso adatos. ADO .NET ha sido ampliado para cubrir todas las necesidades que ADO no ofreca, ADO .NET est diseado para trabajar conconjuntosde datos desconectados, lo que permite reducir el trfico dered. ADO .NET utilizaXMLcomo formato universal de transmisin de los datos.ADO .NET posee una serie de objetos que son los mismos que aparecen en la versin anterior de ADO, como pueden ser el objeto Connection o Command, e introduce nuevos objetos tales como el objeto DataReader, DataSet o DataView.ADO .NET se puede definir como:Un conjunto de interfaces, clases,estructurasy enumeracionesQue permiten el acceso a los datos desde la plataforma .NET de MicrosoftQue permite un modo de acceso desconectado a los datos que pueden provenir de mltiplesfuentede datos de diferentearquitecturadealmacenamiento.

SIGNIFICADOADO.NETes un conjunto decomponentes del softwareque pueden ser usados por los programadores para acceder a datos y a servicios de datos. Es una parte de la biblioteca de clases base que estn incluidas en el Microsoft.NETFramework. Es comnmente usado por los programadores para acceder y para modificar los datos almacenados en unSistema Gestor de Bases de DatosRelacionales, aunque tambin puede ser usado para acceder a datos en fuentes no relacionales. ADO.NET es a veces considerado como una evolucin de la tecnologaActiveX Data Objects(ADO), pero fue cambiado tan extensivamente que puede ser concebido como un producto enteramente nuevo.

Componentes de ADO.NETExisten dos componentes de ADO.NET que se pueden utilizar para obtener acceso a datos y manipularlos:

Proveedores de datos de .NET Framework ElDataSet

En el diagrama siguiente se ilustra la relacin entre un proveedor de datos de .NET Framework y unDataSetProveedores de datos de .NET FrameworkLosproveedores de datos de .NET Frameworkson componentes diseados explcitamente para la manipulacin de datos y el acceso rpido a datos de slo lectura y slo avance. El objetoConnectionproporciona conectividad a un origen de datos. El objetoCommandpermite tener acceso a comandos de base de datos para devolver datos, modificar datos, ejecutar procedimientos almacenados y enviar o recuperar informacin sobre parmetros. El objetoDataReaderproporciona una secuencia de datos de alto rendimiento desde el origen de datos. Por ltimo, el objetoDataAdapterproporciona el puente entre el objetoDataSety el origen de datos. ElDataAdapterutiliza objetosCommandpara ejecutar comandos SQL en el origen de datos tanto para cargar elDataSetcon datos como para reconciliar en el origen de datos los cambios aplicados a los datos incluidos en elDataSet.DataSetElDataSet de ADO.NETest expresamente diseado para el acceso a datos independientemente del origen de datos. Como resultado, se puede utilizar con mltiples y distintos orgenes de datos, con datos XML o para administrar datos locales de la aplicacin. ElDataSetcontiene una coleccin de uno o ms objetosDataTableformados por filas y columnas de datos, as como informacin sobre claves principales, claves externas, restricciones y relaciones relativa a los datos incluidos en los objetosDataTable.

ARQUITECTURA ADO.NET

REQUERIMIENTOSAl trabajar con ADO.NET no se utiliza la dll de acceso ODBC de GX (gxdata.dll), sino que toda la lgica se encuentra en la gxclasses.dll.En el caso de los DBMSs, cada uno utiliza un Data Provider para acceder a la base de datos, cada DBMS tiene su propio Data Provider para acceso ADO.NET.Por el momento los DBMSs que soportan el acceso ADO.NET son: SQL Server Oracle DB2 Universal Database DB2 UDB for iSeries

Los requerimientos necesarios en cada caso son:SQL ServerADO.NET utiliza el Data Provider de Microsoft para SQL Server (el cual se instala con el framework).

OracleSe debe tener el Cliente de Oracle versin 8.1.7 o superior, de esta forma se instala el Data Provider correspondiente.El valor Server Name de las Dbms option hace referencia al Service Name definido en la instancia del Oracle.La implementacin utiliza el Data provider de Microsoft para Oracle (System.Data.OracleClient)

DB2 UDB for iSeriesSe necesita la V5R3 del iSeries Access, que es una versin beta y est solo en ingls.Adems cuando se crea un modelo se debe copiar la dll IBM.Data.DB2.iSeries.dll al directorio gxnet/bin si la aplicacin es web o gxnetwin/bin win.La versin V5R3 del iSeries Access se puede obtener de la URL:http://www-1.ibm.com/servers/eserver/iseries/access/windows/beta.html.

Nota:-El Data provider para DB2 UDB for iSeries no soporta BLOBs por ahora.-Una limitacin del driver client acces V5 R3 no permite el llamado objetos remotos en el Iseries (RPC). Esto implica store procedures (programas RPG o Cobol) u objetos externos en el Iseries (programas CL)

DB2 Universal DatabaseSe necesita tener instalada la versin 8.1.3 o superior.La dll es IBM.Data.DB2.dll, tambin se debe copiar a los directorios gxnet/bin si la aplicacin es web o gxnetwin/bin win.4.3 JDBC

INTRODUCCINJava proporciona una plataforma completa, flexible y segura para el desarrollo de aplicaciones, incluyendo la conectividad con una base de datos. Esta conectividad o acceso a base de datos relacionales con Java es posible gracias a laAPI JDBC (Java DataBase Connectivity).Este API es parte de la plataforma Java desde la versin 1.0 de JDK.Con el paso del tiempo se ha ido mejorando y aumentando su funcionalidad.JDBC es ODBC extendido para toda la plataforma Java. Mientras queODBC es una interfaz escrita en lenguaje C, que tiene que ser instalado manualmente en cada maquina,JDBC, al estar escrito en Java, posee todas las propiedades y ventajas del mismo.ODBC es un estandar para las plataformas MS Windows. JDBCes capaz de trabajar con MS Windows y otras plataformas.ElAPI JDBCpuede definirse como un conjunto de clases, mtodos e interfaces escritos en lenguaje Java, que permiten el acceso a sistemas de bases de datos relacionales utilizando instrucciones SQL. que necesitamos ?- El API JDBC con dos paquetes principale, java.sql y javax.sql- Uncontroladorde acceso a una base de datosEl controlador servir para conectar la aplicacin con la API JDBC, proporcionando comunicacin con la base de datos.En definitiva, lo que elestndar JDBChace posible es: Establecer una conexin. Lanzar sentencias SQL. Capturar conjuntos resultado (resulset) de las consultas. Capturar informacin de la base de datos. Manipular los datos.

Puesto que JDBC est implementado en Java, posee la ventaja de serindependiente de la plataformaeindependiente de la base de datos. En esencia,podr ejecutarse encualquier sistemaque posea unaMquina Virtual de Java.

SIGNIFICADOJDBCes un API (Application programming interface) que describe o define una librera estndar para acceso a fuentes de datos, principalmente orientado a Bases de Datos relacionales que usan SQL (Structured Query Language). JDBC no slo provee un interfaz para acceso a motores de bases de datos, sino que tambin define una arquitectura estndar, para que los fabricantes puedan crear los drivers que permitan a las aplicaciones java el acceso a los datos.

Filosofa y Objetivos de JDBC

Cuando SUN se puso a trabajar en este tema, decidi seguir una serie de normas a seguir para la definicin del interfaz, y que han condicionado en gran manera el resultado final. Algunas de estas caractersticas son: API A NIVEL SQL.JDBC es un API de bajo nivel, es decir, que est orientado a permitir ejecutar comandos SQL directamente, y procesar los resultados obtenidos. Esto supone que ser tarea del programador crear APIs de ms alto nivel apoyndose directamente sobre JDBC. COMPATIBLE CON SQL.Cada motor de Base de Datos implementa una amplia variedad de comandos SQL, y muchos de ellos no tienen por qu ser compatibles con el resto de motores de Base de Datos. JDBC, para solventar este problema de incompatibilidad, ha tomado la siguiente posicin JDBC permite que cualquier comando SQL pueda ser pasado al driver directamente, con lo que una aplicacin Java puede hacer uso de toda la funcionalidad que provea el motor de Base de Datos, con el riesgo de que esto pueda producir errores o no en funcin del motor de Base de Datos. Con el objetivo de conseguir que un driver sea compatible con SQL (SQL compliant), se obliga a que al menos, el driver cumpla el Estndar ANSI SQL 92. JDBC debe ser utilizable sobre cualquier otro API de acceso a Bases de Datos, o ms en particular ODBC (Open Database Connectivity) JDBC debe proveer un interfaz homogneoal resto de APIs de Java. JDBC debe ser un API simple, y desde ah, ir creciendo. JDBC debe ser fuertemente tipado, y siempre que sea posible de manera esttica, es decir, en tiempo de compilacin, para evitar errores en tiempo de ejecucin. JDBC debe mantener los casos comunes de acceso a Base de Datos lo ms sencillo posible: Mantener la sencillez en los casos ms comunes (SELECT, INSERT, DELETE y UPDATE) Hacer realizables los casos menos comunes: Invocacin de procedimientos almacenados... Crear mltiples mtodos para mltiple funcionalidad. JDBC ha preferido incluir gran cantidad de mtodos, en lugar de hacer mtodos complejos con gran cantidad de parmetros.

REQUERIMIENTOS

Para tener acceso a los datos desde una base de datos de SQL Server mediante el controlador JDBC de Microsoft SQL Server, debe tener los siguientes componentes instalados en el equipo: Controlador de JDBC de Microsoft SQL Server Java Runtime Environment3. Procedimiento de Conexin y acceso a datos con JDBC.

Consideraciones previas.El proceso de acceso a una Base de Datos a travs de JDBC, exige dar una serie de pasos previos antes de crear la conexin al motor de Base de Datos. El primer paso es determinar el entorno en el que el proyecto va a ser instalado, y ms en concreto, que parmetros del entorno afectan directamente a JDBC:Debemos considerar las caractersticas especficas de una base de datos, como por ejemplo, como mapear los tipos de datos SQL a Java.Es probable encontrarnos varios drivers distintos para la misma fuente de datos. Debemos saber detectar cual es el driver ms adecuado para nuestra aplicacin, por ejemplo, si elegimos un driver ODBC/JDBC, tendremos ms flexibilidad para elegir distintas fuentes de datos, pero si por ejemplo trabajamos con una Base de Datos Oracle, un driver JDBC diseado especficamente para esta base de datos ser mucho ms eficiente.En funcin de donde se encuentre el driver fsicamente, debemos considerar aspectos de rendimiento y seguridad. Por ejemplo, si cargamos el driver desde un servidor remoto tendremos que considerar aspectos sobre seguridad de Java.

Procedimiento de conexin.1. Cargar el driver. Cualquier driver JDBC, independientemente del tipo debe implementar el interfaz java.sql.Driver. La carga del driver se puede realizar de dos maneras distintas:Definiendo los drivers en la variablesql.driver(variable que mantiene todos las clases de los drivers separados por comas) Cuando la clase DriverManager se inicializa, busca esta propiedad en el sistema. El programador puede forzar la carga de un driver especfico, usando el mtodo Class.forName(driver).2. Registro del driver.Independientemente de la forma de carga del driver que llevemos a cabo, ser responsabilidad de cada driver registrarse a s mismo, usando el mtodo DriverManager.registerDriver. Esto permite a la clase DriverManager, usar cada driver para crear conexiones con el controlador de Base de Datos. Por motivos de seguridad, la capa que gestiona JDBC, controlar en todo momento que driver es el que se est usando, y cuando se realicen conexiones, slo se podrn usar drivers que estn en el sistema local de ficheros o que usen el mismo ClassLoader que el cdigo que est intentando crear la conexin.3. Crear una conexin. El objetivo es conseguir un objeto del tipo java.sql.Connection a travs del mtodo DriverManager.getConnection(String url). La capa de gestin, cuando este mtodo es invocado, tratar de encontrar un driver adecuado para conectar a la base de datos especificada en la URL, intentndolo por el orden especificado en la variable sql.driver. Cada driver debera examinar si ellos proveen el subprotocolo que especifica la URL. (Ver anexo)3. Tipos de conectores (drivers) JDBC Tipo 1. JDBC-ODBC bridge ms driver ODBC: BRIDGE Ventajas: Buena forma de aprender JDBC. Tambin puede ser buena idea usarlo, en sistemas donde cada mquina cliente tenga ya instalado los drivers ODBC. Tambin es posible que sea la nica forma de acceder a ciertos motores de Bases de Datos.Inconvenientes: No es buena idea usar esta solucin para aplicaciones que exijan un gran rendimiento, ya que la transformacin JDBC-ODBC es costosa. Tampoco es buena solucin para aplicaciones con alto nivel de escalabilidad. Tipo 2. Driver Java parciales: NATIVE Ventajas:Mejor rendimiento que el anterior. Quiz puede ser buena solucin para entornos controlados como intranets. Ejemplo OCI oracle. Inconvenientes:Principalmente la escalabilidad, ya que estos drivers exigen que en la mquina cliente libreras del cliente de la Base de Datos. Tipo 3. Driver JDBC a travs de Middleware: NETWORK Ventajas: Buena solucin cuando necesitamos acceder a Bases de Datos distintas y se quiere usar un nico driver JDBC para acceder a las mismas. Al residir la traduccin en el servidor del middleware, los clientes no necesitan libreras especficas, tan solo el driver. Inconvenientes: La desventaja principal reside en la configuracin del servidor donde se encuentra el middleware. Necesitar libreras especficas para cada motor de base de datos distinto, etc. Tipo 4: Driver java puro (acceso directo a Base de Datos): THIN. Ventajas: 100 % portable. Buen rendimiento. El cliente slo necesita el driver. Inconvenientes: Al ser independiente de la plataforma, no aprovecha las caractersticas especficas del S.O5. Arquitecturas JDBC Aplicaciones standalone Applets comunicando con un servidor Web Aplicaciones y applets comunicando con una base de datos a travs de un puente JDBC/ODBC. Aplicaciones accediendo a recursos remotos usando mecanismos como Java RMI

El procedimiento de conexin con el controlador de la base de datos, independientemente de la arquitectura es siempre muy similar.En el primero de los casos (a travs de la propiedad sql.driver), JDBC usar el primer driver que permita conectarse correctamente a la Base de Datos.Los conectores o drivers JDBC, se pueden dividir en cuatro tipos principalmente:Permite el acceso a Base de Datos JDBC mediante un driver ODBC. Cada mquina cliente que use el puente, debe tener libreras clientes de ODBC(dll propias del S.O)

Traducen las llamadas al API de JDBC Java en llamadas propias del motor de Base de Datos (Oracle, Informix...). Al igual que el tipo anterior, exige en las mquinas clientes cdigo binario propio del cliente de la Base de datos especfica y del sistema operativo

Traduce las llamadas al API JDBC en llamadas propias del protocolo especfico del broker. ste se encargar de traducirlas de nuevo en sentencias propias del motor de Base de Datos de cada caso.

Convierte o traduce las llamadas al API JDBC en llamadas al protocolo de red usado por el motor de bases de datos, lo que en realidad es una invocacin directa al motor de bases de datos.S.O donde vaya a correr.

La arquitectura bsica de JDBC (ya la hemos visto) es simple. Una clase llamada DriverManager provee un mecanismo para controlar un conjunto de drivers JDBC. Esta clase intenta cargar los drivers especificados en la propiedad del sistema jdbc.drivers. Tambin podemos cargar un driver explicitamente usando Class.forName(). Durante la carga, el driver intentar registrarse a si mismo usando el mtodo clase DriverManager.registerDriver(). Cuando se invoque al mtodo DriverManager.getConnection(), sta buscar el primer driver de los registrados que pueda manejar una conexin como la descrita en la URL y retornar un objeto que implemente el interfaz java.sql.Connection.

Sin embargo, en funcin de la localizacin de la base de datos, el driver, la aplicacin y el protocolo de comunicacin usado, nos podemos encontrar distintos escenarios que accedan a Base de Datos a travs de JDBC:

Todos ellos se pueden agrupar en dos tipos distintos de arquitecturas:

La aplicacin que accede a la base de datos reside en el mismo lugar que el driver de la base de datos. El driver acceder al servidor donde corra el motor de base de datos.En este caso, ser el driver el encargado de manejar la comunicacin a travs de la red.En el ejemplo, una aplicacin java corriendo en una mquina cliente que usa el driver tambin local. Toda la comunicacin a travs de la red con la base de datos ser manejada por el driver de forma transparente a la aplicacin Java.

Conclusin personal:Las bases de datos de la nube son la manera ms popular hoy en da en lo que compete al almacenamiento de la informacin, a travs del tiempo se ha ido transformando para ofrecer mejores servicios a los usuarios de las mismas ya sea de manera privada o abierta, las bases de datos que manejamos en la actualidad contiene cada vez mejor manera de mostrar los datos de tal manera que el acceso a ellas sea fcil y seguro no obstante siguen evolucionando para mejorar sus servicios, y varan de un proveedor a otro, los modelos se han ido estandarizando para el mejoramiento de la compatibilidad, los modelos SQL son los ms populares utilizados en la actualidad por su fcil manejo y utilizacin, as tambin tenemos modelos No SQL que cumplen con tareas especficas, entre otros modelos, la tarea principal es la gestin de la informacin

Bibliografa:

http://tadebasegino.blogspot.mx/2012/11/arquitectura-clienteservidor.htmlhttp://www.desarrolloweb.com/articulos/arquitectura-cliente-servidor.htmlhttp://www.monografias.com/trabajos81/las-bases-de-datos/las-bases-de-datos2.shtmlhttps://es.wikipedia.org/wiki/Base_de_datos_en_la_nubehttp://www.itpn.mx/recursositics/4semestre/tallerdebasededatos/Unidad%20VII.pdfhttp://tecnologiasdebasededatos-angelalujano.blogspot.mx/{}|