Departamento de Lenguajes y Sistemas Informticos

E.T.S. Ingeniera Informtica. Universidad de Sevilla

Avda Reina Mercedes s/n. 41012 Sevilla

Tlf/Fax 954 557 139 E-mail lsi@lsi.us.es Web www.lsi.us.es

E.T.S. Ingeniera
Informtica

Diseo de bases de datos

Mdulo-2 Tema 4

Proceso de consultas en bases de datos relacionales

Sevilla, mayo 2005

V 2005.01.1

Diseo de bases de datos

Proceso de consultas en bases de datos relacionales

Sevilla mayo 2005, V 2005.01.1

INTRODUCCIN .................................................................................... 3

PROCESO DE CONSULTAS RELACIONALES................................... 5

2.1

DESCOMPOSICIN DE CONSULTAS................................................. 5
3.1

3.1.1
3.1.2
3.1.3

3.2

3.2.1
3.2.2
3.2.3

3.3
3.4

3.4.1
3.4.2
3.4.3

FASES DEL PROCESO ............................................................................................... 5

NORMALIZACIN DE EXPRESIONES ....................................................................... 6

Forma prenex ..........................................................................................................................................................6

Forma conjuntiva....................................................................................................................................................6
Forma disyuntiva.....................................................................................................................................................6
ANLISIS SEMNTICO ............................................................................................. 6
Objetivos del anlisis semntico de expresiones ...............................................................................................6
Grafos de conexin de relaciones (GCR)...........................................................................................................7
Grafos de conexin de atributos (GCA, GNCA).............................................................................................8
SIMPLIFICACIN DE EXPRESIONES ......................................................................... 9
REESTRUCTURACIN ALGEBRAICA ......................................................................... 9
Complejidad de operaciones algebraicas...........................................................................................................10
Reglas de equivalencia en aplicacin de operadores algebraicos ..................................................................11
Mtodos de reestructuracin algebraica............................................................................................................12

OPTIMIZACIN DE CONSULTAS......................................................13
4.1
4.2

FASE DE OPTIMIZACIN ........................................................................................13

PLANES DINMICOS VS PLANES ESTTICOS............................................................13

4.2.1
4.2.2
4.2.3

Planes dinmicos...................................................................................................................................................13
Planes estticos......................................................................................................................................................13
Comparacin enfoque esttico/dinmico ........................................................................................................14
4.3
OPTIMIZACIN BASADA EN REGLAS (RULE BASED) ...............................................14
4.4
OPTIMIZACIN BASADA EN COSTES (COST BASED)................................................14
4.4.1
Problemtica de estimacin de costes ...............................................................................................................14
4.4.2
Estimacin de factores de selectividad..............................................................................................................15
4.4.3
Mantenimiento de estadsticas de la BD...........................................................................................................15

Pg. 2 de 15

Proceso de consultas en bases de datos relacionales

Diseo de bases de datos

Sevilla mayo 2005, V 2005.01.1

