“2021, Año de la Independencia”

Tecnológico de Estudios Superiores de Chimalhuacán

Ingeniería en Sistemas Computacionales

Resumen Capitulo 3: Diseño de Bases de Datos Distribuidas

Prof. Jiménez Alfaro Jorge Abraham

Base de Datos Distribuidas

Martell Jimenez Erik Daniel

8ISC21

Chimalhuacán. Edo Mex. Verano del 2021

 Contenido
Introducción ....................................................................................................................................... 3
Diseño de Bases de Datos Distribuidas........................................................................................ 4
Procesos de Diseños Top-Down................................................................................................ 5
Problemas de Diseño de Distribución. .......................................................................................... 6
Razones Para la Fragmentación. .............................................................................................. 6
Alternativas de Fragmentación................................................................................................... 6
Grado de Fragmentación. ........................................................................................................... 6
Reglas de Corrección de la Fragmentación ............................................................................. 7
Requisitos de Información........................................................................................................... 7
Fragmentación. ................................................................................................................................. 8
Fragmentación Horizontal. .......................................................................................................... 8
Fragmentación Horizontal Primaria ....................................................................................... 8
Fragmentación Horizontal Derivada ...................................................................................... 8
Fragmentación Vertical ................................................................................................................ 8
Asignación. ........................................................................................................................................ 9
Directorio de Datos........................................................................................................................... 9
Bibliografía ....................................................................................................................................... 10
 Introducción
En el presente desarrollo de este documento se redactará el resumen del capitulo
3 que tiene por nombre, Diseño de bases de datos distribuidas, del libro Principios
de los Sistemas de Bases de Datos Distribuidas, de los Autores M. Tamer Özsu
Patrick Valduriez, en el cual este capítulo trata de manera general sobre el diseño y
como se estructura una base de datos distribuida y algunos parámetros que se
deben de tener en cuenta, a lo largo de este documento se vera una parte de
manera mas general y destacando lo mas importante sobre el capitulo completo.
De ser necesario se tomarán fragmentos del libro citando a los autores originales.
 Diseño de Bases de Datos Distribuidas
El diseño de un sistema informático distribuido implica tomar decisiones sobre la
ubicación de datos y programas en los sitios de una red informática, así como
posiblemente diseñar la red en sí. En el caso de los DBMS distribuidos, la
distribución de aplicaciones implica dos cosas: la distribución del software DBMS
distribuido y la distribución de los programas de aplicación que se ejecutan en él.
Se ha sugerido que se puede investigar la organización de sistemas distribuidos a
lo largo de tres dimensiones ortogonales:
• Nivel de intercambio
• Comportamiento de los patrones de acceso
• Nivel de conocimiento sobre el comportamiento del patrón de acceso
En cuanto al nivel de compartir, hay tres posibilidades. Primero, no se comparte:
cada aplicación y sus datos se ejecutan en un sitio, y no hay comunicación con
ningún otro programa ni acceso a ningún archivo de datos en otros sitios. Esto
caracteriza los primeros días de la creación de redes y probablemente no sea muy
común en la actualidad. Entonces encontramos
El nivel de intercambio de datos; todos los programas se replican en todos los sitios,
pero los archivos de datos no son. En consecuencia, las solicitudes de los usuarios
se manejan en el sitio donde se originan y los archivos de datos necesarios se
mueven por la red.
Finalmente, en el intercambio de datos más programas, tanto los datos como los
programas pueden compartirse, lo que significa que un programa en un sitio
determinado puede solicitar un servicio de otro programa en un segundo sitio, que,
a su vez, puede tener que acceder a un archivo de datos. ubicado en un tercer sitio.
Levin y Morgan hacen una distinción entre el intercambio de datos y el intercambio
de datos más programas para ilustrar las diferencias entre sistemas informáticos
distribuidos homogéneos y heterogéneos. Indican, correctamente, que en un
entorno heterogéneo suele ser muy difícil, y en ocasiones imposible, ejecutar un
determinado programa en hardware diferente bajo un sistema operativo diferente.
Sin embargo, podría ser posible mover datos con relativa facilidad.
A lo largo de la segunda dimensión del comportamiento del patrón de acceso, es
posible identificar dos alternativas. Los patrones de acceso de las solicitudes de los
usuarios pueden ser estáticos, por lo que no cambia con el tiempo, ni es dinámico.
Obviamente, es considerablemente más fácil planificar y gestionar los entornos
estáticos de lo que sería el caso de distribuidos dinámicos sistemas.
Desafortunadamente, es difícil encontrar muchas aplicaciones distribuidas de la
vida real. eso se clasificaría como estático. La pregunta importante, entonces, no es
si un sistema es estático o dinámico, sino cuán dinámico es.
La tercera dimensión de la clasificación es el nivel de conocimiento sobre el acceso
patrón de comportamiento. Una posibilidad, por supuesto, es que los diseñadores
no tengan ninguna información sobre cómo los usuarios accederán a la base de
datos. Esta es una posibilidad teórica, pero es muy difícil, si no imposible, diseñar
un DBMS distribuida que pueda hacer frente con eficacia a esta situación. Las
alternativas más prácticas son que los diseñadores tienen información completa,
donde los patrones de acceso pueden razonablemente ser predicho y no se desvíe
significativamente de estas predicciones, o parciales informaciones, donde hay
desviaciones de las predicciones.
Procesos de Diseños Top-Down
El esquema conceptual global (GCS) y la información del patrón de acceso
recopilada como resultado del diseño de la vista son entradas para el paso del
diseño de la distribución. El objetivo en esta etapa, que es el tema central de este
capítulo, es diseñar la estructura conceptual local. esquemas (LCS) mediante la
distribución de las entidades en los sitios del sistema distribuido.
Eso es posible, por supuesto, tratar a cada entidad como una unidad de distribución.
Dado que usamos el modelo relacional como base de discusión en este libro, las
entidades corresponden a relaciones.
En lugar de distribuir relaciones, es bastante común dividirlas en subrelaciones,
llamados fragmentos, que luego se distribuyen. Por lo tanto, el diseño de distribución
la actividad consta de dos pasos: fragmentación y asignación. La razón de la
separación del diseño de la distribución en dos pasos es para lidiar mejor con la
complejidad del problema.
El último paso en el proceso de diseño es el diseño físico, que mapea el local
esquemas conceptuales a los dispositivos de almacenamiento físico disponibles en
el correspondiente sitio. Las entradas a este proceso son el esquema conceptual
local y el patrón de acceso. información sobre los fragmentos en ellos.
Es bien sabido que la actividad de diseño y desarrollo de cualquier tipo es un
proceso continuo, proceso que requiere un seguimiento constante y ajustes y
ajustes periódicos.
 Problemas de Diseño de Distribución.
