10.

3 Componentes de un Sistema de Base de datos

distribuida. Un sistema de base de datos distribuida normalmente tiene los componentes
de software, como se ilustra en la FIGURA 10.4. Tenga en cuenta que algunos sitios contienen
todos estos componentes, mientras que otros podrían no.

Componente de comunicaciones de datos (DC). Las comunicaciones de datos componente es el

software en cada nodo que lo vincula a la red. Este componente de CC incluye una descripción
completa de la nodos y líneas. Para cada nodo, identifica el procesamiento realizado, capacidad de
almacenamiento, potencia de procesamiento y estado actual. Para cada enlace, identifica los
nodos que conecta, el tipo de enlace, el ancho de banda, los protocolos requerido, y el estado
actual del enlace.

Componente de administración de bases de datos locales (LDBMS). El local componente de

gestión de bases de datos funciona como una base de datos estándar sistema de gestión,
responsable de controlar los datos locales en cada sitio que tiene una base de datos. Tiene su
propio diccionario de datos para datos locales, como, así como los subsistemas habituales para el
control de simultaneidad, recuperación, consulta optimización, y así sucesivamente.
Diccionario de datos global (GDD). El diccionario de datos global es un repositorio de información
sobre la base de datos distribuida. Incluye una lista de todos los elementos de datos con su
ubicación y otra información sobre datos almacenados en cualquier lugar del sistema distribuido.

Componente de administración de bases de datos distribuidas (DDBMS). El componente de

gestión de bases de datos distribuidas es el sistema de gestión para la base de datos global. Tiene
muchas funciones, incluyendo las siguientes:

1 Proporciona la interfaz de usuario. La transparencia de la ubicación es una de los

principales objetivos de las bases de datos distribuidas. Idealmente, el usuario necesita no
especificar el nodo en el que se encuentran los datos, sino que actúa como si todo el dato se
almacena localmente y el DBMS local accede a ellos. El DBMS local, sin embargo, no es consciente
de la distribución, por lo que sólo las solicitudes que pueden satisfacerse localmente debe enviarse
al DBMS local. El DDBMS, por lo tanto, intercepta todas las solicitudes de datos y las dirige al
sitio(s) adecuado(s).

2. Localiza los datos. Después de recibir una solicitud de datos, el DDBMS consulta el
diccionario de datos global para encontrar el nodo o nodos donde los datos se almacenan. Si la
solicitud puede ser cumplimentada íntegramente en el nodo, pasa la consulta al DBMS local, que
la procesa. De lo contrario, debe idear y llevar a cabo un plan para obtener los datos

3. Procesa consultas. Las consultas se pueden clasificar como locales, remotas o

Compuesto. Una solicitud local es una que puede ser llenada por el Dbms. Las solicitudes locales
simplemente se transmiten al DBMS local, que encuentra los datos y los pasa de vuelta al DDBMS,
que en turno lo pasa al usuario. (Recuerde que el DBMS local no tiene ningún usuario interfaz.)
Una solicitud remota es una que se puede llenar completamente en otro nodo. En este caso, el
DDBMS pasa la solicitud a el DBMS en ese nodo y espera la respuesta, que luego regalos al
usuario. Una solicitud compuesta, también llamada solicitud, es uno que requiere información de
varios nodos. Para solicitud compuesta, el DDBMS tiene que descomponer la consulta en varias
solicitudes remotas y locales que juntos proporcionar la información necesaria. A continuación,
dirige cada consulta a la DBMS adecuado, que lo procesa y devuelve los datos a el DDBMS. A
continuación, el DDBMS coordina los datos recibidos formular una respuesta para el usuario.

4. Proporciona control y recuperación de simultaneidad en toda la red Procedimientos.

Aunque cada DBMS local es responsable de actualización y recuperación de sus propios datos, sólo
el DDBMS es consciente problemas en todo el sistema. El control de simultaneidad en toda la red
es para evitar que los usuarios simultáneos interfieran con una Otro. Se necesitan procedimientos
de recuperación en toda la red porque, si se produce un error en un nodo local, aunque el DBMS
local puede recuperar sus datos a su estado en el momento del fallo, sólo el DDBMS puede
mantener realizar un seguimiento y aplicar los cambios realizados mientras el nodo estaba
inactivo. Preservación de las propiedades ACID para las transacciones en las bases de datos es una
tarea compleja que es manejada por el DDBMS.

Proporciona traducción de consultas y datos en sistemas heterogéneos. En sistemas

heterogéneos con hardware diferente, pero DBMS local, traducciones menores de códigos y
longitudes de palabras y se necesitan ligeros cambios debido a las diferencias en la
implementación. Si los DBMS locales son diferentes, se necesita una traducción importante. Éste
incluye cambiar del lenguaje de consulta de un DBMS a ese de otro y cambio de modelos de datos
y estructuras de datos. Si ambos hardware y DBMS son diferentes, ambos tipos de traducción son
Necesario.