1 Introduccin
Obtener un resultado en un ambiente de gestin de archivos convencionales requiere la
elaboracin (diseo, edicin, compilacin, montaje, catalogacin y pruebas) de un programa
de aplicacin. Queda en mano del programador la responsabilidad de seleccin del mejor
mtodo posible para obtener el resultado esperado que satisfaga la exigencia o especificacin
del resultado.
El proceso de consultas en bases de datos relacionales deja al programador de aplicaciones en
un escenario distinto al anterior; la razn es el empleo de lenguajes de especificacin1: si se
utiliza un lenguaje de especificacin el programador no tiene que disear ni generar
un mtodo para ejecutar la especificacin o consulta requerida, es decir el
programador es introducido en un escenario no procedural, no est obligado a crear
mtodos ni procedimientos para obtener los datos, slo a especificar los datos que
requiere. Ejemplo: si en un programa de aplicacin se inserta una instruccin SQL del tipo:
SELECT NMatricula,Nombre,Asignatura,Nota FROM notas WHERE curso= 3.
Lo nico que est aportando el programador es la especificacin de los datos requeridos
(qu datos requiere?), pero a diferencia de la obtencin de datos en un ambiente de archivos
convencionales no especifica el algoritmo o mtodo de obtencin (cmo o por qu camino
obtenerlos?).
Se plantea pues: Quin o qu artefacto y cmo llega a fijarse el mtodo de obtencin de los
datos para una especificacin o consulta?; la respuesta es El procesador de consultas (PQ)
del gestor de la base de datos relacional; PQ asociar la mejor alternativa posible de
ejecucin a una especificacin: el plan de ejecucin. El plan de ejecucin ser un
programa en cdigo a bajo nivel (cdigo mquina o cdigo eficiente (al menos ms que el
cdigo fuente de la especificacin de la consulta) interpretable por el SGBD) generado por el
PQ para la especificacin o requerimiento de la consulta deseada.
Claro est que este nuevo escenario no slo goza de ventajas (simplificacin del paradigma de
programacin, pues no hay que pensar en mtodos) y acarrea una problemtica a resolver en
el seno del SGBD: Cmo seleccionar el mejor plan de ejecucin posible de entre todos los
que existen?
Ejemplo Sea la base de datos de una bodega:
Vinos(w#,vino,vendimia,graduacin),

Productores(p#,productor,regin),

Cosechas(p#,w#,cant)

y la consulta

SELECT W.vino FROM Vinos W, Cosechas H

q

WHERE W.w#=H.w# AND cant>100

Qu estrategias de ejecucin podran asociarse a esta consulta q?

Pensando en trminos de equivalencia algebraica (CROT a AR) cabran, p.ej., estas dos:

q(SQL) 1( AR ) = ( Cosechas ) 6 Vinos

vino cant >100

q(SQL) 2( AR) =
( Cosechas Vinos )

vino cant >100Co sec has.w #=Vinos.w #

1

Los lenguajes de especificacin son lenguajes de manipulacin de datos que permiten manipular conjuntos.

Pg. 3 de 15

Proceso de consultas en bases de datos relacionales

Diseo de bases de datos

Sevilla mayo 2005, V 2005.01.1

El tiempo de ejecucin de un proceso que manipula datos podra expresarse en trminos de

una funcin que implica, fundamentalmente, tiempo de ejecucin en CPU y tiempo asociado
a intercambiar entradas/salidas con el medio de almacenamiento; podra expresarse el tiempo
de ejecucin de un proceso P: t(P) como una funcin:
t ( P ) = ( N IOs, MemoriaCPU , TamaoBUFFERS )

El factor ms relevante o influyente en este tiempo de ejecucin es el nmero de

entradas/salidas requeridas (NIOs); es decir, la influencia de los otros factores es casi
despreciable cuando se trata de resolver consultas en un proceso P que maneja volmenes
significativos en una base de datos de gran tamao; dicho de otro modo:
t ( P ) = ( N IOs, MemoriaCPU , TamaoBUFFERS )
( N IOs )

El objetivo ser reducir el nmero de operaciones de entrada/salida requeridas para resolver

la consulta; cuanto menor sea el tamao de los resultados intermedios necesarios para
resolver una consulta mayor ser la probabilidad de que estos puedan alojarse en RAM y
menor ser tambin el nmero de IOs necesarios, luego el objetivo claro ser: disminuir el
tamao de los resultados intermedios hasta obtener el resultado final de la consulta.
Con esta directiva podramos comparar las dos alternativas analizadas para la consulta q;
podra expresarse:
t ( 1) = K ( N IOs ) = K tamao( 1) t ( 2) = K ( N IOs ) = K tamao( 2 )

luego si se reduce el tamao de los resultados intermedios, podr afirmarse que una
alternativa tendr un tiempo de ejecucin menor (en un escenario monotarea o concurrente).
Bajo una mtrica, para este ejemplo, de las relaciones:
Cardinalidad(Vinos)=500 tuplas, Card(Cosechas)=1200 tuplas, Card(cant>100(Cosechas))=100,
T:Tamao uniforme para las tuplas de Vinos, Productores y Cosechas.
el tamao mximo de los resultados intermedios sera2:
tamao( 1) = tamao(vinos ) + tamao(

( Cosechas ) = 500 + 100 = 600

cant >100

tamao( 2) = tamao(Cosechas Vinos)=5001200=6105

luego, evidentemente, tamao( )
tamao( ) y, por tanto, la primera alternativa es

sustancialmente mejor, en comportamiento de tiempo de ejecucin o througput3, que la
segunda.
1

Se ha abierto un escenario simplificado de la problemtica del proceso de consultas. En el

tema se plantear detalladamente el proceso de consultas en bases de datos relacionales y la
algortmica necesaria para obtener buenos planes de ejecucin.

El nmero de tuplas de cada relacin que es necesario mantener en memoria.

Se conoce con este trmino al flujo de transacciones por segundo que es capaz de resolver el gestor de
tareas del SGBD; se expresa en nmero de transacciones por segundo. Cuanto menos tiempo requiera de
ejecucin una tarea o transaccin, mejor ser el througput y por tanto mejor el comportamiento concurrente.

2
3

Pg. 4 de 15

Proceso de consultas en bases de datos relacionales

Diseo de bases de datos

Sevilla mayo 2005, V 2005.01.1

2 Proceso de consultas relacionales

2.1 Fases del proceso
El problema planteado estriba en conseguir un plan de ejecucin a partir de una consulta
expresada en un lenguaje de especificacin (p.ej. SQL).
Un plan de ejecucin es un programa de bajo nivel generado por el subsistema de proceso
de consultas (PQ) del SGBD. Si es un lenguaje de especificacin en el que puede
especificarse la consulta q; es decir, se parte de una expresin q(
) y se pretende obtener un
plan de ejecucin (q), el proceso es el siguiente:
q(
)

Descomposicin

Esquema
conceptual

i(q)
Optimizacin

Esquema interno
Estadsticas BD

(q)
Ejecucin

Argumentos

resultado

i(q) es un programa algebraico

seleccionado para la consulta q(
);
este programa algebraico no es
ejecutable, as que requiere la
asignacin de cdigo eficiente para
las distintas operaciones algebraicas.
La fase de optimizacin consistir en
asignar este cdigo eficiente a los
distintos operadores que forman
parte del programa algebraico
seleccionado en la fase anterior. Se
requiere informacin del esquema
interno y, segn el enfoque de
optimizacin, puede requerirse el
mantenimiento de estadsticas de
volumetra de la base de datos
(mtricas de los objetos catalogados).

Una vez generado el plan (q), este podr ejecutarse con el suministro de parmetros que
convenga (generacin dinmica de planes de ejecucin o enfoque de interpretacin) o bien
catalogarse y cargarse en memoria las veces que sea necesario (generacin esttica de planes
de ejecucin o enfoque de compilacin).
Se estudiarn las dos fases de descomposicin y optimizacin de consultas.

3 Descomposicin de consultas
El objetivo es generar un programa algebraico i(q) partiendo de la expresin de la consulta
en un lenguaje de especificacin contra un esquema externo: q(
).
Ya se ha visto en la introduccin que, en general, para una consulta q(
) puede existir un
espacio de soluciones (no necesariamente finito) o expresiones algebraicas Q q() ={
i(q)}.
Q q(), lo que no se
El primer problema, pues, es seleccionar un programa algebraico i(q)
presente como trivial ni inmediato.
El camino de esta seleccin o bsqueda no pasa por la bsqueda exhaustiva ni por mtodos
de exploracin de dicho espacio de soluciones sino ms bien por la aplicacin de heursticas
que permitan seleccionar una solucin admisible. Se contemplan una serie de etapas hasta
llegar a dicho programa algebraico con el menor coste posible, por lo que si se detectan
inconvenientes que no permitan continuar, el proceso abortar en la etapa correspondiente.
Pg. 5 de 15

Diseo de bases de datos

Proceso de consultas en bases de datos relacionales

Sevilla mayo 2005, V 2005.01.1

En estas heursticas se consideran una serie de etapas que se estudian a continuacin:

I)
II)
III)
IV)

