unidad 1 bases de datos distribuidas

UNIDAD I BASES DE DATOS DISTRIBUIDAS
1.1ARQUITECTURA
1.1.1AUTONOMÍA
Como muchos usuarios de sistemas de bases de datos no están familiarizados con computadoras, los desarrolladores esconden la complejidad a los usuarios a través de varios niveles de abstracción para simplificar la interacción de los usuarios con el sistema. Existen diferentes niveles de abstracción para simplificar la interacción de los usuarios con el sistema:
El nivel interno: Tiene un esquema interno, que describe la estructura física de almacenamiento de la base de datos. El esquema interno emplea un modelo físico de los datos y describe todos los detalles para su almacenamiento, así como los caminos de acceso para la base de datos.
El nivel conceptual: Tiene un esquema conceptual, que describe la estructura de toda la base de datos para una comunidad de usuarios. El esquema conceptual oculta los detalles de las estructuras físicas de almacenamiento y se concentra en describir entidades, tipos de datos, vínculos, operaciones de los usuarios y restricciones. En este nivel podemos usar un modelo de datos de alto nivel o uno de implementación.
>El nivel externo o de vistas: Incluye varios esquemas externos o vistas de usuario. Cada esquema externo describe la parte de la base de datos que interesa a un grupo de usuarios determinado, y oculta a ese grupo el resto de la base de datos. En este nivel podemos usar un modelo de datos de alto nivel o uno de implementación.

1.1.2HETEROGENEIDAD
La heterogeneidad es importante en un sistema distribuido. Aún más si se permite que los recursos migren entre distintos nodos.
En principio, el modelo de DAMN no impone ninguna de las soluciones conocidas para resolver los problemas presentados por entornos heterogéneos. No obstante, Off propone una solución poco común: La eliminación de representaciones independientes de arquitectura.
Es cierto que las representaciones neutrales, de red o independientes de arquitectura son esenciales para interconectar nodos heterogéneos en la red, pero sólo si:
• existe un gran número de arquitecturas que no pueden predecirse con antelación y/o
• los distintos sistemas ocultan su representación interna de la información.
Ninguno de estos dos puntos es cierto en los sistemas objeto de estudio. Consiguientemente, Off exporta o congela los objetos de un modo dependiente de arquitectura. Dado que junto con la firma del objeto se suministra un identificador de arquitectura, nada impide al usuario traducir la representación de una arquitectura a otra.
Nada, ¡salvo la integridad de la firma!
Un portal similar al de autenticación, el de traducción, permite a un núcleo de Off la obtención de una versión congelada válida la arquitectura local. Cuando un usuario intenta descongelar un objeto etiquetado como i586PC en un nodo con arquitectura PA-RISC, Off confía a una aplicación de usuario (en la que se confía) la traducción de dicho objeto congelado.
Dado que el núcleo ha comprobado ya la integridad de la imagen congelada, la traducción puede hacerse de forma segura en área de usuario.
1.1.3DISTRIBUCIÓN Y ESQUEMA GLOBAL
El nivel conceptual describe la estructura lógica global de la base de datos mediante un modelo abstracto de datos comprensible por el SGBD. Se definen la descripción de atributos, de entidades, las conexiones y las restricciones de integridad asociadas a la semántica (significado). Podemos decir que describe que datos son almacenados realmente en la base de datos y las relaciones que existen entre los mismos, describe la base de datos completa en términos de su estructura de diseño. El nivel conceptual de abstracción lo usan los administradores de bases de datos, quienes deben decidir qué información se va a guardar en la base de datos.
El esquema conceptual representa la visión organizacional de la base de datos que se obtiene al integrar los requerimientos de todos los usuarios en una empresa; y es totalmente independiente de las estructuras físicas de almacenamiento y de la representación final de los datos que los usuarios manejan. La implantación de este esquema es responsabilidad del DBA.

