Base de Datos Distribuidas (página 2)

Partes: 1, 2

4. Ambientes de
bases de datos distribuidas

Las BDD pueden ser:

Homogéneas: Todos los sitios tienen el mismo
SGBD, son conscientes de la existencia de los demás
sitios y cooperan en el procesamiento de las solicitudes. Los
sitios locales mantienen un mismo esquema y SGBD.
Heterogéneas: Cada sitio puede tener un SGBD
distinto así como esquemas diferentes. Puede que
algunos sitios no conozcan a otros. Puede que solo ofrezcan
facilidades limitadas para la cooperación en el
procesamiento de transacciones.

5. Problemas
fundamentales a resolver en las bases de datos
distribuidas

Diseño de bases de datos
distribuidas
Procesamiento y optimización de
consultas
Manejo de transacciones y control de
concurrencia

Etapas del
diseño

La etapa diferenciadora entre el diseño de una
base de datos centralizada y una base de datos distribuidas es el
"Diseño de la distribución" que consta de
dos actividades :

Fragmentación: Decidir
"como" dividimos la BD y en "que" partes .

Asignación: Decidir "donde"
ubicamos cada parte, así como si tendremos
replicación de datos.

Aspectos a considerar en el
diseño de una BD distribuida

Fragmentación: Una
relación puede ser dividida en un número de
sub-relaciones, denominadas fragmentos, los cuales son
entonces distribuidas
Asignación: cada fragmento debe
ser almacenado en un sitio en base a una distribución
optima.
Replicación: El SGBDD puede
mantener una copia de un fragmento en diferentes
sitios

6.
Fragmentación

El problema de fragmentación se
refiere al particionamiento de la información para
distribuir cada parte a los diferentes sitios de la
red

Objetivos de la
fragmentación

El objetivo de la fragmentación consiste
en dividir la relación en un conjunto de relaciones
más pequeñas tal que algunas de las aplicaciones de
usuario sólo hagan uso de un fragmento.

Sobre este marco, una fragmentación óptima
es aquella que produce un esquema de división que minimiza
el tiempo de ejecución de las aplicaciones que emplean
esos fragmentos.

La unidad de fragmentación ideal no es la tabla
sino una subdivisión de ésta.

Esto es debido a:

Las aplicaciones usan vistas definidas sobre varias
relaciones, es decir, se forman a partir de "trozos" de
varias tablas. Si conseguimos que cada una de las vistas
esté definida sobre subtablas locales (o en su defecto
lo mas "cerca" posible) a cada aplicación, es de
esperar un incremento en el rendimiento.
Si múltiples vistas de diferentes
aplicaciones están definidas sobre una tabla no
fragmentada, se tiene :

Si la tabla no está replicada entonces se
produce generación de tráfico por accesos
remotos.
Si la tabla está replicada en todos o algunos
de los sitios donde residen cada una de las aplicaciones
entonces la generación de trafico innecesario es
producida por la necesidad de la actualización de las
copias.

Ventajas

Al descomponer una relación en fragmentos
(unidades de distribución) :

Permitimos el procesamiento concurrente de
transacciones ya que no se bloquean tablas enteras sino
subtablas, por lo que dos consultas pueden acceder a la misma
tabla a fragmentos distintos.
Permitimos la paralelización de consultas al
poder descomponerlas en subconsultas, cada una de la cuales
trabajará con un fragmento diferente
incrementándose así el rendimiento.

Desventajas

Degradación del rendimiento en vistas
definidas sobre varios fragmentos ubicados en sitios
distintos (es necesario realizar operaciones con esos trozos
lo cual es costoso)
El control semántico se dificulta y el
rendimiento se degrada debido que la verificación de
restricciones de integridad (claves ajenas, uniques, etc)
implican buscar fragmentos en múltiples
localizaciones.

Por lo tanto división y ubicación de los
fragmentos no es trivial.

Tipos de fragmentación de
datos

Existen tres tipos de fragmentación:

Fragmentación horizontal
Fragmentación vertical
Fragmentación híbrida

Para que una la fragmentación de una
relación sea correcta debe satisfacer las siguientes
condiciones:

Condición de completitud.

La descomposición de una relación
R en los fragmentos R1, R2, …, Rn es completa
si y solamente si cada elemento de datos en R se
encuentra en alguno de los fragmentos Ri.

Condición de
Reconstrucción.

La descomposición de una relación
R en los fragmentos R1, R2, …, Rn es completa
si y solamente si cada elemento de datos en R se
encuentra en alguno de los fragmentos Ri.

Condición de Fragmentos Disjuntos.

Si la relación R se descompone en los
fragmentos R1, R2, …, Rn, y el dato di
está en Rj, entonces, no debe estar en
ningún otro fragmento Rk
(k?j).

Fragmentación
horizontal

La fragmentación horizontal de una
relación R produce una serie de fragmentos
R1, R2, …, Rr, cada uno de los cuales contiene un
subconjunto de las tuplas de R que cumplen determinadas
propiedades (predicados)

Fragmentación horizontal primaria y
derivada

La Fragmentación Horizontal Primaria
(FHP) de una relación se obtiene usando predicados
que están definidos en esa relación.

La Fragmentación Horizontal Derivada
(FHD) por otra parte, es el particionamiento de una
relación como resultado de predicados que se definen en
otra relación.

Fragmentación vertical

La fragmentación vertical de una relación
R produce una serie de fragmentos R1, R2, …,
Rr cada uno de los cuales contiene un subconjunto de los
atributos de R así como la clave primaria de
R.

Complejidad de la fragmentación
Vertical