Normalizacin de expresiones.
Anlisis semntico.
Simplificacin de expresiones.
Reestructuracin algebraica.

Las tres primeras etapas son problemas bien tratados en el seno de los procesadores de
lenguaje y se revisarn en este documento; la ltima, la reestructuracin algebraica, ser objeto
de estudio en detalle.

3.1 Normalizacin de expresiones

En esta etapa se verifica la sintaxis de la expresin q(
).
La normalizacin busca el ordenamiento de partculas en q(
). Son comnmente empleadas
formas prenex, conjuntivas o disyuntivas.
3.1.1 Forma prenex
La forma prenex busca el agrupamiento de cuantificadores y la reduccin de parntesis:
q ( ) x ( F ( y ( G ( x, y ) ) ) ) no est en forma prenex.
q ( ) xy ( F ( G ( x, y) ) ) est en forma prenex.
3.1.2 Forma conjuntiva
La forma conjuntiva permite generar subconsultas cuyos resultados se pueden fusionar
mediante joins y/o restricciones.
q ( ) ( P11 P12.. P1n ) ( P 21 P 22.. P 2 n ) ... ( P s1 Ps 2.. Psn ) equivale a resolver(generar resultados
intermedios para ellas) las subconsultas
q1( ) ( P11 P12.. P1n ) , q 2( ) ( P 21 P 22.. P 2 n ) ,..qs ( ) ( Ps1 Ps 2.. Psn ) y fusionar dichos resultados.
3.1.3 Forma disyuntiva
La forma disyuntiva permite generar subconsultas cuyos resultados se pueden fusionar
mediante uniones.
q ( ) ( P11 P12.. P1n ) ( P 21 P 22.. P 2 n ) ... ( P s1 Ps 2.. Psn ) equivale a resolver(generar resultados
intermedios para ellas) las subconsultas
q1( ) ( P11 P12.. P1n ) , q 2( ) ( P 21 P 22.. P 2 n ) ,..qs ( ) ( Ps1 Ps 2.. Psn ) y fusionar dichos resultados
mediante unin de los mismos.

