viernes, 29 de mayo de 2015

Actividad #22

(imagenes, actuaciones, animaciones) explique:
*Transaciones ( desde el inicio hasta el fin)
*¿Qué pasa si ocurre algún problema sin que se termine o emita el commit?
*Interbloqueo
*Protocolos Undo/redo
*Protocolo 2pc
*candados de dos fases


Presentacion: 

martes, 19 de mayo de 2015

Actividad# 21

Los protocolos REDO/UNDO y el protocolo 2PC de confiabilidad distribuida
Protocolos REDO/UNDO.
El registro de la base de datos contiene información que es utilizada por el proceso de recuperación para restablecer la base de datos a un estado consistente. Esta información puede incluir entre otras cosas:

el identificador de la transacción,
el tipo de operación realizada,
los datos accesados por la transacción para realizar la acción,
el valor anterior del dato (imagen anterior), y
el valor nuevo del dato (imagen nueva).
Considere el escenario mostrado en la Figura de abajo. El DBMS inicia la ejecución en el tiempo 0 y en el tiempo t se presenta una falla del sistema. Durante el periodo [0, t] ocurren dos transacciones, T1 y T2. T1 ha sido concluida (ha realizado su commit) pero T2 no pudo ser concluida.
La propiedad de durabilidad requiere que los efectos de T1 sean reflejados en la base de datos estable. De forma similar, la propiedad de atomicidad requiere que la base de datos estable no contenga alguno de los efectos de T2.

Ejemplo de una falla del sistema.
A pesar que T1 haya sido terminada, puede suceder que el buffer correspondiente a la página de la base de datos modificada no haya sido escrito a la base de datos estable. Así, para este caso la recuperación tiene que volver a realizar los cambios hechos por T1. A esta operación se le conoce como REDO y se presenta en la Figura de abajo.
La operación de REDO utiliza la información del registro de la base de datos y realiza de nuevo las acciones que pudieron haber sido realizadas antes de la falla. La operación REDO genera una nueva imagen.

Operación REDO.
Por otra parte, es posible que el administrador del buffer haya realizado la escritura en la base de datos estable de algunas de las páginas de la base de datos volátil correspondientes a la transacción T2.
Así, la información de recuperación debe incluir datos suficientes para permitir deshacer ciertas actualizaciones en el nuevo estado de la base de datos y regrasarla al estado anterior. A esta operación se le conoce como UNDO y se muestra en la Figura de abajo. La operación UNDO restablece un dato a su imagen anterior utilizando la información del registro de la base de datos.

Operación UNDO.
De forma similar a la base de datos volátil, el registro de la base de datos se mantiene en memoria principal (llamada los buffers de registro) y se escribe al almacenamiento estable (llamadoregistro estable). Las páginas de registro se pueden escribir en el registro estable de dos formas: síncrona o asíncrona. En forma síncrona, también llamada un registro forzado, la adición de cada dato en el registro requiere que la página del registro correspondiente se mueva al almacenamiento estable. De manera asíncrona, las páginas del registro se mueven en forma periódica o cuando los buffers se llenan.

Puntos de verificación (checkpoints).
Cuando ocurre una falla en el sistema es necesario consultar la bitácora para determinar cuáles son las transacciones que necesitan volver a hacerse y cuando no necesitan hacerse. Estos puntos de verificación nos ayudan para reducir el gasto de tiempo consultando la bitácora. El punto de verificación es un registro que se genera en la bitácora para concluir en todo lo que se encuentra antes de ese punto está correcto y verificado.

