Mantenimiento distribuido de los datos mediante soluciones cliente/servidor

Cuando se consideran soluciones de proceso Cliente/Servidor, no sólo es necesario enfrentarse a una distribución de las aplicaciones, sino que el problema está más bien en organizar la distribución de los datos. La verdadera dificultad en una organización de datos distribuida está en la heterogeneidad de los sistemas de bases de datos instalados. En este artículo se presentan algunas iniciativas para minimizar los inconvenientes y problemas en la distribución de los datos.

Las soluciones cliente/servidor no sólo conducen a la distribución de aplicaciones entre varios ordenadores, sino también a la distribución de los datos. Exceptuando el caso de las empresas que se encuentran localizadas únicamente en un determinado lugar, la organización de los datos tiene lugar a múltiples niveles, en servidores centrales y locales. El motivo está en los requerimientos y demandas contradictorias que se plantean a los datos.

Por una parte, es necesario almacenar los datos lo más localmente posible, con el fin de conseguir unos tiempos de acceso satisfactorios. Esto es particularmente necesario en el caso de los interfaces gráficos de usuario (GUIs), ya que una parte del proceso tiene lugar ya en cada campo de datos o con cada click del ratón. Así, por ejemplo, cuando para la verificación de un código postal se requieren varias instrucciones SQL, que se ejecutan no obstante en un ordenador remoto, el cursor de la pantalla tardará posiblemente varios segundos antes de que el usuario pueda continuar trabajando, con la consiguiente pérdida de ergonomía.

Redundancia para accesos rápidos a los datos

No obstante, por otra parte, todos los datos deben estar almacenados de la forma más centralizada posible, para que puedan estar disponibles actualizados y a nivel de la totalidad de la empresa.

Resolver esta discrepancia -por una parte, todos los datos almacenados localmente y, por otra, todos los datos centralizados -está fuera de las posibilidades del diseñador de base de datos, el cual deberá intentar la mejor solución que permita reducir al mínimo los inconvenientes y los problemas.

Una de las medidas más efectivas para mejorar los accesos a los datos en un sistema distribuido es la redundancia. Dentro de una determinada base de datos, los datos redundantes son el "lubricante" que permite reducir la cantidad de accesos y aumentar de esa forma el rendimiento. La redundancia resulta aún más efectiva en los sistemas distribuidos. Sin embargo, la actualización de datos redundantes plantea un problema: cuando cada modificación de datos debe realizarse no sólo en su base de datos local, sino también al mismo tiempo en varias copias remotas, la ganancia de rendimiento previamente obtenida se pierde de nuevo. Y si además no es posible acceder a una de las copias, queda en cuestión la disponibilidad de la totalidad del sistema. De ello resultan las consecuencias siguientes:

O bien se almacenan de forma redundante sólo los contingentes de datos que se modifican rara vez - por ejemplo, datos maestros de artículos, tablas de código postal, tablas de comprobación, o puede prescindirse de una actualización inmediata. En muchos casos es suficiente distribuir las modificaciones al final del día, por ejemplo en el caso del cambio de la dirección de un cliente. En la práctica, la distribución de los datos tiene lugar de formas muy diferentes en las empresas. Dependiendo del grado de integración de las aplicaciones y de los requerimientos de actualidad de los datos, se derivan conceptos completamente diferentes. De todas formas, las empresas no tienen libertad respecto a la forma de la distribución de los datos y por lo tanto de la solución cliente/servidor, sino que más bien existen tres tipos de estructura que pueden presentar las aplicaciones:

1. Contingentes de datos centralizados y datos de comprobación descentralizados

Esta estructura aparece frecuentemente en los bancos, ya que en ellos los datos de clientes y de cuentas deben estar disponibles y actualizados a nivel de toda la organización y, en consecuencia, es conveniente almacenarlos en el servidor central, en el que puede accederse a ellos desde todos los puestos de trabajo. Es posible entonces mantener redundantemente en los diversos servidores locales aquellos datos que son en su mayoría estáticos, como los comprobantes bancarios, productos bancarios (condiciones), cotizaciones de moneda extranjera, tablas de comprobación, textos maestros, etc. Estos datos se utilizan de manera intensiva para los diálogos y los interfaces GUI. La actualización de los datos redundantes descentralizados no plantea ninguna dificultad especial, ya que en este caso es suficiente una transferencia de ficheros normal.

2. Contingentes de datos centralizados, con copias descentralizadas

Existen ejemplos de esto en numerosos sectores, como por ejemplo en el sector comercial o en el de seguros. En una compañía de seguros, los datos de clientes y de contratos pueden ser almacenados también como replicación parcial en los ordenadores de las diversas sucursales, ya que en la mayoría de los casos existe una correspondencia específica entre los clientes y las sucursales encargadas de ellos. Además, como las modificaciones descentralizadas no ejercen un efecto inmediato sobre otras sucursales, pueden realizarse las modificaciones primero a nivel local y posteriormente en el contingente de datos global centralizado. Además, de forma parecida a lo que sucede en un banco, existen también datos redundantes estáticos en los servidores de base de datos descentralizados.

En una estructura de este tipo, el intercambio de datos entre las sucursales y la central no resulta ya tan sencillo. Los contingentes de datos son generalmente demasiado extensos para poder copiarlos completamente. En consecuencia, el intercambio de datos debe tener lugar mediante cantidades diferenciales, lo cual requiere, además de la transferencia de ficheros, programas de selección para extraer las diferencias de los datos. En este sentido pueden resultar muy útiles los productos conocidos como "Servidores de Replicación", como por ejemplo el "Data Propagator" de ADABAS y DB2.

Un problema adicional de este tipo de organización de datos son las demandas que se plantean al proceso descentralizado. Como en este caso los datos deben ser generados o modificados, deberá estar garantizada la seguridad y la capacidad de reconstrucción de los mismos. Ahora bien, ¿quién se encargará de su "Backup and Recovery"? ¿Quién puede actuar correctamente en caso de fallo? ¿Están protegidos los servidores y los datos contra alteraciones, sabotaje, inundaciones, incendios, etc.?

3. Contingentes de datos separados.

Este es el caso en el que los contingentes de datos no se agrupan en una localización centralizada, sino que cada contingente de datos se localiza allí donde se tiene en funcionamiento la aplicación correspondiente. En el sector industrial existen frecuentemente "islas operacionales", que pueden describirse también así técnicamente. Por ejemplo, el sector del diseño industrial constituye con sus aplicaciones de diseño asistido por ordenador (CAD) una unidad en gran medida cerrada. Algo parecido sucede en el sector del Control de Producción y en la contabilidad comercial. Cada una de estas áreas posee sus propios contingentes de datos, en su mayor parte de utilización propia, y que por lo tanto deben poder ser almacenados por separado. Para el necesario almacenamiento de datos es suficiente realizar una transferencia de ficheros de forma regular, de manera que ya no es necesario básicamente un contingente de datos centralizado.

Evitar los accesos a datos a través de la red

La distribución de los datos en un sistema de proceso cliente/servidor tiene lugar naturalmente en conjunción con la distribución de las funciones. O bien pueden almacenarse los