TEMA: LAS BASES DE DATOS DISTRIBUIDAS.

[pic 1][pic 2][pic 3]

LAS BASES DE DATOS DISTRIBUIDAS.

INTRODUCCION:

Las bases de datos distribuidas, son bases de datos conectadas entre sí, mediante algún tipo de red de comunicaciones. Las bases de datos distribuidas son muy utilizadas actualmente por muchas empresas, ya que son la manera más fácil de interconectar sus bases de datos de sus sucursales, ya sea una tienda, en el cual se registran las ventas, ganancias, etc. O simplemente cualquier empresa que necesite guardar sus datos de manera segura, las bases de datos distribuidas no necesariamente deben de estar cerca una de la otra ya que están conectadas por una red de comunicación, pueden estar en diferentes países y aun así se podrían obtener los datos almacenados de una base de datos que esté en otro país.

Las bases de datos distribuidas se caracterizan por su eficiencia en el almacenamiento de datos ya que son muy seguras para su uso.

Además por su autonomía local, por lo tanto no dependen de una base de datos para funcionar ( no dependen de un sitio central), son independientes en cuanto al equipo, sistema operativo, a la red y al DBMS Que es el software que administra todas las bases de datos de los sitios y proporciona un mecanismo de acceso que hace transparente esta distribución a los usuarios.

Los sitios de las bases de datos están diseñados para trabajar en conjunto con el fin de que una persona desde cualquier lugar pueda tener información a los datos desde cualquier punto de la red, como si los datos estuvieran físicamente en el lugar solicitado.

Todos los sitios tienen sus bases de datos reales o físicas, los datos que son almacenados localmente en alguna base de datos de la red están disponibles para todos los puntos, por lo tanto son muy eficaces en su trabajo ya que le facilita a las empresas el trabajo de tener todos los mismos datos en todas sus sucursales de alguna empresa, y así intercambiarse datos entre sí, sin importar la ubicación en la que este siempre y cuando esté conectada a la red.

BASES DE DATOS DISRIBUIDAS