La fragmentación vertical resulta más
complicada que la horizontal. En el caso vertical, si una
relación tiene m atributos clave no primarios, el
número de posibles fragmentos es igual a
B(m), es decir el m-ésimo número
de Bell [3]. Para valores grandes de m,
B(m)(mm; por ejemplo, para m
= 10, B(m) ( 115.000, para m = 15,
B(m) ( 109, para m = 30,
B(m) = 1023.

Estos valores indican que la obtención de una
solución óptima de la fragmentación vertical
resultará una tarea imposible, sino nos apoyamos en el uso
de heurísticas.

El problema de la asignación de
fragmentos

Asumamos que hay un conjunto de fragmentos F =
{ F1, F2, …, Fn } y una red que consiste de los sitios
S = { S1, S2, …, Sm } en los cuales un
conjunto Q = { q1, q2, …, qq } de consultas
se van a ejecutar.

El problema de asignación consiste en determinar
la distribución "óptima" de F en
S.

La optimalidad puede ser definida de acuerdo a dos
medidas:

Costo mínimo. Consiste del costo de
comunicación de datos, del costo de almacenamiento, y
del costo procesamiento (lecturas y actualizaciones a cada
fragmento). El problema de la asignación, es encontrar
un esquema de asignación o ubicación que
minimiza la función de costo
combinada.
Rendimiento: La estrategia de asignación
se diseña para mantener una métrica de
rendimiento. Las dos métricas más utilizadas
son el tiempo de respuesta y el "throughput" (número
de trabajos procesados por unidad de tiempo).

Asignación de
fragmentos

Asignación

Proceso mediante el cual se decide donde se ubicaran los
fragmentos de la etapa anterior y si se harán replicas de
los mismos.

Hacer replicas tiene sentido por :

Confiabilidad : Mayor seguridad ante perdida de
datos
Disponibilidad : Mayor tolerancia a fallos ante
caídas de los computadores
Aumento del paralelismo : Mayor eficiencia en las
consultas de lectura al posibilitarse su
descomposición en subconsultas y la
paralelización de éstas.

Pero presenta el inconvenientes de las consultas de
escritura, que conllevan las actualización de todas las
copias de la red.

En la práctica : Sopesar lecturas vs
escrituras

Mas lecturas que escrituras : Replicación es
buena idea
Mas escrituras que lecturas : No
replicamos.

Según el grado de replicación,
distinguimos entre :

BD fragmentada : Fragmentos disjuntos, cada uno en
un nodo (no hay replicas)
BD totalmente replicada : Se encuentra una copia de
toda la BD en cada nodo
BD parcialmente replicada : Mezcla las anteriores.
Algunos fragmentos están replicados.

Como se ve las técnicas de fragmentación y
replicación se combinan en la práctica.

Replicación de
fragmentos

El problema de la replicación de segmentos
asignación consiste en la determinación de que
fragmentos se replicarán en diferentes sitios a pesar de
los problemas que acarrea la
actualización.

7. Las 12 reglas
de un SGBDD

El principio fundamental de las Bases de Datos
Distribuidas o regla cero plantea que:

"Desde el punto de vista del usuario, un sistema
distribuido deberá ser idéntico a un sistema no
distribuido"

La regla cero conduce a las restantes 12
reglas.

Todas las reglas no son independientes entre sí,
ni tienen igual importancia pero son útiles para entender
la tecnología distribuida.

1. Autonomía Local: Los sitios de un
sistema distribuido deben ser autónomos.

La autonomía Local Implica:

Propietario local.
Administración local.
Responsabilidad local.
Integración local.
Representación local.

2. No dependencia de un sitio
central

No debe existir un único sitio, ya que
implicaría:

Cuello de botella.
Vulnerabilidad.

3. Operación continua

Adición de elementos
Actualización de versiones

4. Independencia de
Localización

El usuario desconoce dónde están
físicamente los datos.

5. Independencia de
fragmentación.

Deseable porque simplifica los programas de los usuarios
y sus actividades en la terminal

6. Independencia de réplica

La creación y destrucción de
réplicas debe hacerse transparente al usuario.

La réplica proporciona:

Ventajas:

Mayor Prestación: los datos son
locales.
Mayor disponibilidad: los datos son accesibles
siempre.

Desventajas

Hay que propagar las actualizaciones.

7. Procesamiento distribuido de
consultas

Los Sistemas relacionales brindan herramientas de
consulta muy eficientes.
Varias maneras de trasladar los datos

6. Manejo distribuido de
transacciones

Transacción distribuida: varios agentes de la
transacción en varios lugares.
Control de recuperación: una
transacción atómica. Todos los agentes avanzan
o retroceden juntos.
Control de concurrencia: Bloqueos mediante paso de
mensajes.

8. Independencia con respecto al
equipo

El SGBD se ejecutará igual sea cual sea el
equipo

10. Independencia con respecto al Sistema
Operativo

El SGBD debe ser multioperativo sin afectar al
usuario.

11. Independencia con respecto a la
Red

El SGBD debe soportar múltiples redes sin afectar
al usuario.

12. Independencia con respecto al
SGBD

Se pueden manejar distintas copias de SGBD si manejan la
misma norma estándar de SQL: Oracle, Informix, Multibase,
etc.

8.
Conclusiones

Las bases de datos distribuidas son cada vez más
usadas por las empresas y suponen una ventaja competitiva frente
a los sistemas centralizados, siempre y cuando la empresa en
cuestión tenga necesidad de usar una base de datos de este
tipo. Lo más habitual es disponer de varias sedes y tener
que manejar información común, para lo cual las
bases de datos distribuidas son especialmente
útiles.