3.2 Anlisis semntico

3.2.1 Objetivos del anlisis semntico de expresiones
Una consulta puede ser contrastada contra el esquema conceptual de la BD con objeto de
verificar la consistencia de las estructuras, contra las restricciones de la misma BD y contra s
misma con objeto de analizar su consistencia. Este anlisis es independiente de la extensin o
estado almacenado en la BD, por lo que, si puede derivarse que dicha consulta ser siempre
vaca entonces dicha consulta ser invalidada semnticamente. Se contemplan dos
herramientas bsicas para el anlisis de consistencia semntica de expresiones: Grafos de
conexin de relaciones (GCR) y grafos de conexin de atributos (GCA).

Pg. 6 de 15

Proceso de consultas en bases de datos relacionales

Diseo de bases de datos

Sevilla mayo 2005, V 2005.01.1

3.2.2 Grafos de conexin de relaciones (GCR)

Ms que invalidar la consulta, se trata de dar un aviso (nivel warning de mensaje, por debajo
del nivel de error; es decir la consulta puede ser ejecutada pero el resultado es dudoso; p.ej.
Warning NULLWHERE clause in SQL expression) en casos de olvidos de clusulas
de conectividad entre relaciones en una expresin lgica (p.ej. se olvida especificar un join o
una clusula de ligadura).
Un GCR es un grafo que dar un camino conexo (sin prdida de conexiones) desde las
relaciones hasta el resultado. En nodos se representan las relaciones y el resultado como
nodo terminal; los arcos entre nodos recogen las condiciones de join y los arcos recursivo
sobre un nodo las restricciones sobre cada relacin; el ltimo arco de conexin entre nodos es
la proyeccin que define el resultado.
Ejemplo 1: GCR conexo
SELECT W.vino FROM Vinos W,Cosechas H,Productores P

WHERE W.w#=H.w# AND H.p#=P.p# AND P.region='Andaluca' AND H.cant>100

H.cant>=100

H.p#=P.p#

El grafo es conexo en el
camino que asocia las
relaciones con el resultado.
P.region=Andaluca

W.w#=H.w#

W.vino

Resultado

Ejemplo 2: GCR inconexo

q [SELECT W.vino FROM Vinos W,Cosechas H WHERE H.cant>100]

H.cant>=100

W.vino

Resultado

El grafo no es conexo en el
camino que asocia las
relaciones con el resultado.
No existe condicin de join
entre Cosechas y Vinos, con
lo que se est generando una
operacin
algebraica
producto cartesiano entre
ambas.

Las consultas disyuntivas requieren la descomposicin en tantos GCR como disyunciones

(uniones) contemple la consulta. Cada subconsulta (conjuntiva) es analizada mediante un
GCR.

Pg. 7 de 15

Proceso de consultas en bases de datos relacionales

Diseo de bases de datos

Sevilla mayo 2005, V 2005.01.1

3.2.3 Grafos de conexin de atributos (GCA, GNCA)

Se pretende verificar la consistencia de condiciones (en restricciones y join).
Para la consulta
SELECT W.vino FROM Vinos W,Cosechas H,Productores P

WHERE
W.w#=H.w#
AND
H.p#=P.p#
AND
P.region='Andaluca'
AND
H.cant>=100

puede especificarse el GCA:

H.cant

>=

100

P.region

Andaluca

W.w#

H.w#

Con este tipo de grafo es difcil verificar la consistencia

semntica.
Es ms utilizado otro tipo de grafo denominado grafo
normalizado de conexin de atributos (GNCA, que se
deben a Ronsenkrantz) donde se representan
inecuaciones del tipo x y + c
x

H.p#

P.p#

modo siguiente:
-100

H.cant
-Andaluca
0
W.w#

Las restricciones entre los atributos y un nodo singular

con valor cero 0; as, se representan:
(0 H .cant 100) (100 H .cant )
(0 P.region + ' Andaluca ') ( P.region 0 + ' Andaluca ') P.region = ' Andaluca '

Andaluca
P.region

con un arco orientado entre los dos

nodos x e y. De este modo, pueden
diferenciarse restricciones de join del

H.w#

Los joins se representan con arcos entre atributos de

distintas relaciones
(W .w # H .w #+ 0) ( H .w # W .w #+ 0) W .w # = H .w #

( P. p # H . p #+ 0) ( H . p # P. p #+ 0) P. p # = H . p #
0
H.p#

P.p#

La utilidad de los GNCA es verificar que no existen

ciclos de suma negativa, pues equivale a expresar
0
inecuaciones contradictorias: Ejemplo: ( A 13) ( A 12)
representa condiciones contradictorias en una consulta conjuntiva; en este caso su GNCA
ser:
Ya que

-13

( A 13) (0 A 13)

Si se realiza la suma en este ciclo, se obtiene: -13+12=-1.

Con esta verificacin es sencillo detectar inconsistencias
conjuntivas de predicados.

12

Ejemplo: contraste semntico con restricciones de integridad.

Si se supone almacenada en la metabase de datos la restriccin de integridad
Is { ( cos echa = 1982 ) ( grado > 12)} , entonces la consulta:
SELECT w# FROM Cosechas

WHERE
cosecha=1982
AND
grado<=11;

Pg. 8 de 15

Proceso de consultas en bases de datos relacionales

Diseo de bases de datos

Sevilla mayo 2005, V 2005.01.1

es una consulta cuya condicin es contradictoria con Is, de modo que para cualquier estado
de la BD se generar un resultado vaco para q, luego no tiene sentido generar el plan de
ejecucin de dicha consulta. El plan debe ser rechazado por razn de contradiccin
semntica con la metabase de datos, ya que el grado de un vino de la cosecha de 1982 no
puede ser simultneamente mayor que doce y menor que doce. El GNCA debe resolverse
para la conjuncin de la condicin de la consulta y las condiciones de Is.
11
grado

-12

Existe un ciclo de suma negativa para las condiciones del

grado, luego saltara la excepcin de contradiccin en el
anlisis semntico.

1982
1982
Cosecha

3.3 Simplificacin de expresiones

Con la simplificacin de expresiones se pretende reducir la complejidad de la consulta que
escribe el usuario utilizando, fundamentalmente, equivalencias o leyes lgicas basadas en el
lgebra de Boole, Leyes de Morgan, tales como:

( a a .F.) ; a .F. a; a .T . .T .; a .F. .F.; a .T . a El objeto es eliminar redundancias en la

propia expresin o en contraste con reglas
( a b) ( a b) ; ( a b) ( a b) ;
de integridad de la metabase de datos.
( a b ) ( a b ); ( a b ) a b ;

( )

Ejemplo:
SELECT region FROM Productores
WHERE nombre='Osborne' OR NOT (region='Jerez')
q
AND (region='Jerez' OR region='La Mancha')

AND NOT (region='La Mancha');

Sustituyendo:
r (nombre='Osborne');
p (region='Jerez');
q (region='La Mancha')

La condicin (WHERE condicin) puede reexpresarse como:

condicin [ r p ( p q) q ] r ( ( p p ) ( p q )) q )

r ( (.F .) ( p q )) q ) r ( p q q ) r ( p .F .) r (.F .) r

Es decir, la consulta es equivalente a la expresin simplificada:

SELECT region FROM Productores
q

WHERE nombre='Osborne'

3.4 Reestructuracin algebraica

Una vez normalizada, contrastada semnticamente y simplificada la expresin de una consulta
q(
), el problema estriba en la seleccin de un programa algebraico dentro del espacio de
soluciones Q q() (AR)={
i(q)}.
La bsqueda exhaustiva en este espacio no es admisible por razones de coste. La solucin es
la implementacin de heursticas; en este caso, la heurstica es conocida como