Un sistema de bases de datos distribuidas es aquel en el que hay múltiples sitios de bases
de datos unidos por un sistema de comunicaciones, en forma tal que los datos en cualquier
sitio son accesibles para los usuarios de otros sitios. Normalmente, cada sitio o nodo tiene
un sistema completo de procesamiento de información, con su propia función de adminis-
tración de datos, personal, usuarios, hardware y software, inclusive una base de datos local,
sistema de administración de base de datos y software de comunicaciones. Lo mínimo que
debe tener un sitio es memoria y procesador de comunicaciones. Los sitios por lo general
están separados geográficamente y están unidos por un sistema de telecomunicaciones,
aunque es posible tener un sistema distribuido y comunicado por medio de una red de área
local dentro de un solo edificio o área pequeña. Se pretende que los usuarios no necesiten
conocer la verdadera localización de los datos a que acceden, y para ellos el sistema parece
ser una base de datos local. En función de las necesidades de la organización, las bases de
datos distribuidas tienen las siguientes ventajas sobre un sistema único y centralizado que
dé acceso remoto a los usuarios.
1. Autonomía local. Un objetivo importante de cualquier sistema distribuido es permitir
que el usuario tenga un control más directo sobre el sistema que utiliza. Si cada sitio
tiene su propio sistema, se pueden hacer localmente más funciones básicas de proce-
samiento de información, como análisis de sistemas, programación de aplicaciones,
operaciones y entrada de datos, lo que resulta en un mayor control local y satisfac-
ción de los usuarios que si estas funciones se efectuaran en un sitio central, lejos de
las ocupaciones y actividades de los usuarios. Al mismo tiempo, los diseñadores de un
sistema distribuido deben insistir en la planeación y coordinación a fin de que se
desarrollen estándares de uso obligatorio, y los sistemas individuales sean compati-
bles.
2. Confiabilidad mejorada. Un sistema distribuido es más confiable que uno centraliza-
do, porque el procesamiento se lleva a cabo en varios sitios, por lo que la falla de un
nodo no detiene a todo el sistema. Los sistemas distribuidos se diseñan para que con-
tinúen funcionando a pesar de que falle un nodo o vínculo de comunicaciones. Si
falla un nodo, los usuarios de ese sitio no podrán usar el sistema, o sus solicitudes se
envían a otro sitio. Los usuarios de otros sitios no se ven afectados a menos que soli-
citen datos almacenados en el nodo inhabilitado, o cierto procesamiento que sólo en
éste se lleva a cabo. Si falla un vínculo, el nodo se puede aislar, pero el resto del siste-
ma continúa en operación. En ciertos sistemas, el nodo tiene otras líneas que se utili-
zan en lugar de la que está fuera de uso.
3. Mejor disponibilidad de datos. Los sistemas de bases de datos distribuidas con fre-
cuencia brindan la duplicación de los datos, de modo que si un nodo falla o el único
vínculo que comunica con éste se cae, sus datos siguen disponibles, siempre y cuan-
do se mantenga una copia en algún lugar del sistema.
4. Mejor rendimiento. A medida que aumentan los requerimientos de procesamiento de
la información, el sistema existente tal vez sea incapaz de manejar la carga de proce-
samiento. En un sistema centralizado llega a ser necesario actualizarlo con cambios
en el hardware y software, o cambio a un sistema nuevo, con mayor conversión de
software, a fin de que satisfaga el incremento de desempeño requerido. Un sistema
distribuido es básicamente modular, lo que permite que se agreguen nuevos procesa-
dores a medida que se necesitan. En función de la topología de la red, o planta física,
es fácil integrar sitios nuevos.
12.2 Arquitecturas para un sistema distribuido 427
mite un acceso más rápido a los datos locales que con un sistema centralizado que
atienda sitios remotos. Sin embargo, en un sistema distribuido mal diseñado, el siste-
ma de comunicaciones quizá se utilice mucho y dé como resultado un tiempo de res-
puesta más largo.
6. Costos menores de comunicaciones. Si los datos que se usan localmente se guardan en
forma local, los costos de las comunicaciones serán menores, ya que no se empleará
la red para la mayor parte de solicitudes. En un sistema centralizado, la red de comu-
nicaciones es necesaria para todas las solicitudes remotas. Sin embargo, se debe con-
siderar el costo adicional del software de la base de datos, los costos adicionales de
almacenamiento para múltiples copias de ítems de datos y software, y mayores costos
de hardware y de distribución.
12.2 Arquitecturas para un sistema distribuido
Los factores que debe considerar el diseñador de un sistema de base de datos distribuidas al
elegir una arquitectura incluyen la colocación de los datos, tipo de sistemas de comunica-
ciones, modelos de datos que soporta y tipos de aplicaciones. Las alternativas de colocación
de los datos se estudiarán en detalle en la sección 12.5. Difieren en la cantidad de replica-
ción que permiten de los datos. Cada alternativa impone un tipo diferente de sistema y uti-
liza procedimientos distintos de actualización y descomposición de solicitudes. Si el sistema
de comunicaciones es lento y caro de usar se favorece un almacenamiento y procesamiento
locales. Un sistema rápido y barato de comunicaciones, como una red de área local, favore-
ce el almacenamiento y procesamiento centralizados. Los sistemas distribuidos aceptan
varios modelos de datos y lenguajes de manipulación para ellos, igual que en los sistemas
centralizados. En general, un diseñador debe evitar los modelos que usen una recuperación
de un registro a la vez, y a cambio de eso elegir aquellos que permitan operaciones a nivel
de conjunto, debido al número de mensajes que se requieren para la recuperación con nave-
gación del programador. Ésta es una de las razones por las que el modelo relacional es el
que se usa con más frecuencia en las bases de datos distribuidas. Al considerar los tipos de
aplicaciones por realizar contra la base de datos escogida, el diseñador necesita estimar el
tamaño de ésta, número de transacciones, cantidad de datos que requiere la transacción,
complejidad de las transacciones, número de recuperaciones en relación con el número de
actualizaciones, y número de transacciones que hacen referencia a datos locales en compa-
ración con los remotos. Entre las alternativas están las siguientes:
12.2.1 Procesamiento distribuido con el uso de una base
de datos centralizada
En esta arquitectura, que se ilustra en la figura 12.1, la base de datos en sí no está distribui-
da, pero los usuarios acceden a ella a través de una red de cómputo. El procesamiento se
lleva a cabo en sitios múltiples, con el empleo de datos del sitio de la base de datos central.
Éste también lleva a cabo procesamiento, con frecuencia tanto para sus aplicaciones locales
como para las centralizadas. Cuando acceden a datos desde la base de datos para su proce-
samiento, los sitios locales se comunican sólo con el sitio central, no entre sí.
en los sistemas cliente-servidor, la base de datos reside en
una máquina en el extremo terminal, llamada servidor, y es común que los usuarios acce-
dan a los datos a través de sus estaciones de trabajo, que funcionan como clientes. Las fun-
ciones de la base de datos se dividen entre el cliente y el servidor. El cliente proporciona al
usuario la interfaz y ejecuta la aplicación lógica, mientras que el servidor administra los
datos y procesa las solicitudes de éstos. En una transacción interactiva común, el usuario
interactúa con la estación de trabajo cliente por medio de una interfaz gráfica provista ya
sea por el sistema de base de datos o por un tercer proveedor. Además de manejar la aplica-
ción lógica, el cliente realiza la edición inicial de las solicitudes de datos (por lo general,
SQL), revisa la sintaxis de la solicitud y genera otra para la base de datos, que es enviada al
servidor a través de la red. Éste valida la solicitud por medio de la revisión del diccionario
de datos, autorización y las restricciones de integridad; optimiza la consulta; aplica contro-
les de concurrencia y técnicas de recuperación; recupera los datos y los envía de regreso al
cliente, que los presenta al usuario. En el cliente también se ejecutan programas de aplica-
ción, en los que las solicitudes de datos pasan por una interfaz de programa de aplicación
(IPA) hacia el servidor en una forma similar a la descrita. Si el cliente se apega a un están-
dar como el ODBC o el JDBC, se comunica con cualquier servidor que provea una interfaz
estándar. A diferencia del ambiente de base de datos centralizada, el servidor no procesa
aplicaciones por sí mismo.
12.2.3 Bases de datos paralelas
En la arquitectura de bases de datos paralelas hay procesadores múltiples que controlan
unidades de disco múltiples que contienen a la base de datos, que puede estar particionada
en los discos, o tal vez duplicada. Si la tolerancia a las fallas tiene gran prioridad, el sistema
se prepara de modo que cada componente sirva como respaldo para los demás componen-
tes del mismo tipo y se haga cargo de las funciones de cualquier componente similar que
falle. Las arquitecturas de sistemas de bases de datos paralelas son de memoria compartida,
disco compartido, nada compartido, o jerárquicas, que también se llaman cluster.
■ En un sistema de memoria compartida, todos los procesadores tienen acceso a la
misma memoria y a los discos compartidos, como se ilustra en la figura 12.3(a). La
base de datos reside en los discos, ya sea que esté duplicada en ellos o particionada
entre todos. Cuando un procesador hace una solicitud de datos, éstos son enviados
desde cualquiera de los discos hacia los búferes de la memoria compartidos por
todos los procesadores. El DBMS informa al procesador cuál página de la memoria
contiene la página de datos solicitada.
■ En el diseño de disco compartido, que se muestra en la figura 12.3(b), cada procesa-
dor tiene acceso exclusivo a su propia memoria, pero todos los procesadores tienen
acceso a las unidades de disco compartidas. Cuando un procesador solicita datos, las
páginas respectivas son llevadas a la memoria del procesador.
■ En los sistemas de nada compartido, cada procesador tiene control exclusivo de su
propia unidad o unidades de disco y de su memoria, como se aprecia en la figura
12.3(c), pero los procesadores se comunican uno con otro.
■ En las arquitecturas jerárquica o cluster, los sistemas constituidos por nodos de
memoria compartida están conectados por medio de una red, como se ve en la figura
12.3(d). Los sistemas sólo comparten comunicaciones entre sí, y la arquitectura gene-
ral entre sistemas no comparte nada.
El propósito de las bases de datos paralelas es mejorar el rendimiento por medio de ejecutar
las operaciones en forma paralela en los distintos dispositivos. Es esencial la partición cui-
dadosa de los datos de modo que sea posible la evaluación en paralelo de las consultas. La
partición de los datos se hace con partición de rango, que significa que los registros se
colocan en discos diseñados de acuerdo con un rango de valores para cierto atributo. Otros
métodos son por dispersión (hashing) de algunos atributos, o con la colocación de los
registros nuevos en un formato round robin sobre discos sucesivos. Cuando se procesa una
consulta, como los datos requeridos tal vez residan en discos diferentes, la consulta se des-
compone en subconsultas que luego se procesan en paralelo con el uso de la partición apro-
piada de la base de datos.
Las bases de datos paralelas que usan una arquitectura de no compartir nada proveen velocidad lineal, lo que significa que conforme se incrementa el número de procesadores y discos,
aumenta en forma lineal la velocidad de las operaciones. También brindan escalamiento
lineal, es decir son escalables, de modo que si se agregan más procesadores y discos el nivel
de rendimiento se mantiene. Esto permite incrementar la cantidad de datos almacenados y
procesados sin sacrificar el rendimiento.
12.2.4 Bases de datos distribuidas
En esta arquitectura, la base de datos está distribuida, tal vez con duplicación, entre varios
sitios relativamente autónomos. La distribución es transparente para el usuario, que no
necesita especificar el lugar en que se localizan los datos (transparencia de la ubicación).
Un sistema distribuido es homogéneo o heterogéneo. En un sistema homogéneo todos los
nodos usan el mismo hardware y software para el sistema de la base de datos. En un sistema
heterogéneo los nodos tienen diferente hardware y/o software. Como un sistema homogé-
neo es mucho más fácil de diseñar y administrar, es normal que los diseñadores lo escojan.
Los sistemas heterogéneos por lo general son el resultado de las situaciones en que los sitios
individuales toman sus propias decisiones sobre el hardware y software, y las comunicacio-
nes se agregan en una etapa posterior, lo cual es la norma. Entonces, el diseñador tiene la
tarea de unificar sistemas dispares. En un sistema heterogéneo es necesario hacer traduccio-
nes que permitan que las bases de datos se comuniquen. Como la transparencia es un obje-
tivo importante, el usuario en un sitio particular hace solicitudes en el lenguaje del sistema
de administración de la base de datos en ese sitio. Entonces, es el sistema el que tiene la res-
ponsabilidad de localizar los datos, que pueden estar en otro sitio con diferente hardware y
software. La solicitud incluso podría requerir la coordinación de datos almacenados en
varios sitios, todos con distintos equipamientos. Si dos sitios tienen hardware diferente pero
iguales sistemas de administración de la base de datos, la traducción no es demasiado difí-
cil, y consiste sobre todo en el cambio de códigos y tamaños de la palabra. Si tienen el
mismo hardware pero diferente software, la traducción sí es difícil, y requiere que el modelo
y estructura de los datos de un sistema se exprese en términos de los modelos y estructuras
de otro. Por ejemplo, si una base de datos es relacional y la otra utiliza el modelo orientado
a objetos, éstos deben presentarse en forma de tabla a los usuarios de la base de datos rela-
cional. Además, deben traducirse los lenguajes de las consultas. El ambiente más difícil
involucra hardware y software distintos. Esto requiere la traducción de los modelos de los
datos, estructuras de éstos, lenguaje de la consulta, tamaños de las palabras y códigos.
12.3 Componentes de un sistema de bases
de datos distribuidas
Un sistema de bases de datos distribuidas normalmente tiene los siguientes componentes de
software, que se ilustran en la figura 12.4. Observe que ciertos sitios contienen a todos,
mientras que otros no.
■ Componente de comunicaciones de los datos (DC). El componente de comunica-
ciones de los datos es el software en cada nodo que lo liga con la red. Este compo-
nente incluye la descripción completa de los nodos y líneas de la red. Identifica para
cada nodo el procesamiento realizado, la capacidad de almacenamiento, la potencia
de procesamiento y el estado actual. Identifica para cada vínculo los nodos que
conecta, el tipo de vínculo, ancho de banda, protocolos requeridos y estado presente
del vínculo.
■ Componente del sistema de administración de la base de datos local (LDBMS, por
sus siglas en inglés). El componente del sistema de administración de la base de datos
local funciona como un sistema estándar de administración de base de datos, res-
ponsable de controlar los datos locales en cada sitio que tenga una base de datos.
Tiene su propio diccionario de datos locales, así como los subsistemas usuales para el
control de concurrencia, recuperación, optimización de la consulta, etcétera.
■ Diccionario de datos global (GDD, por sus siglas en inglés). El diccionario de datos
global es una recopilación de información acerca de la base de datos distribuida.
Incluye una lista de todos los aspectos de los datos, su ubicación y otra clase de infor-
mación sobre cualquier dato almacenado en cualquier parte del sistema distribuido.
■ Componente del sistema de administración de la base de datos distribuida
(DDBMS, por sus siglas en inglés). El componente de la base de datos distribuida es
el sistema de administración para la base de datos global. Tiene muchas funciones,
entre las que se tienen las siguientes:
1. Proporciona la interfaz de usuario. La transparencia de la ubicación es uno de los
principales objetivos de las bases de datos distribuidas. Idealmente, el usuario no
necesita especificar el nodo en que se localiza cada dato, sino que actúa como si
todos los datos estuvieran almacenados localmente y se accediera a ellos por
medio del DBMS local. Sin embargo, éste ignora la distribución, por lo que al
DBMS local sólo deben enviarse solicitudes que se puedan satisfacer en forma
local. Entonces, el DDBMS intercepta todas las solicitudes de datos y las dirige al (los)
sitio(s) apropiado(s).
2. Localiza los datos. Después de recibir una solicitud de datos, el DDBMS consulta
al diccionario de datos global para encontrar el nodo o nodos en los que se alma-
cenan. Si la solicitud se puede satisfacer por completo en el nodo local, pasa la
consulta al DBMS local y éste la procesa. De otro modo, debe desarrollarse y eje-
cutarse un plan para obtener los datos.
3. Proceso de consultas. Las consultas se clasifican en locales, remotas o compuestas.
Una consulta local es aquella susceptible de ser satisfecha por el DBMS local. Las
solicitudes locales son simplemente enviadas al DBMS local, que localiza los datos
y los envía de regreso al DDBMS, que a su vez los pasa al usuario (recuerde que el
DBMS local no tiene interfaz de usuario). Una solicitud remota es la que puede
cumplirse por completo en otro nodo. En este caso, el DDBMS pasa la solicitud al
DBMS de ese nodo y espera la respuesta, que luego presenta al usuario. Una soli-
citud compuesta, también llamada global, es la que requiere información de
varios nodos. Para procesar una solicitud compuesta, el DDBMS tiene que des-
componer la consulta en varias solicitudes remotas y locales que juntas proporcio-
narán la información necesaria. Después dirige cada consulta al DBMS apropiado,
cada uno de los cuales la procesa y envía los datos al DDBMS. Luego, el DDBMS
coordina los datos recibidos a fin de formular una respuesta para el usuario.
4. Proporciona control de concurrencia y procedimientos de recuperación en todo el sistema. Aunque cada DBMS local es responsable de manejar los cambios y recupe-
ración de sus propios datos, sólo el DDBMS está a cargo de problemas que
involucren a todo el sistema. El control de concurrencia en todo el sistema es
necesario para impedir que usuarios simultáneos interfieran uno con otro. Los
procedimientos de recuperación en todo el sistema son necesarios porque si un
nodo falla, aunque el DBMS local devuelva los datos a la condición que tenían en