10.4 Colocación de datos

Una de las decisiones más importantes que tiene un diseñador de bases de datos distribuidas
hacer es la colocación de datos. La colocación adecuada de los datos es un factor crucial
determinar el éxito de un sistema de base de datos distribuido. Hay cuatro alternativas básicas:
centralizada, replicada, particionada e híbrida. Algunos de estos requieren análisis adicionales para
ajustar la colocación de datos.

Al decidir entre las alternativas de colocación de datos, los siguientes factores ser considerado:

1. Referencia de localidad de datos. Los datos deben colocarse en el sitio donde se utiliza
más a menudo. El diseñador estudia las aplicaciones para identificar los sitios donde se
realizan, e intenta colocar el dato de tal manera que la mayoría de los accesos son locales.

2. Fiabilidad de los Datos. Almacenando varias copias de los datos en sitios geográficamente
remotos, el diseñador maximiza la probabilidad que los datos serán recuperables en caso
de daños físicos a cualquier sitio

3. Disponibilidad de datos. Al igual que con la fiabilidad, el almacenamiento de varias copias

asegura los usuarios que los elementos de datos estarán disponibles para ellos, incluso si
el sitio de a los que normalmente se accede a los elementos no está disponible debido a
un fallo del nodo o su único enlace.

4. Capacidades y costos de almacenamiento. Los nodos pueden tener un almacenamiento

diferente capacidades y costos de almacenamiento que deben tenerse en cuenta al decidir
dónde deben conservarse los datos. Los costos de almacenamiento se minimizan cuando
un solo copia de cada elemento de datos, pero los costos de hundimiento del
almacenamiento de datos hacer que esta consideración sea menos importante.

5. Distribución de la carga de procesamiento. Una de las razones para elegir un sistema

distribuido es distribuir la carga de trabajo para que el procesamiento poder se utilizará
más eficazmente. Este objetivo debe ser equilibrado contra la localidad de referencia de
datos.

6. Costos de comunicaciones. El diseñador debe considerar el costo de utilizando la red de

comunicaciones para recuperar datos. Costos de recuperación y el tiempo de recuperación
se minimiza cuando cada sitio tiene su propia copia de todos los datos. Sin embargo,
cuando se actualizan los datos, los cambios deben y luego ser enviado a todos los sitios. Si
los datos son muy volátiles, esto costos de comunicaciones para la sincronización de
actualizaciones.
Las cuatro alternativas de colocación, como se muestra en la FIGURA 10.5, son las Siguientes.

1. El Centralizado. Esta alternativa consiste en una sola base de datos y DBMS almacenado en
una ubicación, con los usuarios distribuidos, como se ilustra en Figura 10.1. No hay
necesidad de un DDBMS o un diccionario de datos global, porque no hay una distribución
real de los datos, sólo del procesamiento. Los costos de recuperación son altos, porque
todos los usuarios, excepto los utilizar la red para todos los accesos. Los costos de
almacenamiento son bajos, ya que sólo se conserva una copia de cada elemento. No hay
necesidad de actualización sincronización y el mecanismo de control de simultaneidad
estándar es suficiente.
2. La fiabilidad es baja y la disponibilidad es pobre, porque error en el nodo central da lugar a
la pérdida de todo el sistema. La carga de trabajo se puede distribuir, pero los nodos
remotos necesitan acceder a la base de datos para realizar aplicaciones, por lo que la
ubicación de la referencia de datos es baja. Esta alternativa no es un verdadero sistema de
bases de datos distribuidas
3. Replicado. Con esta alternativa, se conserva una copia completa de la base de datos en
cada nodo. Las ventajas son la máxima ubicación de referencia, fiabilidad, disponibilidad
de datos y distribución de carga de procesamiento. Los costos de almacenamiento son
más altos en esta alternativa. Los costos de comunicaciones para las recuperaciones son
bajo, pero el costo de las actualizaciones es alto, ya que cada sitio debe recibir cada
actualizar. Si las actualizaciones son muy infrecuentes, esta alternativa es una buena
4. Repartido. Aquí, sólo hay una copia de cada elemento de datos, pero los datos se
distribuyen entre nodos. Para permitir esto, la base de datos es fragmentos o partes
desarticulados. Si la base de datos es relacional uno, los fragmentos pueden ser
 subconjuntos de tablas verticales (formados por proyección) o subconjuntos horizontales
(formados por selección) de relaciones globales.

La FIGURA 10.6 proporciona ejemplos de fragmentación. En cualquier horizontal