1.2DISEÑO DE BASES DE DATOS DISTRIBUIDAS
1.2.1Diseño top-Down: fragmentación.
El enfoque de arriba hacia abajo (top-down). Este enfoque es más apropiado para aplicaciones nuevas y para sistemas homogéneos. Consiste en partir desde el análisis de requerimientos para definir el diseño conceptual y las vistas de usuario. A partir de ellas se define un esquema conceptual global y los esquemas externos necesarios. Se prosigue con el diseño de la fragmentación de la base de datos, y de aquí se continúa con la localización de los fragmentos en los sitios, creando las imágenes físicas. Esta aproximación se completa ejecutando, en cada sitio, "el diseño físico" de los datos, que se localizan en éste. En la Figura 3.1 se presenta un diagrama con la estructura general del enfoque top-down.










1.2.2Diseño bottom-up : integración de bases de datos.
El diseño de abajo hacia arriba (bottom-up). Se utiliza particularmente a partir de bases de datos existentes, generando con esto bases de datos distribuidas. En forma resumida, el diseño bottom-up de una base de datos distribuida requiere de la selección de un modelo de bases de datos común para describir el esquema global de la base de datos. Esto se debe es posible que se utilicen diferentes SMBD. Después se hace la traducción de cada esquema local en el modelo de datos común y finalmente se hace la integración del esquema local en un esquema global común.
1.3 ARQUITECTURAS CLIENTE/SERVIDOR PARA SGBD
Los servidores de bases de datos son Sistemas de Gestión de Bases de Datos o SGBD (en inglés DBMS = DataBase Management System), aplicaciones cuyo objetivo no es solo almacenar y recuperar datos, sino también facilitar la manipulación de éstos de la forma más eficiente y segura.
Un servidor de datos debe elaborar la información que va a devolver al cliente a partir de los datos recuperados del sistema de archivos usando para ellos diferentes estructuras físicas, así como asegurar su integridad verificando restricciones y utilizando transacciones.
Aunque en un principio surgieron SGBD de distintos tipos, según la estructura con la que se almacenaba la información, los más extendidos y conocidos son los Sistemas Administradores de Bases de Datos Relacionales SGBDR (en inglés RDBMS = Relational Data Base Management System) llamados así porque los datos se estructuran con ciertas relaciones entre ellos (Modelo Relacional), simplificando la recuperación y el tratamiento y evitando la repetición innecesaria de información. Algunos ejemplos de SGBDR son los ya mencionados SQL Server, Oracle, MySQL, Firebird, etc.
1.3.1FILOSOFÍA CLIENTE/SERVIDOR
Cliente-servidor de dos capas.- Descrito brevemente en el punto anterior. El modelo de dos capas se encuentra ligado fuertemente a la implantación de una computadora operando como el CLIENTE y otra como SERVIDOR conteniendo la base de datos de la empresa.
Cliente-Servidor de n capas.- Partiendo del modelo cliente/servidor han surgido otros conocidos genéricamente como n-tier, siendo el más habitual el three-tier o de tres capas.
El concepto de n capas ha cambiado con el tiempo, puede referirse tanto al hardware como a software.

Cliente-Servidor de tres capas.- Desde el punto de vista de software, la arquitectura cliente servidor de tres capas esta dada por tres elementos básicos: capa de presentación, capa lógica (de negocio), y capa de datos. Los clientes no se comunican directamente con el servidor de datos, sino que entre ellos se interpone un nuevo servidor: el de aplicaciones (capa lógica,capa de negocio o lógica del negocio).


En este modelo los clientes no tienen acceso directo a los datos, trabajo que queda en manos de los componentes que se ejecutan en el servidor de aplicaciones.Dichos componentes, además, alojan la lógica de proceso de la información, lo que normalmente se conoce como lógica del negocio (capa de negocio),tarea que en el modelo cliente/servidor recaía en la aplicación del cliente. De esta forma, el cliente queda relegado a una simple interfaz de usuario, ya sea nativa en un ordenador, un documento en un navegador web o desde un dispositivo móvil.
La ventaja principal es que resulta más fácil llegar a clientes heterogéneos y dispersos, interconectados no en redes de la propia empresa si no a través de internet.




