Ministerio de Educación Superior de la República de

Cuba
Centro Universitario
Vladimir Ilich Lenin

Monografía

Bases de Datos Distribuidas

Autor: Lic. Maidel de la Rosa Téllez.

Administrador de la Red del CULT.
Facultad de Ciencias Técnicas

Las Tunas, 2005.

© Editorial Universitaria, 2005

Calle 23 No. 667, e/ D y E
El Vedado, Ciudad de La Habana, Cuba

ISBN: 959-16-0336-3.
 2

Bases de Datos Distribuidas

El continuo y creciente desarrollo de la alta tecnología y la disminución de los

costos del Hardware han sido las principales causas que han motivado a los
programadores la implementación de los Sistemas de Bases de Datos Distribuidas
(SBDD). El tema de las bases de datos distribuidas (BDD) constituye por sí mismo
un tema amplio, donde encontramos los SBDD. El principal objetivo de los SBDD
es que el manejo de los datos realice como una única colección global de los
datos. Debido a que los SBDD son aún un área en desarrollo, están jugando un
papel importante en operaciones de negocios. Con los extraordinarios avances
que ocurren a diario en los sistemas de comunicaciones, la tecnología de los
SBDD será necesaria para todas las organizaciones.

Definición
La base de datos consiste en dos o más ficheros de datos almacenados en
diferentes localidades de una red que pueden estar geográficamente separadas y
conectadas por enlaces de comunicación[1]. Cuando las bases de datos son
distribuidas, diferentes usuarios tienen acceso sin interferir unos con otros. Sin
embargo, el sistema de gestión de bases de datos distribuidas (SGBBD) debe
sincronizar periódicamente las bases de datos dispersas, para asegurar que todas
tengan sus datos uniformes[2].

El acceso a los datos en los SBDD se realiza mediante los enlaces de

comunicación que conformen la red en la que se encuentren los sitios que
contengan alguna de las partes los datos. Los sitios pueden estar en una
habitación o geográficamente separados, cada uno de ellos tiene capacidad de
procesamiento autónomo y de ejecución de aplicaciones locales.

Los sistemas de bases de datos distribuidas heredan algunas cuestiones

negativas de los sistemas centralizados, la distribución de los datos incorpora un
nuevo nivel de complejidad, que a su vez añade beneficios adicionales que se
trataran posteriormente en este documento. Es importante destacar que las bases
de datos distribuidas no son implementaciones distribuidas de bases de datos
centralizadas.

El procesamiento de bases de datos distribuidas es el procesamiento de bases de

datos en el cual la ejecución de transacciones y la recuperación y actualización de
los datos acontece a través de dos o más computadoras independientes, que
pueden estar separadas geográficamente.

Cuando diseñamos un sistema de base de dato distribuida debemos tener en

cuanta algunas características claves que caracterizan este tipo de sistemas,
como son:
 3

ƒ Permitir que cada sitio almacene y mantenga su propia BD facilita el acceso

inmediato y eficaz de sus datos que se usan más frecuente.

ƒ Mejora la fiabilidad si la computadora de un sitio se cae, el resto de la red sigue

funcionando.

ƒ Permitir el control local de los datos en un sitio mejora el grado de satisfacción

de los usuarios con relación al sistema de BD.

ƒ Cuando cada sitio procesa sus datos locales se elimina un poco el tráfico de la
red, pero si los sitios usan frecuentemente datos almacenados en otros sitios
las comunicaciones pueden convertirse en un cuello de botella.

Un sistema gestión de bases de datos distribuida no es más que el software que

permite la administración de la base de dato distribuida y hace que tanto como la
distribución y el control de concurrencia de las transacciones, las fallas, sean
transparente para el usuario que opera con el sistema.

Un SBDD está formado por una colección de sitios, cada uno de los cuales opera
un sistema de bases de datos para el procesamiento de las actividades que solo
requieran datos locales. Los SGBDD están compuestos por varios SGBDs
operando en sitios locales y que están conectados mediante la trasmisión de
mensajes, transacciones, datos desde el sitio local hacia remostos y viceversa,
etc.

Arquitectura Distribuida de base de datos.

La tecnología y prototipo de los sistemas de gestión de bases de datos

distribuidas se han desarrollado de uno a otro y cada sistema adopta una
arquitectura particular propia.
 4

Nodo W

ABDW BDw

Nodo X

Programa de
consulta o ATX BDX
ABDx
transacción

Nodo Y

Programa de
consulta o ATY ABDY
BDY
transacción

Nodo X
DDB
Programa de
consulta o
ATZ
transacción Interfaz de
acción

Interfaz de solicitud SGBDD

Fig 1. Arquitectura de Bases de Datos Distribuidas.

En la figura 1 mostramos un sistema de base de datos distribuida donde participan

4 computadoras. El nodo W es un nodo de bases de datos ejecutando un
administrador de datos DBMW y almacenando la BDW. El nodo X es tanto nodo de
transacción como de base de datos ejecutando un administrador de transacciones
DTMX y un administrador de base de datos DBMX almacenado BDX, el nodo Y de
forma similar es tanto un nodo de transacciones, como de datos ejecutando DTMY,
DBMx y almacenando la BDY, pero el nodo Z es solo de transacciones ejecutando
DTMZ.

La independencia de los datos puede entenderse como la fortaleza de las

aplicaciones ante los cambios que pueda tener la estructura lógica de
almacenamiento de los datos y la ubicación física de los mismos.

En las bases de datos distribuidas la redundancia es necesaria por varios motivos,

entre los cuales se encuentran:
 5

1. Los datos deben estar localizados lo más cerca posible de los sitio donde
sean utilizado, es decir, utilizando réplicas de los datos.

2. Aumenta la disponibilidad del sistema.

Las transacciones son unidades de la ejecución ACID que terminan exitosamente

o abortan. Programadores de aplicación, administradores recurso, y
administradores de la transacción cooperan para llevar a cabo las propiedades del
ÁCID. Miremos el papel de cada una de estas propiedades participantes.

Atomic (Atomicidad)
Si una transacción completa exitosamente, sus efectos son durables, en caso
contrario la transacción aborta y sus efectos se deshacen (rollback). Por ejemplo,
cuando actualizamos un registro, el registro cambia de valor y el antiguo valor se
anula (cuando termina exitosamente), o no cambia nada (cuando aborte).

Consistency (Consistencia)
Una transacción es una transformación correcta del estado del sistema. Una
transacción producirá siempre los mismos resultados si se aplican más de una vez
(es decir, deben ser consistentes y reproducibles). Por ejemplo, cuando
agregando un elemento a una lista doblemente enlazada, los cuatro indicadores
(dos delanteros y los dos dirigidos hacia atrás) son puestos al día.

Isolation (Aislamiento).
Se aíslan transacciones concurrentes de las actualizaciones de otras
transacciones incompletas. Estas actualizaciones no constituyen un estado
consistente, los datos deben protegerse de cambios hasta haber completado la
transacción a través de todos los nodos. Esta propiedad es llamada a menudo
seriabilidad. Por ejemplo, una segunda transacción, cruzando la lista doblemente
enlazada mencionada en el ejemplo de consistencia, verá la lista antes o después
de la inserción, pero solo verá cambios completos.

Durability (Durabilidad)
Una vez una transacción completa exitosamente, sus efectos persistirán aun
cuando hay fracasos del sistema. Por ejemplo, después de la actualización en el
ejemplo de atomicidad, el registro tendrá el nuevo valor aun cuando el sistema
falla y cuando el sistema se inicie nuevamente se corrigen después de haber
completado la transacción comprometa completa.

Hoy esta tecnología muestra sus limites y los grandes vendedores de bases de
datos (Oracle, Infomix, Sysbase), a fin de satisfacer las necesidades emergentes
de negocio, hacen posible otro adelanto tecnológico en la gestión de bases de
datos. Este enfoque relativamente nuevo usualmente se conoce bajo términos
como: Almacenaje de Datos, Repetición, DSS-R (Sistemas de apoyo de Decisión-
Repetición).
 6

Los sistemas de datos distribuidos se dividen en dos tipos basados en filosofía

totalmente diferentes[3]:

Sistemas de gestión de bases de datos distribuidas homogéneas.

Sistemas de gestión de bases de datos distribuidas heterogéneas.

SGBDD homogéneos: Un DDBMS homogéneo tiene recaudos múltiples de

datos; integra recursos múltiples de datos.
Las bases de datos distribuidas homogéneas son similares a las bases de datos
centralizadas, pero en vez de almacenar todos los datos en un sitio, los datos se
distribuyen en diferentes sitios de una red.
Si nosotros queremos partir de una arquitectura conceptual estándar para los
DDBMS, debemos conocer que partir de la arquitectura de ANSI-SPARC,
nosotros podríamos incluir un DBMS local y esquemas locales recordando que
estos no tienen que estar explícitamente presentes en ninguna implementación
particular.
Para manejar la distribución de otros aspectos, nosotros debemos agregar dos
niveles adicionales, a la arquitectura estándar tercer - nivel ANSI-SPARC, los que
nombramos fragmentación y localización de schemas.

