En un sistema de base de datos distribuida, los datos se almacenan

BASES DE DATOS DISTRIBUIDAS
En un sistema de base de datos distribuida, los datos se almacenan en varios computadores. Los
computadores de un sistema distribuido se comunican entre sí a través de diversos medios de comunicación, tales como cables de alta velocidad o líneas telefónicas. No comparten la memoria principal ni el
reloj.
Los procesadores de un sistema distribuido pueden variar en cuanto su tamaño y función. Pueden
incluir microcomputadores pequeños, estaciones de trabajo, minicomputadores y sistemas de computadores grandes de aplicación general. Estos procesadores reciben diferentes nombres, tales como localidades, nodos, computadores, dependiendo en el contexto donde se mencionen. Nosotros utilizaremos
normalmente el término localidad para hacer hincapié en la distribución física de estos sistemas.
Un sistema distribuido de bases de datos consiste en un conjunto de localidades, cada una de las
cuales puede participar en la ejecución de transacciones que accedan a datos de una o varias localidades.
La diferencia principal entre los sistemas de base de datos centralizados y distribuidos es que, en los
primeros, los datos residen en una sola localidad, mientras que, en los últimos, se encuentran en varias
localidades.
ESTRUCTURA DE BASES DE DATOS DISTRIBUIDAS
Un sistema distribuido de base de datos consiste en un conjunto de localidades, cada una de las
cuales mantiene un sistema de base de datos local. Cada localidad puede procesar transacciones locales,
es decir, aquellas que sólo acceden a datos que residen en esa localidad. Además, una localidad puede
participar en la ejecución de transacciones globales, es decir, aquellas que acceden a datos de varias
localidades. La ejecución de transacciones globales requiere comunicación entre las localidades.
Las localidades en el sistema pueden conectarse físicamente de diversas formas. Las distintas
configuraciones se representan por medio de grafos cuyos nodos corresponden a las localidades. Una
arista del nodo A al nodo B corresponde a una conexión directa entre las dos localidades.
En la figura se ilustran algunas de las configuraciones más comunes. Las diferencias principales
entre estas configuraciones son:
 Coste de instalación: el coste de conectar físicamente las localidades del sistema.
 Coste de comunicación: el coste en tiempo y dinero que implica enviar un mensaje desde la
localidad A a la B.
 Fiabilidad: la frecuencia con que falla una línea de comunicación o una localidad.
 Disponibilidad: la posibilidad de acceder a información a pesar de fallos en algunas localidades o líneas de comunicación.
Estas diferencias juegan un papel importante en la elección del mecanismo adecuado para manejar la distribución de los datos.
Las localidades de un sistema distribuido de bases de datos pueden estar dispersas de forma física, ya sea por un área geográfica extensa (como un país) o en un área reducida (por ejemplo, un solo
edificio o varios edificios adyacentes). Una red del primer tipo se denomina red de larga distancia, mientras que las últimas se conocen como redes de área local.
Puesto que las localidades de las redes de larga distancia están distribuidas físicamente en un
área geográfica extensa, es probable que las líneas de comunicación sean relativamente lentas y menos
fiables en comparación con las redes de área local. Las líneas de comunicación de larga distancia normales son las líneas telefónicas, conexiones de microondas y canales de satélites. Por otra parte, como todas las localidades de las redes de área local están próximas entre sí, las líneas de comunicación son de
mayor velocidad y menor tasa de errores que sus equivalentes en las redes de larga distancia. Las conexiones más comunes: cables dobles trenzados, coaxiales de banda base, coaxiales de banda ancha y fibra
óptica.
Estos ejemplos se ilustrarán por medio de un sistema bancario que cuenta con cuatro sucursales
situadas en cuatro ciudades diferentes.
Cada sucursal tiene su propio computador con una base de datos que incluye todas las cuentas que tiene
esa sucursal. Así pues, cada una de estas instalaciones es una localidad. También existe una localidad
única que mantiene información acerca de todas las sucursales del banco. Una transacción local es la que
accede a cuentas en la localidad individual donde se inició. En cambio, una transacción global accede a
cuentas de una localidad distinta a la localidad donde se inició o a cuentas de varias localidades diferentes. Para ilustrar la diferencia considérese la transacción de añadir 50 dólares a la cuenta número 177 de
la sucursal de Mar del Plata. Si la transacción se inició en la sucursal de Mar del Plata, se la considerará
como local; en el caso contrario, se la considerará como global. Una transacción para transferir 50 dólares de la cuenta 177 a la cuenta 305, que está situada en la sucursal de Miramar, es una transacción
global, ya que su ejecución implica acceder a cuentas de dos localidades diferentes.
La configuración descrita anteriormente es una base de datos distribuida porque:
 Cada localidad es consciente de la existencia de las demás.
 Cada localidad permite ejecutar transacciones tanto locales como globales.