Pg. 9 de 15

Diseo de bases de datos

Proceso de consultas en bases de datos relacionales

Sevilla mayo 2005, V 2005.01.1

reestructuracin algebraica, consistente en representar un programa algebraico y ordenar

(permutar) adecuadamente los operadores de dicho programa.
La heurstica tiene en cuenta las siguientes directivas:
a) Complejidad relativa de ejecucin de las operaciones algebraicas; lo que
redunda en el coste (tiempo) de ejecucin de dichas operaciones.
b) Reduccin del tamao de los resultados intermedios en cada etapa de
ejecucin del programa algebraico.

3.4.1 Complejidad de operaciones algebraicas

Se entiende por complejidad de una operacin el coste o tiempo que tardara en
ejecutarse dicha operacin en una mquina. A efectos comparativos entre operaciones tiene
ms sentido expresar el coste, pues el tiempo de ejecucin depender de muchos ms
factores: concurrencia, estados de las redes, situacin del sistema operativo, etc., etc.; sin
embargo por coste se entender la funcin que estima el consumo de recursos en funcin del
tamao de las relaciones, del tipo de operacin y del modelo interno (existencia de ndices,
rutinas de hashing, distribucin de fragmentos, encriptacin, etc.) de la base de datos. As,
dadas las relaciones R y R y siendo Card(R) y Card(R) los tamaos respectivos de dichas
relaciones expresados en nmero de tuplas (bajo supuesto de tamaos similares de las tuplas
de R y R), se pueden estimar los siguientes rdenes de magnitud4 de contribucin o medida
de la complejidad de cada operacin:
Operacin

Orden de magnitud de la complejidad

Card(R)

Card(R)

R R '

Card(R) Card(R)

R6 R '

Card(R) log(Card(R))

Card(R) log(Card(R))

Mientras que restricciones y proyecciones tienen costes que varan linealmente con el tamao
de las relaciones, el producto cartesiano tiene una funcin cuadrtica y la combinacin (join)
un coste semicuadrtico.
Las operaciones ms comunes en las consultas son los joins entre relaciones; por lo que se
prestar especial atencin a su orden de resolucin.

Factores de contribucin relevantes a la funcin del coste de ejecucin.

Pg. 10 de 15

Proceso de consultas en bases de datos relacionales

Diseo de bases de datos

Sevilla mayo 2005, V 2005.01.1

3.4.2 Reglas de equivalencia en aplicacin de operadores algebraicos

Se define un rbol algebraico como un tipo de rbol que representa el orden de aplicacin de
operadores en un programa algebraico, desde la base hasta la cima que expresa el resultado.
Ejemplo:
SELECT W.vino FROM Vinos W,Cosechas H,Productores P

WHERE
W.w#=H.w#
AND
H.p#=P.p#
AND
P.region='Andaluca'
AND
H.cant>=100

Un posible programa algebraico queda expresado por el rbol siguiente:

En este rbol se representan los joins entre relaciones, las restricciones sobre la regin y la
cantidad y la proyeccin de vino como resultado.
Se pueden establecer las siguientes
reglas de equivalencia que permitirn
reordenar expresiones algebraicas:

vino

Region=Andaluca
Y Cant>=100

p#

w#

Vinos

p#

w#

Cosechas

Productores

R1. Commutatividad de joins.

R6 S S 6 R
f

R2. Asociatividad de joins.

R6 S 6 T R6 S 6 T
f
g
f g

R3. Agrupacin de restricciones.

R R
Aq =b Ap = a Ap = a Aq =b
R4. Commutatividad restriccin/proyeccin

R R
X Ap = a X Ap = a X
Ap
R5. Commutatividad restriccin/join

R 6 S R 6 S
Ap = a R. Ai = S . Ai Ap = a R. Ai = S . Ai Ap = a

Pg. 11 de 15

Proceso de consultas en bases de datos relacionales

Diseo de bases de datos

Sevilla mayo 2005, V 2005.01.1

R6. Commutatividad restriccin/unin y diferencia

(R S ) R S
(R S) R S

Ai = a
Ai = a
Ai = a Ai = a
Ai = a Ai = a
R7. Commutatividad proyeccin/join

