TEMA: LAS BASES DE DATOS DISTRIBUIDAS.

...

Es razonable suponer que los registros Student son los que se emplean con más frecuen-

cia en el campus sede de un estudiante, por lo que se hará la partición de la relación Student colocando el registro de cada estudiante en su campus sede. Lo mismo se aplica para

los registros Faculty. También podría hacerse la partición de la relación Class de acuer-

do con el campus en que se ofrezca la clase. Sin embargo, esto significaría que las consultas

sobre las ofertas en otros campos siempre requerirían el uso de la red. Si tales consultas fue-

ran frecuentes, una alternativa sería duplicar toda la relación Class en todos los sitios.

Como las actualizaciones a esta tabla son relativamente raras, y la mayor parte de accesos

son de sólo lectura, la duplicación reduciría los costos de comunicación, por lo que se esco-

gerá esta alternativa. La tabla Enroll no sería una buena candidata a ser duplicada porque

durante la inscripción las modificaciones deben hacerse rápido y modificar las múltiples

copias consumiría tiempo. Es deseable tener los registros Enroll en el mismo sitio que los

registros Student y Class, pero éstos pueden no estar en la misma ubicación. Por tanto,

se debería escoger centralizar los registros Enroll en el sitio principal, posiblemente con

copias en los sitios de Student y Class. El sitio principal se puede diseñar como la copia

principal de Enroll .

No se está fragmentando la relación Class. Como ya se han tomado diferentes decisiones

para distintas partes de la base de datos, éste es un esquema de fragmentación híbrido. La

figura 12.7 ilustra las decisiones de ubicación de los datos para este ejemplo.

Lo ideal es que la distribución en un sistema de base de datos distribuida sea transparente

para el usuario, cuya interacción con la base de datos debe ser similar a la que proporciona

una base de datos centralizada y única. Las formas de transparencia que son deseables son

las siguientes:

■ Transparencia de la distribución de los datos. Este tipo de transparencia adopta

diferentes formas. El usuario no necesita conocer la forma en que los datos están

fragmentados, propiedad que se llama transparencia de la fragmentación. Los

usuarios deberían desconocer la ubicación real de los registros de los datos a que

acceden, propiedad denominada transparencia de la ubicación. Si los datos se

duplicaran, los usuarios deberían ignorar el hecho de que existen copias múltiples,

propiedad que recibe el nombre de transparencia de la replicación. Para apoyar

estas propiedades, es esencial que los nombres de los ítems de datos sean exclusivos.

En un sistema centralizado es fácil verificar la exclusividad. Sin embargo, en un sis-

tema distribuido es difícil garantizar que no haya dos sitios con el mismo nombre

para distintos datos. Es posible garantizar la exclusividad de todo el sistema de nom-

bres si cada nombre de ítem de datos tiene un prefijo que sea el identificador del sitio

en que se originó, llamado sitio de nacimiento. Es frecuente que se use la dirección

del sitio de Internet. Sin embargo, esta técnica compromete la transparencia de la

ubicación. El problema se resuelve si se utilizan alias para los ítems de datos, los cuales el sistema puede mapear para formar el nombre compuesto. Otro enfoque es

tener un servidor de nombres con el que se revise la exclusividad de todos los nom-

bres y éstos se registren. No obstante, el servidor podría convertirse en un cuello de

botella, lo que comprometería su desempeño, y si fallara todo el sistema se vería afec-

tado.

■ Transparencia de la heterogeneidad del DBMS. Los usuarios que necesiten acceder

a datos de un sitio remoto con un DBMS diferente al de ellos, no debieran darse

cuenta de que están usando uno distinto. Sus consultas debieran enviarse en el len-

guaje que utilizan normalmente. Por ejemplo, si son usuarios de Access y el sitio

remoto usa Oracle, debieran poder usar el formato de consultas de Access para

hacerlas. El sistema debiera encargarse de cualesquiera traducciones necesarias. El

problema de dar dicha transparencia se hace más difícil si los dos sistemas utilizan

diferentes modelos de datos.

■ Transparencia de la transacción. Las propiedades ACID de las transacciones, estu-

diadas en el capítulo 10 para las bases de datos centralizadas, también deben estar

garantizadas para las transacciones distribuidas. Por tanto, el sistema debe garantizar

la transparencia de la concurrencia, que asegura que las transacciones concurrentes

no interfieren una con otra. También debe proporcionar transparencia de la recuperación, que maneje la recuperación de la base de datos de todo el sistema. Estos

aspectos se estudiarán con detalle en la sección 12.6.

■ Transparencia del desempeño. Un sistema de base de datos distribuida debería

tener un rendimiento comparable con otro que utilizara una arquitectura centrali-

zada. Por ejemplo, debe emplearse