Base de datos: sistemas_clienteservidor

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

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.

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)

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

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

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.

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.

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

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.

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.

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.

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.

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:

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.

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.

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.

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

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

Base de datos: sistemas_clienteservidor

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Base de datos: sistemas_clienteservidor

Más de Jonathan

Base de datos: sistemas_clienteservidor