Protocolo 2PC de confiabilidad distribuida.
El protocolo 2PC básico un agente (un agente-DTM en el modelo) con un rol especial. Este es llamado el coordinador; todos los demás agentes que deben hacer commit a la vez son llamados participantes.
El coordinador es responsable de tomar la decisión de llevar a cabo un commit o abort finalmente. Cada participante corresponde a una subtransacción la cual ha realizado alguna acción de escritura en su base de datos local.
Se puede asumir que cada participante está en un sitio diferente. Aun si un participante y el coordinador se encuentran en el mismo sitio, se sigue el protocolo como si estuvieran en distintos sitios.
La idea básica del 2PC es determinar una decisión única para todos los participantes con respecto a hacer commit o abort en todas las subtransacciones locales.
El protocolo consiste en dos fases:
  • La primera fase tiene como objetivo alcanzar una decisión común.
  • La meta de la segunda fase es implementar esta decisión.
El protocolo procede como sigue:
Fase uno:
  • El coordinador escribe “prepare” en la bitácora y envía un mensaje donde pregunta a todos los participantes si preparan el commit (PREPARE).
  • Cada participante escribe “ready” (y registra las subtransacciones) en su propia bitácora si está listo o “abort” de lo contrario.
  • Cada participante responde con un mensaje READY o ABORT al coordinador.
  • El coordinador decide el commit o abort en la transacción como un resultado de las respuestas que ha recibido de los participantes. Si todos respondieron READY, decide hacer un commit. Si alguno ha respondido ABORT o no ha respondido en un intervalo de tiempo determinado se aborta la transacción.
Fase dos:
  • El coordinador registra la decisión tomada en almacenamiento estable; es decir, escribe “global_commit” o “global_abort” en la bitácora.
  • El coordinador envía mensaje de COMMIT o ABORT según sea el caso para su ejecución.
  • Todos los participantes escriben un commit o abort en la bitácora basados en el mensaje recibido del coordinador (desde este momento el procedimiento de recuperación es capaz de asegurar que el efecto de la subtransacción no será perdido). Finalmente: Todos los participantes envían un mensaje de acuse de recibo (ACK) al coordinador, y ejecutan las acciones requeridas para terminar (commit) o abortar (abort) la subtransacción. Cuando el coordinador ha recibido un mensaje ACK de todos los participantes, escribe un nuevo tipo de registro en la bitácora, llamado un registro “completo”.

Actividad #20










Actividad #19

Disciplinas del Interbloqueo: prevención, detección, eliminación y recuperación.

Un interbloqueo se produce cuando dos o más tareas se bloquean entre sí permanentemente teniendo cada tarea un bloqueo en un recurso que las otras tareas intentan bloquear.
Un interbloqueo es una condición que se puede dar en cualquier sistema con varios subprocesos, no sólo en un sistema de administración de bases de datos relacionales, y puede producirse para recursos distintos a los bloqueos en objetos de base de datos
Por ejemplo:
  • La transacción A tiene un bloqueo compartido de la fila 1.
  • La transacción B tiene un bloqueo compartido de la fila 2.
  • La transacción A ahora solicita un bloqueo exclusivo de la fila 2 y se bloquea hasta que la transacción B finalice y libere el bloqueo compartido que tiene de la fila 2.
  • La transacción B ahora solicita un bloqueo exclusivo de la fila 1 y se bloquea hasta que la transacción A finalice y libere el bloqueo compartido que tiene de la fila 1.
Prevención del interbloqueo.
Objetivo: conseguir que sea imposible la aparición de situaciones de interbloqueo.
Impedir que se produzca una de las cuatro condiciones necesarias para producirlo: Exclusión mutua, Retención y espera, No expropiación, y Espera circular.
Condicionar un sistema para quitar cualquier posibilidad de ocurrencia de interbloqueo. 
Que no se cumpla una condición necesaria
“Exclusión mutua” y “sin expropiación” no se pueden relajar. Dependen de carácter intrínseco del recurso.
Las otras dos condiciones son más prometedoras.

Detención Interbloqueo
Existen diversos algoritmos para ello en la detención de ciclos en el grafo de esperas, entre ellos:
  • Algoritmo 1: Comprueba la existencia de ciclos mediante la eliminación de nodos terminales.
  • Algoritmo 2: Comprueba posibles ciclos desde la ultima transacción bloqueada y marcando los nodos por lo que pasa. Si pasa dos veces por el mismo nodo a detectado un ciclo.
