Explica las fases del procesamiento de consultas en el caso específico

de tu entrega de la Unidad 2, proponiendo dos consultas que requieran

información de varios fragmentos.

Las consultas distribuidas detienen acceso a datos de varios orígenes de datos

heterogéneos. Estos orígenes de datos pueden estar almacenados en el mismo equipo o
en equipos diferentes.

El procesamiento de consultas tiene varias etapas a seguir para resolver una consulta
SQL, las características del modelo relacional permiten que
cada motor de base de datos elija su propia representación que, comúnmente, resulta ser
el álgebra relacional. Existen varios medios para calcular la respuesta a una consulta. En
el caso del sistema centralizado, el criterio principal para determinar el costo de una
estrategia específica es el número de acceso al disco. En un sistema distribuido es
preciso tener en cuenta otros factores como son:

 El costo de transmisión de datos en la red.

 Repetición y fragmentación.
 Procesamiento de intersección simple.

ARBOLES DE CONSULTAS

Pasos:

 Parsing y traducción de la consulta

 Optimización
 Generación de código
 Ejecución de la consulta

1
TRANSFORMACIONES EQUIVALENTES

Cuando una base de datos se encuentra en múltiples servidores ydistribuye a un número
determinado de nodos tenemos:

 El servidor recibe una petición de un nodo.

 El servidor es atacado por el acceso concurrente a la base de datos cargada
localmente.
 El servidor muestra un resultado y le da un hilo a cada una de las maquinas nodo
de la red local.

Cuando una base de datos es acezada de esta manera la técnica que se utiliza es la de
fragmentación de datos que puede ser hibrida, horizontal y vertical.

En esta fragmentación lo que no se quiere es perder la consistencia delos datos, por lo

tanto, se respetan las formas normales de la base de datos.

Bueno para realizar una transformación en la consulta primero desfragmentamos siguiend
o los estándares marcados por las reglas formales y posteriormente realizamos él envió y
la máquina que recibe es la que muestra el resultado pertinente para el usuario, de esta
se puede producir una copia que será la equivalente a la original.

2
 Métodos de ejecución del join

Existen diferentes algoritmos que pueden obtener transformaciones eficientes en el

procesamiento de consultas.

 Join en bucles (ciclos) anidados

Si z = r s, r recibirá el nombre de relación externa y s se llamará relación interna, el

algoritmo de bucles anidados se puede presentar como sigue:

Para cada tupla tr en s si (tr,ts) si satisface la condición, entonces añadir tr * ts al

resultado Donde tr * ts será la concatenación de las tuplas tr y ts. Como para cada registro
de r se tiene que realizar una exploración completa de ts, y suponiendo el peor caso, en el
cual la memoria intermedia sólo puede concatenar un bloque de cada relación, entonces
el número de bloques a acceder es de sr bn b. Por otro lado, en el mejor de los casos si
se pueden contener ambas relaciones en la memoria intermedia entonces sólo se
necesitarían accesos a bloques.

 Join en bucles anidados por bloques

Una variante del algoritmo anterior puede lograr un ahorro en el acceso a bloques, si se
procesan las relaciones por bloques en vez de por tuplas. Para cada bloque Br dar a igual
para cada bloque Bs de s, para cada tupla tr en Br.

3
La diferencia principal en costos de este algoritmo con el anterior es que en el peor de los
casos cada bloque de la relación interna s se lee una vez por cada bloque de dr y no por
cada tupla de la relación externa.

 Join por mezcla

Este algoritmo se puede utilizar para calcular si un Join natural es óptimo en la búsqueda
o consulta. Para tales efectos, ambas relaciones deben estar ordenadas para los atributos
en común es decir se asocia un puntero a cada relación, al principio estos punteros
apuntan al inicio de cada una de las relaciones. Según avance el algoritmo el puntero se
mueve a través de la relación. De este modo se leen en memoria un grupo de tuplas de
una relación con el mismo valor en los atributos de las relaciones.

¿Qué se debe de tomar en cuenta en este algoritmo?

 Se tiene que ordenar primero, para después utilizar este método.

 Se tiene que considerar el costo de ordenarlo / las relaciones.
 Es más fácil utilizar pequeñas tuplas.

 Join por asociación.

Al igual que el algoritmo de join por mezcla, el algoritmo de join por asociación se puede
utilizar para un Join natural o un equi-join. Este algoritmo utiliza una función de asociación
h para dividir las tuplas de ambas relaciones. La idea fundamental es dividir las tuplas de
cada relación en conjuntos con el mismo valor de la función de asociación en los atributos
de join.

El número de bloques ocupados por las particiones podría ser ligeramente mayor que.

Debido a que los bloques no están completamente llenos. El acceso a estos bloques
puede añadir un gasto adicional de 2·max a lo sumo, ya que cada una de las particiones
podría tener un bloque parcialmente ocupado que se tiene que leer y escribir de nuevo.

 Join por asociación híbrida