SGBDD heterogéneos: Esta clase se caracteriza por el uso de diferentes DBMS

en los nodos locales. Hay dos subclases principales: los que hacen su integración
totalmente dentro del sistema, y los más simples “hooks” o los apéndices externos
llamados gateways, para permitir enlace a sistemas ajenos.
La anterior subclase puede ser adicionalmente refinada en una subclase que
provee un subconjunto importante de funciones que uno esperaría desde cualquier
SGBD, y que enfatiza en los aspectos más pragmáticos del manejo de datos
colectivos , tales como conversiones entre sistemas y algún aspecto básico de
desempeño(sistemas multidatabase). Los sistemas multidatabase (SGBDMs)
tienen múltiples SGBD, posiblemente de diferentes tipos, y múltiples, DBs
preexistentes. La integración es desempeñada por lo tanto por múltiples software
de subsistemas.

Ventajas en la arquitectura de las BDD.

ƒ Expandibilidad
Al crecer una organización por la adición una nueva unidad, el nuevo nodo o
unidad de localización de dato pasa a formar parte de la base de datos
distribuida sin reconfigurar la BD completamente – el nuevo nodo casi
automáticamente forma parte de la BD global.

ƒ Confiabilidad o Disponibilidad.
Fácil conexión entre los datos de varias localizaciones sin tener en cuenta los
Sistemas Operativos y/o el hardware y software utilizados.
La capacidad que tiene el sistema para seguir trabajando, a pesar del fallo de
una localidad, da como resultado una mayor disponibilidad. Para aplicaciones
 7

de solo – lectura si se almacenan múltiples copias de la misma información de

forma que el sistema tenga alternativas de solución para asegurar que
siempre alguna de ellas esté disponible.
La disponibilidad es fundamental para los sistemas de base de datos que se
utilizan en aplicaciones de tiempo real. Por ejemplo, si una línea aérea no
puede tener acceso a la información, es posible que pierda clientes a favor de
la competencia.
ƒ Flexibilidad.
Al realizar un movimiento en un dato de un lugar a otro o algún cambio en una
localización física de ciertos nodos requeridos no hay que realizar cambios en
la BD o su arquitectura.

ƒ Distribución de la carga de trabajo: La distribución de la carga de trabajo

sobre los sitios se hace sobre la base de utilizar la potencia de las
computadoras de cada sitio y maximizar paralelismo en la ejecución de las
aplicaciones. Como que la distribución de la carga puede afectar la localidad
del procesamiento, es necesario correlacionar ambos objetivos.

ƒ Sharing o Compartición.
Los datos pueden ser compartidos por sucursales o usuarios diferentes de la
misma organización u organizaciones diferentes, permitiendo así
comunicación eficiente entre usuarios distantes.
La ventaja principal de compartir los datos por medio de la distribución es que
cada localidad puede tener mejor control de sus datos almacenados
localmente. En los sistemas centralizados existe un administrador global de la
base de datos, mientras que en un SBDD existe un administrador global de
base de datos que se descompone en los administradores de base de datos
locales donde reside cada base de datos. Dependiendo del diseño del sistema
distribuido, cada administrador de base de datos local podrá tener un grado de
autonomía diferente, que se conoce como autonomía local. La posibilidad de
contar con autonomía local es en muchos casos una ventaja importante de las
bases de datos distribuidas.

ƒ Confiabilidad.
La confiabilidad se logra al tener replicas de los datos, pues es posible
recuperar una copia dañada o destruida a partir de otra. Por supuesto, que
como los daños pueden obedecer a catástrofes físicas, deben tenerse copias
en lugares geográficamente separadas.

ƒ Razones económicas.
Cuando se maximiza el acceso local de las aplicaciones a los datos se
disminuye el tráfico en las comunicaciones. Hoy en día podemos adquirir
computadoras personales a precios considerados, comparado con el
equivalente a una supercomputadora o MainFrame.

Desventajas de BDD.
 8

ƒ Complejidad.
Un sistema distribuido, que oculta su naturaleza distribuida al usuario, es más
complejo que el sistema centralizado. Las consideraciones adicionales tales
como el control de concurrencia y la seguridad deberían tenerse en cuenta, no
para mencionar la complejidad alta de la optimización de consultas, comparado
con una base de datos centralizada, sino que las actualizaciones se complican
proporcionalmente con el aumento de replicas en el sistema.

ƒ La confiabilidad /Eficiencia.
Se deben implementar mecanismos que garanticen la consistencia y permitan
detectar fallas en el sistema y su posterior recuperación. Al ocurrir alguna falla
en sitios distintos, el sitio que contenga una réplica de esa base de datos, y
además sea operable debe garantizar la consistencia y actualización de su
base de datos. Al reponerse los diferentes sitios el sistema de gestión de base
de datos debe granizar la actualización de esos sitios que estaban sin operar.

AL estar particionada la red que une los diferentes sitios es un poco más difícil
garantizar las actualizaciones de las bases de datos. Puesto que las
localidades del sistema distribuido operan en paralelo, es más difícil garantizar
que los algoritmos sean correctos. Existe la posibilidad de errores
extremadamente sutiles. (Profundizar)

ƒ Mayor tiempo extra de procesamiento.

El intercambio de mensajes y los cálculos adicionales que se requieren para
coordinar las localidades son una forma de tiempo extra que no existe en los
sistemas centralizados.

ƒ Costo.
La complejidad aumentada significa que los costos de mantenimiento y
adquisición del sistema son mucho más altos que los de un DBMS
centralizado.
La capacidad de almacenamiento de cada sitio debe tenerse en cuenta,
usualmente el costo de almacenamiento no es importante comparado con
otros costos, no obstante, las limitaciones de almacenamiento deben ser
consideradas.

ƒ Aumento del trafico de comunicación.

Cuando un sitio accede frecuentemente a los datos de otros sitios, aumenta el
tráfico de mensaje y transacciones en la red, y por tanto las comunicaciones, lo
que puede convertirse en un cuello de botella.

ƒ Integridad.
Debido a que no todos los datos se ubican en un lugar centralizado - una
estación (nodo) - el fracaso podría ocasionar una pérdida de datos para otros
nodos.
 9

Los usuarios interactúan con los SGBDD mediante transacciones. Cada

transacción comunica solo sus lecturas y escrituras a un único administrador de
transacciones, el AT recibe solicitudes de procesamiento de consulta o de
transacciones y las traduce en acciones para el planificador, este comunica cada
lectura y escritura al planificador. La selección del planificador se determina por un
algoritmo de control concurrente, aunque el planificador que se escoge más a
menudo está en el mismo sitio que los datos que se están operando.

El AD puede ser un subconjunto de un producto SGBDD, este ejecuta cada

lectura y escritura que recibe. Para cada lectura el AD recorre su base de datos
local y retorna el valor solicitado. Para cada escritura el AD modifica la BD y
retorna un reconocimiento al planificador que lo envía de regreso al AT y este a la
transacción.
El planificador controla la secuencia según la cual los administradores de datos
(ADs) procesan las órdenes de lectura y escrituras y mantiene el control de las
comunicaciones.

Diseño de un sistema de bases de datos distribuidas

A los problemas que presentamos en el diseño de las Bases de Datos

Centralizadas(BDC) se le añaden otros nuevos cuando diseñamos Bases de
Datos Distribuidas(BDD) entre los cuales se destacan la distribución óptima de
datos y de las aplicaciones en los diferentes sitios.

Cuando pensamos en el diseño de las bases de datos distribuidas debemos tener

en cuenta la ubicación de los programas que accederán a las bases de datos y
sobre los propios datos que constituyen la base de datos, en diferentes puntos de
una red. Sobre la ubicación de los programas supondremos que tenemos una
copia de ellos en cada maquina donde se necesite acceder a la base de datos. Sin
embargo el problema radica en como ubicaremos los datos en la red, existen
diferentes formas de repartir los datos: En solo una maquina que almacene todos
los datos y se encargue de responder a todas las consultas del resto de la red
(sistema centralizado), ubicaríamos la base de dato en cada maquina donde se
utilice, o pensaríamos en repartir las relaciones por toda la red.

La organización de los sistemas de bases de datos distribuidos se ha clasificado

tradicionalmente sobre el nivel de compartición, características de acceso y nivel
de conocimiento de los datos:

1. Inexistencia.
Los datos y programas se ejecutan en un ordenador sin que exista
comunicación entre ellos.

2. Se comparten datos y no programas.

 10

Existe una réplica de los programas de aplicación en cada maquina y los datos
viajan a través de la red.

3. Se comparten datos y programas.