Eliminar interbloqueos.
Para eliminar interbloqueos abortando un proceso, tenemos dos métodos; en ambos, el sistema recupera todos los recursos asignados a los procesos terminados.
Abortar todos los procesos interbloqueados. Esta es una de las soluciones más comunes, adoptada por Sistemas Operativos. Este método romperá definitivamente el ciclo de interbloqueo pero con un costo muy elevado, ya que estos procesos efectuaron cálculos durante mucho tiempo y habrá que descartar los resultados de estos cálculos parciales, para quizá tener que volver a calcularlos más tarde.
Abortar un proceso en cada ocasión hasta eliminar el ciclo de interbloqueo. El orden en que se seleccionan los procesos para abortarlos debe basarse en algún criterio de costo mínimo. Después de cada aborto, debe solicitarse de nuevo el algoritmo de detección, para ver si todavía existe el interbloqueo. Este método cae en mucho tiempo de procesamiento adicional.

Si éste se encuentra actualizando un archivo, cortarlo a la mitad de la operación puede ocasionar que el archivo quede en un mal estado.
Si se utiliza el método de terminación parcial, entonces, dado un conjunto de procesos bloqueados, debemos determinar cuál proceso o procesos debe terminarse para intentar romper el interbloqueo. Se trata sobre todo de una cuestión económica, debemos abortar los procesos que nos representen el menor costo posible.

Recuperación de Interbloqueo.
Limpiar un sistema de interbloqueos, una vez que fueron detectados. 
Cuando se ha detectado que existe un interbloqueo, podemos actuar de varias formas. Una posibilidad es informar al operador que ha ocurrido un interbloqueo y dejar que el operador se ocupe de él manualmente. La otra posibilidad es dejar que el sistema se recupere automáticamente del interbloqueo. Dentro de esta recuperación automática tenemos dos opciones para romper el interbloqueo: Una consiste en abortar uno o más procesos hasta romper la espera circular, y la segunda es apropiar algunos recursos de uno o más de los procesos bloqueados.

lunes, 18 de mayo de 2015

Actividad #18

Algoritmos de Control de Concurrencia
CONTROL DE CONCURRENCIA
El control de concurrencia trata con los problemas de aislamiento y consistencia del procesamiento de transacciones.El control de concurrencia distribuido de una DDBMS asegura que la consistencia de la base de datos se mantiene en un ambiente distribuido multiusuario. Si las transacciones son internamente consistentes, la manera más simple de lograr este objetivo es ejecutar cada transacción sola, una después de otra.

Algoritmos de control de concurrencia
El criterio de clasificación más común de los algoritmos de control deconcurrencia es el tipo de primitiva de sincronización. Esto resulta en dos clases:
  • Aquellos algoritmos que están basados en acceso mutuamente exclusivo adatos compartidos (candados o bloqueos).
  • Aquellos que intentar ordenar la ejecución de las transacciones de acuerdo a un conjunto de reglas (protocolos).
Basados en Bloqueos
En los algoritmos basados en candados, las transacciones indican sus intenciones solicitando candados al despachador (llamado el administrador de candados). Los candados son de lectura (rl), también llamados compartidos, o de escritura (wl), también llamados exclusivos. Como se aprecia en la tabla siguiente, los candados de lectura presentan conflictos con los candados de escritura, dado que las operaciones de lectura y escritura son incompatibles.


rl
wl
rl
Si
No
Wl
No
No