R 6 S R 6 S
R. X , S .Y R. Ai = S . Bj R. X , S .Y R. X
Ai R. Ai = S . Bj S .Y
Bj
R8. Commutatividad proyeccin/unin

(R S ) R S

X
X X

3.4.3 Mtodos de reestructuracin algebraica

La heurstica que se aplicar trata de minimizar el tamao de los resultados intermedios desde
la base del rbol algebraico. Adems se intenta resolver primero las operaciones menos
costosas (restricciones y proyecciones). Con esto, puede plantearse el siguiente mtodo:
I)
II)
III)
IV)
V)

Separar restricciones compuestas (predicados compuestos) en sucesivas

restricciones de un predicado (R3).
Desplazar restricciones hacia la base del rbol (R4,R5,R6) tanto como sea
posible.
Agrupar restricciones sobre la misma relacin (R3).
Desplazar proyecciones hacia la base del rbol (R7,R8) tanto como sea posible.
Agrupar proyecciones sobre las mismas relaciones, eliminando las
proyecciones redundantes.

Si se aplica esta heurstica al rbol anterior:

vino
p#

p#

p#,vino
w#
w#,vino

w#
p#,w#

Cant>=100

Vinos

Cosechas

p#

Regin=Andaluca

Productores

se obtiene este rbol equivalente que representa un programa algebraico ms eficiente que el
programa algebraico de partida.

Pg. 12 de 15

Diseo de bases de datos

Proceso de consultas en bases de datos relacionales

Sevilla mayo 2005, V 2005.01.1

4 Optimizacin de consultas
4.1 Fase de optimizacin
La fase de optimizacin de una consulta tiene por objeto generar el plan de ejecucin para la
consulta a partir del programa algebraico generado en la fase anterior de descomposicin.
Deben contemplarse diversos aspectos en esta fase de optimizacin:
a) El momento o modo de generacin del plan.
b) La estrategia de optimizacin de operadores algebraicos del programa.
En cuanto al momento de generacin, se contemplan:

Planes dinmicos

Planes estticos

La estrategia de optimizacin permite diferenciar los enfoques de:

Optimizacin por reglas

Optimizacin por costes

Las estrategias barajan mtodos alternativos para la descomposicin o programa algebraico.

Lo normal es asignar un mtodo para cada operador algebraico del programa (se asignan
mtodos operacin a operacin) en funcin de las condiciones del esquema interno de la base
de datos.

4.2 Planes dinmicos vs planes estticos

4.2.1 Planes dinmicos
La generacin de un plan dinmico corresponde a un enfoque de interpretacin de consultas.
El plan es generado en el momento en que se especifica la consulta. El procesador
consultas realiza las fases de descomposicin, optimizacin y ejecucin de dicha consulta
cascada; es decir, una a continuacin de otra. El plan de ejecucin se deja residente
memoria y slo es utilizado para esa sesin. Cada vez que se procesa el cdigo fuente
especificacin de la consulta se genera un nuevo plan de ejecucin.

de
en
en
de

Ejemplos de entornos o ambientes de generacin de planes dinmicos son las interfaces de

consulta por ejemplo (QBE: Query by Example) de los SGBDs o de las herramientas de
desarrollo utilizadas por profesionales (p.ej. SqlWorksheet de Oracle, generadores de
consultas de Visual Studio.Net, generador de vistas de Access, etc.).
4.2.2 Planes estticos
Los planes estticos pueden ser asimilados a un enfoque de compilacin y catalogacin del
plan de ejecucin.
El plan de ejecucin se genera en un momento distinto al de ejecucin del mismo; es decir, la
misin inicial del procesador de consultas es generar dicho plan y catalogarlo (en la misma
BD o en libreras al efecto). Con posterioridad, este plan ser cargado y ejecutado en
memoria.
Ejemplos de este enfoque son las compilaciones de programas que acceden a la BD y que
sern ejecutadas por mltiples usuarios en entornos concurrentes y sometidos a cargas
relevantes.
Pg. 13 de 15

Diseo de bases de datos

Proceso de consultas en bases de datos relacionales

Sevilla mayo 2005, V 2005.01.1

4.2.3 Comparacin enfoque esttico/dinmico

En la siguiente tabla se recogen las caractersticas ms relevantes de cada enfoque:
Enfoque de plan dinmico

Enfoque de plan esttico

Toda la informacin necesaria para El plan se genera con la informacin