El algoritmo de join por asociación híbrida realiza otra optimización; es útil cuando el
tamaño de la memoria es relativamente grande paro aún así, no cabe toda la relación s en
4
memoria. Dado que el algoritmo de join por asociación necesita max +1 bloques de
memoria para dividir ambas relaciones se puede utilizar el resto de la memoria (M – max
– 1 bloques)para guardar en la memoria intermedia la primera partición de la relación s,
esto es, así no es necesaria leerla ni escribirla nuevamente y se puede construir un índice
asociativo.

Cuando r se divide, las tuplas de tampoco se escriben en disco; en su lugar, según se van
generando, el sistema las utiliza para examinar el índice asociativo en y así generar las
tuplas de salida del join. Después de utilizarlas, estas tuplas se descartan, así que la
partición no ocupa espacio en memoria. De este modo se ahorra un acceso de lectura y
uno de escritura para cada bloque de y.

Join Complejos

Los join en bucle anidado y en bucle anidado por bloques son útiles siempre, sin
embargo, las otras técnicas de join son más eficientes que estas, pero sólo se pueden
utilizar en condiciones particulares tales como join natural o equi-join.

Se pueden implementar join con condiciones más complejas tales como conjunción o
disyunción Dado un join de las forma se pueden aplicar una o más de las técnicas de join
descritas anteriormente en cada condición individual, el resultado total consiste en las
tuplas del resultado intermedio que satisfacen el resto de las condiciones. Estas
condiciones se pueden ir comprobado según se generen las tuplas. La implementación de
la disyunción es homóloga a la conjunción.

Outer Join (Join externos)

Un outer join es una extensión del operador join que se utiliza a menudo para trabajar con
la información que falta.

5
Basándose en ese esquema de fragmentación, explica las fases del
procesamiento de consultas y cómo se haría la recuperación de la
información.

La mayoría de sistema de manejo de base de datos distribuida disponible actualmente

están basados en la arquitectura ANSI-SPARC la cual divide al sistema en tres niveles:
interno, conceptual y externo.

La vista conceptual, conocida también como la vista lógica global, representa la visión de
la comunidad de usuarios de los datos en la base de datos. No toma en cuenta la forma
en que las aplicaciones individuales observan los datos o como esto son almacenados. La
vista conceptual está basada en el esquema conceptual y su construcción se hace en la
primera fase del diseño de una base de datos.

Los usuarios incluyendo a los programadores de aplicaciones, observan los datos a través
de un esquema externo definido a nivel externo. La vista externa proporciona una venta a
la vista conceptual lo cual permite a los usuarios observar únicamente los datos de interés
y los aísla de otros datos en la base de datos. Puede existir cualquier número de vistas
externa y ellos pueden ser completamente independientes traslaparse entre sí.

El esquema conceptual se mapea a un esquema interno a nivel interno, el cual es el nivel

de descripción más bajo de los datos en una base de datos. Este proporciona una interfaz
al sistema de archivos del sistema operativo el cual es el responsable del acceso a la
base de datos. El nivel interno tiene que ver con la especificación de que elementos serán
indexados, que técnicas de organización utilizar y como los datos se agrupan en el disco
mediante “clúster” para mejorar su acceso.

6
En un sistema de bases de datos distribuidas, existen varios factores que deben tomar en
consideración que definen la arquitectura del sistema:

 Distribución: Los componentes del sistema están localizados en la misma

computadora o no.
 Heterogeneidad: Un sistema es heterogéneo cuando existen en él componentes
que se ejecutan en diversos sistemas operativos, de diferentes fuentes, etc.
Se puede presentar en varios niveles: hardware, sistema de comunicaciones o SMBD.
Para el caso de los SMBD heterogéneo esta se puede presentar debido al manejo de
datos, al leguaje de consulta o a los algoritmos para manejo de transacciones.
 Autonomía: Se puede presentar en diferentes niveles:
- Autonomía de diseño: Habilidad de un componente del sistema para decidir
cuestiones relacionadas a su propio diseño.
- Autonomía de comunicación: Habilidad de un componente del sistema para
decidir cómo y cuándo comunicarse con otros SGBD (Sistema Gestor de
Bases de Datos).
- Autonomía de ejecución: Habilidad de un componente del sistema para
ejecutar operaciones locales como quiera.
Desde el punto de vista funcional y de organización de datos, los sistemas de datos
distribuidos están distribuidos en dos clases separadas, basados en dos filosofías
totalmente diferentes y diseñados para satisfacer necesidades diferentes:

 Sistemas de bases de datos distribuidos homogéneos

 Sistemas de bases de datos distribuidos homogéneos

Un SMBDD homogéneo tiene múltiples colecciones de datos, Los sistemas homogéneos