Los datos y programas se reparten por los diferentes sitios de la red, dado un
programa ubicado en un determinado sitio puede acceder a un servicio a otro
programa de segundo sitio solicitando acceder a los datos ubicados en un
tercero.

Duplicación de los datos. La duplicación de los datos ocurre si el sistema

mantiene varias copias de una relación, R, con cada copia almacenada en un sitio
diferente.

Existen dos modelos básicos de replica:

1. Consistencia estrecha.
Este modelo que garantiza que todas las réplicas sean constantemente
idénticas a la original, requiere una red de alta velocidad, disminuye la
disponibilidad de la base de datos[5].

2. Consistencia ancha.
El modelo de consistencia ancha permite un retardo entre el momento en que
los datos originales son modificados y las copias de los mismos son
actualizadas, lo que permite que la base de datos esté disponible más tiempo
que el modelo de consistencia estrecha. Permite conexiones tanto rápidas
como lentas soportadas en WANs o LANs.

La duplicación se introduce para aumentar la disponibilidad del sistema: cuando

una copia no está disponible debido a un fallo de un sitio sería posible tener
acceso a otra copia. Con la duplicación también se mejora el rendimiento puesto
que las transacciones tienen mayor probabilidad de encontrar una copia
localmente. El inconveniente está en el costo extra del almacenamiento adicional y
del mantenimiento de la consistencia mutua entre las copias cuando tenemos
replicación.

Réplica en SQL Server 6.5.

La réplica en SQL Server se basa en un modelo de consistencia ancha. Con la

duplicación, se puede distribuir automáticamente copias de transacciones de
datos desde un servidor fuente a uno o varios servidores destinos o a una o
varias localizaciones remotas. La duplicación en SQL Server 6.x está basada en el
log de transacciones: las transacciones son marcadas como duplicación, estas
leen el log de transacciones de la base de datos fuente y aplican lo ocurrido en la
base de datos destino.

La duplicación usa terminología que es basada en una metáfora de

publicación/subscripción. La duplicación emplea servidores en tres papeles
diferentes: publicador, distribuidor, y subscriptor.
 11

Servidor de publicación. Servidor que contiene la base de datos que se va a

replicar, también almacena la base de datos de publicación, hace los datos
públicos desde las bases de datos disponibles para replicar, envía copias de todos
los cambios a los datos públicos para el servidor de distribución[5].

Servidor de distribución. Este servidor almacena la base de datos de

distribución, recibe los cambios de los datos públicos, almacena los cambios en su
base de datos de distribución y trasmite los cambios a los servidores de
subscripción. La computadora que hace la función de servidor de subscripción
puede ser o no también servidor de publicación[5].

Servidor de suscripción. Servidor que mantiene las bases de datos destinos,

recibe y mantiene copias de datos públicos[5].

Los servidores de publicación y subscripción no son exclusivos, este es el caso en

que una computadora almacena la BD original X y una copia de la DB Y, y a su
vez tenemos otra computadora que su BD original es Y, y también posee una
copia de la BD X.

La duplicación en bases de datos SQL Server dedicadas utilizan una cola fiable
para los datos duplicados, también ofrece flexibilidad en los datos seleccionados
para la réplica en todas las bases de datos destino. Y, incrementa la seguridad,
limitando que los usuarios pueden preparar y administrar duplicación, y qué los
servidores destino pueden ver y recibir tablas que estén disponibles para ser
duplicadas.

Los movimientos de los datos duplicados se realizan en una dirección del

publicador al subscriptor. El proceso de lectura del log mueve las transacciones
que son marcadas para la duplicación del log de transacciones del publicador a la
base de datos del distribuidor, donde las transacciones esperan por la distribución
a los subscriptores. El proceso de la sincronización prepara archivos de
sincronización iniciales que contienen la tabla de esquema y datos publicados,
almacena los archivos en el directorio de trabajo del distribuidor del Servidor de
SQL, y en el registros de trabajos de sincronización en la base de datos de la
distribución. La sincronización sólo afecta a los nuevos subscriptores[6].

Los movimientos de proceso de distribución de las transacciones y los trabajos de

la sincronización iniciales que se mantienen en la tabla de la base de datos de
distribución a los subscriptores.

Para abordar el diseño de las bases de datos distribuidas podemos optar por dos
tipos de estrategias: Bottom – Up y. Ambas no son excluyentes, es decir que
cuando estemos trabajando en un determinado proyecto podemos usar en
diferentes partes del mismo una u otra estrategia. La estrategia Bottom – Up se
puede utilizar sistemas ya instalados con pequeñas bases de datos existentes con
el fin de integrarlas en una única BDD. Este problema se nos presenta en BD
*heterogéneas. En la vida real este caso se nos puede presentar con facilidad,
 12

pero se prefiere partir de cero y se avanza en el desarrollo del trabajo siguiendo la

estrategia Top – Down. En la estrategia Top – Down es adecuada cuando
creamos un sistema de BD por vez primera sin restricciones de otros sistemas ya
instalados y que deban ser integrados al sistema distribuido, es decir, primero
elaboramos el esquema conceptual global del proyecto y trabajamos en función de
resolver las diferentes parte de dicho proyecto.

Proceso de Diseño Top – Down.

Un esquema de este proceso puede observarse en la siguiente figura:

Análisis de requerimientos

Objetivos del sistema

Diseño conceptual Diseño de las vistas

Información sobre Esquema

Esquema conceptual global
Accesos Externo

Diseño de la distribución

Esquemas conceptuales locales

Diseño físico

Esquema físico

Observación y monitoreo

El diseñó de una BDD involucra 4 pasos:

1. Diseño del esquema conceptual donde se describe la BD integral.

 13

2. Diseño de fragmentación.
3. Diseño de la asignación de los fragmentos.
4. Diseño de la BD física (transformar los esquemas locales en áreas de
almacenamiento y determinar métodos de acceso apropiados).

La fragmentación y asignación de los datos caracterizan el diseño de BDD. La

fragmentación se ocupa fundamentalmente de los criterios lógicos que motivan la
división de relaciones globales en fragmentos, mientras que la asignación se
ocupa de los aspectos físicos de su ubicación y réplicas en sitios; aunque hay una
diferencia entre ambos procesos, su interrelación es importante para obtener un
diseño óptimo.

En caso que también se distribuyan las aplicaciones debemos tener en cuenta el

diseño de los esquemas, los requerimientos más importantes de las aplicaciones
tenemos las siguientes:

1. Sitio que comparte una aplicación.

2. Frecuencia de activación de la aplicación
3. Cantidad, tipo y distribución estadística de los accesos de cada aplicación a
cada dato requerido.

En el diseño de un sistema de bases de datos distribuidas debemos tener en

cuenta algunas estrategias y objetivos y se deben en paralelo tomar decisiones
sobre cómo hay que distribuir los datos entre los sitios de la red.

Estrategias y objetivos.

Desde el punto de vista conceptual la transparencia en un sistema de gestión de

bases de datos distribuida se refiere a la división del nivel semántico y la
implementación del sistema. El objetivo de la transparencia es ocultar al usuario
los detalles de diseño, es decir, el usuario no tiene conocer que se encuentra
trabajando sobre un sistema distribuido, y menos como se encuentra distribuidos
los dato del sistema. El nivel de transparencia tiene que garantizar un compromiso
en dos extremos: la facilidad de uso y el grado de dificultad más el costo de
proporcionar un alto nivel de transparencia.

Los objetivos que son comunes en la implementación de los sistemas de bases de

datos distribuidas son los siguientes:

Transparencia de ubicación. Permite a los usuarios acceder a los datos sin tener
en cuenta la ubicación de los mismos. Esta transparencia se puede conseguir
cuando los administradores de transacciones distribuidas (ATD) son capaces de
determinar la localización de los datos y de emitir acciones a los ADs apropiados,
lo cual puede ejecutarse cuando los ATs poseen acceso a los directorios de
localizaciones de los datos. Si los datos cambian de lugar, solo el ATs necesita
 14

conocer lo ocurrido. Todas las transacciones ignoran la modificación en la

localización.

Transparencia de duplicación. Para que la transparencia de duplicación sea

posible, los administradores de transacciones deben traducir las solicitudes de
procesamiento de transacción en acciones para el administrador de datos. Para
las lecturas el ATs selecciona uno de los nodos que almacena los datos y ordena
la lectura. Para facilitar esta selección el ATs debe conservar estadísticas sobre el
tiempo que se requiere para leer datos de varios nodos, y seleccionar el de mejor
rendimiento. La escritura de datos duplicados suelen ser más complicadas, porque
el ATs debe emitir una acción de escritura para cada uno de los ADs que
almacena una copia de dichos datos. Para mayor información ver la sección de
log de transacciones de SQL Server.

Las actualizaciones afectan las columnas que tienen datos de longitud variable o
nulos, esto se puede resolver combinando los DELETES y INSERT, aun cuando la
longitud física de los datos no varia. En SQL Server para Windows NT ahora se
ejecutan todas las actualizaciones sin modificar el tamaño físico de los datos, a
pesar que el tipo de dato sea afectado