el momento de la falla, únicamente el DDBMS puede darles seguimiento y aplicar
los cambios realizados mientras el nodo estaba inactivo.
5. Proporciona la traducción de consultas y datos en sistemas heterogéneos. En siste-
mas heterogéneos con diferente hardware pero el mismo DBMS local, son necesa-
rias traducciones menores de códigos y tamaños de la palabra, y modificaciones
ligeras debidas a las diferencias en la implementación. Si los DBMS locales son
diferentes, se necesitan traducciones más complejas. Esto incluye el cambio del
lenguaje de las consultas de un DBMS al del otro, y de los modelos y estructuras
de los datos. Si tanto el hardware como el DBMS son diferentes, se requieren
ambos tipos de traducción.
12.4 Colocación de los datos
Una de las decisiones más importantes que un diseñador de bases de datos tiene que tomar
se refiere a la ubicación de los datos. Esto es un factor crucial para determinar el éxito de un
sistema de base de datos distribuida. Hay cuatro alternativas básicas: centralizada, replicada, particionada o híbrida. Algunas de éstas requieren un análisis adicional para afinar la
ubicación de los datos. A fin de decidir entre las alternativas para colocar los datos es nece-
sario considerar los factores siguientes:
1. Localidad de los datos a que se hace referencia. Los datos deben colocarse en el sitio
en que se utilizan con más frecuencia. El diseñador estudia las aplicaciones para
identificar los sitios en que se ejecutan y trata de situar los datos en forma tal que la
mayoría de accesos sean locales.
2. Confiabilidad de los datos. Al guardar múltiples copias de los datos en sitios geográfi-
camente remotos, el diseñador maximiza la probabilidad de que los datos sean recu-
perables en caso de daño físico a cualquier sitio.
3. Disponibilidad de los datos. Igual que con la confiabilidad, guardar muchas copias
garantiza a los usuarios que los datos serán asequibles, aun si el sitio desde el que se
acceden normalmente no se encuentra disponible debido a la falla del nodo o su
único vínculo de comunicación.
4. Capacidades y costos de almacenamiento. Aunque el costo del almacenamiento de los
datos por lo general es más bajo que el de su transmisión, los nodos pueden tener
distintas capacidades y costos de almacenamiento. Éstos deben tomarse en cuenta al
decidir dónde guardarlos. Los costos de almacenamiento se minimizan si se conserva
una sola copia de cada dato.
5. Distribución de la carga de procesamiento. Una de las razones para escoger un sistema
distribuido es repartir la carga de trabajo de modo que la potencia de procesamiento
se utilice con más eficacia. Este objetivo debe balancearse con el de la ubicación de
los datos a que se hace referencia.
6. Costos de comunicación. El diseñador debe considerar el costo de usar la red de
comunicaciones para la recuperación de datos. Los costos y tiempos de recuperación
son mínimos si cada sitio tiene su propia copia de todos los datos. Sin embargo,
cuando los datos se actualizan, los cambios deben enviarse a todos los sitios. Si los
datos son muy volátiles, esto da como resultado costos de comunicación elevados
para actualizar la sincronización.
Como se aprecia en la figura 12.5, las cuatro alternativas de ubicación son las siguientes:
1. Centralizada. Esta alternativa consiste en una sola base de datos y DBMS guardados
en una ubicación.