Razones Para la Fragmentación.
Desde el punto de vista de la distribución de datos, realmente no hay razón para
fragmentar los datos. Después de todo, en los sistemas de archivos distribuidos, la
distribución se realiza sobre la base de archivos completos.
En primer lugar, las vistas de aplicaciones suelen ser subconjuntos de relaciones.
Por lo tanto, la localidad de los accesos de las aplicaciones no se define en
relaciones completas sino en sus subconjuntos. Por tanto, es natural considerar
subconjuntos de relaciones como unidades de distribución.
En segundo lugar, si las aplicaciones que tienen vistas definidas sobre una relación
dada residen en sitios diferentes, se pueden seguir dos alternativas, siendo la
relación completa la unidad de distribución. O la relación no se replica y se almacena
en un solo sitio, o se replica en todos o en algunos de los sitios donde residen las
aplicaciones.
El primero resulta en un volumen innecesariamente alto de accesos remotos a
datos. Este último, por otro lado, tiene una replicación innecesaria, lo que causa
problemas en la ejecución de actualizaciones y puede no ser deseable si el
almacenamiento es limitado.
Por último, la descomposición de una relación en fragmentos, cada uno de los
cuales se trata como una unidad, permite que se ejecuten simultáneamente varias
transacciones.
Alternativas de Fragmentación.
Las instancias de relación son esencialmente tablas, por lo que el problema es
encontrar formas alternativas de dividir una tabla en tablas más pequeñas.
Claramente hay dos alternativas para esto: dividirlo horizontalmente o dividirlo
verticalmente.
Grado de Fragmentación.
La medida en que la base de datos debe estar fragmentada es una decisión
importante que afecta el rendimiento de la ejecución de consultas. El grado de
fragmentación va desde un extremo, es decir, no fragmentarse en absoluto, al otro
extremo, a fragmentarse al nivel de tuplas individuales (en el caso de la
fragmentación horizontal) o al nivel de atributos individuales (en el caso de de
fragmentación vertical).
Lo que necesitamos, entonces, es encontrar un nivel adecuado de fragmentación
que sea un compromiso entre los dos extremos. Dicho nivel solo se puede definir
con respecto a las aplicaciones que se ejecutarán en la base de datos. En general,
las aplicaciones deben caracterizarse con respecto a una serie de parámetros.
Reglas de Corrección de la Fragmentación
Aplicaremos las siguientes tres reglas durante la fragmentación, las cuales, juntas,
aseguran que la base de datos no sufra cambios semánticos durante la
fragmentación.
• Integridad. Si una instancia de relación R se descompone en fragmentos FR
= {R1, R2, ..., Rn}, cada elemento de datos que se puede encontrar en R
también se puede encontrar en uno o más de Ri. Esta propiedad, que es
idéntica a la propiedad de descomposición sin pérdidas de la normalización,
también es importante en la fragmentación ya que asegura que los datos en
una relación global se mapeen en fragmentos sin ninguna pérdida. Tenga en
cuenta que, en el caso de la fragmentación horizontal, el "elemento"
normalmente se refiere a una tupla, mientras que, en el caso de la
fragmentación vertical, se refiere a un atributo.
• Reconstrucción. Si una relación R se descompone en fragmentos FR = {R1,
R2,. . . , Rn}, debería ser posible definir un operador relacional tal que R = Ri,
∀Ri ∈ FR. El operador será diferente para diferentes formas de
fragmentación; sin embargo, es importante que se pueda identificar. La
capacidad de reconstrucción de la relación a partir de sus fragmentos
asegura que se conserven las restricciones definidas en los datos en forma
de dependencias.
• Desarticulación. Si una relación R se descompone horizontalmente en
fragmentos FR = {R1, R2, ..., Rn} y el dato di está en Rj, no está en ningún
otro fragmento Rk (k = j). Este criterio asegura que los fragmentos
horizontales estén disjuntos. Si la relación R se descompone verticalmente,
sus atributos de clave primaria se repiten típicamente en todos sus
fragmentos (para la reconstrucción). Por lo tanto, en caso de particiones
verticales. (M. Tamer Özsu, 2011)
Requisitos de Información.
La información necesaria para el diseño de la distribución se puede dividir en cuatro
categorías: información de la base de datos, información de la aplicación,
información de la red de comunicación e información del sistema informático. Las
dos últimas categorías son de naturaleza completamente cuantitativa y se utilizan
en modelos de asignación más que en algoritmos de fragmentación. En cambio, los
requisitos de información detallada de los algoritmos de fragmentación y asignación
se analizan en sus respectivas secciones.
 Fragmentación.
