Procesamiento de Consultas Locales

Para procesar una consulta local solo se hace referencia a tablas y bases de datos locales
(no a vistas ni a tablas remotas) , es decir que estén dentro de la misma instancia del
manejador de bases de datos, en una única maquina y que nos se tenga que conectar al
servidor a otras maquinas para poder efectuar 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

Ejemplo de procesar y optimizar consultas en SQL server

La entrada al optimizador consta de la consulta, el esquema de la base de datos

(definiciones de tabla e índice) y las estadísticas de base de datos. Una instrucción SELECT
define únicamente los siguientes elementos:
 El formato del conjunto de resultados. Las tablas que contienen los datos de origen.
Esto se especifica en la cláusula FROM.
 Cómo se relacionan lógicamente las tablas para la instrucción SELECT. Esto se
define en las especificaciones de combinación, que pueden aparecer en la cláusula
WHERE o en una cláusula ONE que sigue a FROM.
 Las condiciones que deben cumplir las filas de las tablas de origen para satisfacer
los requisitos de la instrucción SELECT. Estas condiciones se especifican en las
cláusulas WHERE y HAVING.

Un plan de ejecución de consulta es una definición de los siguientes elementos:

 La secuencia en la que se tiene acceso a las tablas de origen.

Normalmente, hay muchas secuencias diferentes en las que el servidor de la base de
datos puede tener acceso a las tablas base para generar el conjunto de resultados.
Por ejemplo, si la instrucción SELECT hace referencia a tres tablas, el servidor de la
base de datos podría tener acceso primero a TablaA, utilizar datos de TablaA para
extraer las filas que coincidan con las de TablaB y, finalmente, utilizar datos de
TablaB para extraer datos de TablaC. Las demás secuencias en las que el servidor

1
 de base de datos podría tener acceso a las tablas son:

TablaC, TablaB, TablaA

TablaB, TablaA, TablaC
TablaB, TablaC, TablaA
TablaC, TablaA, TablaB

 Los métodos que se utilizan para extraer los datos de cada tabla.
Si se necesitan todas las filas de una tabla, el servidor de la base de datos puede
omitir los índices y realizar un recorrido de la tabla.

El optimizador de consultas es uno de los componentes más importantes de un sistema de

base de datos SQL. El optimizador de consultas de SQL Server es un optimizador basado
en el costo. El optimizador de consultas debe analizar los planes posibles y elegir el de
menor costo estimado. Algunas instrucciones SELECT complejas tienen miles de planes de
ejecución posibles.
El optimizador de consultas de SQL Server elige, además del plan de ejecución con el costo
de recursos mínimo, el plan que devuelve resultados al usuario con un costo razonable de
recursos y con la mayor brevedad posible. El optimizador de SQL Server utilizará un plan
de ejecución en paralelo para devolver resultados si esto no afecta negativamente a la carga
del servidor.
Pueden estar seguros de que el optimizador de consultas creará un plan de ejecución eficaz
para el estado de la base de datos cada vez que se ejecuta la instrucción.

1. El optimizador de consultas analiza diferentes formas de acceso a las tablas de

origen. La versión final y optimizada del árbol de la consulta se denomina plan de
ejecución.
2. El motor relacional comienza a ejecutar el plan de ejecución. A medida que se
procesan los pasos que necesitan datos de las tablas base, el motor relacional solicita
al motor de almacenamiento que pase los datos de los conjuntos de filas solicitados
desde el motor relacional.

2
 Procesamiento de Consultas Distribuidas o Remotas

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. Así, el procesamiento de consultas presenta un problema de optimización en el
cual se determina el orden en el cual se hace la menor cantidad de operaciones. Este
problema de optimización es NP-difícil, por lo que en tiempos razonables solo se pueden
obtener soluciones aproximadas. 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 no procedurales
los cuales pueden mejorar significativamente el desarrollo de aplicaciones y la
productividad del usuario final. Ocultando los detalles de bajo nivel acerca de la
localización física de datos, los lenguajes de bases de datos relacionales permiten la
expresión de consultas complejas en una forma concisa y simple. Particularmente, para
construir la respuesta a una consulta, el usuario no tiene que especificar de manera precisa
el procedimiento que se debe seguir. Este procedimiento es llevado a cabo por un módulo
del DBMS llamado el procesador de consultas (query processor). Dado que la ejecución de
consultas es un aspecto crítica en el rendimiento de un DBMS, el procesamiento de
consultas ha recibido una gran atención tanto para bases de datos centralizadas como
distribuidas. Sin embargo, el procesamiento de consultas es mucho más difícil en ambientes
distribuidos que en centralizados, ya que existe un gran número de parámetros que afectan
el rendimiento de las consultas distribuidas. La función principal de un procesador de
consultas relacionales es transformar una consulta en una especificación de alto nivel,
típicamente en cálculo relacional, a una consulta equivalente en una especificación de bajo
nivel, típicamente alguna variación del álgebra relacional. La consulta de bajo nivel
implementa de hecho la estrategia de ejecución para la consulta. La transformación debe ser
correcta y eficiente. Es correcta si la consulta de bajo nivel tiene la misma semántica que la
consulta original, esto es, si ambas consultas producen el mismo resultado. El mapeo bien
definido que se conoce entre el cálculo relacional y el álgebra relacional hace que la
correctitud de la transformación sea fácil de verificar. Sin embargo, producir una estrategia
de ejecución eficiente es mucho más complicado. Una consulta en el cálculo relacional
3
puede tener muchas transformaciones correctas y equivalentes en el álgebra relacional. Ya
que cada estrategia de ejecución equivalente puede conducir a consumos de recursos de
cómputo muy diferentes, la dificultad más importante es seleccionar la estrategia de
ejecución que minimiza el consumo de recursos.