optimizar la consulta est disponible cada disponible en el momento de su
vez que se genera el plan.
catalogacin. Si la informacin cambia con
el tiempo, el plan puede no ser ptimo en las
nuevas circunstancias.
Cada vez que se ejecuta la consulta se genera Slo se incurre en el coste o tiempo de
el plan, aadiendo el tiempo de generacin generacin del plan en el momento en que se
del plan al tiempo de ejecucin del mismo.
cataloga. Las transacciones no sufrirn este
tiempo de generacin, pues pueden cargar y
ejecutar el plan en memoria.

4.3 Optimizacin basada en reglas (Rule based)

La estrategia de optimizacin basada en reglas slo tiene en cuenta los caminos de acceso
existentes en el esquema interno de la BD (ndices primarios, secundarios, clusters, rutinas de
hashing, etc.), un conjunto predefinido de reglas (mtodos alternativos) y la manera de
especificar las condiciones en la consulta (constantes, variables, uso de funciones, etc.).
Es el enfoque clsico de optimizacin.

4.4 Optimizacin basada en costes (Cost based)

4.4.1 Problemtica de estimacin de costes
La optimizacin basada en costes maneja caminos de acceso, como en el caso de
optimizacin por reglas, e informacin volumtrica (tamaos) sobre las tablas manejadas en
cada consulta. El objetivo es maximizar el througput o minimizar el uso de recursos
necesarios para procesar la consulta (minimizar el tamao de resultados intermedios para
ejecutar cada operador algebraico).
Para cada resultado intermedio es necesario evaluar costes de los mtodos alternativos y el
tamao de dicho resultado intermedio. Para ello es fundamental mantener estadsticas en la
BD, siendo usual el mantenimiento de las siguientes mtricas de relaciones:
Card(R):

Nmero de tuplas de la relacin R.

Tam(R):

Tamao de una tupla de R.

Dom(A):

Cardinalidad del dominio del atributo A.

Ndist(A):

Nmero de valores distintos del atributo A.

Max(A):

Valor mximo del atributo A.

Min(A):

Valor mnimo del atributo A.

Para poder estimar los tamaos de los resultados intermedios se recurre al concepto de
factor de selectividad: s, entendido como la proporcin de tuplas que forman parte de un
resultado intermedio.
Lo normal es estimar s o factor de selectividad. Se plantea un enfoque de estimacin de este
factor para diversas operaciones.
Pg. 14 de 15

Proceso de consultas en bases de datos relacionales

Diseo de bases de datos

Sevilla mayo 2005, V 2005.01.1

4.4.2 Estimacin de factores de selectividad

Si se establecen las siguientes hiptesis simplificadoras:
a) Distribucin uniforme de los valores de un atributo A en su dominio.
b) Independencia de valores de atributos.
pueden estimarse los siguientes factores de selectividad para los operadores restriccin y el
join:

Card R = S Card ( R )
f f

Card R16 R 2 = S Card ( R1)Card ( R 2)

f

6f

Para la restriccin:

s
s
s

1
Ndist ( A)
Max(a ) a
s ( A>a ) = Max( A) Min(a)
a Min(a )
s ( A<a ) = Max( A) Min(a)

( A= a )

( A{ } )

= s ( A= a )Card ( )

( P Q )

= s ( P )s ( Q )

( PQ )

= s ( P ) + s (Q ) s ( P ) s (Q )

Para el join:
Puede considerarse una cota mxima

S = 1 puesto que en este caso se tendra el mismo coste

6 f

para el join que para un producto cartesiano.

Puede estimarse una cota para el caso de joins por claves ajenas:

Card ( R1) S Card ( R1)Card ( R 2) , luego 1 S Card ( R 2) S

6

1
Card ( R 2)

4.4.3 Mantenimiento de estadsticas de la BD

El mtodo de optimizacin basado en costes tiene como servidumbre ms importante el
mantenimiento de estadsticas de la base de datos. Esto aade una sobrecarga adicional al
sistema, pues en operaciones de actualizacin, adems de actualizar las zonas de datos e
ndices, ser necesario actualizar los catlogos del sistema con la informacin relativa a estas
mtricas.
Para reducir el impacto de esta sobrecarga es usual realizar en diferido la recopilacin de
informacin estadstica (p.ej. diariamente en horas donde hay menos actividad transaccional
sobre el sistema). En entornos SQL es el comando ANALYZE el que permite capturar esta
informacin.

Pg. 15 de 15