se parecen a un sistema centralizado, pero en lugar de almacenar todos los datos en un
solo lugar, los datos se distribuyen en diferentes sitios comunicados por la red. No existen
usuarios locales y todos ellos acceden a la base de datos a través de una interfaz global.

7
El esquema global es la unión de todas las descripciones de datos locales y las vistas de
los usuarios se definen sobre el esquema global.

La clase de sistema heterogéneo es aquella caracterizada por manejar diferentes SMBD

en los nodos locales. Una subclase importante dentro de esta clase es la de los sistemas
de manejo multi-base de datos.

Un sistema multi-base de datos tiene múltiples SMBDs, que pueden ser de tipos
diferentes, y múltiples bases de datos existentes. La integración de todos ellos se realiza
mediante subsistemas de software.

En contraste con los sistemas homogéneos, existen usuarios locales y globales, los
usuarios locales acceden sus bases de datos locales sin verse afectados por la presencia
de Smulti-BD.

En ocasiones es importante caracterizar a los sistemas de base de datos distribuidas por

la forma en que se organizan sus componentes.

Consiste en dos partes fundamentales El procesador de usuario y el procesador de datos.

El procesador de usuario se encarga de procesar las solicitudes del usuario, por tanto,
utiliza el esquema externo del usuario y el esquema conceptual global. Así también utiliza
un diccionario de datos global. Este consiste en de cuatro partes: Un manejador de la
interfaz de usuario, un controlador semántico de datos, un optimizador global de consultas
y un supervisor de ejecución global.

El procesador de datos existe en cada nodo de la base de datos distribuida. Utiliza un

esquema local conceptual y un esquema local interno, el procesador de datos consiste en
tres partes: Un procesador de consultas locales, un manejador de recuperación de fallas
locales y un procesador de soporte para tiempo de ejecución.

Objetivos de los DDBMS

Sincronizar todos los datos periódicamente.

Procesar de forma independiente las solicitudes de los usuarios que requieran

tener acceso a los datos locales.

8
 Garantizar la actualización y eliminación de los datos, reflejándolos
automáticamente en los datos almacenados en el lugar de origen.

Proporcionar transparencia en la distribución de los datos durante la ejecución de

aplicaciones por parte del usuario.

Dar soporte en el control de concurrencia y recuperación durante la ejecución de

transacciones distribuidas.

Caso Practico
 Sincronizar todos los datos periódicamente.

 Procesar de forma independiente las solicitudes de los usuarios que requieran

tener acceso a los datos locales.

 Garantizar la actualización y eliminación de los datos, reflejándolos

automáticamente en los datos almacenados en el lugar de origen.

 Proporcionar transparencia en la distribución de los datos durante la ejecución de

aplicaciones por parte del usuario.

 Dar soporte en el control de concurrencia y recuperación durante la ejecución de

transacciones distribuidas.

Arquitectura de un DDBMS

9
El sistema de administración de base de datos distribuida (DDBMS), está formado por las
transacciones y los administradores de base de datos distribuidos de todas las
computadoras. Tal y como se muestra, tal DDBMS es un esquema genérico que implica
un conjunto de programas que operan en diversas computadoras.

Un administrador de transacciones distribuidas (DTM) es un programa que recibe so-

licitudes de procesamiento de los programas de consulta o de transacciones ya su vez las
traduce en acciones para los administradores de la base de datos. Una función importante
del DTM es coordinar y controlar dichas acciones.

Un administrador de la base de datos (DBM) es un programa que procesa cierta porción

de la base de datos distribuida, como es el hecho de recuperar y actualizar datos del
usuario y generales, de acuerdo con comandos de acción recibidos de los DTM.

Un nodo es una computadora que ejecuta un DTM, un DBM, o inclusive ambos. Un nodo
de transacción procesa un DTM, y un nodo de base de datos procesa un DBM y su base
10
de datos': En la, el Nodo W es un nodo de base de datos ejecutando DBMwY
almacenando BDw. El Nodo X es tanto un nodo de transacción como de base de datos
con DTMx' DBMx y BDx. De modo similar, el Nodo Y es tanto un nodo de transacción
como de base de datos, pero el Nodo Z es solamente un nodo de transacción.

Ejemplos de BDDMS

11
Caso Práctico

Considere un banco que tiene tres sucursales, en cada sucursal, un computador

controla las terminales de la misma y el sistema de cuentas.

Cada computador con su sistema de cuentas local en cada sucursal constituye un

"sitio" de la BDD; las computadoras están conectadas por la red.

12
Durante las operaciones normales, las aplicaciones en las terminales de la
sucursal necesitan solo acceder al BD de la misma. Como solo acceden la misma
red local, se les llaman aplicaciones locales.

Desde el punto de vista tecnológico, aparentemente lo importante es la existencia

