• Save
Base de datos: sistemas_clienteservidor
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Base de datos: sistemas_clienteservidor

  • 2,486 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,486
On Slideshare
2,486
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Página 3 Temario Tema Página 1. Arquitectura de SGBD Multiusuario 5 1.1 Definición 5 1.2 Evolución 5 1.2.1 Teleprocesamiento 5 1.2.2 Arquitectura de Servidor de Archivos 5 1.2.3 Arquitectura Cliente/Servidor Tradicional en dos Niveles 6 1.2.4 Arquitectura Cliente/Servidor en Tres Niveles 7 1.2.5 Monitores de Procesamiento de Transacciones 8 2. Componentes en la Arquitectura Cliente/Servidor 8 2.1 Generalidades 8 2.2 Componentes de Cliente 9 2.3 Componentes de Servidor 9 2.4 Componentes de Middleware de Comunicaciones 9 2.4.1 Nivel Físico 10 2.4.2 Nivel Lógico 10 2.5 Protocolo de Red 10 2.6 Componentes de Middleware de Base de Datos 10 2.6.1 Interface de programación de aplicaciones (API). 10 2.6.2 Traductor de base de datos. 11 2.6.3 Traductor de red. 11 2.7 Clasificación de Middleware 11 3. Estilo Arquitectónicos de Sistemas Cliente/Servidor 11 3.1 Generalidades 11 3.2 Más Detalles 11 4. Temas de Ejecución de Sistemas Cliente/Servidor 12 4.1 Modelo Cliente/Servidor Contra Procesamiento de Datos Tradicionales 12 4.2 Consideraciones Administrativas 12 4.3 Herramientas de Desarrollo de Sistemas Cliente/Servidor 12 4.4 Método Integrado 12 Anexo A : Elementos de Sistemas de Base de Datos Distribuidas 13 Anexo B : Modelos OSI – TCP/IP 18 Anexo C : ODBC 20 Bibliografía 21 INTEGRANTES: • PLASENCIA GUTIERREZ, William • SÁNCHEZ ROSAS, Juan Venus • REBAZA MENDOZA, Angel Rusell
  • 2. Página 4 1 Arquitectura de SGBD Multiusuario En este Trabajo vamos a examinar las arquitecturas que mas comúnmente se utilizan para implementar sistemas de gestión de base de datos multiusuarios. 1.1 Definición Es un término utilizado para describir un modelo de computación para el modelo de desarrollo de sistemas computarizados. Este modelo en la distribución de funciones entre dos tipos de entidades independientes y autónomas. Servicios: El cliente solicita Archivos servicios a Impresiones diferentes Comunicación procesos Fax servidor Multimedia Red Etcétera (Las solicitudes y respuestas viajan a Proceso servidor través de la red) Proceso cliente 1.2 Evolución 1.2.1 Teleprocesamiento: La arquitectura para los sistemas multiusuarios era el teleprocesamiento, donde hay una computadora con una única unidad central de proceso (UCP) y una serie de terminales. Esta tendencia es la que dio lugar a surgimiento de las dos siguiente dos arquitecturas (El Servidor de Archivos y Modelo Cliente Servidor). Topología de Teleprocesamiento 1.2.2 Arquitectura de Servidor de Archivos: El procesamiento esta distribuido por toda la red, que normalmente suele ser una red de área local (LAN). El servidor de archivos actúa como una unidad de disco compartido El SGBD de cada estación de trabajo envía solicitudes al servidor de archivos para extraer todos los datos que necesita y que están almacenados en disco.
  • 3. Página 5 Cliente 1 Cliente 2 Cliente 3 LAN Solicitudes de Datos Archivos de Vueltos BD Servidor de Archivo Desventajas Principales: • Hay una gran cantidad de trafico de red • Se requiere una copia completa de SGBD en cada estación de trabajo • El control de concurrencia de recuperación y de integridad son más complejos, ya que pueden haber múltiples SGBD accediendo a los mismos archivos. 1.2.3 Arquitectura Cliente/Servidor Tradicional en dos Niveles Como el nombre sugiere, hay un proceso cliente que necesita algún recurso y un servidor que proporciona el recurso. También proporciona una proporción muy básica de estos componentes. El Cliente (nivel 1) es principalmente responsable de la presentación de los datos al usuario, mientras que el servidor (nivel 2) es principalmente responsable de suministrar servicios de datos al cliente. Cliente 1 Cliente 2 Cliente 3 LAN Solicitudes de Datos Devolución de Datos Seleccionada BD Servidor (Con SGBD)
  • 4. Página 6 Ventajas Principales • Permite un acceso mas universal al a base de datos existente. • Mejores prestaciones: si los clientes y el servidor residen en computadoras distintas, las diferentes CPU podrán procesar distintas aplicaciones en paralelo. • Se reducen los costes de comunicaciones: las aplicaciones llevan a cabo parte de las operaciones en el cliente y solo envían a través de la red las solicitudes de acceso a la base de datos, con lo que se envía menos de datos a la red. • Costes de hardware: solo el servidor requiere suficiente espacio de almacenamiento y la suficiente capacidad de proceso como para almacenar y gestionar la base de datos. 1.2.4 Arquitectura Cliente/Servidor en Tres Niveles Se utilizaban en clientes ‘complejos’, lo que requería unos recursos considerables en la computadora del cliente para que este pudiera ejecutarse de forma adecuada. Estos recursos incluían espacio de disco, memoria RAM y potencia de de procesamiento de la CPU. Las tareas de administración en el lado del cliente eran bastante significativas. Esta nueva arquitectura proponía tres niveles, cada uno de los cuales puede ejecutarse de una manera distinta: 1. El nivel de interfaz de usuario, que se ejecuta en la computadora del usuario final (El cliente). 2. el nivel de lógica del negocio y procesamiento de datos. Este nivel intermedio se ejecuta en un servidor que a menudo se denomina servidor de aplicaciones. 3. Un SGBD, que almacena los datos requeridos por el nivel intermedio. Este nivel puede ejecutarse en un servidor independiente, denominados servidor de base de datos. Ventajas • El hardware necesario es menos costoso ya que los clientes son simples. • El mantenimiento de las aplicaciones esta centralizado, al transferirse la lógica del negocio desde la plataformas de los usuarios finales a un único servidor de aplicaciones. Esto elimina los problemas de distribuciones del software que tantos quebraderos proporciona en el modelo tradicional cliente/Servidor en dos niveles. • Resulta mas fácil equilibrar la carga de procesamiento al separa la lógica del negocio de las funciones de base de datos. • Es adaptable para los entornos web, en los que un explorador web actúa como cliente “Simples” y un servidor web actúa como servidor de aplicaciones. Segundo Nivel Tercer Nivel Primer Nivel Servidor de Aplicaciones Servidor de Base de Datos Clientes Tareas Tareas Tareas Lógica Principal del Negocio Validación de los Datos Interfaz de Usuario Lógica del Procesamiento de los Datos Acceso a base de Datos
  • 5. Página 7 1.2.5 Monitores de Procesamiento de Transacciones Un monitor de procesamiento de transacciones o monitor TP (transaction processing) es un componente middleware que proporciona acceso a los servicios de una serie de gestores de recursos y proporciona también una interfaz también para los programadores que desarrolle software transaccional. Ventajas • Encaminamiento de transacciones. El monitor TP puede incrementar la estabilidad dirigiendo las transacciones a sistemas SGBD específicos. • Gestiones de transacciones distribuidas. El monitor TP puede gestionar transacciones que requieren acceder a datos almacenados en múltiples y posiblemente heterogéneos SGBD. Por ejemplo una cierta transacción puede requerir actualizar elementos de datos contenidos en un SGBD Oracle en el servidor 1, un SGBD informix en servidor 2, y un SGBD IMS en el servidor 3. Normalmente los monitores TP controlan las transaciones utilizando el estándar X/Open DTP (Distributed Transaction Processing, procesamiento distribuido de transacciones). • Mejora de la fiabilidad. El monitor TP actúa como gestor de transacciones llevando a cabo las acciones necearías para mantener la coherencia de la base de datos, y actuando el SGBD como un gestor de recursos. Si el SGBD falla, el monitor TP puede ser capaz de reenviar la transacción a otro SGBD o puede tenerla hasta que el SGBD vuelva a estar disponible. 2 Componentes en la Arquitectura Cliente/Servidor 2.1 Generalidades ¿Cómo interactúan los componentes? El procesamiento de aplicación se divide en dos procesos principales independiente: Un cliente y un servidor. El middleware de comunicación hace que los proceso cliente y servidor funcionen juntos. También el middleware biene a ser la plataforma en la que se apoya los clientes y servidores; y a la vez es un componente clave del sistema, su presencia tiene un precio al crear una sobre carga adicional sustancial por la adición de puntos de falla en el sistema y, en general, por la adición de complejidad en el funcionamiento del sistema. El Proceso del Cliente envía solicitudEl Middleware comunicaciones envía El proceso de servidor de la a al SQL s través del Middleware de la solicitud al SQL al proceso del BD recibe la solicitud, valida comunicaciones servidor de la BD y ejecuta SQL SQL Red de Proceso Middleware de Servidor de Cliente Datos Comunicaciones Datos Base de Datos
  • 6. Página 8 2.2 Componentes de Cliente El cliente es cualquier proceso que solicita servicios a un proceso de servidor. El cliente es proactivo y por consiguiente, siempre iniciara conversación con el servidor. El cliente incluye componentes de hardware y software: • Hardware poderoso • Un sistema operativo de realizar varias tareas • Una interfaz de usuario grafica (GUI) • Capacidades de comunicación 2.3 Componentes de Servidor El servidor es cualquier proceso que proporciona servicios a procesos cliente. El servidor es reactivo porque siempre espera la solicitud del cliente. Los servidores por general proporcionan: • Servicio de archivo para un ambiente LAN en el cual una computadora con un disco duro grande y rápido en compartido por diferentes usuarios. Un cliente conectado a la red puede guardar archivos en el servidor de archivos como si fuera otro disco duro local. • Servicio de impresión para un ambiente LAN en el cual una pc con una o mas impresoras conectadas es compartida por varios clientes. Un cliente puede acceder a cualquiera de las impresoras como si estuviera directamente conectada a su propia computadora. Los datos a ser impresos viajan de la pc cliente a la pc del servidor de impresión, donde se guardan temporalmente en los discos. Cuando el cliente termina de enviar la tarea de impresión, los datos se trasladan del disco duro del servidor de impresión a la impresora adecuada. • Al igual que el cliente, el servidor también dispone de componentes de hardware y software. • Un CPU rápido (RISC, Pentium, Power Pc o varios procesadores). • Capacidad de tolerancia a las fallas (Fuente de alimentación eléctrica, fuente de poder, memoria con verificación y corrección de errores). • Expansibilidad del CPU, memoria, disco y periféricos. • Soporte de bus para múltiples tarjetas adicionales. 2.4 Componentes de Middleware de Comunicaciones El software de middleware de comunicaciones proporciona los medios mediante los cuales cliente y los servidores se comunican para realizar funciones específicas. Aunque puede ser utilizado en diferentes tipos de escenarios, tales como correo electrónico, fax o traducciones de protocolo de red, la mayoría de middleware de primera generación utilizados en cliente servidor fue pensado para proporcionar el acceso transparente a los datos a varios servidores de base de datos.
  • 7. Página 9 2.4.1 Nivel Físico Se encarga de las comunicaciones entre computadoras cliente y servidor (computadora a computadora). En otras palabras se ocupa de la forma en la que las computadoras están físicamente vinculadas. Los vínculos físicos incluyen el hardware y software de red. El software de red incluye los protocolos de red. 2.4.2 Nivel Lógico Se ocupa de las comunicaciones entre los procesos cliente y servidor (Proceso a proceso), es decir, con la forma en la que se comunican. Las características lógicas son regidas por protocolos proceso a proceso o protocolos de comunicación de comunicación entre procesos. 2.5 Protocolo de Red Un protocolo de red es un conjunto de reglas que determina como se envían, interpretan y procesan los mensajes entre computador. Los protocolos de red permiten que los computadores permiten que las computadoras interactuen en una red y trabajen a diferente niveles del modelo OSI. Los principales protocolos de red son los siguientes: • El Protocolo de transmisión / Protocolo de Internet (TCP/IP) • El Intercambio de paquetes de redes / Intercambio de paquetes de secuencia (IPX/SPX) • Entrada básica a red / Sistema de salida (NetBIOS) • Comunicación programa a programa mediante aplicación (APPC) 2.6 Componentes de Middleware de Base de Datos El middleware de base datos consta de tres componentes principales. • Interface de programación de aplicaciones (API). • Traductor de base de datos. • Traductor de red. 2.6.1 Interface de programación de aplicaciones (API). El API del middleware permite que el programador escriba un código SQL genérico en lugar de un código especifico de cada servidor de base de datos. En otras palabras el API de middleware permite que el proceso cliente sea independiente del servidor de base de datos.
  • 8. Página 10 2.6.2 Traductor de base de datos. Traduce las solicitudes SQL en la sintaxis del servidor de base de datos. Si la solicitud SQL utiliza datos de dos servidores de base de datos diferentes, la capa traductora de la base de datos se encargara de comunicarse con cada servidor. 2.6.3 Traductor de red. Maneja los protocolos de comunicación de red. Los servidores de base de datos pueden utilizar cualquiera de los protocolos de red. 2.7 Clasificación de Middleware El software de middleware se clasifica de acuerdo con la manera en que los clientes y servidores se comunican a través de la red. • Middleware orientados a mensajes (MOM, por sus siglas en ingles). • Middleware basado en llamada a procesamiento remoto (Basado en RPC). • Middleware basado en objetos. 3 Estilo Arquitectónicos de Sistemas Cliente/Servidor 3.1 Generalidades Normalmente los estilos arquitectónicos de cliente servidor dividen los componentes lógicos de procesamiento y aplicación 3.2 Más Detalles Normalmente los estilos arquitectónicos de cliente servidor dividen los componentes lógicos de procesamiento y aplicación. • Componente de entrada y salida (I/O) formatea y presenta los datos en dispositivos de salida, tales como la pantalla y maneja la información ingresada por el usuario mediante dispositivos tales como el teclado. • Componente de procesamiento se refiere al código de aplicación que valida los datos, verifica los errores, etc. La lógica de componente de procesamiento representa las reglas del negocio y la lógica de manejo de los datos para recuperarlos y guardarlos. • El Componente de almacenamiento utiliza lógica de manipulación de datos para encargarse del almacenamiento y recuperación de los datos de los dispositivos de almacenamiento físico Un Servidor web actúa como un servidor de transacciones para coordinar el acceso a los datos de varios clientes. El servidor web también controla el estado de la sesión por cada cliente que accede al servidor, y se comporta eficazmente como servidor de aplicaciones
  • 9. Página 11 4 Temas de Ejecución de Sistemas Cliente/Servidor EL desarrollo de sistemas Cliente/Servidor difiere en gran medida en cuanto a proceso y estilo de lo métodos de desarrollo de sistemas de información tradicionales, por ejemplo, el método de desarrollo de sistemas, orientado hacia el ambiente mainframe centralizado y basado en lenguaje de programación tradicional, difícilmente se puede esperar que funcione bien en un ambiente Cliente/Servidor basado en diversidad de hardware y software. 4.1 Modelo Cliente/Servidor Contra Procesamiento de Datos Tradicionales Las características técnicas básicas d el modelo Cliente/Servidor apenas son suficientes para explicar porque a montado el escenario para otro sacudimiento de información. En cambio, es mas importante señalar que el modelo Cliente/Servidor cambia la manera en que se contempla la mayoría de los temas de procesamiento de datos fundamentales. 4.2 Consideraciones Administrativas Están basados en el manejo de múltiples plataformas, hardware, sistemas operativos y ambientes de desarrollo y en el trato con varios proveedores. Los costos iniciales asociados con la arquitectura Cliente/Servidor debe ser tratados con una inversión que probablemente produzca buenas ganancias por los ahorros subsiguientes de el desarrollo de sistemas nuevos, la flexibilidad incrementada y lo beneficios d servicio a clientes mejorados. 4.3 Herramientas de Desarrollo de Sistemas Cliente/Servidor La selección de un diseño o herramienta de desarrollo de aplicación también puede ser motivada por los requerimientos del sistema. Una vez que se delineen los requerimientos, conviene determinar las características de la herramienta que le gustaría tener. Las herramientas Cliente/Servidor incluyen: Desarrollo basado en GUI • Un constructor GUI que soporte múltiples interfaces (Windows, OS/2, Motif, Macintosh, etc.). • Un diccionario de datos con depósito central de datos y aplicaciones. • Acceso perfecto a múltiples base de datos. • Soporte al desarrollo d equipos. • Soporte de herramientas de desarrollo de terceros (CASE, bibliotecas, etc.). • Soporte de múltiples plataformas (Sistemas Operativos, hardware e interfaces de usuarios graficas). 4.4 Método Integrado Los sistemas Cliente/Servidor nunca deben ser desarrollados solo porque las herramientas disponibles no son técnicamente avanzadas o porque la gerencia desea aprobar una nueva tecnología. Si un estudio completo de la s dimensiones técnicas y humanas de sistemas Cliente/Servidor indica que su uso puede ayudar a alcanzar los fines deseados, es importante que se desarrolle un plan de comercialización antes de iniciar el esfuerzo de desarrollo y diseño del sistema Cliente/Servidor.El objetivo de este plan es construir y obtener el soporte de la gerencia y lo usuarios para el futuro ambiente Cliente/Servidor.
  • 10. Página 12 Anexo A MODELO OSI Por: Ing. Jorge Arroyo R. Definición: La comunicación según el modelo OSI siempre se realizará entre dos sistemas. OSI (Open System Interconect) fue creado por ISO y esta establecido como debe de estar la comunicación entre computadoras. Sus capas se dividen en Software y Hardware. Las Capas del Software son: Capas OSI: Veamos las funciones de cada capa en el modelo OSI. Capa 7: La capa de aplicación: La capa de aplicación es la capa del modelo OSI más cercana al usuario, y está relacionada con las funciones de más alto nivel que proporcionan soporte a las aplicaciones o actividades del sistema, suministrando servicios de red a las aplicaciones del usuario y definiendo los protocolos usados por las aplicaciones individuales. Es el medio por el cual los procesos de aplicación de usuario acceden al entorno OSI. Su función principal es proporcionar los procedimientos precisos que permitan a los usuarios ejecutar los comandos relativos a sus propias aplicaciones. Los procesos de las aplicaciones se comunican entre sí por medio de las entidades de aplicación asociadas, estando éstas controladas por protocolos de aplicación, y utilizando los servicios del nivel de presentación. Difiere de las demás capas debido a que no proporciona servicios a ninguna otra capa OSI, sino solamente a aplicaciones que se encuentran fuera del modelo OSI. La capa de aplicación establece la disponibilidad de los diversos elementos que deben participar en la comunicación, sincroniza las aplicaciones que cooperan entre sí y establece acuerdos sobre los procedimientos de recuperación de errores y control de la integridad de los datos. Algunos ejemplos de procesos de aplicación son: • Programas de hojas de cálculo. • Login remoto (rlogin, telnet). • Programas de procesamiento de texto. • Correo electrónico (mail - smtp). • Transferencia de archivos (ftp). • Páginas web (http). Capa 6: La capa de presentación: La capa de presentación proporciona sus servicios a la capa de aplicación, garantizando que la información que envía la capa de aplicación de un sistema pueda ser entendida y utilizada por la capa de aplicación de otro, estableciendo el contexto sintáctico del diálogo. Su tarea principal es aislar a las capas inferiores del formato de los datos de la aplicación, transformando los formatos particulares (ASCII, EBCDIC, etc.) en un formato común de red.
  • 11. Página 13 Es también las responsable de la obtención y de la liberalización de la conexión de sesión cuando existan varias alternativas disponibles. Por ello, de ser necesario, la capa de presentación realiza las siguientes operaciones: Traducir entre varios formatos de datos utilizando un formato común, estableciendo la sintaxis y la semántica de la información transmitida. Para ello convierte los datos desde el formato local al estándar de red y viceversa. Definir la estructura de los datos a transmitir. Por ejemplo, en el caso de un acceso a base de datos, definir el orden de transmisión y la estructura de los registros. Definir el código a usar para representar una cadena de caracteres (ASCII, EBCDIC, etc). Dar formato a la información para visualizarla o imprimirla. Comprimir los datos si es necesario. Capa 5: La capa de sesión: La capa de sesión proporciona sus servicios a la capa de presentación, proporcionando el medio necesario para que las entidades de presentación en cooperación organicen y sincronicen su diálogo y procedan al intercambio de datos. Sus principales funciones son: Establece, administra y finaliza las sesiones entre dos hosts que se están comunicando. Si por algún motivo una sesión falla por cualquier causa ajena al usuario, esta capa restaura la sesión a partir de un punto seguro y sin perdida de datos o si esto no es posible termina la sesión de una manera ordenada chequeando y recuperando todas sus funciones, evitando problemas en sistemas transaccionales. Sincroniza el diálogo entre las capas de presentación de los dos hosts y administra su intercambio de datos, estableciendo las reglas o protocolos para el dialogo entre maquinas y así poder regular quien habla y por cuanto tiempo o si hablan en forma alterna, es decir, las reglas del dialogo que son acordadas. Ofrece disposiciones para una eficiente transferencia de datos, clase de servicio y un registro de excepciones acerca de los problemas de la capa de sesión, presentación y aplicación. Manejar tokens.- Los tokens son objetos abstractos y únicos que se usan para controlar las acciones de los participantes en la comunicación. Hacer checkpoints; que son puntos de recuerdo en la transferencia de datos. Capa 4: La capa de transporte: La capa de transporte proporciona sus servicios a la capa de sesión, efectuando la transferencia de datos entre dos entidades de sesión. Para ello segmenta los datos originados en el host emisor y los reensambla en una corriente de datos dentro del sistema del host receptor. El límite entre la capa de sesión y la capa de transporte puede imaginarse como el límite entre los protocolos de capa de medios y los protocolos de capa de host. Mientras que las capas de aplicación, presentación y sesión están relacionadas con aspectos de las aplicaciones, las tres capas inferiores se encargan del transporte de datos. Además, esta capa es la primera que se comunica directamente con su par de destino, ya que la comunicación de las capas anteriores es de tipo máquina a máquina. La capa de transporte intenta suministrar un servicio de transporte de datos que aísla las capas superiores de los detalles de implementación del transporte, liberándolas de luchar por conseguir una transferencia de datos segura y económica. Las funciones de la capa de transporte son las siguientes: Controla la interacción entre procesos usuarios. Incluye controles de integración entre usuarios de la red para prevenir perdidas o doble procesamiento de transmisiones. Controla el flujo de transacciones y direccionamiento de maquinas a procesos de usuario. Asegura que se reciban todos los datos y en el orden adecuado, realizando un control de extremo a extremo. Acepta los datos del nivel de sesión, fragmentándolos en unidades más pequeñas, llamadas segmentos, en caso necesario y los pasa al nivel de red. Realiza funciones de control y numeración de unidades de información, fragmentación y reensamblaje de mensajes. Se encarga de garantizar la transferencia de información a través de la sub-red. Capa 3: La capa de red: La capa de red proporciona sus servicios a la capa de transporte, siendo una capa compleja que proporciona conectividad y selección de ruta entre dos sistemas de hosts que pueden estar ubicados en redes geográficamente distintas. También se ocupa de aspectos de contabilidad de paquetes.
  • 12. Página 14 Es la responsable de las funciones de conmutación y encaminamiento de la información, proporcionando los procedimientos precisos necesarios para el intercambio de datos entre el origen y el destino, por lo que es necesario que conozca la topología de la red, con objeto de determinar la ruta más adecuada. Las funciones de la capa de red son: Divide los mensajes de la capa de transporte en unidades más complejas, denominadas paquetes, y los ensambla al final. Debe conocer la topología de la subred y manejar el caso en que las fuente y el destino están en redes distintas. Para ello, se encarga de encaminar la información a través de la sub-red, mirando las direcciones del paquete para determinar los métodos de conmutación y enrutamiento, y rutea los paquetes de la fuente al destino a través de rute adores intermedios. Envía los paquetes de nodo a nodo usando ya sea un circuito virtual o como data gramas. Debe controlar la congestión de la subred. En esta capa es donde trabajan los routers. Capa 2: La capa de enlace de datos: La capa de enlace proporciona sus servicios a la capa de red, suministrando un tránsito de datos confiable a través de un enlace físico. Al hacerlo, la capa de enlace de datos se ocupa del direccionamiento físico (comparado con el lógico), la topología de red, el acceso a la red, la notificación de errores, formación y entrega ordenada de tramas y control de flujo. Por lo tanto, su principal misión es convertir el medio de transmisión en un medio libre de errores de cualquier tipo. Sus principales funciones son: Establece los medios necesarios para una comunicación confiable y eficiente entre dos máquinas en red. Agrega una secuencia especial de bits al principio y al final del flujo inicial de bits de los paquetes, estructurando este flujo bajo un formato predefinido llamado trama o marco. Suelen ser de unos cientos de bytes. Sincroniza el envío de las tramas, transfiriéndolas de una forma confiable libre de errores. Para detectar y controlar los errores se añaden bits de paridad, se usan CRC (Códigos Cíclicos Redundantes) y envío de acuses de recibo positivos y negativos, y para evitar tramas repetidas se usan números de secuencia en ellas. Envía los paquetes de nodo a nodo usando ya sea un circuito virtual o como data gramas. Controla la congestión de la red. Regula la velocidad de tráfico de datos. Controla el flujo de tramas mediante protocolos que prohíben que el remitente envíe tramas sin la autorización explícita del receptor, sincronizando así su emisión y recepción. Se encarga de la de secuencia, de enlace lógico y de acceso al medio (soportes físicos de la red). Capa 1: La capa física: La misión principal de esta capa es transmitir bits por un canal de comunicación, de manera que cuanto envíe el emisor llegue sin alteración al receptor. La capa física proporciona sus servicios a la capa de enlace de datos, definiendo las especificaciones eléctricas, mecánicas, de procedimiento y funcionales para activar, mantener y desactivar el enlace físico entre sistemas finales, relacionando la agrupación de circuitos físicos a través de los cuales los bits son movidos. Las características tales como niveles de voltaje, temporización de cambios de voltaje, velocidad de datos físicos, distancias de transmisión máximas, conectores físicos y otros atributos similares se definen a través de las especificaciones de la capa física. Sus principales funciones las podemos resumir en: Definir las características físicas (componentes y conectores mecánicos) y eléctricas (niveles de tensión). Definir las características funcionales de la interfaz (establecimiento, mantenimiento y liberación del enlace físico). Transmitir el flujo de bits a través del medio. No existe estructura alguna. Maneja voltajes y pulsos eléctricos. Especificar cables, conectores y componentes de interfaz con el medio de transmisión, polos en un enchufe, etc. Garantizar la conexión, pero no la fiabilidad de ésta. Esta capa solamente reconoce bits individuales, no reconoce caracteres ni tramas multicaracter. El modelo OSI - TCP/IP Protocolos TCP/IP: Este protocolo se encarga de fragmentar la información para que llegue sin errores. Ofrece una conexión en ambientes diferentes, nos permite una conectividad universal y se divide en las siguientes capas: Internet Aplicación Transporte Red IP.- Se encarga del direccionamiento. Características del IP: Es un protocolo orientado a no conexión. Hace todo lo posible para que un paquete llegue a su destino.
  • 13. Página 15 Le importa solo la dirección. El diagrama que aparece en la siguiente figura se denomina gráfico de protocolo. Este gráfico ilustra algunos de los protocolos comunes especificados por el modelo de referencia TCP/IP. En la capa de Aplicación: Aparecen distintas tareas de red que probablemente usted no reconozca, pero como usuario de Internet, probablemente use todos los días. Estas aplicaciones se ven controladas por los siguientes protocolos: FTP: File Transfer Protocol (Protocolo de transporte de archivos). Este protocolo permite el acceso al sistema de directorios de un ordenador remoto y el envío y la descarga de ficheros de ellos. Como medida de seguridad, el acceso a dichos directorios está protegido por un sistema de control de acceso de tipo usuario - password. TELNET: Protocolo de servicio de conexión remota (remote login). Es un emulador de terminal que permite acceder a los recursos y ejecutar programas en un ordenador remoto; es decir, nos permite conectarnos a un equipo remoto y actuar sobre él como si estuviéramos físicamente conectados al mismo. HTTP: Hypertext Transfer protocol (Protocolo de transferencia de hipertexto). Proporciona el servicio de páginas web, mediante el cual podemos solicitar éstas a un servidor web y visualizarlas en los navegadores clientes. SMTP: Simple Mail transport protocol ( Protocolo de transporte de correo simple). Proporciona el servicio de correo electrónico, permitiendo enviar mensaj4es a otros usuarios de la red. Estos mensajes se envían primero a unos equipos servidores especiales, desde los cuales pueden ser descargados por el destinatario final. DNS: Domain Name Service (Servicio de nombre de dominio). Proporciona el servicio de traducción de nombres de domino en direcciones IP reales. TFTP:Trival File transport protocol (Protocolo de transporte de archivo trivial). El modelo TCP/IP enfatiza la máxima flexibilidad, en la capa de aplicación, para los diseñadores de software. Capa de Transporte: Las funciones principales de la capa de transporte son regular el flujo de información para garantizar la conectividad de extremo a extremo entre aplicaciones de host de manera confiable y precisa.. El control de extremo a extremo, que suministran las ventanas deslizantes, y la confiabilidad proporcionada por el uso de números de secuencia y acuses de recibo son las funciones principales de la Capa 4. En la Capa de Transporte aparecen dos protocolos principales:
  • 14. Página 16 1) Protocolo para el Control de la Transmisión (TCP): Que ofrece maneras flexibles y de alta calidad para crear comunicaciones de red confiables, sin problemas de flujo y con un nivel de error bajo. Las conexiones TCP son punto a punto y full dúplex, caracterizándose éste último tipo porque en ellas se permite una transferencia concurrente en ambas direcciones, con lo que en realidad existen dos flujos independientes que se mueven en direcciones opuestas y sin ninguna interacción aparente. Este hace que se reduzca eficazmente el tráfico en la red. 2) Protocolo de Data grama de Usuario (UDP): Protocolo no confiable y no orientado a conexión para la entrega de mensajes discretos. En este caso los paquetes enviados mediante el protocolo IP reciben el nombre específico de data gramas, y estos se envían y ya está; no se realiza una conexión definida entre los host ni un control de los paquetes enviados y recibidos. Los data gramas se rutean independientemente, por lo que deben llevar las dirección completa de destino. En la capa de Internet o red : Del modelo TCP/IP existe solamente un protocolo, el protocolo Internet (IP), independientemente de la aplicación que solicita servicios de red o del protocolo de transporte que se utiliza. Esta es una decisión de diseño deliberada. IP sirve como protocolo universal que permite que cualquier computador en cualquier parte del mundo pueda comunicarse en cualquier momento, y es la base fundamental de Internet. El protocolo IP define las unidades de transferencia de datos, denominadas paquetes o data gramas, y se encarga de su transferencia desde el host origen al host destino. Se implementa por software. Una dirección IP identifica un host de forma única. Dos host no pueden tener una misma dirección IP pública, pero si pueden tener la misma IP si pertenecen a dos redes privadas diferentes. El protocolo IP no está orientado a conexión y no es confiable, ya que manda paquetes (data gramas) sin contar con mecanismos de verificación de entrega y sin comprobación de errores. En la capa de acceso a la red: Como TCP/IP no especifica claramente un protocolo de nivel de enlace de datos, eran necesarios un mecanismos para traducir las direcciones IP a direcciones que entendieran el software de capa de enlace de datos por sobre el que corre TCP/IP y para controlar posibles errores a nivel de subred. Por eso se introdujeron protocolos específicos, entre los que destacan: ICMP (Protocolo de Mensajes de Control y Error de Internet): es de características similares a UDP, pero con un formato mucho más simple, y su utilidad no está en el transporte de datos de usuario, si no en controlar si un paquete no puede alcanzar su destino. ARP (Protocolo de Resolución de Direcciones): una vez que un paquete llega a una red local mediante el ruteo IP, la entrega del mismo al host destino se debe realizar forzosamente mediante la dirección MAC del mismo (número de la tarjeta de red), por lo que hace falta algún mecanismo capaz de transformar la dirección IP que figura como destino en el paquete en la dirección MAC equivalente, es decir, de obtener la relación dirección lógica-dirección física. De esta labor se encarga el protocolo ARP, que en las LAN equipara direcciones IP con direcciones Ethernet (de 48 bits) de forma dinámica, evitando así el uso de tablas de conversión. RARP (ARP por Réplica): permite que una máquina que acaba de arrancar o sin disco pueda encontrar su dirección IP desde un servidor. Para ello utiliza el direccionamiento físico de red, proporcionando la dirección hardware física (MAC) de la máquina de destino para identificar de manera única el procesador, transmitiendo por difusión la solicitud RARP. Una vez que la máquina obtiene su dirección IP la guarda en memoria, y no vuelve e usar RARP hasta que no se inicia de nuevo.
  • 15. Página 17 Anexo B Elementos de Bases de Datos Distribuidas En el procesamiento distribuido una máquina, conectada en una red local (LAN) o amplia (WAN) a otras máquinas, puede realizar una tarea de procesamiento de datos en ella y sobre el resto de las máquinas de la red, de tal manera que los procesos y los datos se ejecuten de manera paralela, coherente y mediante ciertas reglas en uno o varios nodos de la red. Si los nodos se encuentran localizados en un sistema físico de cómputo compacto, tendremos un esquema “estrictamente paralelo” y si los nodos están dispersos geográficamente entonces nos encaramos a un sistema distribuido. La comunicación entre los nodos se garantiza mediante un SO de red o bien con un componente de software de comunicaciones. Una organización diferencial posible para los sistemas distribuidos se compone por cuatro categorías, a saber: 1. Sistema Dorsal o Arquitectura Centralizada. Hay un solo servidor y varios clientes, en el servidor se encuentra instalado el DBMS y residen las BD para diversas aplicaciones. Los clientes mediante su poder local de cómputo, presentan las interfases a los usuarios y preparan las transacciones solicitadas, las cuales son enviadas al servidor para su procesamiento. Este modelo tiene la ventaja de repartir el trabajo en partes (en paralelo), lo cual mejora el tiempo de respuesta y reduce la latencia en las comunicaciones. a. El servidor puede ser una máquina especializada de alto rendimiento para el manejo de BD, por ejemplo contener un arreglo de discos duros de alta velocidad y rendimiento (SCSI) y un sistema operativo estable multitarea, multiusuario y con seguridad. b. El cliente puede ser una estación de trabajo personal (PC) con software y hardware adaptado a las necesidades del usuario final, con alta disponibilidad, respuesta rápida y autonomía local para procesos internos. De esta manera varias máquinas cliente podrán acceder a la misma máquina que juega el rol de servidor. Por lo cual una base de datos puede ser compartida entre distintos clientes. Este modelo se acopla en términos formales al mecanismo que utilizan las empresas e instituciones. Por ejemplo es común que una empresa operen muchas computadoras, donde algunas juegan el papel de servidores y el resto (la mayoría) de clientes. Más no se descarta que alguna de ellas juegue el doble rol, es decir ser servidor para algunas y cliente para otras. Podemos decir que al menos en los servidores se puede afirmar que cada uno de ellos soporta un sistema de bases de datos completo, en el sentido de las BD distribuidas. 2. Arquitectura Distribuida. El sistema se conforma por varios servidores y varios clientes. Cada servidor contiene su DBMS y una o varias BD’s. Los clientes dependiendo de las necesidades del usuario se conectan a uno o varios servidores para satisfacer sus demandas. EL acceso puede ser proporcionado de dos maneras: a. Un cliente puede acceder a cualquier servidor, pero solo a uno a la vez. De tal forma que el cliente conoce donde debe solicitar la información. En este esquema no es posible combinar datos de dos o más servidores en una misma petición. b. El cliente puede acceder a varios servidores a la vez, de tal forma que una petición de base de datos puede combinar información de varios servidores. Este modelo tiene la ventaja de que el usuario no tiene que saber en qué servidor se encuentran ubicados los datos. El soporte de una base de datos distribuida implica que las aplicaciones deben operar de manera transparente sobre los datos que están dispersos sobre la red, donde es posible que los manejadores de BD locales (en cada servidor) utilicen una representación diferente para los datos, es decir los DBMS no tienen que ser iguales, así como los Sistemas Operativos (SO) en cada servidor. Al referirnos a “transparencia” debemos entender que la aplicación opera como si los datos fueran manejados por un solo DMBS y en una sola máquina donde reside un servidor virtual. Una característica extra de este modelo es que un servidor puede atender a muchos clientes o bien servidores a la vez. Para que un sistema distribuido trabaje adecuadamente además es necesario contar con un sistema de comunicaciones (red) robusto, estable y oportuno. Lo cual incluye un ingrediente más a la arquitectura de los sistemas distribuidos.
  • 16. Página 18 El principio fundamental de una Base de Datos Distribuida (BDD) es que: Ante un usuario, un sistema distribuido se comporta exactamente igual que uno no distribuido. Entonces los problemas de los sistemas distribuidos son problemas internos o en el nivel de implementación, y no externos o en el nivel del usuario. Los sistemas de BDD operan sobre 12 reglas u objetivos interrelacionados, a continuación se presenta un resumen de estos, para mayor detalle ver. 1. Autonomía local. Los sitios deben ser autónomos, es decir las operaciones en un sitio X están controladas por él; de tal suerte que la operación satisfactoria de X no depende de otro sitio Y. Esto implica que los datos locales son propiedad del sitio y son administrados por él. Debido a esto la seguridad, integridad y representación de almacenamiento de los datos locales permanecen bajo el control y jurisdicción del sitio local. 2. Independencia de un sitio central. No debe haber un sitio “maestro” central para algún servicio central de tal manera que todo el sistema dependa de ese sitio central. La existencia de sitios maestros conlleva al problema de vulnerabilidad de todo el sistema por una falla de éste. 3. Operación continua. El sistema no debe interrumpir de manera aleatoria sus servicios. Esto se refleja en la confiabilidad y disponibilidad: la primera implica que la respuesta del sistema debe ser sostenida a pesar que uno o varios sitios fallen; y la segunda debe garantizar que casi todo el tiempo el sistema responda a las solicitudes. Estos objetivos se alcanzan mediante la replicación y la redundancia, juntos forma el esquema de tolerancia a fallas. 4. Independencia de la Ubicación. Esta también se conoce como transparencia de ubicación y consiste en el hecho de que los usuarios no tienen que saber dónde se encuentran almacenados físicamente los datos, sino que deben ser capaces de comportarse, al menos desde el punto de vista lógico, como si estuvieran almacenados de forma local. 5. Independencia de fragmentación. También llamada transparencia de fragmentación. Los datos, a nivel de registros o tablas, pueden estar fragmentados, es decir distribuidos en diferentes sitios para efectos de almacenamiento físico. Normalmente la fragmentación se provoca para localizar los datos en los sitios donde son utilizados con mayor frecuencia, esto reduce el uso de la red para realizar las transacciones y aumenta la velocidad de respuesta del sistema de BDD. Existen dos tipos de fragmentación: horizontal y vertical. La primera se refiera a partir las tablas en partes con registros íntegros; y la segunda corresponde a separar los campos de los registros en dos o mas sub-tablas, donde cada una de éstas contiene las llaves para la localización del registro. Un principio básico que se debe cumplir es que todos los fragmentos deben ser independientes, es decir que ninguno de ellos podrá ser derivado a partir de los otros ni existen restricciones o proyecciones que puedan ser derivadas a partir de otros. 6. Independencia de replicación. Esto significa que una tabla o un fragmento distribuido de ella que se encuentra almacenado en algún sitio puede ser representado por otras copias (réplicas) almacenadas en diferentes sitios. Esta propiedad se denomina redundancia controlada. La principal desventaja de la replicación radica en que al hacer un cambio en algún registro, éste se debe propagar a los demás sitios que contengan copias sin violar la integridad del sistema completo de la BDD. En general será responsabilidad del encargado del sistema de definir cuáles réplicas deben ser accedidas físicamente para satisfacer una solicitud de usuario dada. 7. Procesamiento distribuido de consultas. Este criterio implica que el sistema debe optimizar las transacciones de tal manera que se reduzca el tráfico en la red y se acceda a la réplica más cercana o bien al sitio de menor tiempo de respuesta. Esto implica que el modelo a utilizarse para realizar las transacciones debe ser al menos relacional. 8. Administración de transacciones distribuidas. Dada la característica distribuida del sistema, se deben tomar las previsiones necesarias para garantizar el control de la recuperación de los datos y el control de concurrencia. El mecanismo natural que se utiliza es de agentes, es decir dado que se BD/CS:2004:MM12 pueden realizar varias transacciones de forma concurrente en diferentes sitios, los agentes se encargarán de realizar las transacciones en cada sitio representando la transacción original del usuario. 9. Independencia del hardware. Esta regla define que debe ser posible ejecutar el mismo DBMS en diferentes plataformas de hardware, de tal manera que cada máquina participe como un socio igualitario ene l sistema distribuido. 10. Independencia del Sistema Operativo. Este criterio implica que cada sitio puede funcionar con un sistema operativo diferente (tanto de versión como de tecnología). Y a pesar de esto el DBMS debe operar en cada sitio de la misma manera. 11. Independencia de la red. Esto implica que algunos nodos pueden trabajar sobre redes de comunicación diferentes, pero el sistema en general puede comunicar a un nodo con otro en todo momento. Esto se logra mediante dispositivos de traducción e interfase, los cuales hacen compatibles los mensajes de entrada y salida. 12. Independencia del DBMS. En todos los sitios de tipo servidor no necesariamente opera el mismo DBMS, sino que se requiere que cada DBMS local soporte la misma interfase para las transacciones. Este principio completa el esquema heterogéneo de un sistema de BDD. En general el problema principal que debe resolverse para la operación correcta de un sistema de BDD es la reducción del uso de la red, es decir se debe minimizar la cantidad y volumen de los mensajes entre sitios. Los aspectos donde impacta más este aspecto son los siguientes: • Procesamiento de consultas • Control de recuperación • Administración de catálogos. • Control de concurrencia • Propagación de las actualizaciones • Procesos de mantenimiento En particular cada DBMS para ambientes distribuidos ofrece diferentes mecanismos para atender éstas problemáticas.
  • 17. Página 19 Anexo C ODBC El estándar ODBC (Open Data Base Connectivity, Conectividad abierta de base de datos) es una interfaz propuesta por Microsoft para facilitar el desarrollo de aplicaciones sobre entornos de bases de datos distribuidas. La mayoría de las bases de datos comerciales soportan este estándar y existe una versión adaptada a Java, llamada JDBC. Más concretamente. ODBC es una versión restringida de SQL que contiene los comandos más comúnmente utilizados. Bajo esta arquitectura, la conexión entre una aplicación y un servidor de datos requiere la utilización de una librería que oculta las diferencias de interacción debidas al sistema de gestión de bases de datos, el sistema operativo y el protocolo de red utilizados. Estas librerías son proporcionadas por los fabricantes de sistemas de gestión de bases de datos. El acceso a una base de datos remota desde una aplicación requiere los siguientes pasos: • La aplicación formula las consultas SQL en el lenguaje de ODBC. • Un gestor de librerías proporcionado por Microsoft se encarga de arrancar la librería adecuada, dependiendo del servidor al que vaya dirigido la consulta. • La librería traduce la consulta al lenguaje específico del sistema de gestión de base de datos del servidor que la debe ejecutar. • El servidor optimiza y ejecuta la consulta. Esquema de comunicación ODBC
  • 18. Página 20 Bibliografía Sistemas de Base de Datos Thomas M. Connolly – Carolyn E. Begg. PEARSON Addison Wesley Cuarta edición Sistemas de Base de Datos Peter Rob – Carlos Coronel. Thomsom Quinta edición Aplicaciones de datos Cliente / Servidor Dr. Marín Ortiz. Benemérita Universidad Autónoma de Puebla Primera edición Redes y Protocolos de Red Ing. Jorge Arroyo R. Universidad San Pedro Primera edición Arquitectura de Computadoras Stallings Prience Hall Primera edición