1.3.2SOCKETS
Socket designa un concepto abstracto por el cual dos programas (posiblemente situados en computadoras distintas) pueden intercambiar cualquier flujo de datos, generalmente de manera fiable y ordenada.
Un socket queda definido por una dirección IP, un protocolo de transporte y un número de puerto.

Para que dos programas puedan comunicarse entre sí es necesario que se cumplan ciertos requisitos:
• Que un programa sea capaz de localizar al otro.
• Que ambos programas sean capaces de intercambiarse cualquier secuencia de octetos, es decir, datos relevantes a su finalidad.
Para ello son necesarios los tres recursos que originan el concepto de socket:
• Un protocolo de comunicaciones, que permite el intercambio de octetos.
• Una dirección del Protocolo de Red (Dirección IP, si se utiliza el Protocolo TCP/IP), que identifica una computadora.
• Un número de puerto, que identifica a un programa dentro de una computadora.
Los sockets permiten implementar una arquitectura cliente-servidor. La comunicación ha de ser iniciada por uno de los programas que se denomina programa cliente. El segundo programa espera a que otro inicie la comunicación, por este motivo se denomina programa servidor.
Un socket es un fichero existente en la máquina cliente y en la máquina servidora, que sirve en última instancia para que el programa servidor y el cliente lean y escriban la información. Esta información será la transmitida por las diferentes capas de red.
Propiedades inherentes a los sockets
Las propiedades de un socket dependen de las características del protocolo en el que se implementan. El protocolo más utilizado es TCP, aunque también es posible utilizar UDP o IPX. Gracias al protocolo TCP, los sockets tienen las siguientes propiedades:
• Orientado a conexión.
• Se garantiza la transmisión de todos los octetos sin errores ni omisiones.
• Se garantiza que todo octeto llegará a su destino en el mismo orden en que se ha transmitido.
Estas propiedades son muy importantes para garantizar la corrección de los programas que tratan la información.
El protocolo UDP es un protocolo no orientado a la conexión. Sólo se garantiza que si un mensaje llega, llegue bien. En ningún caso se garantiza que llegue o que lleguen todos los mensajes en el mismo orden que se mandaron.
1.3.3RPC
El RPC (del inglés Remote Procedure Call, Llamada a Procedimiento Remoto) es un protocolo que permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, estando éstas encapsuladas dentro de las RPC.
Las RPC son muy utilizadas dentro del paradigma cliente-servidor. Siendo el cliente el que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando éste de vuelta el resultado de dicha operación al cliente.
Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser el RPC de Sun denominado ONC RPC (RFC 1057), el RPC de OSF denominado DCE/RPC y el Modelo de Objetos de Componentes Distribuidos de Microsoft DCOM, aunque ninguno de estos es compatible entre sí. La mayoría de ellos utilizan un lenguaje de descripción de interfaz (IDL) que define los métodos exportados por el servidor.
Hoy en día se está utilizando el XML como lenguaje para definir el IDL y el HTTP como protocolo de red, dando lugar a lo que se conoce como servicios web. Ejemplos de éstos pueden ser SOAP o XML-RPC.
ONC RPC, abreviación del inglés Open Network Computing Remote Procedure Call, es un protocolo de llamada a procedimiento remoto (RPC) desarrollado por el grupo ONC de Sun Microsystems como parte del proyecto de su sistema de archivos de Red NFS, algunas veces se lo denomina Sun ONC o Sun RPC. Trabaja sobre los protocolos TCP y UDP. La codificación de datos se realiza utilizando el protocolo XDR (presentación de datos).
Desarrollo de aplicaciones: compiladores de protocolo
El desarrollo de aplicaciones para ONC RPC consisten en desarrollar programas cliente/servidor, donde los datos deben codificarse según el protocolo XDR.
Las aplicaciones se realizan en forma sistemática mediante compiladores de protocolo como el programa rpcgen, que fue el programa original desarrollado por Sun que generaba casi todo el código en lenguaje C necesario para crear los programas servidor y cliente. Existen compiladores de este protocolo que generan código en java, denominados jrpcgen.
1.3.4CORBA
En computación, CORBA (Common Object Request Broker Architecture — arquitectura común de intermediarios en peticiones a objetos), es un estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos.
CORBA fue definido y está controlado por el Object Management Group (OMG) que define las APIs, el protocolo de comunicaciones y los mecanismos necesarios para permitir la interoperabilidad entre diferentes aplicaciones escritas en diferentes lenguajes y ejecutadas en diferentes plataformas, lo que es fundamental en computación distribuida.
En un sentido general, CORBA "envuelve" el código escrito en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos. Los objetos que resultan, pueden entonces ser invocados desde otro programa (u objeto CORBA) desde la red. En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras, pero con más información.
CORBA utiliza un lenguaje de definición de interfaces (IDL) para especificar las interfaces con los servicios que los objetos ofrecerán. CORBA puede especificar a partir de este IDL, la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Implementaciones estándar existen para Ada, C, C++, Smalltalk, Java, Python, Perl y Tcl.
Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). El código del cliente sirve para poder realizar las llamadas a métodos remotos. Es el conocido como stub, el cual incluye un proxy (representante) del objeto remoto en el lado del cliente. El código generado para el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que rellenar para implementar los métodos del objeto.
CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones. Y así este no es un sistema operativo en si, en realidad es un middleware.