Transparencia de concurrencia. Cuando múltiples transacciones que involucre

la base de datos distribuida se ejecuten al mismo tiempo, los resultados de las
transacciones no deberán afectarse. La trasparencia de concurrencia se logra si
los resultados de todas las transacciones concurrentes son consistentes de
manera lógica con los resultados que se habrían obtenido si las transacciones se
hubieran ejecutado una por una, en un orden serial arbitrario.

Transparencia de fallas. Significa que a pesar de fallas en la transacción, en el

SGBDD, en la red y en la computadora, las transacciones sean procesadas de un
modo correcto. Frente a una falla, las transacciones deben ser atómicas, significa
que se procesen todas o ninguna de ellas. Para este tipo de problemas es
importante tener resguardo(Backup) de la base de datos, y así poder restaurarla
cuando sea conveniente.
El sistema debe detectar cuándo falla una localidad y tomar las medidas
necesarias para recuperarse del fallo. El sistema no debe seguir utilizando la
localidad que falló. Por último, cuando se recupere o repare esta localidad, debe
contarse con mecanismos para reintegrarla al sistema con el mínimo de
complicaciones.
En un SBDD pueden surgir uno o varios problemas imprevistos, los cuales hay
que solucionar de inmediato, de modo que la afectación de la disponibilidad del
sistema sea mínima. Dentro de estos problemas encontramos los siguientes:

™ Fallo de disco.
Cuando una o más de las unidades de disco donde se almacena la base de
datos falla, nos encontramos ante una pérdida completa de los datos, esto se
puede resolver, restaurando la base de datos con el respaldo más actualizado.
 15

™ Errores del usuario

En caso que un usuario o una determinada aplicación haga un gran número de
modificaciones inválidas involuntariamente o malévolamente a los datos, la
mejor manera de resolver este problema puede ser restaurar los datos en el
punto antes de que se efectuaran estas modificaciones.

™ Pérdida permanente de un servidor.

Cuando un servidor queda fuera de servicio, ya sea por rotura o por alguna
otra razón es necesario activar un servidor de reserva o restaurar una copia de
la base de datos en otro servidor.

Localidad del procesamiento. Los datos se deben distribuir lo más cerca posible
de las aplicaciones que los usan para maximizar la localidad del procesamiento,
este principio responde a minimizar el acceso remoto a los datos.
Diseñar una distribución que maximice localidad del procesamiento puede hacerse
añadiendo la cantidad de referencias locales y remotas correspondientes a cada
fragmentación candidata y asignar la fragmentación eligiendo la mejor solución.

Independencia de configuración. La independencia de configuración permite

añadir o reemplazar hardware sin tener que cambiar componentes de software
existentes en el SGBBD.

SGBDD no homogéneos. Posibilita integrar bases de datos mantenidas por

diferentes SGBDD sobre computadoras diferentes. Existen numerosos SGBDD
que son suministrados por diferentes fabricantes. Para solucionar este problema
se realizó esta amplia interfaz

Particionamiento de la Base de Datos. La base de datos se distribuye de modo

que no haya solapamiento o duplicación de los datos mantenidos en las diferentes
localidades, como no hay duplicaciones de los datos, se evitan los costos
asociados con el almacenamiento y mantenimiento de datos redundantes. Si un
mismo segmento de datos se usa en más de una localidad se ve limitada la
disponibilidad de los datos. La fiabilidad también puede verse limitada cuando se
produce un fallo en el sistema de cálculo de una localidad se afecta la
disponibilidad de los datos de esa localidad no estén disponible para los usuarios
en cualquier parte del sistema.

Fragmentación de datos. Consiste en subdividir las relaciones, figura 3a y

distribuirlas entre los sitios de la red, tiene como objetivo buscar formas
alternativas de dividir una las instancias (tablas) de relaciones en otras más
pequeñas. La fragmentación se puede realizar por tuplas individuales
(fragmentación horizontal), por atributos individuales (fragmentación vertical) o una
combinación de ambas (fragmentación híbrida)
 16

El principal problema de la fragmentación radica en encontrar la unidad apropiada

de distribución. Una relación no es una buena unidad por muchas razones.

Normalmente las vistas de una relación están formadas por subconjuntos de

relaciones. Además, las aplicaciones acceden localmente a subconjuntos de
relaciones. Por ello, es necesario considerar a los subconjuntos de relaciones
como unidad de distribución.
Al descomponer de una relación en fragmentos, tratados cada uno de ellos como
una unidad de distribución, permite el proceso concurrente de las transacciones.
El conjunto de estas relaciones, provocará la ejecución paralela de una consulta al
ser dividida en una serie de subconsultas que operará sobre los fragmentos.
Cuando las vistas definidas sobre una relación son consideradas como unidad de
distribución que se ubican en diferentes sitios de la red, podemos optar por dos
alternativas diferentes: La relación no estará replicada y se almacena en un único
sitio, o existe réplica en todos o algunos de los sitios en los cuales reside la
aplicación. Las consecuencias de esta estrategia son la generación de un volumen
de accesos remotos que pueden ser innecesarios con un mal manejo de estas
replicas. Además, las réplicas innecesarias pueden causar problemas en la
ejecución de las actualizaciones y puede no ser deseable si el espacio de
almacenamiento está limitado.

Los inconveniente de la fragmentación están dados en que si las pueden estar

definidas por fragmentos mutuamente exclusivos y al recuperar los datos de dos
fragmentos situados en sitios diferentes es necesario trasmitir los datos de un sitio
a otro y realizar sobre ellos la operación de unión (Join), lo cual puede ser
costoso. El control semántico cuando los atributos implicados en una dependencia
una relación se descompone en diferentes fragmentos y estos se ubican en sitios
diferentes puede ser muy costos porque es necesario hacer búsquedas en un
gran número de sitio.

Fragmentación horizontal. La fragmentación horizontal es la división en tuplas

de una relación en fragmentos, vea figura 3c. Estos fragmentos pueden ser
disjuntos y pueden estar duplicados. Del concepto la fragmentación horizontal se
desprende el de fragmentación horizontal primaria (FHP) utilizando predicados
definidos en la relación y el de fragmentación horizontal derivada (FHD) que
resulta de los predicados definidos en otra relación[8].

Fragmentación vertical. Es la división de un conjunto de atributos de un objeto

en subconjuntos que pueden solaparse, figura 3b. Cuando se proyecta la relación
original sobre un conjunto de atributos se obtienen los fragmentos.

Fragmentación mixta. Es el resultado de aplicar los dos tipos fragmentaciones

mencionados anteriormente, este tipo de fragmentación puede llevarse a cabo de
tres formas diferentes:
 17

1. Es el resultado de aplicar la fragmentación vertical y, posteriormente el

fraccionamiento horizontal sobre los fragmentos verticales (denominada
VH), figura 3e.

2. Es el resultado de realizar la división horizontal, para posteriormente aplicar

sobre los fragmentos generados la fragmentación vertical (llamada HV)
figura 3d.

3. Este enfoque es relativamente nuevo [2] consiste en aplicar de forma

simultánea, y no secuencial sobre una relación, la fragmentación horizontal
y la vertical; en este caso, se generara una rejilla y los fragmentos formaran
las celdas de esa rejilla, cada celda será exactamente un fragmento vertical
y un fragmento horizontal (nótese que en este caso el grado de
fragmentación alcanzado es máximo, y no por ello la descomposición
resultará más eficiente) figura 3f.

a) Relación R b) Fragmentación c) Fragmentación

Vertical Horizontal

d) Fragmentación HV e) Fragmentación VH f) Celdas

Figura 3. Distintos tipos de fragmentación

Reglas de corrección de la fragmentación.

A continuación se enuncian tres reglas que se deben cumplir durante el proceso

de fragmentación, estas asegurarán que no se produzcan cambios semánticos en
la base de datos durante el proceso.

1. Compleción. Al decomponerse una relación Si una relación R en una serie de

fragmentos R1, R2, ..., Rn, cada elemento de datos que pueda encontrarse en R
deberá poder encontrarse en uno o varios fragmentos Ri. Esta propiedad
 18

extremadamente importante asegura que los datos de la relación global se

proyectan sobre los fragmentos sin pérdida alguna. Es necesario aclarar que
en el caso de la fragmentación horizontal los elementos o fragmentos son
tuplas, mientras que en el caso vertical los fragmentos o elementos de datos
son atributos.

2. Reconstrucción. Si una relación R se descompone en una serie de fragmentos

R1, R2, ..., Rn, puede definirse un operador relacional ∇ tal que

R = ∇ Ri, ∀Ri ∈ FR

El operador ∇ será diferente en dependencia de la forma de fragmentación. La

reconstrucción de la relación a partir de sus fragmentos asegura la
preservación de las restricciones definidas sobre los datos en forma de
dependencias.

