TECNOLÓGICO DE ESTUDIOS SUPERIORES

DE TIANGUISTENCO

MATERIA: BASE DE DATOS DISTRIBUIDAS

UNIDAD 1 FUNDAMENTOS DE BASE DE

DATOS DISTRIBUIDAS

1.5 DEFINICIÓN DEL TÉRMINO CLIENTE-

SERVIDOR
1.6 ARQUITECTURA DE CLIENTE-
SERVIDOR
1.7 INTEGRACIÓN DE DATOS VS
DISTRIBUCIÓN DE DATOS

DOCENTE: ALEJANDRO GONZÁLEZ ZETA

ALUMNO: ENRIQUE EMILIANO SANTOS

CANTÚ

MATRICULA: 201523030

GRUPO: 3901
1.5 DEFINICIÓN DEL TERMINO CLIENTE-SERVIDOR
La expresión cliente servidor se utiliza en el ámbito de la informática. En dicho
contexto, se llama cliente al dispositivo que requiere ciertos servicios a un
servidor. La idea de servidor, por su parte, alude al equipo que brinda servicios a
las computadoras (ordenadores) que se hallan conectadas con él mediante una
red.
El concepto de cliente servidor, o cliente-servidor, refiere por lo tanto a un modelo
de comunicación que vincula a varios dispositivos informáticos a través de
una red. El cliente, en este marco, realiza peticiones de servicios al servidor, que
se encarga de satisfacer dichos requerimientos.
Con esta arquitectura, las tareas
se distribuyen entre los servidores (que
proveen los servicios) y los clientes (que
demandan dichos servicios). Dicho de
otro modo: el cliente le pide un recurso
al servidor, que brinda una respuesta.
Este tipo de modelos permite repartir de
la capacidad de procesamiento.
El servidor puede ejecutarse sobre más
de un equipo y ser más de un programa.
De acuerdo a los servicios que brinda,
se lo puede llamar servidor web, servidor de correo o de otro modo.
En las redes estructuradas bajo el modelo cliente servidor, los clientes centralizan
diferentes aplicaciones y recursos en el servidor. El servidor, a su vez, se encarga
de que estos recursos estén disponibles cada vez que un cliente los requiere.
Es importante mencionar que gran parte de los servicios de Internet obedecen a la
arquitectura cliente servidor. El servidor web pone a disposición del cliente los
sitios web, a los cuales el cliente accede a través de su navegador. El servidor, de
esta manera, aloja los datos que el cliente solicita mediante el navegador instalado
en su computadora.
Entre las disposiciones más comunes del modelo cliente servidor se encuentran
los sistemas multicapa, según los cuales el servidor ofrece la ejecución de varios
programas para que varios ordenadores puedan solicitarlos según sus
necesidades, de manera que el nivel de distribución aumenta.

Una de las ventajas menos aparentes de la

organización en servidores y clientes es que
la capacidad de procesamiento y memoria
de estos últimos no debe ser tan grande
como la de los primeros, lo cual beneficia al
consumidor final permitiéndole usar un
equipo relativamente antiguo para disfrutar
de servicios generalmente muy avanzados.
Por ejemplo, a pesar de que el correo
electrónico parezca una “aplicación” muy liviana y sencilla, los servidores deben
almacenar volúmenes colosales de datos para satisfacer a todos sus clientes, y,
por consiguiente, realizar búsquedas y consultas muy demandantes para
responder a todas sus solicitudes. Cuando buscamos un término en nuestra casilla
para dar con un mensaje en particular, el servidor debe revisar cientos o miles de
archivos, y lo hace en una fracción de segundo, algo que sería imposible en
nuestros hogares.
Los sistemas de streaming de videojuegos para usarlos a distancia son otro
ejemplo, en este caso mucho más exigente que el correo electrónico, ya que el
cliente puede disfrutar de un programa de última generación en tiempo real con un
ordenador que simplemente le permita recibir el vídeo de forma fluida y enviar
los eventos de su mando, teclado y ratón.

1.6 ARQUITECTURA DE CLIENTE-SERVIDOR

La arquitectura cliente/servidor persigue el objetivo de procesar la información de
un modo distribuido. De esta forma, los usuarios finales pueden estar dispersos en
un área geográfica más o menos extensa (un edificio, una localidad, un país, …) y
acceder a un conjunto común de recursos compartidos.
Además, el acceso debe ser transparente (el cliente puede desconocer la
ubicación física del recurso que pretende utilizar) y, preferiblemente,
multiplataforma, es decir, independiente del sistema operativo, del software de
aplicación e incluso del hardware. En definitiva, cuando hablamos de la
implantación de una arquitectura cliente/servidor, nos referimos a un sistema de
información distribuido.