Se asume que cada localidad ejecuta el mismo software de control de base de datos distribuida.
Si no se cumple esta premisa, será muy difícil manejar transacciones globales.
CONSIDERACIONES AL DISTRIBUIR LA BASE DE DATOS
Existen varias razones para construir sistemas distribuidos de bases de datos que incluyen compartir la información, fiabilidad y disponibilidad y agilizar el procesamiento de las consultas. Sin embargo,
estas ventajas vienen acompañadas de varias desventajas, como son mayores costes de desarrollo del
software, mayor posibilidad de errores y el aumento en el coste extra del procesamiento. A continuación
se comentarán brevemente cada una de ellas.

Ventajas de la distribución de datos. La principal ventaja de los sistemas distribuidos de base de
datos es la capacidad de compartir y acceder a la información de una forma fiable y eficaz.

Utilización compartida de los datos y distribución del control. Si varias localidades
diferentes están conectadas entre sí, entonces un usuario de una localidad puede acceder a
datos disponibles en otra localidad. Por ejemplo, en el sistema bancario distribuido que se
describió, un usuario de una sucursal puede acceder a datos de otra. Si no se contara con
esta facilidad, un usuario que quisiera transferir fondos de una sucursal a otra tendría que
recurrir a un mecanismo externo para realizar la transferencia. Este mecanismo externo
sería, de hecho, una base de datos única centralizada.
La ventaja principal de compartir los datos por medio de la distribución es que cada localidad pueda controlar hasta cierto punto los datos almacenados localmente. En un sistema
centralizado, el administrador de base de datos de la localidad central controla la base de
datos. En un sistema distribuido existe un administrador global de la base de datos que se
encarga de todo el sistema. Parte de estas responsabilidades se delega al administrador de
base de datos de cada localidad. Dependiendo del diseño del sistema distribuido, cada administrador 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.


Fiabilidad y disponibilidad. Si se produce un fallo en una localidad en un sistema distribuido, es posible que las demás localidades puedan seguir trabajando. En particular, si los
datos se repiten en varias localidades, una transacción que requiere un dato específico
puede encontrarlo en más de una localidad. Así, el fallo de una localidad no implica necesariamente la desactivación del sistema.
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.
Aunque la recuperación de fallos es más compleja en sistemas distribuidos que en los centralizados, la capacidad que tiene el sistema para seguir trabajando, a pesar del fallo de
una localidad, da como resultado una mayor disponibilidad. 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.

Agilización del procesamiento de consultas. Si una consulta comprende datos de varias localidades, puede ser posible dividir la consulta en varias subconsultas que se ejecuten en paralelo en distintas localidades. Se podrían usar algunas de las estrategias de
computación. Sin embargo, en un sistema distribuido no se comparte la memoria principal,
así que no todas las estrategias de intersección para procesadores paralelos se pueden
aplicar directamente a los sistemas distribuidos. En los casos en que hay repetición de los
datos, el sistema puede pasar la consulta a las localidades más ligeras de carga.
Desventajas de la distribución de los datos. La desventaja principal de los sistemas distribuidos
de base de datos es la mayor complejidad que se requiere para garantizar una coordinación, adecuada entre localidades. El aumento de la complejidad se refleja en:



Coste de desarrollo de software. Es más difícil estructurar un sistema de base de datos
distribuido y, por tanto, su coste es mayor.
Mayor posibilidad de errores. 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.
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.
Al escoger el diseño de una base de datos, el diseñador debe hacer un balance entre las ventajas y
las desventajas de la distribución de los datos. Se verá que existen varios enfoques del diseño de
bases de datos distribuidas que van desde diseños totalmente distribuidos hasta diseños que incluyen un alto grado de centralización.
DISEÑO DE BASES DE DATOS DISTRIBUIDAS
A continuación se explicarán los factores de diseño que se aplican específicamente a las bases de
datos distribuidas.
Considérese una relación r que se va a almacenar en la base de datos. Hay varios factores que
deben tomarse en cuenta al almacenar esta relación en la base de datos distribuida. Tres de ellos son:




Repetición. El sistema mantiene varias copias idénticas de la relación. Cada copia se almacena en una localidad diferente, lo que resulta en una repetición de la información. La
alternativa a la repetición es almacenar una sola copia de la relación r .
Fragmentación. La relación se divide en varios fragmentos. Cada fragmento se almacena
en una localidad diferente.
Repetición y fragmentación. Esta es una combinación de los dos conceptos antes mencionados. La relación se divide en varios fragmentos. El sistema mantiene varias copias
idénticas de cada uno de los fragmentos.
Repetición de los datos. Si la relación r está repetida, se almacena una copia en dos o más localidades. En el caso extremo se tiene repetición total, en la que se almacena una copia de la relación en
cada una de las localidades del sistema. La repetición tiene varias ventajas y desventajas.

Disponibilidad. Si falla una de las localidades que contienen la relación r, puede disponerse de ésta en otra localidad. Así, el sistema puede continuar procesando consultas que impliquen a r a pesar de haber fallado una localidad.


Mayor paralelismo. En el caso en que la mayor parte de los accesos a la relación r resulten sólo en la lectura de la relación, varias localidades podrán procesar consultas que involucren a r en paralelo. Mientras más copias de r existan, mayor será la probabilidad de que
los datos requeridos se encuentren en la localidad donde se está ejecutando la transacción.
Por tanto, la repetición de los datos reduce al mínimo el movimiento de información entre
localidades.
Mayor tiempo extra para actualizaciones. El sistema debe asegurarse de que todas las
copias de la relación r sean consistentes, pues de otra manera pueden hacerse cálculos
erróneos. Esto implica que cada vez que se actualice r, la actualización debe propagarse a
todas las localidades que contengan copias, lo que resulta en un mayor tiempo extra. Por
ejemplo, en un sistema bancario, donde se repite la información de cuentas en varias localidades, es necesario que las transacciones garanticen que el saldo de una cuenta determinada sea el mismo en todas las localidades.
En general, la repetición mejora el rendimiento de las operaciones de lectura y aumenta la disponibilidad de datos para las transacciones de lectura. Por otra parte, las transacciones de actualización
requieren mayor tiempo extra. El problema de controlar las actualizaciones concurrentes de datos
repetidos es complejo. Puede simplificarse el manejo de copias de la relación r al designar a una de
ellas copia primaria de r. Por ejemplo, en un sistema bancario, una cuenta puede estar asociada con
la localidad en que se abrió la cuenta. De manera similar, en un sistema de reservas de una línea aérea, un vuelo puede estar asociado a la localidad donde se origina el vuelo.

Fragmentación de los datos. Si la relación r está fragmentada, r se dividirá en varios fragmentos
r1, r2, ..., rn. Estos fragmentos contienen información suficiente para reconstruir la relación r original. Esta reconstrucción puede llevarse a cabo ya sea aplicando la operación de unión o un tipo especial de operación de unión sobre los diversos fragmentos. Existen dos esquemas diferentes para
fragmentar una relación: fragmentación horizontal y fragmentación vertical. La fragmentación horizontal divide a la relación asignando cada tupla de r a uno o más fragmentos. La fragmentación vertical divide la relación descomponiendo el esquema R de la relación r de una manera especial. Estos
dos esquemas pueden aplicarse en forma sucesiva a la misma relación, lo que resulta en varios fragmentos.
TRANSPARENCIA Y AUTONOMÍA
Ya se vio que una relación r puede almacenarse de varias formas en un sistema de base de datos
distribuida. Es esencial que el sistema reduzca al mínimo la necesidad de que el usuario se dé cuenta de
cómo está almacenada una relación. Como veremos, un sistema puede ocultar los detalles de la distribución de la información en la red. Esto se denomina transparencia de la red.
La transparencia de la red se relaciona, en algún modo, a la autonomía local. La transparencia de
la red es el grado hasta el cual los usuarios del sistema pueden ignorar los detalles del diseño distribuido.
La autonomía local es el grado hasta el cual el diseñador o administrador de una localidad pueden ser
independientes del resto del sistema distribuido.
Los temas de transparencia y autonomía serán considerados desde los siguientes puntos de vista:

Nombre de los datos.

Repetición de los datos.

Fragmentación de los datos.

Localización de los fragmentos y copias.

Asignación de nombres y autonomía local. Todo elemento de información de una base de datos
debe tener un nombre único. Esta propiedad se asegura fácilmente en una base de datos que no esté
distribuida. Sin embargo, en una base de datos distribuida, las distintas localidades deben asegurarse
no utilizar el mismo nombre para dos datos diferentes.
Una solución para este problema es requerir que se registren todos los nombres en un asignador central de nombres. Sin embargo, este enfoque tiene varias desventajas:



Es posible que el asignador de nombres se convierta en un cuello de botella.
Si el asignador de nombres se cae, es posible que ninguna de las localidades del sistema
distribuido pueda seguir trabajando.
Se reduce la autonomía local, ya que la asignación de nombres se controla de forma centralizada.
Un enfoque diferente que origina una mayor autonomía local es exigir que cada localidad ponga como prefijo un identificador de localidad a cualquier nombre que genere. Esto garantiza que dos localidades nunca generarán el mismo nombre (ya que cada localidad tiene un identificador único).
Además, no se requiere un control central. Esta solución al problema de asignación de nombres logra
autonomía local, pero no transparencia de la red, ya que se agregan identificadores de localidad a
los nombres. Cada copia y fragmento de un elemento de información deben tener un nombre único.
Es importante que el sistema pueda determinar qué copias son copias del mismo elemento de información y qué fragmentos son fragmentos del mismo elemento de información.

Transparencia de la repetición y la fragmentación. No es conveniente requerir que los usuarios
hagan referencia a una copia específica de un elemento de información. El sistema debe ser el que
determine a qué copia debe acceder cuando se le solicite su lectura, y debe modificar todas las copias
cuando se produzca una petición de escritura.
Cuando se solicita un dato, no es necesario especificar la copia. El sistema utiliza una tabla-catálogo
para determinar cuáles son todas las copias de ese dato.
De manera similar, no debe exigirse a los usuarios que sepan cómo está fragmentado un elemento de
información. Por tanto, un sistema de base de datos distribuido debe permitir las consultas que se
hagan en términos de elementos de información sin fragmentar. Esto no presenta problemas graves,
ya que siempre es posible reconstruir el elemento de información original a partir de sus fragmentos.
Sin embargo, este proceso puede ser ineficiente.

Transparencia de localización. Si el sistema es transparente en cuanto a repetición y fragmentación, se ocultará al usuario gran parte del esquema de la base de datos distribuida. Sin embargo, el
componente de los nombres que identifican a la localidad obliga al usuario a darse cuenta del hecho
de que el sistema está distribuido.
La transparencia de localización se logra creando un conjunto de seudónimos o alias para cada usuario. Así, el usuario puede referirse a los datos usando nombres sencillos que el sistema traduce a
nombres completos.
Con el uso de seudónimos, no será necesario que el usuario conozca la localización física de un dato.
Además, el administrador de la base de datos puede cambiar un dato de una localidad a otra sin
afectar a los usuarios.

Esquema completo de asignación de nombres. Un nombre proporcionado por el usuario debe
pasar por varios pasos de traducción antes de que pueda servir como referencia a una copia específica de un fragmento determinado en una localidad específica, para ilustrar cómo funciona el esquema,
consideramos un usuario que se encuentra en la sucursal Hillside (localidad L1). Este usuario emplea
el seudónimo depósito-local para el fragmento local depósito-f1 de la relación depósito. Cuando este
usuario hace referencia a depósito-local, el subsistema de procesamiento de consultas busca depósito-local en la tabla de seudónimos y la sustituye por L1.depósito.f1. Es posible que L1.depósito.f1 esté repetido. Si es así, debe consultarse la tabla de copias para elegir una copia. Esta copia podría
también estar fragmentada, lo que haría necesario consultar la tabla de fragmentación. En la mayor
parte de los casos, sólo es preciso consultar una o dos tablas.