3. Disyunción. Esta regla garantiza que cuando una relación R se descompone

en fragmentos R1, R2, ..., Rn, horizontales y un elemento de datos di se
encuentra en algún fragmento Rj, entonces no se encuentra en otro fragmento
Rk (k ≠ j). Esta regla asegura que los fragmentos horizontales sean disjuntos. Si
una relación R se descompone verticalmente, sus atributos primarios clave
normalmente se repiten en todos sus fragmentos.

Alternativas de asignación

Partiendo de que la base de datos ha sido fragmentada correctamente, es

necesario ubicar los diferentes fragmentos en varios sitios de la red, una vez que
los fragmentos son asignados es necesario pensar en la posibilidad de duplicar
algunos de ellos para mantener una copia. Las razones para mantener varias
copias están en lograr incrementar de la seguridad, mayor disponibilidad, mayor
paralelismo, mayor independencia de las unidades de procesamiento, menor
tráfico de datos en la red. Las solicitudes de actualizaciones se complican un poco
ya que el sistema tiene que asegurar que todas las copias de los datos se
actualicen garantizando que sean consistentes. Por otra parte, la ejecución de
consultas de actualización, de escritura, implicaría la actualización de todas las
copias que existan en la red, cuyo proceso puede resultar problemático y
complicado. Por tanto, un buen parámetro para afrontar es el grado de réplica, que
consistiría en sopesar la cantidad de consultas de lectura que se efectuarán, así
como el número de consultas de escritura que se llevarán a cabo. En una red
donde las consultas que se procesen sean mayoritariamente de lectura, se podría
alcanzar un alto grado de réplica, no así en el caso contrario.

Con respecto a la duplicación de fragmentos se pueden seguir tres tendencias

básicas:
 19

1. Un extremo es replicar la base de datos completamente en cada sitio del

sistema distribuido, en este caso la base de datos distribuida estaría
completamente replicada. En este caso se mejora la disponibilidad e
incrementa rapidez de las recuperaciones para solicitudes globales, pero
retrasa drásticamente las operaciones de actualización y encarece los métodos
de control de concurrencia y recobrado.

2. El otro extremo se refiere a las bases de datos no replicadas; o sea, cada

fragmento es asignado a solo un sitio. En este caso todos los fragmentos
deben ser disjuntos, excepto para la réplica de la llave primaria en la
fragmentación vertical o mixta. Esta variante también se nombra localización
no redundante.
3. En las bases de datos parcialmente replicada algunos de los fragmentos de la
base de datos son replicados, se ubicaran copias de algunos fragmentos en
diferentes sitio de la red.

En la figura 4 se muestra las tres alternativa de réplicas con respecto a distintas

funciones de bases de datos distribuido

Réplica total Réplica Parcial No Replicada

Procesamiento de
Fácil Dificultad similar
Consultas
Manipulación de Fácil o
Dificultad similar
Directorios inexistente
Control de
Moderado Difícil Fácil
Concurrencia
Seguridad y
Muy alta Alta Baja
confiabilidad
Aplicación Posible Real Posible

Figura 4. Comparación entre las alternativas de réplicas.

Fragmentación de los Datos.

Para ejemplicar los diferentes tipos de fragmentación tomamos las siguientes

relaciones:

Relación Estudiantes
Id_Estudiante Nombre_E Dirección Edad
E1 Pablo Peña C/ maceo no 33 19
E2 Enrique Ortega C/ martí no 45 22
E3 Juan Escobar C/ 39 no 34 21
E4 Miguel Suárez Edif. 23 apto 5 20
 20

E5 Pedro Alcina C/ maceo no 21 18

Relación Profesores
Id_Profesor Nombre_P Facultad Salario
P1 Pedro R. Cont 380.00
P2 Alicia A. Cont 340.00
P3 Juan R. Agro 380.00
P4 Enrique M. Agro 360.00
P5 Edecio P. CF 330.00

Relación Asignaturas Relación Imparte

Id_Asignatura Nombre_Asignatura Id_Asignatura Id_Profesor Id_Grupo
AM1 Análisis Matemático 1 AM1 P1 1ro Cont
CC Contabilidad de CC P2 2do Cont
Costos
NA Nutrición Animal NA P3 3ro Agro
HC Horticultura HC P4 4to Agro
VB Voleibol VB P5 1ro CF

Relación Grupos Relación Pertenece

Id_Grupo Nombre_Grupo Facultad Id_Estudiante Id_Grupo
1ro Agro 1er año Agronomía Agronomía E1 1ro Agro
4to Agro 4to año Agronomía Agronomía E2 4to Agro
Contabilidad y
3ro Cont 3er año Contabilidad E3 3ro Cont
Finanzas
Contabilidad y
2do Cont 2do año Contabilidad E4 2do Cont
Finanzas
1ro CF 1er año Cultura física Cultura Física E5 1ro CF

Figura 5. Relaciones de las bases de datos empleadas para los ejemplos.

Este esquema de fragmentación es ventajoso porque proporciona pequeños

tiempos de respuesta y bajo costo de procesamiento para solicitudes locales, lo
que se justifica porque existen grandes sistemas (por ejemplo dentro de las
universidades tenemos, facultades, bibliotecas, etc.) que por sus estructuras es
conveniente aplicar la una fragmentación horizontal debido a la complejidad y
tamaño de sus. Su principal objetivo es producir fragmentos con máxima localidad
respecto a las aplicaciones.

Para la fragmentación necesitamos tanto información cualitativa como cuantitativa.

La información cualitativa guiará la fragmentación, mientras que la cuantitativa se
necesitará en los modelos de asignación. La principal información de carácter
 21

cualitativo esta basada en las consultas generadas por los usuarios y las
aplicaciones. Debemos investigar cuales son las principales aplicaciones en caso
que no fuese posible investigarlas todas para determinar estos predicados. Para
guiarnos en este análisis nos podemos auxiliar en la regla de que el xx% de las
consultas acceden al yy% de los datos. Llegados a este punto, sería interesante
determinar los predicados simples. Dada una relación R(A1, A2, ..., An), donde Ai
es un atributo definido sobre el dominio Di, un predicado simple pj definido sobre R
es de la forma

pj : Ai θ Valor

donde θ es un operador relacional y Valor se escoge de entre el dominio de Ai.

Usaremos Pri para notar al conjunto de todos los predicados simples definidos
sobre una relación Ri. Los miembros de Pri se notan por pij.
Ejemplo F1. En la relación Profesores de la figura 5, podemos definir como
predicados simples los siguientes:

p1: Facultad = “Agro”

p2: Salario ≥ 360.00

También podemos formar predicados complejos que estarían formados por

combinaciones booleanas de predicados simples. Se obtiene como predicado
mintérmino a la conjunción de los predicandos simples tanto en su forma natural
como negada. Partiendo de que siempre es posible transformar una expresión
lógica en su forma normal conjuntiva, usaremos los predicados mintérmino en los
algoritmos para no causar ninguna pérdida de generalidad.

Dado un conjunto de predicados simples de una relación R, Pri = {pi1, pi2, ..., pim},
el conjunto de predicados mintérmino Mi = {mi1, mi2, ..., miz} se define como

M i = {mij | mij = ∧
pik ∈Pri
p * ik },1 ≤ k ≤ m,1 ≤ j ≤ z

donde p ik = pik o p ik = ¬pik. Es decir, cada predicado mintérmino puede ser igual
* *

a la forma natural o a la forma negada del predicado simple. Es importante señalar

que la referencia a la negación de un predicado es significativa para predicados de
igualdad de la forma

Atributo = Valor

Cuando se trata de predicados de desigualdad la negación es complemento del

predicado del predicado simple.

¬(Atributo ≤ Valor) es Atributo > Valor

 22

En caso de que los predicados sean de la forma

Límite_inferior ≤ Atributo_1 ≤ Límite_superior

Esto se traduce como

Límite_inferior ≤ Atributo_1
Atributo_1 ≤ Límite_superior

Y sus complementos son

¬(Límite_inferior ≤ Atributo_1)
¬(Atributo_1≤ Límite_superior)
Que se traduce como:

¬( Límite_inferior ≤ Atributo_1 ≤ Límite_superior)

Ejemplo F2: Dada la relación Profesores de la figura 5 tomaremos una muestra de

los predicados simples definidos como:

p1: Facultad = “Cont”

p2: Facultad = “Agro”
p3: Salario ≤ 360.00
p4: Salario ≥ 380.00

Los predicados definidos anteriormente tienen como significado la pertenencia de

los profesores a las facultades Cont y Agro, así como los profesores con salarios
menores o iguales 360.00 y mayores o iguales a 380.00. Podemos definir los
siguientes predicados mintérminos:

m1: (Facultad=“Cont”) ∧ (p3: Salario ≤ 360.00)