Además de la transparencia y la independencia del hardware y del software, una

implantación cliente/servidor debe tener las siguientes características:
Las características de una implantación cliente/servidor deben ser:
 Debe utilizar protocolos asimétricos, donde el servidor se limita a escuchar,
en espera de que un cliente inicie una solicitud.
 El servidor ofrecerá recursos, tanto lógicos como físicos a una cantidad
variable y diversa de clientes (por ejemplo, espacio de almacenamiento,
bases de datos, impresoras, etc.)
 El servidor ofrecerá también una serie de servicios, que serán usados por
los clientes. Estos servicios estarán encapsulados, para ocultar a los
clientes los detalles de su implementación (por ejemplo, aceptar el
requerimiento de un cliente sobre una base de datos o formatear los datos
obtenidos antes de transmitirlos al cliente).
  Se facilitará la integridad y el mantenimiento tanto de los datos como de los
programas debido a que se encuentran centralizados en el servidor o
servidores.
 Los sistemas estarán débilmente acoplados, ya que interactúan mediante el
envío de mensajes.
 Se facilitará la escalabilidad, de manera que sea fácil añadir nuevos clientes
a la infraestructura (escalabilidad horizontal) o aumentar la potencia del
servidor o servidores, aumentando su número o su capacidad de cálculo
(escalabilidad vertical)
Elementos de la arquitectura cliente/servidor.
De lo dicho hasta ahora, podemos deducir que los principales elementos que
conforman la arquitectura cliente/servidor son los siguientes:
El servidor
Cuando hablamos de una forma genérica, si mencionamos a un servidor, nos
referimos a un ordenador, normalmente con prestaciones elevadas, que ejecuta
servicios para atender las demandas de diferentes clientes.
Sin embargo, bajo el punto de vista de la arquitectura cliente/servidor, un servidor
es un proceso que ofrece el recurso (o recursos) que administra a los clientes que
lo solicitan (consultar la definición de cliente más abajo).
Es muy frecuente que, para referirse a un proceso servidor, se utilice el
término back-end.
Según el tipo de servidor implantado, tendremos un tipo de arquitectura
cliente/servidor diferente.
Por último, mencionar que en algunas ocasiones, un servidor puede actuar, a su
vez, como cliente de otro servidor.
El cliente
Igual que antes, al hablar de forma genérica sobre un cliente, nos referimos a un
ordenador, normalmente con prestaciones ajustadas, que requiere los servicios de
un equipo servidor.
Sin embargo, bajo el punto de vista de la arquitectura cliente/servidor, un cliente
es un proceso que solicita los servicios de otro, normalmente a petición de un
usuario.
En entornos cliente/servidor, suele utilizarse el término front-end para referirse a
un proceso cliente.
Normalmente, un proceso cliente se encarga de interactuar con el usuario, por lo
que estará construido con alguna herramienta que permita implementar interfaces
gráficas (GUI). Además, se encargará de formular las solicitudes al servidor y
recibir su respuesta, por lo que deberá encargarse de una parte de la lógica de la
aplicación y de realizar algunas validaciones de forma local.

El Middleware
Es la parte del software del sistema que se encarga del transporte de los
mensajes entre el cliente y el servidor, por lo que se ejecuta en ambos lados de la
estructura.
El middleware permite independizar a los clientes y a los servidores, sobre todo,
gracias a los sistemas abiertos, que eliminan la necesidad de supeditarse a
tecnologías propietarias.
Por lo tanto, el middleware facilita el desarrollo de aplicaciones, porque resuelve la
parte del transporte de mensajes y facilita la interconexión de sistemas
heterogéneos sin utilizar tecnologías propietarias.
Además, ofrece más control sobre el negocio, debido a que permite obtener
información desde diferentes orígenes (uniendo tecnologías y arquitecturas
distintas) y ofrecerla de manera conjunta.
Podemos estructurar el middleware en tres niveles:
 El protocolo de transporte, que será común para otras aplicaciones del
sistema.
 El sistema operativo de red
 El protocolo del servicio, que será específico del tipo de sistema