hay necesidad de un DDBMS o diccionario de datos global, porque no hay distribu-
ción real de los datos, sólo del procesamiento. Los costos de recuperación son altos
porque todos los usuarios, excepto aquellos en el sitio central, usan la red para todos
los accesos. Los costos de almacenamiento son bajos, ya que se conserva sólo una
copia de cada registro. No hay necesidad de actualizar la sincronización, es suficiente
con el mecanismo estándar de control de concurrencia. La confiabilidad es baja y la
disponibilidad mala, ya que una falla en el nodo central da como resultado la pérdida
de todo el sistema. La carga de trabajo puede ser distribuida pero los nodos remotos
necesitan acceder a la base de datos para ejecutar las aplicaciones, de modo que la
ubicación de los datos a que se hace referencia es baja. Esta alternativa no es un ver-
dadero sistema de base de datos distribuida.
2. Replicada. Con esta alternativa se mantiene en cada nodo una copia completa de la
base de datos. Las ventajas son máxima referencia de ubicación, confiabilidad, dispo-
nibilidad de los datos y distribución de la carga de procesamiento. Con esta alternati-
va los costos de almacenamiento son los más elevados, y los de comunicación para
hacer recuperaciones son bajos, pero los de las actualizaciones son altos, ya que cada
sitio debe recibir cada una de éstas. Si es muy raro hacer actualizaciones, esta alterna-
tiva es buena.
3. Particionada. Aquí únicamente hay una copia de cada uno de los ítems de datos, pero
están distribuidos en los nodos. Para permitir esto la base de datos se descompone en
fragmentos desarticulados. Si la base de datos es relacional, los fragmentos pueden
ser subconjuntos verticales en una tabla (formados por proyección) u horizontales
(formados por selección) de relaciones globales. En cualquier esquema de fragmentación horizontal, cada tupla de toda relación debe asignarse a uno o más fragmen-
tos de modo que al tomar la unión de éstos el resultado sea la relación original; para
el caso de la partición horizontal, se asigna una tupla exactamente a un fragmento.
En un esquema de fragmentación vertical, las proyecciones deben ser sin pérdida a
fin de que las relaciones originales se reconstruyan con la combinación de los frag-
mentos. El método más fácil de asegurar que las proyecciones son sin pérdida es, por
supuesto, incluir la clave en cada fragmento; sin embargo, esto viola la condición de