m2: (Facultad=“Cont”) ∧ (p3: Salario ≥ 380.00)
m3: ¬ (Facultad=“Cont”) ∧ (p3: Salario ≤ 360.00)
m4: ¬ (Facultad=“Cont”) ∧ (p3: Salario ≥ 380.00)
m5: (Facultad=“Agro”) ∧ (p3: Salario ≤ 360.00)
m6: (Facultad=“Agro”) ∧ (p3: Salario ≥ 380.00)
m7: (Facultad=“Agro”) ∧ ¬ (p3: Salario ≤ 360.00)
m8: (Facultad=“Agro”) ∧ ¬ (p3: Salario ≥ 380.00)

Estos 8 predicados mintérminos no son todos los que se pueden definir, estos son
solo una muestra de todos los posibles a definir.

A partir de los predicados simples o de selección se determinan los predicados

minterminos, que determinan el proceso de fragmentación deben poseer las
 23

propiedades de Completitud y Minimalidad para garantizar una

fragmentación correcta y eficiente.

Para que un conjunto de predicado {Pr} sea completo debe garantizar que, para
cada aplicación del conjunto de aplicaciones, accedan con igual probabilidad a dos
tuplas cualquiera de un mismo fragmento.

El conjunto de predicados {Pr} es minimal si todos loa predicados son releventes

en la determinación de la fragmentación, es decir, si para cada predicado Pj, que
causa que la relación R se divida en dos fragmentos Ri y Rj, exista una aplicación
que acceda de forma diferente a ambos fragmentos. De aquí podemos afirmar que
un conjunto minimal siempre es completo, pero lo contrario no siempre es
verdadero.

Log de Transacciones en SQL Server

Los cambios en el log de transacciones no son colocados en el cache, las

escrituras en él son operaciones intensivas del SGBD, por medio de nuevas
paginas que son asignadas y liberadas al mismo tiempo, esto incrementa la
eficiencia en el log. El SQL Server para Windows NT ha reducido los gastos e
incrementado el funcionamiento[6] ya que el log de asignación y liberación de
paginas ocurre en grupos de 8 paginas en cada tiempo.

La mayoría de los servidores SQL procesan sus anotaciones en el syslogs de la

tabla de log de transacciones. Cada una de las base de datos tienen su propia
tabla de log de transacciones, el log de transacciones es truncado mediante la
sentencia DUMP TRANSACTION o automáticamente con la opción trunc. log on
chkpt[7].

Al comenzar la ejecución de una transacción se almacena en el log de

transacciones el evento o identificador de dicha transacción, este evento o
identificador es usado en la recuperación y determina el punto de partida de cada
transacción. En el log también se almacena el valor de los datos antes de la
ejecución de alguna de las sentencias INSERT, DELETE o UPDATA.

Cuando se realiza una modificación siempre se almacena en el log antes de ser

almacenada en la base de datos. El tipo de log es llamado log de escritura hacia
delante (write-ahead).

Al terminar la transacción se almacena el commit en el registro de transacciones.

Este dato nos sirve para determinar si la transacción terminó con éxito y también
nos permite la recuperación automática del registro de transacciones.

Es indispensable que el Servidor SQL conozca que las escrituras se han

completado. La escritura en cache del controlador de disco compromete la
habilidad del Servidor SQL de manejar transacciones haciendo que parezca que
 24

ha completado las anotaciones en el write-ahead, aunque no la tiene. Esto puede

producir errores como error 605 y también puede causar corrupción en la base de
datos. Por esta razón, no se debe usar escritura en cache del controlador de disco
con Servidor de SQL a menos que se pueda garantizar que se puedan completar
las escrituras[7].

El log de transacción es compartido por todos los usuarios de la base de datos.

Frecuentemente se graban múltiples cambios cada vez que una página del log
escribe al dispositivo de la base de datos. Este proceso mejora grandemente la
entrada/salida del sistema.
entrada/salida del sistema.

Distribución de archivos no fragmentados.

La distribución de archivos no fragmentados es el caso en que relaciones

completas se ubican en los sitios. La razón principal es que la mayoría de los
archivos son no fragmentados porque hay muchos accesos importantes que lo
que necesitan es recuperar todos los registros de los archivos. Esto es una
cuestión central en el diseño e implementación de los SBDD.
Uno de los métodos que se destaca para determinar la asignación de archivos es
el de Bell y Grimson. La función objetivo de este método es maximizar el acceso
local, sujeto a las restricciones de almacenamiento.

Este algoritmo consiste en maximizar el acceso local, ya que el acceso remoto es

más costoso. La función objetiva intenta poner los archivos en la localidad donde
tengan más acceso.

Veamos el siguiente ejemplo.

La capacidad de almacenamiento de cada sitio es de 25 Mb

En la tabla 1 se muestra el acceso de las transacciones a los 8 archivos.

En la Tabla 2 tenemos la frecuencia en que se generan las transacciones desde

los cinco sitios de la red.

En la tabla 3 muestra el resultado de multiplicar el número de filas accedidas por

transacción por el número de transacciones generadas en cada sitio.

Archivo (tamaño).
1 2 3 4 5 6 7 8
Trans. (8) (8) (16) (9) (10) (7) (4) (5)
1 10 9 0 0 0 10 0 20
2 0 0 0 0 0 20 0 9
3 0 0 0 60 70 140 16 0
4 0 0 0 6 5 15 10 0
 25

5 0 0 0 4 4 0 0 10
6 4 10 0 6 1 0 0 15
7 9 2 0 3 4 0 0 0
8 6 5 0 2 4 0 0 0
9 2 2 0 0 0 0 0 0
10 0 0 0 0 0 0 0 0

Tabla 1. Razón de transacciones a los archivos.

Sitio
Trans. 1 2 3 4 5
1 0 25 0 0 0
2 12 30 0 0 0
3 0 3 5 4 5
4 0 0 10 10 10
5 0 0 12 8 4
6 20 150 100 2 2
7 2 100 0 30 40
8 18 32 12 12 10
9 4 2 0 0 0
10 0 4 0 0 0

Tabla 2. Frecuencia de las transacciones en los sitios.

214 302 0 162 100 240 0 408

1946 2089 0 1444 888 1270 48 3020
472 1060 0 1032 596 850 180 1620
350 140 0 458 532 710 164 110
428 150 0 528 618 850 180 70

Tabla 3. Ficheros accedidos por transacciones generadas en cada sitio.

Paso1: Para cada archivo identificar el sitio que requiere mayor número de
acceso. Significa buscar el máximo de cada columna de la tabla 3, de esta forma
tenemos en que sitio se generaron más transacciones para cada fichero.

1 2 3 4 5 6 7 8
1 214 302 0 162 100 240 0 408
2 1946 2089 0 1444 888 1270 48 3020
3 472 1060 0 1032 596 850 180 1620
4 350 140 0 458 532 710 164 110
 26

5 428 150 0 528 618 850 180 70

Tabla 4. Máximo de acceso de cada sitio a cada archivo.

Paso 2: Asignar a la variable de decisión dij = 1 para todas las entradas en

negritas y dij = 0 para los demás casos.
Paso 3: Comprobar que no se haya excedido la capacidad de almacenamiento del
sitio. Ej. Al sitio 2 se le asignaron archivos con una totalidad de 47 Mb y solo
disponemos de 25 Mb.
Paso 4: Calcular el máximo de los archivos que se puedan almacenar sin que se
exceda la capacidad de almacenamiento. Ej el máximo se logra almacenando los
archivos 1,2 y 8, se elimina la fila 2 y las columnas 1, 2 y 8, Y regresamos al paso
2.

3 4 5 6 7
1 0 162 100 240 0
3 0 1032 596 850 48
4 0 458 532 710 164
5 0 528 618 850 180

Tabla 5. Máximo de acceso de los sitios 1,3,4,5 a los ficheros 3,4,5,6,7.

Paso 2’: Se le asigna dij = 1 para todas las entradas en negritas y dij = 0 para los
demás casos.

Paso 3’: Comprobar que no se exceda la capacidad de almacenamiento en sitio,

ej. En sitio 3 se le asignaron 16 Mb y su capacidad es de 25, en este caso los
máximos de los acceso a los ficheros 4 y 6 no se encuentran el sitio 3 por tanto en
el sitio 5 se almacena los ficheros 5 y 7 con capacidad total de 14 Mb, el fichero 3
no es accedido, por tanto no se distribuye.
La asignación quedaría como lo muestra la tabla 6:

Sitio Archivos Mbyte usados

1 - 0
2 1,2,8 21
3 4,6 16
4 - 0
5 5,7 14

Tabla 6. Asignación distribuida de archivos.

Procesamiento distribuido de las consultas.

Existen algunos sistemas de bases de datos que soportan bases de datos cuyas
partes están físicamente separadas. Las relaciones pueden estar ubicadas en
sitos diferentes, pueden existir múltiples copias de una misma relación en sitios
 27

diferentes, o una relación puede estar particionada y cada subparticion estar