Fragmentación Horizontal.
La fragmentación horizontal divide una relación a lo largo de sus tuplas. Por tanto,
cada fragmento tiene un subconjunto de las tuplas de la relación. Hay dos versiones
de partición horizontal: primaria y derivada. La fragmentación horizontal primaria de
una relación se realiza utilizando predicados que se definen en esa relación. La
fragmentación horizontal derivada, por otro lado, es la partición de una relación que
resulta de la definición de predicados en otra relación
Fragmentación Horizontal Primaria
Una fragmentación horizontal primaria se define mediante una operación de
selección en las relaciones de propietario de un esquema de base de datos. Por
tanto, dada la relación R, sus fragmentos horizontales están dados por Ri = σFi (R),
1 ≤ i ≤ w donde Fi es la fórmula de selección utilizada para obtener el fragmento Ri
(también llamado predicado de fragmentación). Tenga en cuenta que, si Fi está en
forma normal conjuntiva, es un predicado de mini término (mi). (M. Tamer Özsu,
2011)
Fragmentación Horizontal Derivada
Una fragmentación horizontal derivada se define en una relación de miembro de un
enlace de acuerdo con una operación de selección especificada en su propietario.
Es importante recordar dos puntos. Primero, el vínculo entre el propietario y las
relaciones de los miembros se define como una unión equitativa. En segundo lugar,
un equi-join se puede implementar mediante semiuniones. En consecuencia, dado
un enlace L donde propietario (L) = S y miembro (L) = R, los fragmentos horizontales
derivados de R se definen como Ri = R Si, 1 ≤ i ≤ w donde w es el número máximo
de fragmentos que se definirá en R, y Si = σFi (S), donde Fi es la fórmula según la
cual se define el fragmento horizontal primario Si. (M. Tamer Özsu, 2011)
Fragmentación Vertical
El objetivo de la fragmentación vertical es dividir una relación en un conjunto de
relaciones más pequeñas para que muchas de las aplicaciones de usuario se
ejecuten en un solo fragmento. En este contexto, una fragmentación "óptima" es
aquella que produce un esquema de fragmentación que minimiza el tiempo de
ejecución de las aplicaciones de usuario que se ejecutan en estos fragmentos.
Su motivación dentro del contexto centralizado es como herramienta de diseño, que
permite que las consultas del usuario manejen relaciones más pequeñas,
provocando así un menor número de accesos a la página. También se ha sugerido
que las subrelaciones más "activas" se pueden identificar y colocar en un
subsistema de memoria más rápido en aquellos casos en los que se admiten
jerarquías de memoria. La partición vertical es inherentemente más complicada que
la partición horizontal.
 Asignación.
La asignación de recursos a través de los nodos de una red informática es un
problema antiguo que se ha estudiado ampliamente. La mayor parte de este trabajo,
sin embargo, no aborda el problema del diseño de bases de datos distribuidas, sino
el de colocar archivos individuales en una red informática.
Es en la etapa de asignación que necesitamos los datos cuantitativos sobre la base
de datos, las aplicaciones que se ejecutan en ella, la red de comunicación, las
capacidades de procesamiento y las limitaciones de almacenamiento de cada sitio
en la red.

Directorio de Datos
La información del esquema se almacena en un diccionario / directorio de datos,
también llamado catálogo o simplemente directorio. Un directorio es una meta base
de datos que almacena una cantidad de información.
Dentro del contexto de la arquitectura centralizada ANSI / SPARC, el directorio es
el componente del sistema que permite el mapeo entre diferentes vistas
organizacionales de datos. Debe contener al menos definiciones de esquema y
mapeo. También puede contener estadísticas de uso, información de control de
acceso y similares. Se ve claramente que el diccionario / directorio de datos sirve
como el componente tanto en el procesamiento de diferentes esquemas como en el
suministro de asignaciones entre ellos.
 Bibliografía
M. Tamer Özsu, P. V. (2011). Principles of Distributed. New York: Springer.