En sistemas basados en candados, el despachador es un administrador de candados (LM). El administrador de transacciones le pasa al administrador de candados la operación sobre la base de datos (lectura o escritura) e información asociada, como por ejemplo el elemento de datos que es accesado y el identificador de la transacción que está enviando la operación a la base de datos. El administrador de candados verifica si el elemento de datos que se quiere accesar ya ha sido bloqueado por un candado. Si candado solicitado es incompatible con el candado con que el dato está bloqueado, entonces, la transacción solicitante es retrasada. De otra forma, el candado se define sobre el dato en el modo deseado y la operación a la base de datos es transferida al procesador de datos. El administrador de transacciones es informado luego sobre el resultado de la operación. La terminación de una transacción libera todos los candados y se puede iniciar otra transacción que estaba esperando el acceso al mismo dato.

Basado en Estampas de Tiempo
Protocolo de marcas de tiempo (timestamp protocols) Su objetivo es ordenar las transacciones globalmente de manera que transacciones con una marca de tiempo menor, obtengan la prioridad en el caso de conflicto.
Estampas de tiempo: son valores derivados de un dominio totalmente ordenado.

Identificador de nodo: se agrega en la posición menos significativa, de manera que, éste sirve solo en el caso en que dos nodos diferentes le asignen el mismo contador local a dos transacciones diferentes.
El administrador de transacciones asigna también una estampa de tiempo a todas las operaciones solicitadas por una transacción.
Dado este orden, un conflicto entre operaciones se puede resolver de la siguiente forma:
for Ri(x) do begin if ts(Ti) < wts( x ) then reject Ri(x) else accept Ri(x) rts(x) ¬ ts(Ti) end for Wi(x) do begin if ts(Ti) < rts(x) and ts(Ti) < wts(x) then reject Wi(x) else accept Wi(x) wts(x) ¬ ts(Ti) end Ordenamiento básico (conservador) por estampas de tiempo: trata de ejecutar una operación tan pronto como se recibe una operación. Así, la ejecución de las operaciones es progresiva pero pueden presentar muchos reinicios de transacciones.
Ordenamiento conservador de estampas de tiempo: retrasa cada operación hasta que exista la seguridad de que no será reiniciada.
Ordenamiento por estampas de tiempo múltiples
Estrategias para prevenir la formación de interbloqueos: Al hacer una operación de escritura, no se modifican los valores actuales sino se crean nuevos valores.
Estrategias Para crear copias únicas de acuerdo al tipo de operación de que se trate:
1.Una operación de lectura Ri(x): se traduce a una operación de lectura de x de una sola versión encontrando la versión de x, digamos xv.
2. Una operación de escritura: Wi(x) se traduce en una sola version, Wi(xw), y es aceptada si el despachador no ha procesado cualquier lectura Rj(xr).
Pruebas de Validación Optimistas
Los Algoritmos de control de concurrencia discutidos antes son por naturaleza pesimistas.
Algoritmos optimistas: retrasan la fase de validación justo antes de la fase de escritura. De esta manera, una operación sometida a un despachador optimista nunca es retrasada.


martes, 12 de mayo de 2015

Actividad #17























Investigación:
Una transacción en un Sistema de Gestión de Bases de Datos (SGBD), es un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atómica.
Un SGBD se dice transaccional, si es capaz de mantener la integridad de los datos, haciendo que estas transacciones no puedan finalizar en un estado intermedio. Cuando por alguna causa el sistema debe cancelar la transacción, empieza a deshacer las órdenes ejecutadas hasta dejar la base de datos en su estado inicial (llamado punto de integridad), como si la orden de la transacción nunca se hubiese realizado.
Para esto, el lenguaje de consulta de datos SQL (Structured Query Language), provee los mecanismos para especificar que un conjunto de acciones deben constituir una transacción.

  • BEGIN TRAN: Especifica que va a empezar una transacción.
  • COMMIT TRAN: Le indica al motor que puede considerar la transacción completada con éxito.
  • ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que debe restablecer la base al punto de integridad.