distribuida en sitios diferentes. Para realizar una consulta en un sitio dado pudiera
ser necesario transferir datos entre varios sitios. La consideración más importante
aquí es que el tiempo requerido para realizar una consulta está estrechamente
comprometido con el tiempo que se emplea en la transmisión de los datos entre
los sitios.

Si la ejecución de una consulta sobre la base de dato, y estos están distribuidos

en diferentes localidades podemos dividirla en varias subconsultas que se
ejecuten en paralelo en cada una de las localidades.

Integridad de los datos en sistemas de bases de datos

distribuidas.

En los sistemas de bases de datos distribuidas las transacciones dejan de ser

secuencias lineales y ordenadas de las acciones sobre los datos, quiere decir que
como los datos están distribuidos, las actividades de la transacción pueden tener
lugar en diferentes sitios y puede ser difícil mantener un orden de tiempo entre las
acciones.
El problema más común lo tenemos cuando dos (o más) transacciones se
ejecutan al mismo tiempo y ambas requieren acceso al mismo registro de datos
con vistas a completar su procesamiento. El problema de concurrencia en
sistemas distribuidos es mayor que en sistemas centralizados, puesto que puede
haber varias copias de un mismo registro, y todas las copias deben tener los
mismos valores o de lo contrario las transacciones trabajarían con datos
imprecisos.
Para implementar el control de concurrencia se debe conocer lo siguiente[3]:

1. El tipo de algoritmo de planificación utilizado.

2. La localización del planificador.
3. Cómo se controlan los datos duplicados.

Anomalías de procesamiento concurrente.

Cuando se ejecutan transacciones concurrentes en bases de datos distribuidas

pueden interferir unas con otras, lo que puede afectar la integridad y consistencia
de la base de datos. Los diferentes problemas que se pueden presentar son los
siguientes:

1. Problema de actualización perdidas.

2. Violación de integridad.
3. Lectura o recuperación inconsistente.
 28

Problema de actualización perdidas ocurre cuando un usuario aparentemente

completa una actualización con éxito y puede ser sobre escrita por otro usuario, es
decir cuando dos o más transacciones acceden concurrentemente sobre un
mismo registro de datos, una transacción actualiza un registro de datos y otra
transacción escribe este mismo registro. En el siguiente ejemplo se ejecutan 2
transacciones T1 y T2 de forma concurrente, la transacción T1 resta 500 unidades
de registro X y la transacción T2 incrementa 200 unidades del registro X, como
podemos observar se pierde la actualización de la transacción T2.

Ej. Actualizaciones perdidas.

Valor del Registro X

T1 500 T2
Begin T2
Begin T1 Read X
Read X Inc(X,200)
Dec(X,500) 700 Write(X)
Write X 0 Commit T2
Commit T1

Violación de integridad

Se obtiene de violación de integridad en el manejo de la base de datos, cuando se

permite la ejecución de dos transacciones concurrentemente sin previo
sincronismo.

Para el siguiente ejemplo tenemos una base profesores con los campos: nombre,
departamento, asignatura. También otra base con la información de un grupo de
una facultad que le llamaremos Grupo_1 que posee los campos: turno, asignatura,
nombre_P. Inicialmente estas bases se encuentran en siguiente estado:

Profesores Grupo_1
Nombre Departamento Asignatura Turno Asignatura Nombre_P
Pepe Computación DDB 1er DB Pepe
Pepe Computación DB 2da Análisis Pedro
Juan Computación DB 3ra MOC Tomas

Tenemos una transacción T4 que decide cambiar la asignatura DB por DDB y

actualiza el nombre del profesor en la base Grupo_1, Por razones de trabajo Pepe
no puede impartir la asignatura DB en el 1er turno y la transacción T5 cambia el
profesor que imparte esa asignatura por Juan.
 29

T4
Select Asignatura
From Grupo_1 Where Turno = 1er
Select Nombre
From Profesores Where
Asignatura_I = DDB
Asignatura = DDB
Nombre_P = Nombre
T5
Select Asignatura
From Grupo_1 Where
Nombre_P = Pepe AND Turno= 1er
Select Nombre_P
From Profesores
Where Asignatura_I = Asignatura
AND Nombre_P <> Pepe
Nombre = Nombre_P

Donde finalmente la base de datos Grupo_1 quedaría en el siguiente estado:

Grupo_1
1er DDB Juan
2da Análisis Pedro
3ra MOC Tomas

Que sería una violación de integridad

Problemas de recuperaciones inconsistentes.

La mayoría del trabajo de control de concurrencia se concentra en las

transacciones que actualizando la base de datos pueden interferir unas con otras
y provocar datos erróneos. Sin embargo, transacciones que solo lean la base de
datos pueden obtener resultados inexactos si se permite leer resultados parciales
de transacciones incompletas que actualizan la base de datos, lo que algunas
veces se hace, obteniéndose lecturas erróneas.
Veamos el siguiente ejemplo:
Tenemos un base de datos S con los salarios de los profesores de la universidad
y la referencia al mismo se hace mediante la siguiente forma para Pepe es
S_Pepe, para Juan es S_Juan, La transacción T5 actualiza los salarios de los
profesores que han cambiado de categoría, en este caso S_Juan, T6 suma el
salario de todos los profesores para sacar del BPA para pagar en la Universidad.
El resultado final es que a Juan no le pagarán el salario correcto.

Ej Problemas de recuperaciones inconsistente.

T5 T6
Begin T6
Total = 0
Begin T5 Do while not end_S
Read (S, S_Juan) Read S_juan
Inc(S_juan, 15$) Inc(total, S_Juan)
Write(S, S_juan) :
Commit T5 :
 30

Read S_Pepe
Inc(Total, S_Pepe)
:
:
Commit T6

Estos factores proporcionan las bases para la construcción de reglas que

determinen cuándo un algoritmo de control de concurrencia es correcto. Las
reglas se basan en la teoría de la serialización(Theory of serializability).
Una transacción consiste en una secuencia de lecturas y escrituras en la base de
datos.

El objetivo del algoritmo de control de concurrencia usado en los SGBD es el

horario de las transacciones para evitar interferencia. Si el SGBD permite que solo
una transacción se ejecute en un mismo tiempo no habrá problema alguno, o sea
para que una transacción pueda comenzar su proceso debemos esperar que
termine otra que esté ejecutándose.
Una transacción consiste en una secuencia de lecturas y escrituras en la base de
datos

Serialización en sistemas distribuidos. El concepto básico de seriabilidad es el

mismo para SGBD pero distribuidas, pero se le añade la complejidad generada
por la distribución. Considere dos transacciones globales T1 y T2 con dos agentes
a a
o sub-transacciones en los sitos A y B. T 1 es el agente de T1 en A y T 2 es el
B B
agente T2 en A y T 1 es el agente T1 en B y T 2 es el agente T2 en B. Suponemos
que Ta1 precede a Ta2 en el sito A, y TB2 precede a TB1 en el sitio B. Supongamos
que cada agente hace una lectura seguido de una escritura en los sitios A y B
respectivamente , entonces SA y SB quedarían de la siguiente forma:
A a a
S = [R1(x), W1(x), R2(x), W2(x)] ==> T 1 < T 2
SB = [R2(y), W2(y), R1(y), W1(y)] ==> TB2 < TB1

Donde SA y SB denotan en horario de las lecturas y escrituras de cada registro en

los sitos A y B.

Globalmente, dos transacciones no se ejecutan de forma serial pero sus agentes

sí se ejecutan de forma serial en cada sitio. Para transacciones distribuidas, se
requiere el manejo de la seriabilidad de todos los horarios locales, y la
serialización global para todas las transacciones globales. [3]

El orden de las solicitudes conflictivas deberá ser una imagen de espejo del orden
de las transacciones independiente de donde procedan e independiente de
cuantas veces se procesen. De alguna forma los mecanismos de control de
 31

concurrencia deben asegurar que las solicitudes conflictivas se procesen en el

orden de las transacciones que la generaron[4].

Técnicas para el control concurrente

Existen tres técnicas básicas que permiten que las transacciones concurrentes se
ejecuten en paralelo sin que se generen datos erróneos en la base de datos.
Estas técnicas son las siguientes:

1. Métodos de bloqueos.
2. Métodos de marcas de tiempos.
3. Métodos optimistas.

Los métodos de bloqueo y los de marcas de tiempo son métodos esencialmente

conservativos. Ellos causan que las transacciones entren en espera en caso que
haya alguna transacción que entre en conflicto con otra en un futuro. Sin embargo
los métodos optimistas, son basados en la premisa de que el conflicto es raro y
además permite que las transacciones se procesen sin sincronismo alguno, estos
métodos solo chequean los conflictos al final cuando la transacción termina
(commit).

Protocolo de cierre de dos-fases. En los sistemas de bases de datos