fragmentación, cada tupla de cada relación debe asignarse a uno o más fragmentos tales
que tomar la unión de los fragmentos resultados en la relación original; para el caso con
particiones horizontales, un tupla se asigna exactamente a un fragmento. En una
fragmentación vertical esquema, las proyecciones deben ser sin pérdidas, por lo que las
relaciones originales pueden ser reconstruido tomando la unión de los fragmentos. El
método más fácil de asegurar que las proyecciones son sin pérdidas es, por supuesto,
incluir la clave en cada fragmento; sin embargo, esto viola la desarticulación condición
porque los atributos clave se replicarían. El diseñador puede optar por aceptar la
replicación de claves, o el sistema puede agregar un ID de tupla(un identificador único
para cada tupla) invisible para el usuario. El sistema incluiría el ID de tupla en cada
fragmento vertical de la tupla y usaría ese identificador para realizar combinaciones.
Además de los fragmentos verticales y horizontales, se pueden mezclar fragmentos,
obtenidos por sucesivas aplicaciones de selección y proyecto Operaciones. La creación de
particiones requiere un análisis cuidadoso para garantizar que los datos se asignan
elementos al sitio adecuado. Si los elementos de datos han sido asignados al sitio donde se
utilizan con mayor frecuencia, la localidad de los datos referencia será alta con esta
alternativa. Porque sólo una copia de cada artículo se almacena, la fiabilidad de los datos y
la disponibilidad de un artículo específico son bajos. Sin embargo, el error de un nodo da
lugar a la pérdida de datos, por lo que la fiabilidad y disponibilidad en todo el sistema son
más altas que en el caso centralizado. Los costos de almacenamiento son bajos, y las
comunicaciones los costos de un sistema bien diseñado deben ser bajos. La carga de
procesamiento también debe estar bien distribuidos si los datos se distribuyen
correctamente.

5. Híbrido. En esta alternativa, diferentes partes de la base de datos son distribuidos de

manera diferente. Por ejemplo, aquellos registros con alta localidad de referencia están
particionados, mientras que los utilizados comúnmente por todos los nodos se replican, si
las actualizaciones son poco frecuentes. Los que son necesarios por todos los nodos, pero
actualizado con tanta frecuencia que la sincronización ser un problema, podría estar
centralizado. Esta alternativa está diseñada para optimizar la colocación de los datos, de
modo que todas las ventajas y ninguna de las desventajas de los otros métodos son
posibles. Sin embargo, muy se requiere un análisis cuidadoso de los datos y el
procesamiento con este plan.

Como ejemplo, consideremos cómo el esquema de base de datos de la Universidad podría

ser distribuidos. Suponemos que la universidad tiene un campus principal y cuatro
sucursales (Norte, Sur, Este y Oeste), y que los estudiantes tienen un campus donde
normalmente se registran y toman clases. Sin embargo, los estudiantes pueden inscribirse
en cualquier clase en cualquier campus. Los miembros de la facultad enseñan en un solo
campus. Cada clase se ofrece en un solo campus. Modificaremos el esquema para incluir
ligeramente la información del campus en nuestro nuevo esquema global:
Es razonable suponer que los registros de los estudiantes se utilizan con mayor frecuencia
en el campus del estudiante, por lo que dividiríamos la relación del estudiante, colocando
el registro de cada estudiante en su campus de origen. Lo mismo es cierto para Registros
de la facultad. La relación Class también podría dividirse de acuerdo con el campus donde
se ofrece la clase. Sin embargo, esto significaría que las consultas acerca de las ofertas en
otros campus siempre requerirían el uso de la red. Si tales consultas son frecuentes, una
alternativa sería replicar toda la Clase relación en todos los sitios. Debido a que las
actualizaciones de esta tabla son relativamente infrecuentes, y la mayoría de los accesos
son de solo lectura, la replicación reduciría la comunicación costos, por lo que elegiremos
esta alternativa. La tabla Enroll no sería un candidato para la replicación, porque durante
el registro, las actualizaciones deben hacer rápidamente y actualizar varias copias
consume mucho tiempo. Es deseable para tener los registros de Inscripción en el mismo
sitio que el registro del Estudiante y como el registro de clase, pero estos pueden no ser el
mismo sitio. Por lo tanto, podríamos centralizar los registros de Inscripción en el sitio
principal, posiblemente con copias en el sitio del estudiante y el sitio de la clase. Podemos
designar el sitio principal como la copia principal para Inscribirse. El esquema de
fragmentación se expresaría por especificar las condiciones para seleccionar registros,
como en:

No estamos fragmentando la relación Class. Porque hemos hecho diferentes decisiones

para diferentes partes de la base de datos, se trata de una fragmentación híbrida
Esquema. La FIGURA 10.7 ilustra las decisiones de colocación de datos para este ejemplo.