EL PROCESAMIENTO DISTRIBUIDO

Para repetir lo dicho en la sección 2.10, el término "procesamiento distribuido" significa que dis- tintas máquinas pueden conectarse en una red de comunicaciones como Internet, de tal manera que una sola tarea de procesamiento de datos pueda extenderse a varias máquinas de la red. (En ocasiones, también se usa el término "procesamiento paralelo" básicamente con el mismo sig- nificado, con excepción de que las máquinas distintas tienden a estar físicamente muy cerca en un sistema "paralelo", lo que no es necesario en un sistema "distribuido"; en último caso, por

Capítulo 2 / Arquitectura de los sistemas de bases de datos 51

ejemplo, podrían estar geográficamente dispersas). La comunicación entre las diversas máquinas es manejada mediante algún tipo de software de administración de redes; tal vez una extensión del administrador CD que explicamos en la sección 2.9 y más probablemente un componente de software independiente.

El procesamiento distribuido presenta muchos niveles o variedades posibles. Para repetir lo dicho en la sección 2.10, un caso sencillo comprendería la operación de los servicios dorsales del DBMS (el servidor) en una máquina y las aplicaciones de usuario (los clientes) en otra. Con- sulte la figura 2.6.

Como mencioné al final de la sección 2.10, aunque estrictamente hablando el término "cliente-servidor" es puramente arquitectónico. Se ha convertido casi en sinónimo de la organi- zación ilustrada en la figura 2.6, en la que un cliente y un servidor se ejecutan en máquinas dife- rentes. De hecho, hay muchos argumentos a favor de dicho esquema:

■ El primero es básicamente el simple argumento de procesamiento paralelo normal: es decir, ahora se están aplicando muchas unidades de procesamiento para las tareas en conjunto, mientras que el procesamiento del servidor (base de datos) y del cliente (aplicación) se están haciendo en paralelo. De ahí que el tiempo de respuesta y la velocidad real de transporte tengan mejorías.

■ Además, la máquina servidor podría ser una máquina construida a la medida y adaptada a la función del DBMS (una "máquina de base de datos") y podría, por lo tanto, proporcionar un mejor desempeño del DBMS.

Aplicaciones Máquina cliente

Acceso remoto transparente

DBMS

Figura 2.6 Cliente y servidor operando en máquinas diferentes.

52 Parte I / Preliminares

■ En forma similar, la máquina cliente podría ser una estación de trabajo personal adaptada a las necesidades del usuario final y por lo tanto, capaz de proporcionar mejores interfaces, una alta disponibilidad, respuestas más rápidas y en general una mejor facilidad de uso para el usuario.

■ Varias máquinas cliente distintas podrían ser (de hecho serían) capaces de acceder a la misma máquina servidor. Por lo tanto, una sola base de datos podría ser compartida entre varios sistemas cliente distintos (vea la figura 2.7).

Además de los argumentos anteriores, está el punto de que ejecutar los clientes y el servi- dor en máquinas separadas coincide con la forma en que operan en realidad las empresas. Es muy común que una sola empresa —por ejemplo, un banco— opere muchas computadoras, de tal modo que los datos de una parte de la empresa estén almacenados en una computadora y los da- tos de otra parte estén almacenados en otra computadora. También es bastante común que los usuarios de una computadora necesiten acceso por lo menos ocasional a los datos almacenados en otra computadora. Siguiendo con el ejemplo del banco, es muy probable que los usuarios de una sucursal necesiten acceder ocasionalmente a los datos almacenados en otra. Observe, por lo tanto, que las máquinas cliente podrían tener almacenados datos propios y que la máquina servi- dor podría tener sus propias aplicaciones. Por lo tanto, es común que cada máquina actúe como servidor para ciertos usuarios y como cliente para otros (vea la figura 2.8); en otras palabras, cada máquina soportará un sistema de base de datos completo, en el sentido al que se refieren las sec- ciones anteriores de este capítulo.

Máquinas cliente

Clientes

Servidor Servidor

Figura 2.8 Cada máquina opera como clientes y como servidor.

La idea final es que una sola máquina cliente podría ser capaz de acceder a varias máquinas servidor diferentes (lo contrario al caso ilustrado en la figura 2.7). Esta posibilidad es conve- niente ya que, como mencioné antes, las empresas operan por lo regular de tal manera que la to- talidad de sus datos no están almacenados en una sola máquina, sino más bien están esparcidos a través de muchas máquinas distintas, y las aplicaciones necesitarán a veces tener la posibili- dad de acceder a los datos de más de una máquina. Básicamente, este acceso puede ser propor- cionado en dos formas:

Una máquina cliente dada podría ser capaz de acceder a cualquier cantidad de servidores, pero sólo uno a la vez (es decir, cada petición individual de base de datos debe ser dirigida

54 Parte I / Preliminares

a un solo servidor). En un sistema así, no es posible combinar datos de dos o más servidores con una sola petición. Además, el usuario de dicho sistema debe saber qué máquina en par- ticular contiene qué piezas de datos.

■ El cliente podría ser capaz de acceder a varios servidores en forma simultánea (es decir, una sola petición de base de datos podría combinar datos de varios servidores). En este caso, los servidores ven al cliente —desde un punto de vista lógico— como si en realidad fuera un solo servidor y el usuario no tiene que saber qué máquinas contienen qué piezas de datos.

Este último caso constituye lo que por lo regular se denomina un sistema de base de datos distribuida. La base de datos distribuida es en sí un tema extenso. Llevada a su conclusión ló- gica, el soporte total a la base de datos distribuida implica que una sola aplicación debe ser capaz de operar "de manera transparente" sobre los datos que están dispersos a través de una variedad de bases de datos diferentes, las cuales son administradas por una variedad de DBMSs distintos. operan en varias máquinas distintas, son manejadas por varios sistemas operativos diferentes y están conectadas por una variedad de redes de comunicación distintas; aquí, "de manera trans- parente" significa que la aplicación opera desde un punto de vista lógico como si los datos fueran manejados por un solo DBMS y en una sola máquina. ¡Una posibilidad como ésta podría parecer muy difícil de lograr!; pero es bastante conveniente desde una perspectiva práctica, y los fabrican- tes están haciendo un gran esfuerzo para hacer realidad dichos sistemas, los cuales explicaremos con detalle en el capítulo 20.

2.13 RESUMEN

En este capítulo hemos visto los sistemas de bases de datos desde el punto de vista de la ar- quitectura. Primero describimos la arquitectura ANSI/SPARC, la cual divide a un sistema de base de datos en tres niveles, como sigue: El nivel interno es el más cercano al almacenamiento físico (es decir, es aquel que se ocupa de la forma en que están almacenados físicamente los datos); el nivel externo es el más cercano a los usuarios (es decir, es el que se ocupa de la forma en que los usuarios individuales ven los datos); y el nivel conceptual es un nivel de indirección entre los otros dos (proporciona una vista comunitaria de los datos). Los datos, como se perci- ben en cada nivel, están descritos por medio de un esquema (o por varios esquemas, en el caso del nivel externo). Las transformaciones definen la correspondencia entre (a) un esquema externo dado y el esquema conceptual y (b) el esquema conceptual y el esquema interno. Estas transformaciones son la clave para proporcionar la independencia lógica y física de los datos, respectivamente.

Los usuarios —es decir, los usuarios finales y los programadores de aplicaciones, los cuales operan al nivel externo— interactúan con los datos por medio de un sublenguaje de datos, el cual se divide por lo menos en dos componentes: un DDL (lenguaje de definición de datos) y un DML (lenguaje de manipulación de datos). El sublenguaje de datos está incrustado en un lenguaje anfitrión. Nota: Los límites entre el lenguaje anfitrión y el sublenguaje de datos, y entre el DDL y el DML, son principalmente de naturaleza conceptual; en forma ideal, deberían ser "transparentes para el usuario".

También vimos más de cerca las funciones del DBA y del DBMS. Entre otras cosas, el DBA es el responsable de crear el esquema interno (el diseño físico de la base de datos); en contraste,

la creación del esquema conceptual (el diseño lógico o conceptual de la base de datos) es responsabilidad del administrador de datos. Y el DBMS es responsable, entre otras cosas, de implementar las peticiones DDL y DML del usuario. El DBMS también es responsable de pro- porcionar cierto tipo de función de diccionario de datos.

Otra forma conveniente de ver a los sistemas de bases de datos es como si consistieran en un servidor (el propio DBMS) y un conjunto de clientes (las aplicaciones). Los clientes y servi- dores pueden operar, y a menudo lo harán, en máquinas independientes, proporcionando así un tipo de procesamiento distribuido sencillo. En general, cada servidor puede atender a muchos clientes y cada cliente puede tener acceso a muchos servidores. Si el sistema proporciona "trans- parencia" total —lo que significa que cada cliente puede comportarse como si tratara con un solo servidor en una sola máquina, sin importar el estado físico general de las cosas— entonces te- nemos un verdadero sistema de base de datos distribuida.

EJERCICIOS

2.1 Dibuje un diagrama de la arquitectura de sistema de base de datos presentada en este capítulo (la