distribuidas el mantenimiento de la integridad de los datos requiere del
procesamiento automatizado de las transacciones. Antes de cerrar las
actualizaciones de una transacción T, cada subtransacción debe mostrar que está
preparada para el cierre. De lo contrario, se abortará la transacción y todos sus
cambios. Las subtransacciones que se ejecutan en el sitio local se denotan por Ci
(coordinadora) y las otras se denominan participantes Ti. En la primera fase Ci
envía un mensaje a las subtransacciones que están preparadas para el cierre en
todos los sitios donde se esté ejecutándo Ti. Cada Ti le responde a Ci con voto de
cierre o voto de aborto. En la segunda fase Ci determina, con los resultados de la
primera fase, si T puede cerrarse o no y envía a todos los Ti un mensaje de cerrar
T o abortar T.

Bloque distribuido. En cada localidad el SGBDD mantiene un administrador de

bloqueo que administra la demanda de bloqueo y desbloqueo de los datos
almacenados en cada sitio. Estos bloqueos se pueden aplicar de dos modos:
compartido y exclusivo. Si una transacción bloquea un registro en modo
compartido, puede leer este registro pero no actualizarlo. Cuando una transacción
bloquea un registro en modo exclusivo, solo ella puede acceder a este ya sea para
leerlo y/o actualizarlo. Varias transacciones pueden bloquear un registro en modo
compartido. Sin embargo solo una puede bloquear un registro en modo exclusivo.

Bloqueo distribuido de dos-fases. A través de este método, los ATs son

requeridos para realizar bloqueos antes de leer y de escribir datos. Estos bloqueos
 32

se realizan de dos formas: modo de lectura o compartido y modo de escritura o

exclusivo. Una vez que ATs libera un bloqueo, no se le puede volver a conceder
otro bloqueo. A partir de este punto lo único que se puede hacer es liberar
bloqueos[4].
El término de dos-fases proviene de esta última limitación. Eswaran y sus colegas
probaron que los bloqueos de lectura y escritura generarán programas
consistentes si y solo si las transacciones se procesan en dos fases. En la primera
fase, se les permite adquirir bloqueos sin liberar ninguno(se denomina fase de
crecimiento). Cuando una transacción libera un bloqueo, en un punto llamado el
punto de bloqueo, las transacciones entran en la segunda fase o de
encogimiento. Durante esta fase, las transacciones pueden liberar bloqueos pero
no adquirirlos.

Marcas de Tiempo. Método para identificar mensajes con la hora de transmisión.

A cada transacción Ti que entra al sistema se le asocia una marca de tiempo
ST(Ti). Si ST(Ti) entra al sistema antes que ST(Tj) entonces ST(Ti) < ST(Tj).
Hay dos métodos principales de asignar marcas tiempo únicas[3]:

1. Método descentralizado. Se da en un único sitio sin la responsabilidad de

asignar marcas de tiempo a las transacciones.
2. Método centralizado. A cada sitio se le permite asignar una única marca de
tiempo local. Una marca de tiempo global se obtiene al concatenar los sellos
de tiempos locales con un identificador único del sitio.

Las marcas de tiempo de las transacciones pueden crearse haciendo que el AT

lleve la cuenta del número de transacciones que ha planificado y asigne estos
números en orden creciente a la nueva transacción que entre al sistema, de esta
manera el orden relativo es consistente con el orden con que se inician las
transacciones. Otro enfoque de asignar las marcas de tiempo es usar el reloj
interno de la máquina en el momento que se inicie la transacción.

Métodos optimistas Cuando una transacción desea terminar, el sistema chequea

si hay conflictos con otras transacciones, en caso de que se detecte algún
conflicto la transacción debe comenzar nuevamente desde el principio. Para
asegurar la atomicidad de la transacción todas las actualizaciones se realizan en
copias locales de los datos y solo se actualiza la base de datos en caso de que no
se detecten conflictos.

Recuperación de la base de datos.

Como ya hemos enunciado, la transparencia de fallas deben ser atómicas; quiere

decir que se procesará toda la transacción, o ninguna parte de ella. Al
comprometerse una transacción sus efectos deberán ser permanentes.

La realidad es que esta atomicidad no siempre se puede conseguir. Si una parte

demasiado sustancial de la red falla o porciones criticas fallan en momentos
 33

críticos, la recuperación con atomicidad no pudiera ser posible. El administrador

de recuperación de SDD-1, se reconoce con la definición de catástrofes del
sistema. En cada sitio se debe llevar un diario o bitácora donde se registren todas
las acciones de las transacciones. Existen momentos en que es importante contar
con la garantía de que el diario se encuentre en perfecto estado en caso de fallas.
Los SGBDD deben tener mecanismos para detectar las fallas y restablecer el
estado del sistema. El diario debe contener cuáles transacciones fueron iniciadas
y no terminaron en el sitio.

Arquitectura multiusuario.

Sistema de teleprocesamiento

Es sistema de teleprocesamiento se basa en una computadora central en la que

se ejecutan los programas de aplicaciones, o microcomputadoras emulando
terminales, desde donde los usuarios interactúan con la base de datos.

La porción de control de las comunicaciones del sistema operativo recibe los

mensajes y los datos y los envía al programa de aplicación apropiado. Luego el
programa solicita los servicios al sistema de administración y el mismo utiliza la
porción de administración de datos del sistema operativo y se procesa la base de
datos. Terminada la transacción los resultados se devuelven a los usuarios en las
terminales a través de la porción de controles de comunicaciones del sistema
operativo.
Estos sistemas basan su nombre en que todas las entradas y las salidas son
comunicadas a la macrocomputadora para su procesamiento a distancia, de ahí la
palabra "tele". Por lo general la interfaz de usuario está orientada a caracteres y es
primitiva. Como conclusión se puede señalar que los sistemas de
teleprocesamiento han sido la alternativa más común para sistemas de base de
datos multiusuario, pero con la dramática reducción de los costos de las
microcomputadoras se han implementado nuevas soluciones.

Sistema Cliente Servidor.

Los sistemas cliente/servidor involucran varias computadoras conectadas a una

red. Las computadoras que procesan programas de aplicaciones se conocen
como clientes y las que procesan bases de datos se conocen como servidor.

Arquitectura Cliente Servidor

 34

AP 1
Usuario 1
OS net
AP 2
Red de área local
Cliente 1

Usuario 2 AP2 OS net

Cliente 2
OS net DBMS OSdm DB

AP 2 Servidor de bases de datos

Usuario n OS net
AP 3

Cliente N

Un sistema cliente servidor puede tener varios servidores de procesamiento de

bases de datos, cuando esto ocurre cada servidor debe procesar una base de
datos distinta. Cuando dos o más servidores procesan una misma base de datos,
el sistema no es considerado cliente servidor, más bien, es conocido como
sistema de base de datos distribuido.

Funciones del cliente:

ƒ Administrar la interfaz de usuario.
ƒ Aceptar datos del usuario.
ƒ Procesar la lógica de la aplicación.
ƒ Generar las solicitudes para la base de datos.
ƒ Trasmitir las solicitudes de la base de datos al servidor.
ƒ Recibir los resultados del servidor.
ƒ Dar formatos a los resultados.

Funciones del servidor:

ƒ Aceptar las solicitudes de la base de datos de los clientes.
ƒ Procesar las solicitudes de los clientes.
ƒ Dar formato a los resultados y trasmitirlos al cliente.
ƒ Llevar a cabo la verificación de integridad.
ƒ Mantener los datos generales de la base de datos.
ƒ Proporcionar control de acceso concurrente.
ƒ Llevar a cabo la recuperación.
ƒ Optimizar el procesamiento de consulta/actualización.

Una desventaja de los sistemas cliente servidor es el control. Las computadoras

clientes operan en forma simultánea y procesan las aplicaciones en paralelo, lo
 35

cual hace más difícil el control de los problemas de pérdidas por actualización y
otros problemas que provoca el control multiusuario.
 36

Bibliografía

1. Silberschatz, A.; Korth, H. F.; Sudarshan S. "Fundamentos de Bases de Datos".

(3ª Edición), Mc.Graw-Hill, 1998.
2. Ceri, S.; Pelagatti, G. "Distributed Database. Principles and Systems". Mc.Graw-
Hill, 1985
3. Thomas M. Connolly, Carolyn E. Begg “SISTEMAS DE BASES DE DATOS 4/E”
Pearson Educación
4. García González Carlos, “La réplica en SQL Server y las aplicaciones
distribuidas.”, GIGA, No. 2, 1999, pp 29-35.
5. Microsoft Developer Network (MSDN) CDs. Enero 98, Microsoft
Corporations.
6. SQL Server 6.5 Books Online.
7. Lic. Ileana Zamora González, MsC. Abel Rodríguez Morffi, Dra. Luisa Ma.
González González, “Distribución de los datos en Sistemas de Bases de Datos
Distribuidas.”, GIGA, No. 1, 1999, pp 28-35.