cliente/servidor que estemos considerando.
El funcionamiento básico
Aunque es probable que a estas alturas ya te hagas una idea sobre el
funcionamiento general del modelo cliente/servidor, vamos a concretarlo a
continuación:
Lo primero que debe ocurrir es que se inicie el servidor. Esto ocurrirá durante el
arranque del sistema operativo o con la intervención posterior del administrador
del sistema. Cuando termine de iniciarse, esperará de forma pasiva las solicitudes
de los clientes.
En algún momento, uno de los clientes conectados al sistema realizará una
solicitud al servidor.
El servidor recibe la solicitud del cliente, realiza cualquier verificación necesaria y,
si todo es correcto, la procesa.
Cuando el servidor disponga del resultado solicitado, lo envía al cliente.
Finalmente, el cliente recibe el resultado que solicitó. A continuación realiza las
comprobaciones oportunas (si son necesarias) y, si era ese el objetivo final, se lo
muestra al usuario.

Si descomponemos este modo de

funcionamiento en elementos
estructurales, será más fácil
comprender los conceptos
implicados.
[CITATION 13Ag \l 2058 ]

De esta forma, podemos obtener una definición de la arquitectura por niveles,

estructurada como sigue:
 Un nivel de presentación, que aglutina los elementos relativos al cliente.
 Un nivel de aplicación, compuesto por elementos relacionados con el
servidor.
 Un nivel de comunicación, que está formado por los elementos que hacen
posible la comunicación entre el cliente y el servidor.
 Un nivel de base de datos, formado por los elementos relacionados con el
acceso a los datos.
Elementos de la arquitectura cliente/servidor.
De lo dicho hasta ahora, podemos deducir que los principales elementos que
conforman la arquitectura cliente/servidor son los siguientes:
El servidor
Cuando hablamos de una forma genérica, si mencionamos a un servidor, nos
referimos a un ordenador, normalmente con prestaciones elevadas, que ejecuta
servicios para atender las demandas de diferentes clientes.
Sin embargo, bajo el punto de vista de la arquitectura cliente/servidor, un servidor
es un proceso que ofrece el recurso (o recursos) que administra a los clientes que
lo solicitan (consultar la definición de cliente más abajo).
Es muy frecuente que, para referirse a un proceso servidor, se utilice el
término back-end.
Según el tipo de servidor implantado, tendremos un tipo de arquitectura
cliente/servidor diferente.
Por último, mencionar que en algunas ocasiones, un servidor puede actuar, a su
vez, como cliente de otro servidor.
El cliente
Igual que antes, al hablar de forma genérica sobre un cliente, nos referimos a un
ordenador, normalmente con prestaciones ajustadas, que requiere los servicios de
un equipo servidor.
Sin embargo, bajo el punto de vista de la arquitectura cliente/servidor, un cliente
es un proceso que solicita los servicios de otro, normalmente a petición de un
usuario.
En entornos cliente/servidor, suele utilizarse el término front-end para referirse a
un proceso cliente.
Normalmente, un proceso cliente se encarga de interactuar con el usuario, por lo
que estará construido con alguna herramienta que permita implementar interfaces
gráficas (GUI). Además, se encargará de formular las solicitudes al servidor y
recibir su respuesta, por lo que deberá encargarse de una parte de la lógica de la
aplicación y de realizar algunas validaciones de forma local.
El Middleware
Es la parte del software del sistema que se encarga del transporte de los
mensajes entre el cliente y el servidor, por lo que se ejecuta en ambos lados de la
estructura.
El middleware permite independizar a los clientes y a los servidores, sobre todo,
gracias a los sistemas abiertos, que eliminan la necesidad de supeditarse a
tecnologías propietarias.
Por lo tanto, el middleware facilita el desarrollo de aplicaciones, porque resuelve la
parte del transporte de mensajes y facilita la interconexión de sistemas
heterogéneos sin utilizar tecnologías propietarias.
Además, ofrece más control sobre el negocio, debido a que permite obtener
información desde diferentes orígenes (uniendo tecnologías y arquitecturas
distintas) y ofrecerla de manera conjunta.
Podemos estructurar el middleware en tres niveles:
 El protocolo de transporte, que será común para otras aplicaciones del
sistema.
 El sistema operativo de red
 El protocolo del servicio, que será específico del tipo de sistema
cliente/servidor que estemos considerando.
 El funcionamiento básico
Aunque es probable que a estas alturas ya te hagas una idea sobre el
funcionamiento general del modelo cliente/servidor, vamos a concretarlo a
continuación:
Lo primero que debe ocurrir es que se inicie el servidor. Esto ocurrirá durante el
arranque del sistema operativo o con la intervención posterior del administrador
del sistema. Cuando termine de iniciarse, esperará de forma pasiva las solicitudes
de los clientes.
En algún momento, uno de los clientes conectados al sistema realizará una
solicitud al servidor.
El servidor recibe la solicitud del cliente, realiza cualquier verificación necesaria y,
si todo es correcto, la procesa.
Cuando el servidor disponga del resultado solicitado, lo envía al cliente.
Finalmente, el cliente recibe el resultado que solicitó. A continuación realiza las
comprobaciones oportunas (si son necesarias) y, si era ese el objetivo final, se lo
muestra al usuario.