En un sistema ideal, las transacciones deberían garantizar todas las propiedades ACID; en la práctica, a veces alguna de estas propiedades se simplifica o debilita con vistas a obtener un mejor rendimiento.
Un ejemplo de transacción
Un ejemplo habitual de transacción es el traspaso de una cantidad de dinero entre cuentas bancarias. Normalmente se realiza mediante dos operaciones distintas, una en la que se decrementa el saldo de la cuenta origen y otra en la que incrementamos el saldo de la cuenta destino. Para garantizar la atomicidad del sistema (es decir, para que no aparezca o desaparezca dinero), las dos operaciones deben ser atómicas, es decir, el sistema debe garantizar que, bajo cualquier circunstancia (incluso una caída del sistema), el resultado final es que, o bien se han realizado las dos operaciones, o bien no se ha realizado ninguna.

Mecanismos de control
Si no se lleva a cabo un adecuado control de concurrencia, se podrían llegar a presentar dos anomalías. En primer lugar, se pueden perder actualizaciones provocando que los efectos de algunas transacciones no se reflejen en la base de datos. En segundo lugar, pueden presentarse recuperaciones de información inconsistentes.
Los algoritmos para el control de concurrencia son útiles cuando se ejecutan varias  transacciones al mismo tiempo
      Los principales algoritmos son:
  • Los de cerradura o basados en candados
  • El de control optimista de la concurrencia
  • El de las marcas de tiempo  Estructura De Las Transacciones
Estructura de las transacciones
La estructura de una transacción usualmente viene dada según el modelo de la transacción, estas pueden ser planas (simples) o anidadas.
Transacciones planas: Consisten en una secuencia de operaciones primitivas encerradas entre las palabras clave BEGIN y END. Por ejemplo:
            BEGIN _TRANSACTION Reservación

             ....

            END.

Transacciones Anidadas: Consiste en tener transacciones que dependen de otras, estas transacciones están incluidas dentro de otras de un nivel superior y se las conoce como subtransacciones. La transacción de nivel superior puede producir hijos (subtransacciones) que hagan más fácil la programación del sistema y mejoras del desempeño.
En las transacciones anidadas las operaciones de una transacción pueden ser así mismo otras transacciones. Por ejemplo:
Monografias.com
Fase de preparación
Cuando el administrador de transacciones recibe una solicitud de confirmación, envía un comando de preparación a todos los administradores de recursos implicados en la transacción. Cada administrador de recursos hace lo necesario para que la transacción sea duradera y todos los búferes que contienen imágenes del registro de la transacción se pasan a disco. A medida que cada administrador de recursos completa la fase de preparación, notifica si la preparación ha tenido éxito o no al administrador de transacciones.

Fase de confirmación
Si el administrador de transacciones recibe la notificación de que todas las preparaciones son correctas por parte de todos los administradores de recursos, envía comandos de confirmación a cada administrador de recursos. A continuación, los administradores de recursos pueden completar la confirmación. Si todos los administradores de recursos indican que la confirmación ha sido correcta, el administrador de transacciones envía una notificación de éxito a la aplicación. Si algún administrador de recursos informó de un error al realizar la preparación, el administrador de transacciones envía un comando para revertir la transacción a cada administrador de recursos e indica a la aplicación que se ha producido un error de confirmación.

Requiere:
Existe un agente raíz que inicia toda la transacción, así que cuando el usuario requiere la ejecución de una aplicación distribuida el agente raíz es iniciado; el sitio del agente raíz es llamado el sitio origen de la transacción.
El agente raíz tiene la responsabilidad de asegurar BEGIN-TRANSACTION, COMMIT O ROLLBACK de toda la transacción distribuida.