de algunas transacciones que faciliten información en más de una sucursal. Estas
transacciones son llamadas transacciones globales o transacciones distribuidas.

La existencia de transacciones globales será considerada como una característica

que nos ayude a discriminar entre las BDD y un conjunto de base de datos locales.

Una típica transacción global sería una transferencia de fondos de una sucursal a
otra.

Esta aplicación requiere de actualizar datos en dos diferentes sucursales y

asegurarse de la real actualización en ambos sitios o en ninguno.

Asegurar el buen funcionamiento de aplicaciones globales es una tarea difícil, y

esto se debe a:

 El rendimiento que es una ventaja podría verse contradicho, por la

naturaleza de la carga de trabajo, pues un nodo puede verse abrumado,
por las estrategias utilizadas de concurrencia y de fallos, y el acceso local a
los datos. Se puede dar esta situación cuando la carga de trabajo requiere
un gran número de actualizaciones concurrentes sobre datos duplicados y
que deben estar distribuidos.

 La confiabilidad de los sistemas distribuidos, esta entre dicha, puesto que,

en este tipo de base de datos existen muchos factores a tomar en cuenta
como: La confiabilidad de los ordenadores, de la red, del sistema de
gestión de base de datos distribuida, de las transacciones y de las tazas de
error de la carga de trabajo.

 La mayor complejidad, juega en contra de este tipo de sistemas, pues

muchas veces se traduce en altos gastos de construcción y mantenimiento.
Esto se da por la gran cantidad de componentes Hardware, muchas cosas

13
 que aprender, y muchas aplicaciones susceptibles de fallar. Por ejemplo, el
control de concurrencia y recuperación de fallos, requiere de personal muy
especializado y por tal costoso.

 El procesamiento de base de datos distribuida es difícil de controlar, pues

estos procesos muchas veces se llevan a cabo en las áreas de trabajo de
los usuarios, e incluso el acceso físico no es controlado, lo que genera una
falta de seguridad de los datos.

Conclusiones

El guardado y recuperación de la información, en el cual los objetos generados mediante

la programación son guardados como objetos en la base de datos, permitiendo así, tener
una idea clara de que es lo que está sucediendo con la información y como se encuentra
clasificada en la base de datos. Por consiguiente, el guardar la información de esta
14
forma, nos permite tener una recuperación eficiente y rápida, sin reestructurar
información en el proceso. Este se cumplió gracias a que la base de datos en que se
desarrolló el almacenamiento permitió la generación de tipos de datos necesarios para
nuestro modelo. Reduciendo así las restricciones de tipos de datos como los que son
manejados en una base de datos relacional.

El impacto que presenta se debe a la estructura de la información. Permite una

transparencia amplia, y una reducción de tablas y tuplas en su base de datos. Entre ellas
encontramos el modelo orientado a objeto, el cual nos permite guardar la información de
un objeto creado en la base de datos, y no generar más tablas y tuplas de las
necesarias, como es el caso del modelo relacional. Ese último la información se
encuentra distribuida tanto en varias tablas como tuplas este formada. Con el modelo
orientado a objeto nos olvidamos de tener que reestructurar nuestra información
tomando de diferentes tablas la información.

En este modelo el objeto creado es almacenado como objeto en la base de datos y de la

misma forma es recuperado, lo que nos evita tener que realizar varios accesos a la base
de datos y a su vez nos permite ver en forma más clara el manejo de la información.
Hasta el momento la representación del modelo se manejó relacional, pero ahora con las
ventajas que nos ofrecen los lenguajes orientados a objeto y las bases de datos Objeto-
Relacional.

Realización de una extensión en el guardado/recuperación de la información

espacial, debido al problema encontrado con el manejo de listas en la base de
datos.
Realización de queries más elaborados, utilizando los tipos generados en este
modelo, como pueden ser la creación de un tipo llama Edificio en la cual podrá
contener atributos como: número de pisos con los que cuenta, material didáctico
o de cómputo con él cuente, número de salones, etc. Y por medio de queries
poder obtener la información requerida.
Acceso a diferentes bases de datos, mediante el modelo presentado, lo cual arrojaría
beneficios importantes ya que no se tendría restricción en el manejo de la información y

15
será más homogénea.

Bibliografía

Capítulo 2: Arquitectura de Base de datos distinuida. (s.f.). En A. Bolivia, Diseño

de Base de Datos Distribuida. Cochabamba – Bolivia: IC Editorial.

PARTE 7 ARQUITECTURA DE SISTEMAS- Cap 20 Arquitecturas de los sistemas

de bases de datos. (2006). En A. S.-H. KORTH-SUDARSHAN, Fundamentos de
Bases de Datos Quinta Edicion (págs. 663-666). Madrid: McGRAW-
HILL/INTERAMERICANA DE ESPAÑA, S.A.U.

16