Si descomponemos este modo de

funcionamiento en elementos estructurales,
será más fácil comprender los conceptos
implicados. De esta forma, podemos obtener
una definición de la arquitectura por niveles,
estructurada como sigue:
 Un nivel de presentación, que aglutina los elementos relativos al cliente.
 Un nivel de aplicación, compuesto por elementos relacionados con el
servidor.
 Un nivel de comunicación, que está formado por los elementos que hacen
posible la comunicación entre el cliente y el servidor.
 Un nivel de base de datos, formado por los elementos relacionados con el
acceso a los datos.

1.7 INTEGRACIÓN DE DATOS VS DISTRIBUCIÓN DE

DATOS
La integración de datos es el proceso que implica combinar datos desde distintas
fuentes en una única visión unificada: empezando por la ingesta, la limpieza, el
mapeo hasta la transformación en un colector determinado y, por último, convertir
los datos en elementos más explotables y valiosos para aquellos que acceden a
ellos. Actualmente las empresas llevan a cabo iniciativas de integración de datos
para analizar y tomar decisiones a partir de sus datos de forma más eficaz, en
especial dada la explosión de datos y de nuevas tecnologías cloud y de big data.
La integración de datos es una obligación, puesto que permite a las empresas
modernas mejorar la toma de decisiones estratégica y aumentar su ventaja
competitiva.
No existe un planteamiento universal en materia de integración. No obstante, las
soluciones de integración de datos existentes suelen contener elementos
comunes, como una red de fuentes de datos, un servidor maestro y clientes que
acceden a los datos desde el servidor maestro.
En un proceso típico de integración de datos, el cliente envía una solicitud de
datos al servidor maestro. A continuación, el servidor maestro incorpora los datos
necesarios desde fuentes internas y externas. Se extraen los datos de las fuentes
y luego se combinan en un formato cohesionado y unificado. El resultado se hace
llegar al cliente en un formato explotable y cohesionado.
1. La integración de datos mejora la colaboración y unificación de sistemas
Cada vez más los empleados de todos los departamentos (y en ocasiones en
ubicaciones físicas dispares) necesitan acceder a los datos de la empresa para
proyectos tanto compartidos como particulares. Informática requiere una solución
segura para poder suministrar los datos mediante un acceso en autoservicio por
todas las líneas de negocio.
Además, los empleados de prácticamente todos los departamentos generan y
mejoran datos que el resto del negocio necesita. La integración de datos necesita
ser colaborativa y unificada para poder mejorar la colaboración y la unificación en
la organización.
2. La integración de datos ahorra tiempo
Cuando una empresa adopta medidas para integrar sus datos adecuadamente,
rebaja de forma notable el tiempo que dedica a preparar y analizar los datos. La
automatización de visiones unificadas elimina la necesidad de recabar datos
manualmente y los empleados ya no necesitan crear conexiones desde cero cada
vez que tienen que ejecutar un informe o crear una aplicación.
Además, utilizando las herramientas más adecuadas, en lugar de programar
manualmente la integración restituye aún más tiempo (y recursos en general) al
equipo de desarrollo.
Todo el tiempo que se ahorra en estas tareas puede dedicarse a mejores usos,
con más horas asignadas al análisis y la ejecución para que la organización sea
más productiva y competitiva.
3. La integración de datos reduce errores (y modificaciones posteriores)
Los recursos de datos de una empresa exigen un g [ CITATION sasf \l 2058 ]ran
esfuerzo para estar siempre al día. Para recabar datos manualmente, los
empleados deben conocer cada ubicación y cada cuenta que puedan tener que
explorar (y tener todo el software necesario instalado antes de empezar) para
garantizar que sus conjuntos de datos sean completos y veraces. Si se añade un
repositorio de datos y ese empleado no lo sabe, tendrá un conjunto de datos
incompleto.
Además, sin una solución de integración de datos que sincronice los datos, deben
emitirse informes periódicamente desde cero para cubrir cualquier posible cambio.
Sin embargo, con actualizaciones automatizadas, los informes se emiten
fácilmente en tiempo real cada vez que son necesarios.
4. La integración de datos suministra datos más valiosos
En realidad, con el tiempo las iniciativas de integración de datos mejoran el valor
de los datos de una empresa. Cuando se integran los datos en un sistema
centralizado, se identifican problemas de calidad y se aplican las mejoras
necesarias, que en última instancia redundan en datos más precisos, que son el
fundamento de un análisis de calidad.
En una base de datos distribuida tenemos una serie de bases de datos que
pueden estar distribuidas geográficamente por todo el mundo. Por encima de esto
tenemos un sistema de gestión de bases de datos distribuidas (DDBMS)  que se
encarga de gestionar todo esto de manera que el conjunto aparezca como una
sola base de datos para los usuarios.
Por lo tanto, una base de datos distribuida es una colección de múltiples bases de
datos interconectadas, que pueden estar extendidas físicamente a través de varios
lugares comunicados mediante una red informática.
VENTAJAS DE UNA BASE DE DATOS DISTRIBUIDA
Desarrollo modular. Si el sistema necesita ser ampliado con nuevas localizaciones
o nuevas unidades, en sistemas de base de datos centralizados, esta acción
requiere sustanciales esfuerzos adicionales, así como la interrupción del servicio.
Sin embargo, en las bases de datos distribuidas, el trabajo simplemente requiere
agregar nuevos ordenadores y datos en los nuevos sitios y finalmente conectarlos
al sistema distribuido, sin que exista ninguna interrupción de funciones.
Mejor tiempo de respuesta. Si los datos están distribuidos de una manera
eficiente, las peticiones de los usuarios van a poder ser satisfechas directamente
desde los datos locales, por lo que se proporciona una respuesta más rápida. Por
otro lado, en sistemas centralizados, todas las solicitudes tienen que pasar a
través del ordenador central, lo cual incrementa el tiempo de respuesta.
Más fiable. En caso de fallo en la base de datos, el todo el sistema de base de
datos centralizada se detiene. Sin embargo, en sistemas distribuidos, cuando un
componente falla, el funcionamiento del sistema continua, aunque pueda tener
una reducción de rendimiento. Por lo tanto, una base de datos distribuida es más
fiable.
Menor coste de comunicación. En sistemas de bases de datos distribuidas, si el
dato se localiza allí dónde es más usado, el coste de comunicación para
manipulación de datos puede ser minimizado. Esto no es factible en sistemas
centralizados.
¿POR QUÉ PUEDES NECESITAR UNA BASE DE DATOS DISTRIBUIDA?
Naturaleza distribuida de unidades organizacionales. Muchas organizaciones
actuales se dividen en varias unidades que se distribuyen físicamente por el
mundo. Cada unidad requiere su propio conjunto de datos local. Así, la base datos
global de la organización se convierte en una base de datos distribuida.
Necesidad de intercambio de datos. Cuando hay múltiples unidades organizativas,
a menudo necesitarán comunicarse entre sí y compartir sus datos y recursos. Esto
requiere bases de datos comunes o bases de datos replicadas que deberían ser
utilizadas mediante sincronización.
Soporte para procesamiento de transacciones online (OLTP) y procesamiento de
analítica online (OLAP). OLTP y OLAP funcionan con sistemas diversificados que
pueden tener datos comunes. Los sistemas de bases de datos distribuidas ayudan
a ambos procesos proporcionando datos sincronizados.
Recuperación de base de datos. Una de las técnicas comunes utilizadas en un
sistema de gestión de base de datos distribuida es la replicación de datos a través
de los diferentes sitios. Esta replicación de datos, automáticamente ayuda a la
recuperación de datos si una base de datos fuera dañada en algún sitio. Los
usuarios podrían acceder a los datos desde otros sitios mientras que la base de
datos dañada se reconstruye. Por lo tanto, un fallo en la base de datos puede
llegar a ser casi imperceptible por los usuarios.
Soporte para múltiple aplicaciones. La mayoría de organizaciones utilizan una
gran variedad de aplicaciones de software, cada una con su base de datos
específica. Un sistema de gestión de base de datos distribuida proporciona una
funcionalidad uniforme al utilizar  los mismos datos entre las diferentes
plataformas.
Bibliografía
a, s. (s f). Talend. Obtenido de ¿En qué consiste la integración de datos?:
https://www.talend.com/es/resources/what-is-data-integration/
Informatica para tu negocio. (2016). Obtenido de
https://www.informaticaparatunegocio.com/blog/una-base-datos-distribuida-
puede-interesante/
Porto, J. P. (20 de Febrero de 2018). Definicion de. Obtenido de Julián Pérez
Porto: https://definicion.de/cliente-servidor/
Ruiz, P. (13 de Agosto de 2013). SomeBooks.es. Obtenido de Arquitectura
cliente/servidor: http://somebooks.es/arquitectura-clienteservidor/