Recuperación de transacciones distribuidas
  • Para realizar la recuperación de transacción distribuidas se asume que cada sitio tiene su propio manejador de transacción local (LTM).
  • Cada agente utiliza de manera local las primitivas asociadas a sus transacciones. Podemos llamar a los agentes subtransacciones, lo cual origina distinguir las primitivas BEGIN-TRANSACTION, COMMIT Y ROLLBACK asociado a la transacción distribuida de la primitivas locales utilizada por
  • cada agente en LTM; para poder distinguir una de las otras, a las ultimas les llamaremos:
  • LOCAL-BEGIN, LOCAL-COMMIT Y LOCALROLLBACK.
  • Para propósito del manejador de transacciones distribuidas (DTM), requieren que los LTM se conformen de la siguiente manera:
  1. Asegurar la atomicidad de su transacción.
  2. Grabar en bitácora por ordenes de la transacción distribuida.
Para asegurar que todas las acciones de una transacción distribuida son ejecutadas o no ejecutadas dos condiciones son necesarias:
  • En cada sitio todas las acciones son ejecutadas o ninguna es ejecutada.
  • Todos los sitios deberán tomar la misma decisión respecto al COMMIT o ROLLBACK de la transición global.

jueves, 30 de abril de 2015

Actividad #16

PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS
El procesamiento de consultas es de suma importancia en bases de datos centralizadas. Sin embargo, en BDD éste adquiere una relevancia mayor.

El objetivo es convertir transacciones de usuario en instrucciones para manipulación de datos. No obstante, el orden en que se realizan las transacciones afecta grandemente la velocidad de respuesta del sistema.

En BDD se tiene que considerar el procesamiento local de una consulta junto con el costo de transmisión de información al lugar en donde se solicitó la consulta.
El éxito creciente de la tecnología de bases de datos relacionales en el procesamiento de datos se debe, en parte, a la disponibilidad de lenguajes los cuales pueden mejorar significativamente el desarrollo de aplicaciones y la productividad del usuario final.

Estrategias de procesamiento de consultas distribuidas.
Consulta distribuida:

  • Las consultas distribuidas tienen acceso a datos de varios orígenes de datos heterogéneos.
  • Estos orígenes de datos pueden estar almacenado en el mismo equipo o en equipos diferentes.
  • El procesamiento de consultas tiene varias etapas a seguir para resolver una consulta en sql.
  • Las características del modelo relacional permiten que cada motor de base de datos elija su propia representación: álgebra relacional.
  • Existen varios medios para calcular la respuesta a una consulta.
  • 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.
Árboles de consultas:
Son estructuras de datos en forma de árbol, en donde, los datos al estar ordenados en la estructura, hace más ágiles las consultas.
Pasos:

  • Parsing y traducción de la consulta
  • Optimización
  • Generación de código
  • Ejecución de la consulta

Transformaciones equivalentes 
1.-el servidor recive una peticion de un nodo
2.-el servidor es atacado por el acceso concurrente a la base de datos cargada localmente
3.-el servidor muestra un resultado y le da un hilo a cada una de las maquinas nodo de la red local.

Una base de datos es accesada 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 de los datos, por lo tanto se respetan las formas normales de la base de datos ok.
Bueno para realizar una transformación en la consulta primero desfragmentamos siguiendo los estandares marcados por las reglas formales y posteriormente realizamos el envio y la maquina que recibe es la que muestra el resultado pertinente para el usuario, de esta se puede producir una copia que sera la equivalente a la original.

Join
La sentencia join en SQL permite combinar registros de dos o más tablas en una base de datos relacional. En el Lenguaje de Consultas Estructurado (SQL), hay tres tipo de JOIN: interno, externo, y cruzado.
En casos especiales una tabla puede unirse a sí misma, produciendo una auto-combinación,SELF-JOIN.
Matemáticamente, JOIN es composición relacional, la operación fundamental en el álgebra relacional, y generalizando es una función de composición.

Objetivos de la optimización de consultas
Como se estableció antes, el objetivo del procesamiento de consultas en un ambiente distribuido es transformar una consulta sobre una base de datos distribuida en una especificación de alto nivel a una estrategia de ejecución eficiente expresada en un lenguaje de bajo nivel sobre bases de datos locales.