usaría ese identificador para hacer las combinaciones. Además de los fragmentos
verticales y horizontales hay fragmentos mixtos, obtenidos por medio de aplicacio-
nes sucesivas de las operaciones de seleccionar y proyectar. Esta alternativa requiere
un análisis cuidadoso para asegurar que los registros de los ítems de datos se asignen
al sitio apropiado. La figura 12.6 proporciona ejemplos de fragmentación. Si los ítems
de los datos se asignan al sitio en que se utilizan con más frecuencia, la ubicación de
referencia de los datos será alta con esta alternativa. Debido a que sólo se almacena
una copia de cada ítem, serán bajas la confiabilidad y disponibilidad de los datos para
un ítem específico. Sin embargo, la falla de un nodo da como resultado la pérdida
exclusivamente de los datos de ese nodo, por lo que la confiabilidad y disponibilidad
de todo el sistema son más altas que en el caso centralizado. Los costos de almacena-
miento y comunicaciones de un sistema bien diseñado deben ser bajos. La carga de
procesamiento también debe estar bien distribuida si los datos están distribuidos en
forma apropiada.
4. Híbrida. En esta alternativa, porciones distintas de la base de datos están distribuidas
de manera diferente. Por ejemplo, aquellos registros o tablas que son muy referencia-
dos localmente estarán fragmentados, mientras que aquellos que es común utilizar
en todos los nodos estarán duplicados, si las actualizaciones no son frecuentes. Aque-
llos que se necesitan en todos los nodos, pero se actualizan con tanta frecuencia que
la sincronización es un problema, deberían estar centralizados. Esta alternativa está
diseñada para optimizar la ubicación de los datos a fin de posibilitar todas las venta-
jas y ninguna de las desventajas de los otros métodos. Sin embargo, con este plan se
requiere un análisis y un procesamiento muy cuidadosos de los datos.
Como ejemplo, considere cómo se distribuiría el esquema de la base de datos University. Se
supuso que la universidad tiene un campus principal y cuatro sucursales (Norte, Sur, Este
y Oeste), y que los estudiantes tienen un campus sede en el que normalmente se inscriben y
toman clases. Sin embargo, se pueden inscribir en cualquier materia de cualquier campus.
Los profesores enseñan en un solo campus. Cada clase se ofrece en un solo campus.

...