Transparencia y actualizaciones. De alguna forma es más difícil hacer transparente la base de
datos para usuarios que la actualizan que para aquellos que sólo leen datos. El problema principal es
asegurarse de que se actualizan todas las copias de un dato y también todos los fragmentos afectados.
En el caso más general, el problema de actualización de información repetida y fragmentada está relacionado con el problema de actualización de vistas.
PROCESAMIENTO DISTRIBUIDO DE CONSULTAS
Existen varios medios para calcular la respuesta a una consulta. En el caso de sistemas centralizados, el criterio principal para determinar el coste de una estrategia específica es el número de accesos
al disco. En un sistema distribuido es preciso tener en cuenta otros factores, como son:


El coste de transmisión de datos en la red.
El beneficio potencial que supondría en la ejecución el que varias localidades procesaran en
paralelo partes de la consulta.
El coste relativo de la transferencia de datos en la red y la transferencia de datos entre la memoria y el disco varía en forma considerable, dependiendo del tipo de red y de la velocidad de los discos. Por
tanto, en un caso general, no podemos tener en cuenta sólo los costes del disco o los de la red. Es necesario llegar a un equilibrio adecuado entre los dos.
RECUPERACIÓN EN SISTEMAS DISTRIBUIDOS
Hemos definido una transacción como una unidad de programa cuya ejecución conserva la consistencia de una base de datos. Una transacción debe ejecutarse de forma atómica. Es decir, se ejecutan
completamente todas las instrucciones de la transacción, o no se ejecuta ninguna. Además, en el caso de
ejecución concurrente, el efecto de ejecutar una transacción debe ser el mismo que si se ejecutara sola
en el sistema.

Estructura del sistema. Para garantizar la propiedad de atomicidad, existen varias planificaciones
de recuperación y control de concurrencia. Sin embargo, cuando se tiene un sistema de base de datos distribuido, es mucho más difícil garantizar la propiedad de atomicidad de una transacción. Esto
se debe a que es posible que participen varias localidades en la ejecución de una transacción. El fallo
de una de estas localidades o el fallo de la línea de comunicación entre ellas, puede dar como resultado un cálculo erróneo.
La función del gestor de transacciones de un sistema de base de datos distribuido es asegurar que la
ejecución de las distintas transacciones de un sistema distribuido conserve la atomicidad. Cada localidad cuenta con su propio gestor de transacciones local. Los distintos gestores de transacciones
cooperan para ejecutar las transacciones globales. Para comprender cómo puede estructurarse un
gestor de este tipo, definiremos un modelo abstracto para un sistema de transacciones. Cada localidad del sistema contiene dos subsistemas:

Gestor de transacciones, cuya función es gestionar la ejecución de aquellas transacciones (o sub transacciones) que accedan a datos almacenados en esa localidad. Observamos
que cada transacción puede ser bien una transacción local (es decir, que se ejecuta sólo en
esa localidad), o parte de una transacción global (es decir, que se ejecuta en varias localidades).

Coordinador de transacciones, cuya función es la de coordinar la ejecución de varias
transacciones (tanto local como global) iniciadas en esa localidad.
La estructura de un gestor de transacciones es similar en muchos aspectos a la que se utiliza en el
caso de un sistema centralizado. Cada gestor de transacciones se encarga de:

Mantener una bitácora para la recuperación.

Participar en un esquema de control de concurrencia apropiado para coordinar la ejecución
en paralelo de las transacciones que se ejecuten en esa localidad.
Como veremos, los esquemas, tanto de recuperación como de concurrencia, deben modificarse para
tomar en cuenta la distribución de transacciones.
El subsistema coordinador de transacciones no se necesita en el sistema centralizado, ya que las
transacciones tienen acceso a datos de una sola localidad. Como su nombre indica, un coordinador de
transacciones se encarga de coordinar todas las transacciones que se inicien en esa localidad. Para
cada una de estas transacciones, el coordinador debe:

Iniciar la ejecución de la transacción.

Dividir la transacción en varias sub transacciones, las cuales ha de distribuir en las localidades apropiadas para su ejecución.

Coordinar la terminación de la transacción, ya sea que quede ejecutada o abortada en todas las localidades.

Robustez. Un sistema distribuido puede sufrir el mismo tipo de fallos que un sistema centralizado
(por ejemplo, fallo de memoria, fallo del disco ). Sin embargo, en una configuración distribuida es necesario prever otro tipo de fallos, como pueden ser:

El fallo total de una localidad.

La interrupción de una línea de comunicación.

Pérdida de mensajes.

Fragmentación de la red.
Por tanto, para que el sistema sea robusto, es menester que detecte cualquiera de estos fallos, que
reconfigure el sistema de manera que pueda reanudarse el proceso y que se recupere una vez que
haya sido reparado el procesador o la línea de comunicación afectados. En general, no es posible distinguir entre la interrupción de una línea de comunicación, el fallo total de una localidad, la pérdida
de mensajes o la fragmentación de la red. Por lo general, es posible detectar que existe un fallo, pero
resulta difícil identificar el tipo del que se trata. Por ejemplo, suponemos que la localidad L1 no se
puede comunicar con la L2. Una posibilidad es que la L2 se encuentre fuera de servicio, pero también
es factible que se haya interrumpido la línea de comunicación entre L1 y L2.
Suponemos que la localidad Ll se da cuenta de que existe un fallo. En ese momento debe iniciar un
procedimiento de reconfiguración del sistema que le permita continuar con sus operaciones normales.

Si en la localidad que está fuera de servicio se almacena información repetida, debe actualizarse el catálogo de manera que las consultas no hagan referencia a la copia que se encuentra en dicha localidad.

Si, en el momento de presentarse el fallo existían transacciones activas en la localidad que
quedó fuera de servicio, deben abortarse. Es conveniente abortar estas transacciones tan
pronto como sea posible, ya que puede darse el caso de que hayan puesto bloqueos a información que se encuentra en localidades que siguen activas.

Si la localidad que quedó fuera de servicio es el distribuidor central de algún subsistema, es
preciso «elegir» un nuevo distribuidor. Los distribuidores centrales pueden ser, por ejem-
plo, asignadores de nombres, coordinadores de concurrencia o detectores de bloqueo globales.
En general, no es posible distinguir entre los fallos en las líneas de comunicación de la red y de las localidades. Por tanto, el esquema de reconfiguración que se adopte debe estar diseñado para que funcione correctamente aun cuando la red quede fragmentada. En particular es preciso evitar que se
presenten las siguientes situaciones:


Elección de dos o más distribuidores centrales en distintos fragmentos.
Actualización de un dato repetido en más de un fragmento de la red.
También es necesario tener cuidado al reintegrar al sistema una localidad o línea de comunicación
separada. Cuando una localidad que quedó fuera de servicio se recupera, debe iniciar un procedimiento de actualización de sus tablas de sistema para que reflejen los cambios que tuvieron lugar
mientras estaba inactiva. Si la localidad tenía copias de datos, debe obtener los valores actuales de
todos ellos y asegurarse de recibir las actualizaciones futuras. Esto es más complicado de lo que parece, ya que es posible que se actualicen los datos que se están procesando mientras que el sistema
se recupera.
Una solución sencilla es suspender temporalmente todas las operaciones del sistema mientras la localidad que quedó fuera de servicio se reintegra a él. Los problemas que acarrea esta suspensión en la
mayor parte de las aplicaciones no pueden aceptarse. Es preferible representar a las tareas de recuperación como una serie de transacciones. En este caso, el subsistema de control de concurrencia y
el manejo de transacciones puede encargarse de realizar de manera fiable la reintegración de la localidad.
Si se recupera una línea de comunicación interrumpida, es posible que se unan de nuevo dos fragmentos de la red. Dado que la fragmentación de una red limita las operaciones que pueden permitirse en algunas localidades, o en todas ellas, es conveniente enviar un mensaje a todas ellas informando sin dilación que la línea se recuperó. En las redes en que no se permita el envío de este tipo de
mensajes pueden utilizarse otros esquemas.