Tipo de optimización
El problema de optimización de consultas es altamente demandante en tiempo de ejecución y, en el caso general, es un problema de la clase NP. Así existen dos estrategias para su solución: búsqueda exhaustiva oel uso de heurísticas. Los algoritmos de búsqueda exhaustiva tienen una complejidad combinatorial en el número de relaciones de la consulta.

Obtienen la transformación óptima, pero sólo se aplican a consultas simples dado su tiempo de ejecución. Por otro lado, los algoritmos heurísticos obtienen solo aproximaciones a la transformación óptima pero lo hacen en un tiempo de ejecución razonable. Las heurísticas más directas a aplicar son el agrupamiento de expresiones comunes para evitar el cálculo repetido de las mismas, aplicar primero las operaciones de selección y proyección, reemplazar una junta por una serie de semijuntas y reordenar operaciones para
reducir el tamaño de las relaciones intermedias.

Granularidad de la optimización
Existen dos alternativas: considerar sólo una consulta a la vez o tratar de
optimizar múltiples consultas. La primera alternativa no considera el uso
de resultados comunes intermedios. En el segundo caso puede obtener
transformaciones eficientes si las consultas son similares. Sin embargo,
el espacio de decisión es mucho más amplio lo que afecta grandemente
el tiempo de ejecución de la optimización.

Tiempo de optimización
Una consulta puede ser optimizada en tiempos diferentes con relación a tiempo de ejecución de la consulta. La optimización se puede realizar de manera estática antes de ejecutar la consulta o de forma dinámica durante la ejecución de la consulta. La optimización estática se hace en tiempo de compilación de la consulta. Así, el costo de la optimización puede ser amortizada sobre múltiples ejecuciones de la misma consulta.
Durante la optimización de consultas dinámica la elección de la mejor operación siguiente se puede hacer basado en el conocimiento exacto de los resultados de las operaciones anteriores. Por tanto, se requiere tener estadísticas acerca del tamaño de los resultados intermedios para aplicar esta estrategia. Un tercer enfoque, conocido como híbrido, utiliza básicamente un enfoque estático, pero se puede aplicar un enfoque dinámico cuando los
tamaños de las relaciones estimados están alejados de los tamaños actuales.

Estadísticas
La efectividad de una optimización recae en las estadísticas de la base de datos. La optimización dinámica de consultas requiere de estadísticas para elegir las operaciones que deben realizarse primero. La optimización estática es aún más demandante ya que el tamaño de las relaciones intermedias también debe ser estimado basándose en estadísticas.

Localización de Datos
La entrada a esta capa es una consulta algebraica definida sobre relaciones distribuidas. El objetivo de esta capa es localizar los datos de la consulta usando la información sobre la distribución de datos. Esta capa determina cuales fragmentos están involucrados en la consulta y transforma la consulta distribuida en una consulta sobre fragmentos.

Optimización Global de Consultas
Dada una consulta algebraica sobre fragmentos, el objetivo de esta capa es hallar una estrategia de ejecución para la consulta cercana a la óptima. La estrategia de ejecución para una consulta distribuida puede ser descrita con los operadores del álgebra relacional y con primitivas de comunicación para transferir datos entre nodos. Para encontrar una
buena transformación se consideran las características de los fragmentos, tales como, sus cardinalidades. Un aspecto importante de la optimización de consultas es el ordenamiento de juntas, dado que algunas permutaciones de juntas dentro de la consulta pueden conducir a un mejoramiento de varios órdenes de magnitud. La salida de la capa de optimización global es una consulta algebraica optimizada con operación de comunicación incluidas sobre los fragmentos.

Optimización Local de Consultas
El trabajo de la última capa se efectúa en todos los nodos con fragmentos involucrados en la consulta. Cada subconsulta que se ejecuta en un nodo, llamada consulta local, es optimizada usando el esquema local del nodo. Hasta este momento, se pueden eligen los algoritmos para realizar las operaciones relacionales. La optimización local utiliza los
algoritmos de sistemas centralizados.