1.4 OPTIMIZACIÓN DE PREGUNTAS Y TRANSACCIONES
En nuestras aplicaciones podemos optimizar los procesos forzando que éstos se ejecuten en tercer plano, es decir, en el servidor. Veámoslo con un ejemplo.
A continuación presentamos un proceso sin optimizar:

El origen del proceso es una lista de la tabla CLIENTES y en él se pregunta si queremos o no actualizar los clientes. En caso afirmativo se recorre la lista y se modifica el campo FECHA ALTA.
El proceso se ejecuta en primer plano, es decir, en nuestra máquina. Además,como incluye la función recorrer lista lectura / escritura, escribe en disco.
Esto implica que sólo realice una transacción al recorrer el bucle (si no escribiera en disco realizaría tantas transacciones como registros encontrara, ralentizándose mucho más el proceso).
Podemos optimizar este proceso partiéndolo en dos: uno que incluya el bucle y que se ejecute en tercer plano y otro encargado de lanzar el anterior y que se ejecute en primer plano. Veámoslo:
El proceso que se va a ejecutar en el servidor es el siguiente:

El proceso anterior tiene como origen una lista de la tabla CLIENTES y lo hemos identificado como UPDATE-CLIENTES-OPT-3P.
El proceso encargado de lanzar el anterior es:

Este proceso se ejecuta en primer plano, y en él incluimos la función Ejecutar proceso en la que seleccionamos el proceso UPDATE-CLIENTESOPT-3P, indicando que éste debe lanzarse en modo servidor.
Al montar el proceso de este segundo modo (optimizado) la actualización de la lista se realiza mucho más rápido (diez veces más de media), ya que es el servidor quien la realiza, evitando que haya tráfico de información a través de la red.
Al montar una estructura como la anterior hemos de tener en cuenta que en un proceso en tercer plano no podemos lanzar preguntas, presentar formularios, rejillas… sólo podemos usar la función de procesos Mensaje, que se suele usar para depurar. Sus contenidos se presentarán en la barra de mensajes del servidor de aplicaciones.
Forzar una única transacción
Supongamos un proceso para actualizar las ventas en una lista de clientes y que necesita confirmación por parte del usuario. Éste se compondrá de dos procesos:
Uno lanzador, en primer plano y con origen una lista de la tabla CLIENTES. En él incluiremos la parte que interactúa con el usuario.

PROCESO LANZADOR
Otro en tercer plano (ACTUALIZAR-VENTAS-CLIENTES-3P en el proceso anterior) con origen ficha de la tabla CLIENTES, en el que cargamos el histórico de ventas de cada cliente, lo recorremos y realizamos la modificación necesaria en cada registro.