Your SlideShare is downloading. ×
Capnulo
Procesamiento de consultas
Objetivos del capítulo:
En este capítulo aprenderá:
• Los objetivos del procesamiento d...
576 Sistemas de bases de datos
mice el uso de recursos. Puesto que el acceso a disco resulta lento comparado con el acceso...
Capítulo 21 Procesamiento de consultas 577
ro de operaciones paralelas (Valduriez y Gardarin, 1984). Puesto que el problem...
578 Sistemas de bases de datos
una sucursal). En consecuencia, la operación de selección requiere 1000 accesos a disco par...
Capítulo 21 Procesamiento de consultas 579
Consulta en un lenguaje de alto nivel
(generalmente SQL)
Descomposición
de la c...
580 Sistemas de bases de datos
Completada esta etapa, la consulta de alto nivel habrá sido trasformada en algún tipo de re...
Capítulo 21 Procesamiento de consultas 581
position = 'Assistant') v salary > 20000) podría simplificarse a (salary > 2000...
582 Sistemas de bases de datos
Ahora considere la consulta:
SELECT p.propertyNo,p.street
FROM Clientc, Viewingv, PropertyF...
Capítulo 21 Procesamiento de consultas 583
Como hemos explicado en la Sección 6.4.3, durante la resolución de la vista est...
584 Sistemas de bases de datos
Esta transformación se denomina en ocasiones cascada de selecciones. Por ejemplo:
U branchN...
Capítulo 21 Procesamientode consultas 585
(T position='Manager' Á city= 'London,(Staff C><JStaff.branchNo=Branch.branchNo ...
586 Sistemas de bases de datos
Observe que en este ejemplo sería incorrecto simplemente 'mover los paréntesis' ya que esto...
Capítulo 21 Procesamiento de consultas 587
rr p.propertyNo, p.street
x P
TI p.propertyNo, p.street
1
i
pv
e
I
°c.pretType=...
588 Sistemas de bases de datos
Una optimización adicional en este ejemplo concreto consiste en observar que la operación d...
Capítulo 21 Procesamiento de consultas 589
En la Sección 23.7 mostraremos cómo pueden aplicarse estas reglas heurísticas a...
590 Sistemas de bases de datos
[nTuples(R) * ((maxA(R) - c) /(maxA (R) - minA(R))] para la desigualdad (A > c)
[nTuples(R)...
Estrategias
Capítulo 21 Procesamiento de consultas 591
Tabla 21.1. Resumen del coste estimado de E/S para las estrategias
...
592 Sistemas de bases de datos
//
// Búsqueda lineal
// El predicado predicate es la clave de búsqueda.
// El archivo no e...
Capítulo 21 Procesamiento de consultas 593
//
// Búsqueda binaria
// El predicado predicate es la clave de búsqueda.
// El...
~'
594 Sistemas de bases de datos
//
// Búsqueda B+-tree
// La estructura B+-tree está representada como una lista enlazad...
Capítulo 21 Procesamiento de consultas 595
dición. Después podemos comprobar si cada tupla extraída satisface las condicio...
596 Sistemas de bases de datos
S3: abranchNo='B003,(Staff)
S4: asalary>2oooo(Staff)
S5: (J"position='Manager' A branchNo='...
Capítulo 21 Procesamiento de consultas 597
Tabla 21.2. Resumen de las estimaciones de coste de E/R de las distintas estrat...
598 Sistemas de bases de datos
o
nTuples(T) = SCB(S)*nTuples(R)
Para obtener la primera estimación, usamos el hecho de que...
Capítulo 21 Procesamiento de consultas 599
Si los atributos de combinación en una equicombinación (o combinación natural) ...
600 Sistemas de bases de datos
nBlocks(R) + nBlocks(S)
Si es necesario ordenar una relación, por ejemplo R, tendríamos que...
Capítulo 21 Procesamiento de consultas 601
si la relación R se particiona en R¡, R2' ... , RM Y la relación S en SI' S2, ....
602 Sistemas de bases de datos
También presupone que el índice hash se pueda almacenar en memoria. Si no es así, el partic...
Capítulo 21 Procesamiento de consultas 603
En ambos casos, sabemos que la cardinalidad de la relación resultante no puede ...
604 Sistemas de bases de datos
11
11 Proyección mediante ordenación
11 Suponemos que se está proyectando la relación R sob...
Capítulo 21 Procesamiento de consultas 605
Si el número de bloques requeridos para la tabla temporal resultante de la proy...
606 Sistemas de bases de datos
hash de forma similar para eliminar los duplicados. Podemos estimar la cardinalidad de la r...
Capítulo 21 Procesamiento de consultas 607
Por regla general, una cadena de procesamiento (pipelining) se implementa como ...
(4) IndexScan(R, A):
(3) IndexScan(R, P):
(1) TableScan(R):
(2) SortScan(R, L):
608 Sistemas de bases de datos
las relacio...
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)
Upcoming SlideShare
Loading in...5
×

Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)

1,465

Published on

Cap 1-20 en Un regalo http://www.slideshare.net/DebateInformaticaMaterias/cap-1-20completo-y-corregido-32864494

Published in: Education
2 Comments
1 Like
Statistics
Notes
No Downloads
Views
Total Views
1,465
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
219
Comments
2
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)"

  1. 1. Capnulo Procesamiento de consultas Objetivos del capítulo: En este capítulo aprenderá: • Los objetivos del procesamiento de consultas y optimización. • Las diferencias entre la optimización de consultas estática y dinámica. • Cómo se descompone y se analiza semánticamente una consulta. • Cómo crear un árbol de álgebra relacional para representar una consulta. • Las reglas de equivalencia para las operaciones de álgebra relacional. • Cómo aplicar reglas de transformación heurística para mejorar la eficiencia de una consulta. • Los tipos de estadísticas de bases de datos requeridas para estimar el coste de las operaciones. • Las diferentes estrategias para implementar las operaciones de álgebra relacional. • Cómo evaluar el coste y el tamaño de las operaciones de álgebra relaciona!. • Cómo puede utilizarse el pipelining para mejorar la eficiencia de las consultas. • La diferencia entre materialización y pipelining. • Las ventajas de los árboles de profundidad izquierda. • Las técnicas para determinar una estrategia de ejecución óptima. • Cómo gestiona Oracle la optimización de consultas. Cuando se lanzó por primera vez comercialmente el modelo relacional, una de las principales críticas que se hacían era el pobre rendimiento de las consultas. Desde entonces, se ha dedicado una gran cantidad de esfuer- zos de investigación para desarrollar algoritmos altamente eficientes para el procesamiento de consultas. Hay muchas formas en las que se puede ejecutar una consulta compleja y uno de los objetivos de procesamiento de consultas es determinar cuál de esas formas es la menos costosa. En los sistemas de bases de datos en red y jerárquicos de primera generación, el lenguaje de consulta pro- cedimental de bajo nivel está generalmente incrustado en un lenguaje de programación de alto nivel tal como COBOL y es responsabilidad del programador seleccionar la estrategia de ejecución más apropiada. Por con- traste, con lenguajes declarativos del tipo de SQL, el usuario especifica qué datos se requieren en lugar de cómo hay que extraerlos. Esto libera al usuario de la responsabilidad de determinar, e incluso de conocer, qué es una buena estrategia de ejecución y hace que el lenguaje sea más universalmente utilizable. Adicionalmente, asignar al SGBD la responsabilidad de seleccionar la mejor estrategia evita que los usuarios seleccionen estrategias que ya se sabe que son ineficientes y proporciona al SGBD un mayor control sobre las prestaciones del sistema. Existen dos técnicas principales de optimización de consultas, aunque en la práctica se suelen combinar ambas estrategias. La primera técnica utiliza reglas heurísticas que ordenan las operaciones de una consulta. La otra técnica compara diferentes estrategias basándose en su coste relativo y selecciona aquella que mini-
  2. 2. 576 Sistemas de bases de datos mice el uso de recursos. Puesto que el acceso a disco resulta lento comparado con el acceso a memoria, los accesos a disco tienden a representar el coste más importante del procesamiento de consultas en un SGBD centralizado, y es en este aspecto en el que nos vamos a concentrar exclusivamente en este capítulo a la hora de proporcionar estimaciones de coste. Estructura del capítulo En la Sección 21.1 se proporciona una panorámica del procesamiento de consultas y se examinan las fases principales de esta actividad. En la Sección 21.2 se examina la primera fase del procesamiento de consultas, que es la descomposición de la consulta, que transforma una consulta de alto nivel en una consulta de álgebra relacional y comprueba que ésta sea sintáctica y semánticamente correcta. En la Sección 21.3 exami- namos la técnica heurística de optimización de consultas, que ordena las operaciones de una consulta utili- zando reglas de transformación que se sabe generan buenas estrategias de ejecución. En la Sección 21.4 ana- lizaremos la técnica de estimación de costes para la optimización de consultas, que se basa en comparar diferentes estrategias basándose en sus costes relativos y seleccionar aquella que minimice el uso de recursos. En la Sección 21.5 hablaremos del pipelining, que es una técnica que puede utilizarse para mejorar todavía más el procesamiento de las consultas. El pipelining (o procesamiento en cadena) permite que se realicen diversas operaciones de forma paralela, en lugar de requerir que cada operación se complete antes de que la siguiente pueda comenzar. También explicaremos cómo puede un procesador de consultas típico seleccionar una estrategia de ejecución óptima. En la sección final, examinaremos brevemente cómo lleva a cabo Oracle la optimización de las consultas. En este capítulo nos vamos a concentrar en las técnicas de procesamiento y optimización de consultas en un SGBD relacional centralizado, ya que éste es el área que ha atraído la mayor parte de los esfuerzos de investigación y es el modelo en el que nos centramos a lo largo de todo el libro. Sin embargo, algunas de las técnicas tienen aplicación general en otros tipos de sistemas que dispongan de una interfaz de alto nivel. Posteriormente, en la Sección 23.7, examinaremos brevemente el procesamiento de consultas en un SGBD distribuido. En la Sección 28.5 veremos que algunas de las técnicas examinadas en este capítulo pueden requerir un análisis adicional para un SGBD objeto-relacional, que soporta consultas que contienen tipos defi- nidos por el usuario y funciones definidas por el usuario. El lector debe estar familiarizado con los conceptos tratados en la Sección 4.1 sobre el álgebra relacional y con los del Apéndice e referidos a los tipos de organización de archivos. Los ejemplos de este capítulo están extraídos del caso de estudio de DreamHome descrito en la Sección 10.4 Y en el Apéndice A. 21.1 Panorámica del procesamiento de consultas Procesamiento de consultas Las actividades implicadas en el análisis sintáctico, la validación, la optimización y la ejecución de una consulta. Los objetivos del procesamiento de consultas son transformar una consulta escrita en un lenguaje de alto nivel, normalmente SQL, en una estrategia de ejecución correcta y eficiente expresada en un lenguaje de bajo nivel (implementación de álgebra relacional) y ejecutar la estrategia para extraer los datos requeridos. Optimización de consultas La actividad de seleccionar una estrategia de ejecución eficiente para el procesa- miento de una consulta. Un aspecto importante del procesamiento de consultas es la optimización de la consulta. Puesto que hay otras transformaciones equivalentes de la misma consulta de alto nivel, el objetivo de la optimización de consultas consiste en elegir aquella que minimice el uso de recursos. Generalmente, lo que intentaremos será reducir el tiempo total de ejecución de la consulta, que es la suma de los tiempos de ejecución de todas las operaciones individuales que componen la consulta (Selinger el al., 1979). Sin embargo, el uso de recursos también podría medirse según el tiempo de respuesta de la consulta, en cuyo caso nos concentraremos en maximizar el núme-
  3. 3. Capítulo 21 Procesamiento de consultas 577 ro de operaciones paralelas (Valduriez y Gardarin, 1984). Puesto que el problema es computacionalmente intratable cuando el número de tablas es grande, la estrategia adoptada se reduce generalmente a encontrar una solución cercana a la óptima (Ibaraki y Kameda, 1984). Ambos métodos de optimización de consultas dependen de las estadísticas de la base de datos para eva- luar apropiadamente las diferentes opciones disponibles. La precisión y grado de actualización de dichas es- tadísticas tienen un gran impacto sobre la eficiencia de la estrategia de ejecución elegida. Las estadísticas recopilan información acerca de las relaciones, atributos e índices. Por ejemplo, el catálogo del sistema puede almacenar estadísticas que proporcionen la cardinalidad de las relaciones, el número de valores distintos que tiene cada atributo y el número de niveles de un índice multinivel (véase el Apéndice C.5A). Mantener las estadísticas actualizadas puede llegar a ser problemático. Si el SGBD actualizara las estadísticas cada vez que se inserta, actualiza o borra una tupla, esto tendría un impacto significativo sobre el rendimiento durante los picos de carga de trabajo. Otra alternativa generalmente preferible, consiste en actualizar las estadísticas de forma periódica, por ejemplo todas las noches, o siempre que el sistema esté inactivo. Otra solución adopta- da por algunos sistemas consiste en asignar a los usuarios la responsabilidad de indicar cuándo hay que actua- lizar las estadísticas. Hablaremos con más detalle de las estadísticas de las bases de datos en la Sección 2104.1. Como ilustración de los efectos que las diferentes estrategias de procesamiento tienen sobre el uso de recursos, vamos a comenzar con un ejemplo. I Ejemplo 21.1 Comparación de diferentes estrategias de procesamiento Hallar todos los gerentes que trabajen en una sucursal de Londres. Podemos escribir esta consulta en SQL como: SELECT * FROM Staff s, Branch b WHERE s.branchNo = b.branchNo AND (s.position = 'Manager' AND b.city = 'London'); Tres consultas de álgebra relacional equivalentes a esta instrucción SQL serían: (1) a(position~'Manager')Á (cit)='London')(Staff.branchNo~Branch.branchNoiStaffX Branch) (2) a(position~'Manager')Á (citY~'LOndOn,)(Staff~ Staff.branchNo~Branch.branchNoBranch) (3) (aposition~'Manager,(Staff))~ Staff.branchNo~Branch.branchNo(acitY~'LOndon,(Branch)) Para los propósitos de este ejemplo, vamos a suponer que hay 1000 tuplas en Staff, 50 tuplas en Branch, 50 empleados con categoría Manager (uno por cada sucursal) y 5 sucursales en Londres. Vamos a com- parar estas tres consultas basándonos en el número de accesos de disco requeridos. En aras a la sim- plicidad, vamos a suponer que no hay índices ni claves de relación en ninguna de las relaciones y que los resultados de cualquier operación intermedia se almacenan en el disco. El coste de la escritura final se ignorará, ya que es el mismo en los tres casos. Vamos a suponer también que se accede a las tuplas de una en una (aunque en la práctica los acceso a disco se basarían en bloques, cada uno de los cuales contendría normalmente varias tuplas) y que la memoria principal es lo suficientemente grande como para procesar relaciones completas para cada una de las operaciones de álgebra relaciona!. La primera consulta calcula el producto cartesiano de Staff y Branch, que requiere (1000 + 50) accesos a disco para leer las relaciones y crea una relación con (1000 * 50) tuplas. Después tendremos que leer cada una de estas tuplas de nuevo para comprobar si cumplen el predicado de selección, lo que impli- ca otros (1000 * 50) accesos a disco, dándonos un coste total de: (1000 + 50) + 2*(1000 * 50) = 101050 accesos a disco La segunda consulta combina Staff y Branch según el número de sucursal branchNo, lo que de nuevo requiere (1000 + 50) accesos a disco para leer cada una de las relaciones. Sabemos que la combinación de las dos relaciones tiene 1000 tuplas, una por cada empleado (un empleado sólo puede trabajar en
  4. 4. 578 Sistemas de bases de datos una sucursal). En consecuencia, la operación de selección requiere 1000 accesos a disco para leer el resultado de la combinación, lo que nos da un coste total de: 2*1000 + (1000 + 50) = 3050 accesos a disco La última de las consultas lee primero cada tupla de 81aff para determinar si se trata de un empleado con categoría de Manager, lo que requiere 1000 accesos a disco y produce una relación con 50 tuplas. La segunda operación de selección lee cada tupla Branch para determinar cuáles son las sucursales de Londres, lo que requiere 50 accesos a disco y genera una relación con 5 tuplas. La operación final es la combinación de las relaciones 81aff y Branch reducidas, lo que requiere (50 + 5) accesos a disco, dando un coste total de: 1000 + 2*50 + 5+(50 + 5) = 1160 accesos a disco Claramente, la tercera es la mejor de las opciones en este caso, según un factor de 87:1. Si incremen- táramos el número de tuplas de 81aff a 10000 y el número de sucursales a 500, la mejora sería según un factor de aproximadamente 870: 1. Intuitivamente, cabía esperar esto desde el principio, ya que el pro- ducto cartesiano de las operaciones de combinación es mucho más costoso que la operación de selec- ción y la tercera de las operaciones de consulta reduce significativamente el tamaño de las relaciones que están siendo combinadas. Veremos en breve que una de las estrategias fundamentales del procesa- miento de consultas es realizar las operaciones unarias, las de selección y proyección, lo antes posible, reduciendo así el tamaño de los operandos para las subsiguientes operaciones binarias. El procesamiento de consultas puede dividirse en cuatro partes principales: descomposición (compuesta de análisis sintáctico y validación), optimización, generación de código y ejecución, como se ilustra en la Figura 21.1. En la Sección 21.2 vamos a examinar brevemente la primera de las fases, de descomposición, antes de volver nuestra atención hacia la segunda fase, la de optimización de consultas. Para completar esta panorámica, vamos a hablar brevemente de cuándo puede llevarse a cabo la optimización. Optimización dinámica y estática Existen dos opciones relativas a cuándo llevar a cabo las primeras tres fases del procesamiento de una consul- ta. Una de las opciones consiste en llevar a cabo dinámicamente la descomposición y la optimización cada vez que se ejecuta una consulta. La optimización dinámica de consultas tiene la ventaja de que toda la informa- ción requerida para seleccionar una estrategia óptima estará actualizada. Las desventajas son que la velocidad de la consulta se verá afectada debido a la necesidad de analizar sintácticamente, validar y optimizar la con- sulta antes de poder ejecutarla. Además, puede que sea necesario reducir el número de estrategias de ejecu- ción que hay que realizar, con el fin de conseguir que ese coste de procesamiento adicional sea aceptable, lo que a su vez puede tener el efecto de que se seleccione una estrategia significativamente inferior a la óptima. La opción alternativa consiste en efectuar una optimización estática de consultas, en la que las consultas son analizadas sintácticamente, validadas y optimizadas una sola vez. Esta técnica es similar a la que se uti- liza cuando se ejecuta un compilador de un lenguaje de programación. Las ventajas de la optimización está- tica son que se elimina el coste adicional de procesamiento en tiempo de ejecución y que puede haber más tiempo disponible para evaluar un mayor número de estrategias de ejecución, incrementándose así las posibi- lidades de encontrar una estrategia mejor. Para las consultas que se ejecutan muchas veces, tomarse un cierto tiempo adicional para encontrar un plan mejor puede proporcionar muchos beneficios. Las desventajas sur- gen del hecho de que la estrategia de ejecución que se selecciona como óptima en el momento de compilar la consulta puede haber dejado de ser óptima en el momento de ejecutarla. De todos modos, también puede emplearse una técnica híbrida para evitar esta desventaja, técnica que consiste en reoptimizar la consulta si el sistema detecta que las estadísticas de la base de datos han cambiado significativamente desde la última vez que se compiló la consulta. Alternativamente, el sistema podría compilar la consulta para la primera ejecución de cada sesión y luego almacenar en caché el plan óptimo durante el resto de la sesión, de modo que el coste se distribuya entre toda la sesión del SGBD.
  5. 5. Capítulo 21 Procesamiento de consultas 579 Consulta en un lenguaje de alto nivel (generalmente SQL) Descomposición de la consulta Expresión de álgebra relacional oCatálogo del sistema Tiempo de compilación Optimización de la consulta Plan de ejecución Generación de código Código generado Ejecución de la consulta Salida de la consulta Figura 21.1. Fases del procesamiento de consultas. 21.2 Descomposición de consultas La descomposición de consultas es la primera fase del procesamiento de consultas. Los objetivos de la des- composición de consultas son transformar una consulta de alto nivel en una consulta de álgebra relacional y comprobar que la consulta sea sintáctica y semánticamente correcta. Las etapas típicas de la descomposición de consultas son el análisis, la normalización, el análisis semántico, la simplificación y la reestructuración de la consulta. (1) Análisis En esta etapa, se analiza la consulta léxica y sintácticamente utilizando las técnicas de los compiladores de los lenguajes de programación (véase, por ejemplo Aho y Ullman, 1977). Además, en esta etapa se verifica que las relaciones y atributos especificados en la consulta están definidos en el catálogo del sistema. Se verifica asimismo que todas las operaciones aplicadas a los objetos de la base de datos sean apropiadas para el tipo de objeto. Por ejemplo, considere la siguiente consulta: SELECT staffNumber FROM Staff WHERE position > 10; Esta consulta sería rechazada por dos motivos (1) En la lista de selección, el atributo staffNumber no está definido para la relación 8taff (debería ser staffNo). (2) En la cláusula WHERE, la comparación '>1O' es incompatible con el tipo de datos position, que es una cadena de caracteres de longitud variable.
  6. 6. 580 Sistemas de bases de datos Completada esta etapa, la consulta de alto nivel habrá sido trasformada en algún tipo de representación interna más adecuada para su procesamiento. La forma interna que se suele elegir es algún tipo de árbol de consulta, que se construye de la forma siguiente: • Se crea un nodo hoja para cada relación base de la consulta. • Se crea un nodo no hoja para cada relación intermedia producida por una operación de álgebra relacio- na!. • La raíz del árbol representa el resultado de la consulta. • La secuencia de operaciones se dirige desde las hojas hacia la raíz. La Figura 21.2 muestra un ejemplo de un árbol de consulta para la instrucción SQL del Ejemplo 21.1 que utiliza el álgebra relacional en su representación interna. Nos referiremos a este tipo de árbol de consulta deno- minándolo árbol de álgebra relacional. (2) Normalización La etapa de normalización del procesamiento de consulta convierte la consulta en una forma normalizada que pueda manipularse más fácilmente. El predicado (en SQL, la condición WHERE), que puede ser arbitraria- mente complejo, puede convertirse a una de dos formas aplicando unas pocas reglas de transformación (Jarke y Koch, 1984): • Forma normal conjuntiva. Una secuencia de conjunciones conectadas mediante el operador / (AND). Cada conjunción contiene uno o más términos conectados mediante el operador v (OR). Por ejemplo: (position = 'Manager' v salary > 20000) / branchNo = '8003' Una selección conjuntiva contiene únicamente aquellas tuplas que satisfacen todas las conjunciones. • Forma normal disyuntiva. Una secuencia de disyunciones conectadas mediante el operador v (OR). Cada disyunción contiene uno o más términos conectados mediante el operador / (AND). Por ejemplo, podríamos reescribir la forma normal conjuntiva anterior como: (position = 'Manager' / branchNo = '8003' ) v (salary > 20000 / branchNo = '8003') Una selección disyuntiva contiene todas las tuplas formadas por la unión de todas las tuplas que satis- facen las disyunciones. (3) Análisis semántica El objetivo del análisis semántico es rechazar las consultas normalizadas que estén incorrectamente formula- das o que sean contradictorias. Una consulta estará incorrectamente formulada si sus componentes no contri- buyen a la generación del resultado, lo que puede suceder si faltan algunas especificaciones de combinación. Una consulta será contradictoria si su predicado no puede ser satisfecho por ninguna tupla. Por ejemplo, el predicado (position = 'Manager' / position = 'Assistant') para la relación Staff será contradictorio, ya que un empleado no puede ser a la vez Manager y Assistant. Sin embargo, el predicado ((position = 'Manager' / !><I s.branchNo=b.branchNo /~0s.position='Manager' 0b.city='London' i i Raiz iOperaciones intermedias i8taft Branch Hojas Figura 21.2. Ejemplo de árbol de álgebra relaciona!.
  7. 7. Capítulo 21 Procesamiento de consultas 581 position = 'Assistant') v salary > 20000) podría simplificarse a (salary > 20000) interpretándose la cláusula con- tradictoria como el valor booleano FALSE. Desafortunadamente, la manera de gestionar las cláusulas contra- dictorias no es coherente entre un SGBD y otro. I Ejemplo 21.2 Comprobación de la corrección semántica Considere la siguiente consulta SQL: SELECT p.propertyNo, p.street FROM Client e, Viewing Y, PropertyForRent p WHERE c.c1ientNo = Y.clientNo AND c.maxRent >= 500 AND c.prefType = 'Flat' AND p.ownerNo = 'C093'; El grafo de conexión de relaciones mostrado en la Figura 21.3(a) no está completamente conectado, lo que implica que la consulta no está correctamente formulada. En este caso, hemos omitido la condi- ción de combinación (Y.propertyNo = p.propertyNo) del predicado. (a) 8·:·8 s· :·s(b) Figura 21.3. (a) Grafo de conexión de relaciones que muestra que la consulta está incorrectamente formulada; (b) grafo de conexión de atributos normalizado que muestra que la consulta es contradictoria.
  8. 8. 582 Sistemas de bases de datos Ahora considere la consulta: SELECT p.propertyNo,p.street FROM Clientc, Viewingv, PropertyForRentp WHERE c.maxRent > 500 ANOc.clientNo= v.c1ientNoANO v.propertyNo= p.propertyNoANOc.prefType= 'Flat'ANOc.maxRent < 200; El grafo de conexión de atributos normalizado para esta consulta se muestra en la Figura 21.3(b), donde podemos ver que tiene un ciclo entre los nodos c.maxRent y O con una suma de evaluación nega- tiva, lo que indica que la consulta es contradictoria. Claramente, no podemos tener un cliente con un alquiler máximo que sea a la vez mayor de 500 euros e inferior a 200 euros. Sólo existen algoritmos para determinar la corrección para el subconjunto de consultas que no contengan disyunciones y negaciones. Para estas consultas, podemos aplicar las siguientes comprobaciones: (1) Construimos un grajo de conexión de relaciones (Wong y Youssefi, 1976). Si el grafo no está conec- tado, la consulta estará incorrectamente formulada. Para construir un grafo de conexión de relaciones, creamos un nodo por cada relación y otro nodo para el resultado. Después dibujamos aristas entre dos nodos para representar una combinación y aristas entre los nodos que representen el origen de las ope- raciones de proyección. (2) Construimos un grajo de conexión de atributos normalizado (Rosenlcrantz y Hunt, 1980). Si el grafo tiene un ciclo para el que la suma de evaluación sea negativa, la consulta sería contradictoria. Para construir un grafo de conexión de atributos normalizado, creamos un nodo por cada referencia a un atributo o para la constante O. Después creamos una arista dirigida entre los nodo s que representen una combinación y una arista dirigida entre un nodo de atributo y un nodo de constante O que represente una operación de selección. A continuación, ponderamos las aristas a ~ b con el valor c, si represen- ta la condición de desigualdad (a ::; b + c), y ponderamos las aristas O ~ a con el valor -c si repre- senta la condición de desigualdad (a :::::c). (4) Simplificación Los objetivos de la etapa de simplificación son detectar las cualificaciones redundantes, eliminar las subex- presiones comunes y transformar la consulta en otra consulta que sea semánticamente equivalente pero que se pueda calcular de forma más fácil y eficiente. Normalmente, las restricciones de acceso, las definiciones de vista y las restricciones de integridad se toman en consideración en esta etapa, pudiendo algunas de esas restricciones y definiciones introducir redundancia. Si el usuario no dispone de los derechos de acceso apro- piados a todos los componentes de la consulta, será necesario rechazar ésta. Suponiendo que el usuario tenga los privilegios de acceso apropiados, una optimización inicial consiste en aplicar las muy conocidas reglas de idempotencia de álgebra booleana, como son: pl(p)==p P 1 false ==false p 1 true ==p p 1 (~p) ==false pl(pvq)==p pv(P)==p p v false ==p p v true ==true p v (~p) ==true pv(plq)==p Por ejemplo, considere la siguiente definición de vista y la siguiente consulta realizada sobre la vista: CREATE VIEW Staff3AS SELECT staffNo,fName, IName,salary, branchNo FROM Staff WHERE branchNo = 'B003'; SELECT * FROM Staff3 WHERE (branchNo = 'B003'ANO salary > 20000);
  9. 9. Capítulo 21 Procesamiento de consultas 583 Como hemos explicado en la Sección 6.4.3, durante la resolución de la vista esta consulta se transforma- rá en: SELECT staffNo, fName, IName, salary, branchNo FROM Staff WHERE (branchNo = 'B003'ANO salary > 20000) ANO branchNo = 'B003'; y la condición WHERE se reduce a (branchNo = 'B003' AND salary > 20000). También pueden aplicarse las restricciones de integridad para ayudar a simplificar las consultas. Por ejem- plo, considere la siguiente restricción de integridad, que garantiza que sólo los empleados con categoría de Manager tengan un salario superior a 20.000 euros: CREATE ASSERTION OnlyManagerSalaryHigh CHECK ((position <> 'Manager' AND salary < 20000) OR (position = 'Manager' AND salary > 20000)); Y considere el efecto sobre la consulta: SELECT * FROM Staff WHERE (position = 'Manager' AND salary < 15000); El predicado de la cláusula WHERE, que busca gerentes cuyo salario sea inferior a 15.000 euros, estará ahora en contradicción con la restricción de integridad, por lo que no puede haber ninguna tupla que satisfa- ga este predicado. (5) Reestructuración de la consulta En la etapa final de la descomposición de una consulta, la consulta se reestructura para obtener una imple- mentación más eficiente. Hablaremos más en detalle de la reestructuración en la sección siguiente. 21.3 Método heurístico de optimización de consultas En esta sección, vamos a examinar el método heurístico de optimización de consultas, que utiliza reglas de transformación para convertir una expresión de álgebra relacional en otra forma equivalente que se sepa que es más eficiente. Por ejemplo, en el Ejemplo 21.1 hemos observado que era más eficiente realizar la opera- ción de selección sobre una relación antes de utilizar dicha relación en una combinación, en lugar de efectuar primero la combinación y luego la selección. Veremos en la Sección 21.3.1 que existe una regla de transfor- mación que permite cambiar el orden de las operaciones de combinación y selección de modo que la selec- ción pueda realizarse primero. Habiendo explicado cuáles son las transformaciones válidas, en la Sección 21.3.2 presentaremos un conjunto de reglas heurísticas que se sabe que producen estrategias de ejecución 'buenas' (aunque no necesariamente óptimas). 21.3.1 Reglas de transformación para las operaciones de álgebra relacional Aplicando reglas de transformación, el optimizador puede transformar una expresión de álgebra relacional en otra expresión equivalente que se sabe que es más eficiente. Utilizaremos estas reglas para reestructurar el árbol de álgebra relacional (canónico) generado durante la descomposición de la consulta. El lector puede encontrar demostraciones de estas reglas en Aho el al. (1979). Al enumerar estas reglas, utilizaremos tres rela- ciones R, S Y T, estando R definida sobre los atributos A = {Al, Al, ... , An} Y S definida sobre B = {BI,Bl, ... , Bn}; p, q y r denotan predicados y L, LI, Ll, M, M¡, Ml Y N denotan conjuntos de atributos.~ (1) Las operaciones conjuntivas de selección pueden transformarse en una cascada de operaciones individuales de selección (y viceversa).
  10. 10. 584 Sistemas de bases de datos Esta transformación se denomina en ocasiones cascada de selecciones. Por ejemplo: U branchNo='B003'ASalarY>15000(Staff) = UbranchNo='B003'(Usalary>15000(Staff)) (2) Conmutatividad de las operaciones de selección. up(uq(R)) = uq(up(R)) Por ejemplo: U branchNo='B003'Usalary>15000(Staff)) = U salary>15000(ubranchNo='B003,(Staff)) (3) En una secuencia de operaciones de proyección, sólo se requiere la última proyección de la secuencia. ITLITM' .. ITN(R) = ITL(R) Por ejemplo: ITrNameITbranchNo,IName(Staff) = ITrName(Staff) (4) Conmutatividad de la selección y la proyección. Si el predicado p implica sólo los atributos de la lista de proyección, entonces las operaciones de selec- ción y de proyección son conmutativas: nAf,.Am (up(R)) = Up(TlAf, .,Am (R)) donde p E {Af, A2' ... , Am) Por ejemplo: ITfName,IName(UlName='Beech,(Staff)) = UIName='Beech,(ITfName,IName(Staff)) (5) Conmutatividad de la combinación Theta (y del producto cartesiano). R [><Ip S = S [><Ip R RxS=SxR Puesto que la equicombinación y la combinación natural son casos especiales de la combinación Theta, entonces esta regla también se aplica a dichas operaciones de combinación. Por ejemplo, utilizando la equicombinación de Staff y Branch: 8taff C><Jstaff.branchNo=Branch.branchNo Branch Branch C><JStaff.branchNo=Branch.branchNo Staff (6) Conmutatividad de la selección y de la combinación Theta (o del producto cartesiano). Si el predicado de selección implica sólo atributos de una de las relaciones que están siendo combina- das, entonces las operaciones de selección y de combinación (o de producto cartesiano) son conmuta- tivas: up(R [><Ir S) = (up(R)) [><Ir S up(R X S) = (up(R)) X S donde P E {A1' A2' ... , An} Alternativamente, si el predicado de selección es un predicado conjuntivo de la forma (p 1 q), donde p implica sólo atributos de R y q implica sólo atributos de S, entonces las operaciones de selección y combinación Theta son conmutativas de la forma siguiente: upAq(R [><Ir S) = (up(R)) [><Ir (uq(S)) upAq(R X S) = (up(R)) X (uq(S)) PO~jemplo:
  11. 11. Capítulo 21 Procesamientode consultas 585 (T position='Manager' Á city= 'London,(Staff C><JStaff.branchNo=Branch.branchNo Branch) = (JPOSitiOn='Manager,(Staff)) [><JStaff.branChNO=BranCh.branChNO (T citY='London,(Branch)) (7) Conmutatividad de la proyección y de la combinación Theta (sobre el producto cartesiano). Si la lista de proyección tiene la forma L = L¡ U Lz, donde LI implica sólo atributos de R y Lz implica sólo atributos de s, entonces si la condición de combinación sólo contiene atributos de L, las opera- ciones de proyección y de combinación Theta son conmutativas: IlL1 v dR C><Ic S) = (IlL1 (R)) C><Ic (IlL2(S)) Por ejemplo: Ilposition, city, branchNo(Staff [><JStaff.branchNo=Branch.branchNo Branch) = (Ilpos;t;on, bcanchNO(Staff)) C><IStaff.bcanchNo=Bcanch.bcanchNo (Ilc;ty, bcanchNo(Branch)) Si la condición de combinación contiene atributos adicionales que no estén en L, como, por ejemplo, los atributos M = MI U Mz, donde MI implica sólo atributos de R y Mzimplica sólo atributos de S, enton- ces se requiere una operación final de proyección: IlL1 vL2(R C><Ic S) = IlL1 vL2 IlL1 vM1 (R)) C><Ic (IlnL2VM2(S)) Por ejemplo: Ilposition, city(Staff [><]Staff.branchNo=Branch.branchNo Branch) = Ilposition, city( (Ilposition, branchNO(Staff)) C><JStaff.branchNo=Branch"branchNo (Ilcity, branchNO(Branch))) (8) Conmutatividad de la unión y la intersección (pero no de la diferencia de conjuntos). RuS=SuR RnS=SnR (9) Conmutatividad de la selección y de las operaciones de conjuntos (unión, intersección y diferen- cia de conjuntos). up(R u S) = up(S) u up(R) up(R n S) = up(S) U up(R) up(R - S) = up(S) - up(R) (10) Conmutatividad de la proyección y la unión. IlL(R u S) = IlL(S) u IlL(R) (11) Asociatividad de la combinación Theta (y del producto cartesiano). El producto cartesiano y la combinación natural son siempre asociativos: (R C><I S) C><I T = R C><I (S C><I T) (R x S) x T = R x (S x T) Si la condición de combinación q implica sólo atributos de las relaciones S and T, entonces la com- binación Theta es asociativa de la siguiente forma: (R C><IpS) C><IqAC T = R C><IPAC(S C><Iq T) Por ejemplo: ~ (Staff C><IStaff.staffNo=pcopertYFOCRentstaffNo PropertyForRent) C><IownerNo=Ownec.ownecNo AStaff.IName=OwnecIName Owner = Staff C><I Staff.staffNo=PcopertyForRentstaffNo AStaff.IName=IName (PropertyForRent ownecNo Owner)
  12. 12. 586 Sistemas de bases de datos Observe que en este ejemplo sería incorrecto simplemente 'mover los paréntesis' ya que esto resul- taría en una referencia no definida (Staff.IName)en la condición de combinación entre PropertyForRent y Owner: PropertyForRent [><J PropertyForRent.ownerNo=Owner.ownerNo Á Staff.IName=Ow[1er.IName Owner (12) Asociatividad de la unión y la intersección (pero no de la diferencia de conjuntos). (R u S) uT = S u (R uT) (R n S) nT = S n (R nT) I Ejemplo 21.3 Utilización de las reglas de transformación Para los inquilinos en perspectiva que estén buscando apartamentos, localizar los inmuebles que satisfacen sus requisitos y son propiedad del propietario C093. Podemos escribir esta consulta en SQL como: SELECT p.propertyNo,p.street FROM Clientc, Viewingv, PropertyForRentp WHERE c.prefType= 'Flat' AND c.c1ientNo= v.c1ientNoAND v.propertyNo= p.propertyNoAND c.maxRent >= p.rent AND c.prefType= p.type AND p.ownerNo= 'C093'; Para los propósitos de este ejemplo, vamos a asumir que hay menos inmuebles propiedad del propie- tario C093 que inquilinos en perspectiva que hayan especificado como tipo preferido de inmueble el de apartamento (flat). Convirtiendo la instrucción SQL en álgebra relacional, tendremos: IIp,propertyNo, p,street( (J" c.prefTyp'Flat' 1 c.c1ientNo=v.c1ientNo 1 v.propertyNo=p.propertyNo 1 c.maxRent>=p.rent A c.prefType=p.type 1 p,ownerNO='C093'( (e xv) x p)) Podemos representar esta consulta mediante el árbol de álgebra relacional canónico que se muestra en la Figura 21.4(a). A continuación utilizamos las siguientes reglas de transformación para mejorar la efi- ciencia de la estrategia de ejecución: (1) (a) Regla 1, dividir la conjunción de operaciones de selección en operaciones de selección indivi- duales. (b) Regla 2 y Regla 6, reordenar las operaciones de selección y luego conmutar las selecciones y los productos cartesianos. El resultado de estas dos primeras etapas se muestra en la Figura 21.4(b). (2) Teniendo en cuenta lo explicado en la Sección 4.1.3, podemos reescribir una selección con un pre- dicado de equicombinación y una operación de producto cartesiano como una operación de equi- combinación, es decir: aRa=Sb(R X S) = R ~Ra=Sb S Aplicamos esta transformación en todos los lugares apropiados. El resultado de este paso se mues- tra en la Figura 21.4(c). (3) Regla 11, reordenación de las equicombinaciones de modo que la selección más restrictiva sobre (p.ownerNo = 'C093') se realice en primer lugar, como se muestra en la Figura 21.4(d). (4) Reglas 4 y 7, mediante las que movemos las proyecciones hacia abajo más allá de las equicombi- naciones y creamos nuevas operaciones de proyección según sea necesario. El resultado de aplicar estas reglas se muestra en la Figura 21.4( e). l.
  13. 13. Capítulo 21 Procesamiento de consultas 587 rr p.propertyNo, p.street x P TI p.propertyNo, p.street 1 i pv e I °c.pretType='Flat' IIp.propertyNo, p.street i itx1 v.propertyNo=p.propertyNo 1t><Ic.ctientNo=v.clientNo °p.ownerNo='C093' 1 0c.maxRent>=p.rent" c.pretType=p.type 0c.prefType='Flar V !e 0c.c1ientNo=v.clientNo 0p.OwnerNO='C093' t0C,maxRent>=p.rent 1 c.prefType=p.type t °v.propertyNo=p.prOpertyNo t x /"- 1 x P r ve Dc.prefType='Flaf / c.ctientNo=v.clientNo 1 v.propertyNo=p.propertyNo 1 c.maxRent>=p.rent 1 c.prefTypeop.type tP.ownerNOO'C093' x 1 (a) (b) (e) rr p.propertyNo, p.street 0c.maxRent>=p.rent 1 c.prefType=p.type CXlv.propertyNo=p.propertyNo 0c.prefType='Flat' i ev i°c.maxRent>=p.rent ITp.propertyNo, p.street ! ! P (f) 0p.ownerNo='C093' 1 p.type='Flat' itx1c.clientNo=v.clientNo 1t><Iv.propertyNo=p.propertyNo IT c.clientNo, c.maxRent 1 I1p.propertyNo, p.street Ilv,propertyNo, 0c.prefType='Flat' p.rent v.clientNo e °c.prefType='Flar v 1 rIp.propertyNo, p.street i0c,maxRent>""p.rent 1 c.prefTypeo;;;p.type I ! p (e) °p.ownerNo='C093' i~c.clientNo=v.clientNo 1CXlv.propertyNo=p.propertyNo TI c.clientNo, c.maxRent, c.preffype IIp.propertyNo, p.street, TIv.propertyNo, p.rent, p.type v.clientNo e it:x:lc.c1ientNo=v.clientNo 1 p 1 ! (d) 0p.ownerNo='C093' V Figura 21.4. Árbol de álgebra relacional para el Ejemplo 21.3: (a) árbol canónico de álgebra relacional; (b) árbol de álgebra relacional formado al llevar las selecciones hacia abajo; (c) árbol de álgebra relacional formado al cambiar las selecciones/productos cartesianos por equicombinaciones; (d) árbol de álgebra relacional que se forma aplicando la regla de asociatividad de las equicombinaciones; (e) árbol de álgebra relacional que se forma llevando las proyecciones hacia abajo; (f) árbol final reducido de álgebra relacional que se forma sustiuyendo c.prefType = 'Flat' en la selección sobre p,type y llevando hacia" abajo del árbol la selección resultante.
  14. 14. 588 Sistemas de bases de datos Una optimización adicional en este ejemplo concreto consiste en observar que la operación de selec- ción (c.preIType=p.type)puede reducirse a (p.type='Flat'), ya que sabemos que (c.preIType='Flat') de la primera cláusula del predicado. Utilizando esta sustitución, movemos esta selección hacia abajo en el árbol, lo que da como resultado el árbol final reducido de álgebra relacional que se muestra en la Figura 21.4(f). ~ 21.3.2 Estrategias de procesamiento heurística Muchos SGBD utilizan reglas heurísticas para determinar las estrategias de procesamiento de las consultas. En esta sección vamos a examinar algunas reglas heurísticas convenientes que pueden aplicarse para proce- sar las consultas. (1) Realizar las operaciones de selección lo antes posible. La selección reduce la cardinalidad de la relación y el subsiguiente procesamiento de dicha relación. Por tanto, debemos utilizar la regla 1para conectar en cascada las operaciones de selección y las reglas 2, 4, 6 y 9 referidas a las conmutatividad de la selección con las operaciones unarias y binarias, con el fin de mover las operaciones de selección lo más abajo posible en el árbol. Mantenga juntos los predi- cados de selección relativos a una misma relación. (2) Combinar el producto cartesiano con una operación de selección subsiguiente cuyo predicado represente una condición de combinación, para formar una operación de combinación. Ya hemos observado que podemos reescribir una selección con un predicado de combinación Theta y una operación de producto cartesiano como una operación de combinación Theta: (3) Utilizar la asociatividad de las operaciones binarias para reordenar los nodos hoja de modo que los nodos hoja con las operaciones de selección más restrictivas se ejecuten primero. De nuevo, la regla práctica consiste en realizar el máximo posible de reducciones antes de llevar a cabo las operaciones binarias. Así, si tenemos dos operaciones de combinación consecutivas que realizar: debemos emplear las reglas 11 y 12 relativas a la asociatividad de la combinación Theta (y de la unión e intersección) para reordenar las operaciones de modo que las relaciones que nos de la combinación más pequeña se calculen primero, lo que significa que la segunda combinación también estará basada en un primer operando más pequeño. (4) Realizar las operaciones de proyección lo antes posible. De nuevo, las operaciones de proyección reducen la cardinalidad de las relaciones y, por tanto, el sub- siguiente procesamiento de las mismas. Por tanto, debemos emplear la regla 3 para conectar en casca- da las operaciones de proyección y las reglas 4, 7 Y la referidas a la conmutatividad de la proyección y las operaciones binarias con el fin de mover las operaciones de proyección lo más abajo posible en el árbol. Hay que mantener juntos los atributos de proyección correspondientes a una misma relación. (5) Calcular una única vez las expresiones comunes. Si una expresión común aparece más de una vez en el árbol y el resultado que produce no es excesi- vamente grande, hay que almacenar el resultado después de haberlo calculado la primera vez y luego reutilizarlo cada vez que se requiera. Esto sólo representará una ventaja si el tamaño del resultado correspondiente a la expresión común es lo suficientemente pequeño como para almacenarlo en memo- ria principal o como para poder acceder a él en el almacenamiento secundario con un coste inferior al de recalcular el resultado. Esto puede ser especialmente útil cuando se efectúan consultas sobre las vis- tas, puesto que puede utilizarse la misma expresión para calcular la vista cada vez.
  15. 15. Capítulo 21 Procesamiento de consultas 589 En la Sección 23.7 mostraremos cómo pueden aplicarse estas reglas heurísticas a las consultas distribui- das. En la Sección 28.5 se mostrará que algunas de estas reglas heurísticas pueden requerir un análisis adicio- nal para los SGBD objeto-relacionales, que soportan consultas que contienen tipos definidos por el usuario y funciones definidas por el usuario. 21.4 Estimación de costes para las operaciones de álgebra relacional Un SGBD puede tener muchas formas distintas de implementar las operaciones de álgebra relacional. El obje- tivo de la optimización de consultas consiste en seleccionar la más eficiente. Para ello, utilice fórmulas que estiman los costes para una serie de opciones y seleccione aquella que tenga el coste menor. En esta sección vamos a examinar las diferentes opciones disponibles para implementar las principales operaciones de álge- bra relacional. Para cada una de ellas, proporcionaremos una panorámica de la implementación y daremos un coste estimado. Puesto que el coste dominante en el procesamiento de consultas es usualmente el de los acce- sos a disco, que son lentos comparados con los accesos a memoria, nos concentraremos exclusivamente en el coste de los accesos a disco dentro de las estimaciones proporcionadas. Cada estimación representa el núme- ro requerido de accesos a bloques de disco, excluyendo el coste de escribir la relación que se genera como resultado de la consulta. Muchas de las estimaciones de coste están basadas en la cardinalidad de la relación. Por tanto, puesto que necesitamos poder estimar la cardinalidad de las relaciones intermedias, también mostraremos algunas esti- maciones típicas que pueden deducirse para dichas cardinalidades. Comencemos esta sección examinando los tipos de estadísticas que el SGBD almacena en el catálogo del sistema para servir de ayuda durante la estima- ción de costes. 21.4.1 Estadísticas de la base de datos El éxito en la estimación del tamaño y el coste de las operaciones de álgebra relacional intermedias depende de la cantidad y grado de actualización de la información estadística guardada por el SGBD. Normalmente, esperamos que el SGBD sea capaz de mantener las siguientes informaciones en su catálogo del sistema: Para cada relación base R • nTuples(R): el número de tuplas (registros) en una relación R (es decir, su cardinalidad). • bFactor(R): el factor de bloqueo de R (es decir, el número de tuplas de R que caben en un bloque). • nBlocks(R): el número de bloques requeridos para almacenar R. Si las tuplas de R se almacenan físi- camente juntas, se cumplirá que: nBlocks(R) = [nTuples(R)/bFactor(R)] Utilizamos [x] para indicar que el resultado del cálculo se redondea al entero más bajo que sea igualo supenor ax. Para cada atributo A de la relación base R • nDistinctA(R): el número de valores distintos que aparecen para el atributo A en la relación R. • minA(R),maxA(R):los valores mínimo y máximo posibles para el atributo A en la relación R. • SCA(R):la cardinalidad de selección del atributo A en la relación R. Se trata del número medio de tuplas que satisfacen una condición de igualdad para el atributo A. Si asumimos que los valores de A están uniformemente distribuidos en R y que existe al menos un valor que satisface la condición, entonces: tI SCA (R) = [nTuples(R) / DistinctA (R)] si A es un atributo clave de R en caso contrario También podemos estimar la cardinalidad de selección para otras condiciones:
  16. 16. 590 Sistemas de bases de datos [nTuples(R) * ((maxA(R) - c) /(maxA (R) - minA(R))] para la desigualdad (A > c) [nTuples(R) * ((c - maxA (R)) /(maxA (R) - minA(R))] para la desigualdad (A < c) SCA(R) = i[(nTUPleS(R) / nDistinctA (R)) * n] SC A(R) *SCs (R) SCA(R) +SCs (R) -SCA (R) * SCs (R) para A perteneciente a {cl, c2'·· ., cn} para (A ¡ B) para (A v B) Para cada índice multinivel 1 sobre el conjunto de atributos A • nLevelsA(I): el número de niveles de I. • nLfBlocksA(I): el número de bloques hoja de I. Mantener estas estadísticas actualizadas puede ser problemático. Si el SGBD actualiza las estadísticas cada vez que se inserta, actualiza o borra una tupla, esto tendrá un impacto significativo sobre las prestacio- nes en los momentos de mayor carga de trabajo. Una alternativa generalmente preferible consiste en que el SGBD actualice las estadísticas de forma periódica, por ejemplo durante la noche o cada vez que el sistema esté inactivo. Otro enfoque adoptado por algunos sistemas es hacer a los usuarios responsables de indicar que las estadísticas deben ser actualizadas. 21.4.2 Operación de selección (S = O"p(R» Como hemos dicho en la Sección 4.1.1, la operación de selección en el álgebra relacional funciona sobre una única relación R, y define una relación S que contiene únicamente aquellas tuplas de R que satisfacen el predicado especificado. El predicado puede ser simple, implicando la comparación de un atributo de R con un valor constante o con otro valor de atributo, y también puede ser compuesto, implicando más de una condición, combinándose las distintas condiciones mediante las conectivas lógicas ¡ (AND), v (OR) Y ~ (NOT). Existen diversas implementaciones distintas para la operación de selección, dependiendo de la estructura del archivo en que esté almacenada la relación y de si los atributos implicados en el predicado han sido indexados o se les ha aplicado una función hash. Las principales estrategias que vamos a conside- rar son: • búsqueda lineal (archivo desordenado, sin índice); • búsqueda binaria (archivo ordenado, sin índice); • igualdad de la clave hash; • condición de igualdad de la clave principal; • condición de desigualdad de la clave principal; • condición de igualdad en un índice (secundario) de clústering; • condición de igualdad en un índice (secundario) no de clústering; • condición de desigualdad en un índice secundario de tipo B+-tree. Los costes de cada una de estas estrategias se resumen en la Tabla 21.1. Estimación de la cardinalidad de la operación de selección Antes de considerar estas opciones, vamos a presentar primero estimaciones para el número esperado de tuplas y el número esperado de valores distintos de un atributo en la relación resultado S obtenida al efectuar la operación de selección sobre R. Generalmente, es bastante difícil proporcionar estimaciones precisas; sin embargo, si aceptamos las suposiciones tradicionales de simplificación que suponen que los valores de los atributos están uniformemente distribuidos dentro de su dominio y que los atributos son independientes, pode- mos usar las siguientes estimaciones: nTuples(S) = SCA(R) el predicado p es de la forma (A e x)
  17. 17. Estrategias Capítulo 21 Procesamiento de consultas 591 Tabla 21.1. Resumen del coste estimado de E/S para las estrategias correspondientes a una operación de selección. Coste Búsqueda lineal (archivo desordenado, [nBlocks(R)/2], para una condición de igualdad sobre un atributo clave sin índice) nBlocks(R), en caso contrario Búsqueda binaria (archivo ordenado, [loginBlocks(R»], para una condición de igualdad sobre un atributo ordenado sin índice) [loginBlocks(R»] + [SCA(R)/bFactor(R)] - 1, en caso contrario Igualdad de la clave hash Condición de igualdad de la clave principal Condición de desigualdad de la clave principal Condición de igualdad en un índice (secundario) de clústering Condición de igualdad en un índice (secundario) no de clústering Condición de desigualdad en un índice secundario de tipo B+-tree 1, suponiendo que no se produzca desbordamiento nLevelsA(I) + 1 nLevelsA(I) + [nBlocks(R)/2] nLevelsA(I) + [SCA(R)/bFactor(R)] nLevelsA(I) + [nLfBlocksA(I)/2 nTuples(R)/2] Para cualquier atributo B *- A de s: {nTUPleS(S) nDistinctB (S) = [(nTuples(S) +nDistinctB (R»)/3] nDistinctB (R) si nTuples(S) < nDistinctB (R)/2 si nDistinctB (R)/2 :S: nTuples(s) :S: 2*nDistinctB (R) si nTuples(S) > 2*nDistinctB (R) Podemos calcular estimaciones más precisas si relajamos la suposición de la distribución uniforme de los valores, pero esto requiere el uso de información estadística más detallada, como, por ejemplo, histogramas y pasos de distribución (Piatetsky-Shapiro y Connell, 1984). Hablaremos brevemente de cómo utiliza Oracle los histogramas en la Sección 21.6.2. (1) Búsqueda lineal (archivo desordenado, sin índice) Con esta técnica, puede se necesario analizar cada tupla de cada bloque para determinar si satisface el predi- cado, como se ilustra en el algoritmo resumidos que se ilustra en la Figura 21.5. Esto se denomina algunas veces exploración completa de tabla. En el caso de una condición de igualdad sobre un atributo clave, si supo- nemos que las tuplas están uniformemente distribuidas por el archivo sólo hará falta, por término medio explorar la mitad de los bloques para encontrar una tupla específica, por lo que la estimación de costes será: [nBlocks(R)/2] Para cualquier otra condición, puede que sea necesario explorar el archivo completo, por lo que la estima- ción más general de coste será: nBlocks(R) (2) Búsqueda binaria (archivo ordenado, sin índice) Si el predicado tiene la forma (A = x) y el archivo está ordenado según el atributo A, que es también el atribu- to clave de la relación R, entonces la estimación de coste para la búsqueda será:
  18. 18. 592 Sistemas de bases de datos // // Búsqueda lineal // El predicado predicate es la clave de búsqueda. // El archivo no está ordenado. Los bloques están numerados secuencialmente a partir de 1. // Devuelve una tabla de resultados que contiene las tuplas de R que satisfacen el predicado. // for i = 1 to nBlocks(R) { block = read_bJock(R, i); for j = 1 to nTuples(block) { if (block.tuple [j] satisfies predicate) then add tuple to result; // recorrer en bucle cada bloque // recorrer en bucle cada tupla del bloque i Figura 21.5. Algoritmo para búsqueda lineal. [log2(nBlocks(R))] El algoritmo para este tipo de búsqueda está esbozado en la Figura 21.6. Con carácter más general, la esti- mación de coste será: [log2(nBlocks(R))] + [SCA(R)/bFactor(R)] - 1 El primer término representa el coste de encontrar la primera tupla utilizando un método de búsqueda bina- ria. Esperamos que existan SCA(R)tuplas que satisfagan el predicado, las cuales ocuparán [SCA(R)/bFactor(R)] bloques, de los cuales uno ya ha sido extraído al localizar la primera tupla. (3) Igualdad de la clave hash Si el atributo A es la clave hash, aplicamos el algoritmo hash para calcular la dirección correspondiente a la tupla. Si no hay ningún desbordamiento, el coste esperado será 1. Si hay desbordamiento, puede que sean necesarios accesos adicionales, dependiendo de la cantidad de desbordamiento y del medio para gestionarlo. (4) Condición de igualdad de la clave principal Si el predicado implica una condición de igualdad para la clave principal (A = x), podemos utilizar el índice principal para extraer la única tupla que satisface esta condición. En este caso, necesitaremos leer un bloque más que el número de accesos de índice, equivalente al número de niveles del índice, por lo que el coste esti- mado será: nLevelsA(I) + 1 (5) Condición de desigualdad de la clave principal Si el predicado implica una condición de desigualdad para la clave principal A (A < x, A <= x, A > x, A >= x), podemos primero utilizar el índice para localizar la tupla que satisface el predicado A = x. Suponiendo que el índice está ordenado, podrá accederse a las tuplas requeridas leyendo todas las tuplas situadas antes o después de esta tupla que hemos localizado. Suponiendo una distribución uniforme, cabría esperar que la mitad de las tuplas satisfagan la desigualdad, por lo que el coste estimado será: nLevelsA(I) = [nBlocks(R)/2] (6) Condición de igualdad en un índice (secundario) de clústering Si el predicado implica una condición de igualdad para el atributo A, que no es la clave principal pero propor- ciona un índice secundario de clústering, podemos utilizar el índice para extraer las tuplas requeridas. El coste estimado será:
  19. 19. Capítulo 21 Procesamiento de consultas 593 // // Búsqueda binaria // El predicado predicate es la clave de búsqueda. // El archivo está ordenado según valores ascendentes de la clave de ordenación, A. // El archivo ocupa nBlocks bloques, numerados secuencialmente a partir de l. // Devuelve una variable booleana (found) que indica si se ha encontrado un registro que // se ajuste al predicado y una tabla de resultados en caso afirmativo. // next = 1; last = nBlocks; found = FALSE;keep_searching = TRUE; while (last >= 1 and (not found) and (keep_searching» { i = (next + last)/2; // la mitad del espacio de búsqueda block = read_block(R, i) ; if (predicate < orderinll-key_fie1d(firsCrecord(block») then // el registro se encuentra en la mitad inferior del área de búsqueda last=i-l; else if (predicate > orderinll-key_fie1d(last_record(block») then // el registro se encuentra en la mitad superior del área de búsqueda next= i + 1; e1seif (check_block_for_predicate(block, predicate, result» then // el registro requerido se encuentra en el bloque found = TRUE; e1se keep_searching = FALSE; // el registro no está ahí Figura 21.6. Algoritmo de búsqueda binaria en un archivo ordenado. nLevelsA(I) + [SCA(R)/bFactor(R)] El segundo término es una estimación del número de bloques que se requerirá para almacenar el número de tuplas que satisfacen la condición de igualdad, que hemos estimado como SCA(R). (7) Condición de igualdad en un índice (secundario) no de clústering Si el predicado implica una condición de igualdad para el atributo A, que no es la clave principal pero propor- ciona un índice secundario no de clústering, podemos utilizar el índice para extraer las tuplas requeridas. En este caso, tenemos que asumir que las tuplas se encuentran en diferentes bloques (el índice no tiene estructu- ra de clúster en este caso), por lo que el coste estimado será: (8) Condición de desigualdad en un índice secundario de tipo B+-tree Si el predicado implica una condición de desigualdad para el atributo A (A < x, A <= x, A > x, A >= x), que pro- porciona un índice secundario de tipo B+-tree, entonces a partir de los nodos hoja del árbol podemos explo- rar las claves desde el valor más pequeño hasta x (para condiciones < o <=) o desde x hasta el valor máximo (para condiciones> o >=). Suponiendo una distribución uniforme cabría esperar que haya que acceder a la mitad de los bloques de nodos hoja y a la mitad de las tuplas (a través del índice). El coste estimado será entonces: nLevelsA(I) + [nLfBlocksA(I)/2 + nTuples(R)/2] El algoritmo para explorar un índice B+-tree en busca de una única tupla se muestra en la Figura 21.7.
  20. 20. ~' 594 Sistemas de bases de datos // // Búsqueda B+-tree // La estructura B+-tree está representada como una lista enlazada en la que cada nodo no hoja está estructurado como: // un máximo de n elementos, cada uno compuesto por: // un valor clave (key) y un puntero (P) a un nodo hijo (posiblemente NULL). // Las claves están ordenadas: keYl < keY2 < keY3 < ... < keYn_l // Los nodos hoja apuntan a las direcciones de los registros reales. // El predicado predicate es la clave de búsqueda. // Devuelve un valor booleano (jound) que indica si el registro ha sido encontrado y // la dirección (return_address) del registro, en caso afirmativo. // nade = gecrooCnodeO; while (node is not a leaf node) { i = 1; // localizar la clave que sea inferior al predicado while (not (i > n al' predicate < node[i].key)) { i= i+ 1; node = gecnexcnode(node[i] .pYinode[i].p apunta a un subárbol que puede contener un predicado. } // Se ha encontrado un nodo hoja, así que hay que comprobar si existe un registro con este predicado. i= 1; found = FALSE; while (not (found 01' i > n)) { if (predicate = node[i].key) then { found = TRUE; retufl1_address = node[i] .p; ese i= i+ 1; Figura 21.7. Algoritmo para explorar un árbol B+-tree en busca de una única tupla que se corresponda con un determinado valor. (9) Predicados compuestos Hasta ahora, hemos limitado nuestro análisis a predicados simples que sólo implican un atributo. Sin embar- go, en muchas-s-itQaciones el predicado puede ser compuesto, consistiendo en varias condiciones relativas a más de un atributo. Ya hemos observado en la Sección 21.2 que podemos expresar un predicado compuesto de dos formas: mediante la forma normal conjuntiva y mediante la forma normal disyuntiva: • Una selección conjuntiva contendrá únicamente aquellas tuplas que satisfagan todas las conjunciones . • Una selección disyuntiva contendrá aquellas tuplas formadas por la unión de todas las tuplas que satis- fagan todas las disyunciones. Selección conjuntiva sin disyunción Si el predicado compuesto no contiene ningún término de disyunción, podemos considerar las siguientes téc- lllcas: (1) Si uno de los atributos en una conjunción tiene un índice o está ordenado, podemos utilizar una de las estrategias de selección 2-8 explicadas anteriormente para extraer las tuplas que satisfagan dicha con-
  21. 21. Capítulo 21 Procesamiento de consultas 595 dición. Después podemos comprobar si cada tupla extraída satisface las condiciones restantes del pre- dicado. (2) Si la selección implica una condición de igualdad sobre dos o más atributos y existe un índice com- puesto (o clave hash) sobre los atributos combinados, podemos explorar el índice directamente, como se ha explicado anteriormente. El tipo de índice determinará cuál de los algoritmos anteriores hay que utilizar. (3) Si hay índices secundarios definidos sobre uno o más atributos y, de nuevo, estos atributos están impli- cados únicamente en condiciones de igualdad dentro del predicado, entonces si los índices utilizan punteros de registro (un puntero de registro identifica unívocamente cada tupla y proporciona la direc- ción de la tupla al disco), en lugar de punteros de bloque, podemos explorar cada índice para encon- trar las tuplas que satisfagan una condición individual. Formando a continuación la intersección de todos los punteros extraídos, tenemos el conjunto de punteros que satisfacen las condiciones. Si no hay disponibles índices para todos los atributos, podemos comprobar si las tuplas extraídas cumplen las condiciones restantes. Selecciones con disyunción Si uno de los términos de la condición de selección contiene un v (OR) y el término requiere una búsqueda lineal porque no existe ningún índice u ordenación adecuado, toda la operación de selección requerirá una búsqueda lineal. Sólo si existe un índice u ordenación para cada término de la selección podremos optimizar la consulta extrayendo las tuplas que satisfagan cada condición y aplicando la operación de unión, como se explica más abajo en la Sección 21.4.5, operación que también permitirá eliminar los duplicados. De nuevo, pueden utilizarse punteros de registros, si es que existen. Si no puede utilizarse ningún atributo para extraer de manera eficiente las tuplas, empleamos el método de la búsqueda lineal y comprobamos todas las condiciones simultáneamente para cada tupla. A continuación vamos a ver un ejemplo para ilustrar el uso de la estimación con la operación de selección. I Ejemplo 21.4 Estimación de coste para una operación de selección Para los propósitos de este ejemplo, vamos a hacer las siguientes suposiciones acerca de la relación Staff: • Existe un índice hash sin desbordamiento sobre el atributo de clave principal staffNo. • Existe un índice de clústering sobre el atributo de clave externa branchNo. • Existe un índice B+-tree sobre el atributo salary. • La relación Stafftiene las siguientes estadísticas almacenadas en el catálogo del sistema: nTuples(Staff) = 3000 taff) = 30~nBlocks(Staff) = 100= 500~SCbranchNo(Staff)=6= 10~SCposition(Staff)= 300= 500~SCsalary(Staff) =6= 10.000maxsalary(Staff)= 50.000=2 alary(l) =2nLffilockssa'ary(I)= 50 El coste estimado de una búsqueda línea sobre el atributo clave staffNoes 50 bloques y el coste de una búsqueda lineal sobre un atributo no clave es de 100 bloques. A continuación, consideramos las siguien- tes operaciones de selección y utilizamos las estrategias anteriores para mejorar estos dos costes: SI: astaffNO='SG5,(Staff) S2: aPosition='Manager,(Staff)
  22. 22. 596 Sistemas de bases de datos S3: abranchNo='B003,(Staff) S4: asalary>2oooo(Staff) S5: (J"position='Manager' A branchNo='B003,(Staff) SI: S2: S3: S4: S5: Esta operación de selección contiene una condición de igualdad sobre la clave principal. Por tanto, como el atributo staffNoestá almacenado con un método hash, podemos utilizar la estrategia 3 definida anteriormente para estimar el coste, que será de 1 bloque. La cardinalidad estimada de la relación resultante será SCstaffNo(Staff)= 1. El atributo del predicado es un atributo no clave y no indexado, por lo que no podemos mejorar el método de la búsqueda lineal, lo que nos da un coste estimado de 100 bloques. La cardinalidad estimada de la relación resultante será SCposition(Staff)= 300. El atributo del predicado es una clave externa con un índice de clústering, por lo que podemos uti- lizar la Estrategia 6 para estimar el coste, que será 2 + [6/30] = 3 bloques. La cardinalidad esti- mada de la relación resultante es SCbranchNO(Staff)= 6. Este predicado implica una búsqueda de rango sobre el atributo salary, que tiene un índice B+-tree, por lo que podemos utilizar la Estrategia 7 y estimar el coste como: 2 + [50/2] + [3000/2] = 1527 bloques. Sin embargo, esto es significativamente peor que la estrategia en búsqueda lineal, por lo que en este caso utilizaríamos el método de búsqueda lineal directamente. La cardinalidad esti- mada de la relación resultante será SCsalariStaff)= [3000*(50000-20000)/(50000-10000)] = 2250. En el último ejemplo, tenemos un predicado compuesto, pero la segunda condición puede imple- mentarse utilizando el índice de clústering sobre branchNo (el caso S3 anterior), que sabemos que tiene un coste estimado de 3 bloques. Mientras extraemos cada tupla utilizando el índice de clús- tering, podemos comprobar si satisface la primera condición (position= 'Manager'). Sabemos que la cardinalidad estimada de la segunda condición es SCbranchNO(Staff)= 6. Si denominamos a esta relación intermedia T, podemos estimar el número de valores distintos de position en T, nDistinctposition(T),como: [(6 + 10)/3] = 6. Aplicando ahora la segunda condición, la cardinalidad estimada de la relación resultante será SCposition(T)= 6/6 = 1, que sería correcta si hubiera un único gerente por cada sucursal. 21.4.3 Operación de combinación (T = (R t><1F S)) Hemos mencionado al principio de este capítulo que una de las principales preocupaciones cuando se lanzó por primera vez comercialmente el modelo relacional era el rendimiento de las consultas. En particular, la ope- ración que más preocupación suscitaba era la operación de combinación que, a parte del producto cartesia~o, es la más costosa en términos de tiempo de procesamiento, por lo que será necesario garantizar que se pueda ejecutar de la forma más eficiente posible. Recuerde, de la Sección 4.1.3, que la operación de combinación Theta define una relación que contiene tuplas que satisfacen un predicado específico F dentro del producto cartesiano de dos relaciones, por ejemplo R y s. El predicado F es de la forma R.a e S.b, donde e puede ser uno de los operadores lógicos de comparación. Si el predicado sólo contiene el operador de igualdad (=), la co,binación será una equicombinación. Si la combinación implica todos los atributos comunes de R y S, se denomina combinación natural. En esta sección, vamos a examinar las principales estrategias para implemen- &r la operación de combinación: • combinación mediante bucle anidado por bloques; • combinación de bucle anidado indexada; • combinación mediante ordenación-mezcla; • combinación hash.
  23. 23. Capítulo 21 Procesamiento de consultas 597 Tabla 21.2. Resumen de las estimaciones de coste de E/R de las distintas estrategias para la operación de combinación. Estrategias Combinación mediante bucle anidado por bloques Combinación mediante bucle anidado indexado Combinación mediante ordenación-mezcla Combinación hash Coste nBlocks(R) + (nBlocks(R) * nBlocks(S)), si el búfer sólo tiene un bloque para R y S nBlocks(R) + [nBlocks(S)*(nBlocks(R)/(nBuffer - 2))], si hay (nBuffer - 2) bloques para R nBlocks(R) + nBlocks(S), si todos los bloques de R pueden leerse en el búfer de la base de datos Depende del método de indexación, por ejemplo: nBlocks(R) + nTuples(R)*(nLevelsA(I) + 1), si el atributo de combinación A en S es la clave principal nBlocks(R) + nTuples(R)*(nLevelsA(I) + [SCiR)IbFactor(R)]), para un índice de clús- tering 1 sobre el atributo A nBlocks(R)*[log2(nBlocks(R)] + nBlocks(S)*[logz(nBlocks(S)], para las ordenaciones nBlocks(R) + nBlocks(S), para las mezclas 3(nBlocks(R) + nBlocks(S», si el índice hash se almacena en memoria 2(nBlocks(R) + nBlocks(S))*[lognBlllTer_¡(nBlocks(S)) - 1] + nBlocks(R) + nBlocks(S), en caso contrario (3) Si ni A ni B son claves, podemos estimar la cardinalidad de la combinación como: El lector interesado puede encontrar un resumen más completo de las estrategias de combinación en Mishra y Eich (1992). Las estimaciones de coste para las diferentes estrategias aplicables a las operaciones de combinación se resumen en la Tabla 21.2. Comenzaremos estimando la cardinalidad de las operaciones de combinación. Estimación de la cardinalidad de la operación de combinación La cardinalidad del producto cartesiano de R y S, R x S, es simplemente: nTuples(R) * nTuples(S) Desafortunadamente, es mucho más difícil estimar la cardinalidad de cualquier combinación, ya que depende de la distribución de los valores de los atributos de combinación. En el caso peor, sabemos que la cardinalidad de la combinación no puede ser superior a la cardinalidad del producto cartesiano, por lo que: nTuples(T) ::; nTuples(R) * nTuples(S) Algunos sistemas utilizan esta cota superior, pero esta estimación es generalmente demasiado pesimista. Si volvemos a asumir una distribución uniforme de valores en ambas relaciones, podemos mejorar esta esti- mación para las equicombinaciones con un predicado (R.A = S.B) de la forma siguiente: (1) Si A es un atributo clave de R, entonces cada tupla de S sólo podrá ser combinada con una tupla de R. Por tanto, la cardinalidad de la equicombinación no puede ser superior a la cardinalidad de S: nTuples(T) ::; nTuples(S) el) De forma similar, si B es una clave de S, se cumplirá que: / nTuples(T)::; nTuples(R) / nTuples(T) = SCA(R)*nTuples(S)
  24. 24. 598 Sistemas de bases de datos o nTuples(T) = SCB(S)*nTuples(R) Para obtener la primera estimación, usamos el hecho de que para cualquier tupla s en s, podemos esperar como media SCA(R)tuplas con un determinado valor del atributo A y que este mismo número aparezca en la combinación. Multiplicando esto por el número de tuplas de s, se obtiene la primera de las estimaciones ante- riores. Para la segunda estimación procederíamos de forma similar. (1) Combinación mediante bucle anidado por bloques El algoritmo de combinación más simple es un bucle anidado que combine las dos relaciones entre sí, una tupla cada vez. El bucle externo recorre todas las tuplas de la relación R y el bucle interno recorre todas las tuplas de la segunda relación, S. Sin embargo, como sabemos que la unidad básica de lectura/escritura es el bloque de disco, podemos mejorar el algoritmo básico teniendo dos bucles adicionales que procesen los blo- ques, como se indica en el algoritmo resumido de la Figura 21.8. Puesto que cada bloque de R debe ser leído y cada bloque de S debe ser también leído para cada bloque de R, el coste estimado de esta solución será: nBlocks(R) + (nBlocks(R) * nBlocks(S)) Con esta estimación, el segundo término es fijo, pero el primer término podría variar dependiendo de cuál relación se elija para el bucle externo. Obviamente, deberemos elegir para el bucle externo la relación que ocupe el número más pequeño de bloques. Otra mejora de esta estrategia consiste en leer tantos bloques como sea posible de la relación más peque- ña, por ejemplo R, en el búfer de la base de datos, guardando un bloque para la relación interna y otro para la relación resultante. Si el búfer puede albergar nBuffer bloques, entonces deberemos leer (nBuffer - 2) bloques de R en el búfer cada vez y un bloque de S. El número total de bloques de R al que se accede seguirá siendo nBlocks(R), pero el número total de bloques de S leídos se reduce a aproximadamente [nBlocks(S)* (nBlocks(R)/(nBuffer - 2))]. Con esta técnica, la nueva estimación de costes será: nBlocks(R) + [nBlocks(S)*(nBlocks(R)/(nBuffer - 2))] Si podemos leer todos los bloques de R y el búfer, esto se reduce a: nBlocks(R) + nBlocks(S) // // Combinación mediante bucle anidado por bloques // Los bloques en ambos archivos están numerados secuencialmente a partir de l. 1/ Devuelve una tabla de resultados que contiene la combinación de R y S. 1/ for iblock = 1 to nBlocks(R) { 1/ bucle externo Rblock = read_block(R, iblock); for jblock = 1 to nBlocks(S) { 1/ bucle interno Sblock = read_block(S, jblock); fJr i = 1 to nTuples(Rblock) { // for j = 1 to nTuples(Sblock) { iE(Rblock.tuple[i]!Sblock.tuple[j] match join condition) then add them to result; } Figura 21.8. Algoritmo para la combinación mediante bucle anidado por bloques.
  25. 25. Capítulo 21 Procesamiento de consultas 599 Si los atributos de combinación en una equicombinación (o combinación natural) constituyen una clave de la relación interna, entonces el bucle interno puede terminar en cuanto se encuentre la primera corresponden- cia. (2) Combinación mediante bucle anidado indexado Si existe un índice (o función hash) sobre los atributos de combinación de la relación interna, podemos sus- tituir la ineficiente exploracíón del archivo por una búsqueda de índice. Para cada tupla en R, utilizamos el índice para extraer las tuplas correspondientes de s. El algoritmo de combinación por bucle animado indexa- do se esboza en la Figura 21.9. En aras a la claridad, utilizamos un algoritmo simplificado que procesa el bucle externo, de bloque en bloque. Sin embargo, como hemos indicado anteriormente, debemos leer tantos bloques de R en el búfer de base de datos como sea posible. Dejemos esta modificación del algoritmo como sea posi- ble. Dejamos esta modificación del algoritmo como ejercicio para el lector (véase el Ejercicio 21.19). Este algoritmo es mucho más eficiente para una combinación, evitándose con él la enumeración del pro- ducto cartesiano de R y s. El coste de explorar R es nBlocks(R), como antes. Sin embargo, el coste de extraer las tuplas correspondientes en S dependerá del tipo de índice y del número de tuplas correspondientes. Por ejemplo, si el atributo de combinación A de S es la clave principal, la estimación de coste se hará: nBlocks(R) + nTuples(R)*(nLevelsA(I) + 1) Si el atributo de combinación A en S es un índice de clústering, la estimación de coste será: nBlocks(R) + nTuples(R)*(nLevelsA(I) + [SCA(R)/bFactor(R)]) (3) Combinación mediante ordenación-mezcla Para las equicombinaciones, la combinación más eficiente se consigue cuando ambas relaciones están orde- nadas según los atributos de combinación. En este caso, podemos buscar las tuplas apropiadas de R y S mez- clando las dos relaciones. Si no están ordenadas, puede llevarse a cabo una etapa de preprocesamiento para ordenarlas. Puesto que las relaciones están ordenadas, las tuplas con el mismo valor del atributo de combina- ción estarán necesariamente en orden consecutivo. Si asumimos que la combinación es de tipo muchos a muchos, es decir, que puede haber muchas tuplas tanto de R como de S con el mismo valor de combinación, y si asumimos que de cada conjunto de tuplas con el mismo valor de combinación puede caber en el búfer de la base de datos, entonces cada bloque de cada relación sólo tendrá que ser leído una vez. Por tanto, la esti- mación de costes para la combinación mediante ordenación-mezcla es: // // Combinación mediante bucle anidado indexado de R y S utilizando A como atributo de combinación // Suponga que hay un índice 1 sobre el atributo A de la relación S y que // hay m entrada de Úldice 1[1], 1[2], ... , I[m] con el valor indexado de la tupla R[i].A // Los bloques de R están numerados secuencialmente a partir de 1. // Devuelve una tabla de resultados que contiene la combinación de R y S. // or iblock = 1 to nBlocks(R) { Rblock read_block(R, iblock); for i = 1 to nTuples(Rblock) { for j = 1 to m { if (Rblock.tuple[i].A = I[j]) then add corresponding tuples to result; Figura 21.9. Algoritmo para la combinación mediante bucle anidado indexado.
  26. 26. 600 Sistemas de bases de datos nBlocks(R) + nBlocks(S) Si es necesario ordenar una relación, por ejemplo R, tendríamos que añadir el coste de la ordenación, que podemos aproximar como: nBlocks(R)* [loglnBlocks(R))] En la Figura 21.10 se muestra un algoritmo resumido para la operación de combinación mediante ordena- ción-mezcla. (4) Combinación hash Para una combinación natural (o equicombinación) también puede utilizarse un algoritmo de combinación hash para calcular la combinación de dos relaciones R y S según el conjunto de atributos de combinación A. La idea que subyace a este algoritmo consiste en particionar las relaciones R y S utilizando alguna función hash que presente características de uniformidad y aleatoriedad. Cada partición equivalente para R y S debe contener el mismo valor de los atributos de combinación, aunque puede contener más de un valor. Por tanto, el algoritmo tiene que comprobar las particiones equivalentes para ver si tienen el mismo valor. Por ejemplo, // // Combinación mediante ordenación-mezcla de R y S según el atributo de combinación A // El algoritmo presupone que la combinación es de tipo muchos a muchos // Se omiten las lecturas por simplicidad // Primero se ordenan R y S (esto no es necesario si los archivos ya están ordenados según los atributos // de combinación) sort(R); sort(S); // Ahora se realiza la mezcla nextR = 1; nextS = 1; while (nextR <= nTuples(R) and nextS <= nTuples(S)) { join_value = R.tuples[nextR].A; // Se explora S hasta encontrar un valor inferior al valor actual de combinación while (S.tuples[nextS].A < join_value and nextS <= nTuples(S)) { nextS = nextS + 1; } // Puede que tengamos tuplas correspondientes de R y S. // Para cada tupla de S con el valor join_ value, hay que hacerla corresponder con cada tupla de R // que tenga el valor join_value. // (Se asume una combinación M:N) while (S.tuples[nextS].A = join_value and nextS <= nTuples(S)) { m = nextR; while (R.tuples[m].A = join_value and m <= nTuples(R)) { add matching tuples S.tuples[nextS] and R.tuples[m] to res~lt; m =m+ 1; nextS = nextS + 1; // Ya ~emos en~respondientes de R y S con el mismo valor join _value // Ahora localizamos la siguiente tupla de R con un valor diferente de combinación while (R.tuples[nextR].A = join_value and nextR <= nTuples(R)) { nextR = nextR + 1; Figura 21.10. Algoritmo para la combinación meOdianteordenación-mezcla.
  27. 27. Capítulo 21 Procesamiento de consultas 601 si la relación R se particiona en R¡, R2' ... , RM Y la relación S en SI' S2, ... , SMutilizando una función hash hQ, entonces si By e son atributos de R y S respectivamente y h(RB) *- h(s.e), entonces RB *- s.e. Sin embar- go, si h(RB) = h(S.e), esto no implica necesariamente que RB = s.e, ya que puede haber diferentes valores que se asignen al mismo valor hash. La segunda fase, denominadafase de comprobación, lee cada una de las particiones de R por turno y para cada una de ellas trata de combinar las tuplas de la partición con las tuplas de la partición de S equivalente. Si se utiliza una combinación de bucle anidado para la segunda fase, emplearemos la partición más pequeña como bucle externo, por ejemplo R¡.Leeremos la partición completa R¡en memoria y a continuación se leerá cada bloque de la parición S¡ equivalente y se usará cada tupla para comprobar si R¡contiene tuplas corres- pondientes. Para mejorar la eficiencia, resulta común construir en memoria una tabla hash para cada partición R¡utilizando una segunda función hash, diferente de la función hash empleada para el particionamiento. El algoritmo para la combinación hash se esboza en la Figura 21.11. Podemos estimar el coste de la combina- ción hash como: 3(nBlocks(R) + nBlocks(S» Aquí estamos teniendo en cuenta que hay que leer R y S para particionarlas, escribir cada partición en disco y luego leer cada una de las particiones de R y S de nuevo para encontrar las tuplas correspondientes. Esta estimación es aproximada y no tiene en cuenta los desbordamientos que tengan lugar en una partición. 11 11Algoritmo de combinación hash 11 Se omiten las lecturas por simplicidad. 11 11 Se comienza particionando R y S. for i = 1 to nTuples(R) { hash_ value = hash_function(R.tuple[i] .A); add tuple R.tuple[i].A to the R partition corresponding to hash value, hash_value; for j = 1 to nTuples(S) { hash_value = hash_function(S.tuple[j).A); add tuple S.tuple[j).A to the S partition corresponding to hash value, hash_value; 11 Ahora se ejecuta la fase de comprobación (correspondencia). for ihash = 1 to M { read R partition corresponding to hash value ihash; RP = Rpartition[ihash]; for i = 1 to max_tuples_in_R_partition(RP) { 11 Construir un índice hash en memoria utilizando la función hash _function2( ), diferente de hash _function( ) new_hash = hash_function2(RP.tuple[i].A); add new_hash to in-memory hash index; 11 Exployar la partición S en busca de tuplas de R correspondientes = Spartition[ihash]; for j = 1 to max_tuples_in_S_partition(SP) { read S and probe hash table using hash_function2(SP.tuple[j].A); add all matching tuples to output; clear hash table to prepare for next partition; Figura 21.11. Algoritmo para una combinación hash.
  28. 28. 602 Sistemas de bases de datos También presupone que el índice hash se pueda almacenar en memoria. Si no es así, el particionamiento de las relaciones no puede realizarse en una pasada y será necesario utilizar un algoritmo de particionamiento recursivo. En este caso, se puede demostrar que la estimación de costes es: 2(nBlocks(R) + nBlocks(S))*[lognBuffer_¡(nBlocks(S)) - 1] + nBlocks(R) + nBlocks(S) El lector interesado puede hallar una explicación más completa de los algoritmo s de combinación hash en Valduriez y Gardarin (1984), DeWitt el al. (1984) y DeWitt y Gerber (1985). En Shapiro (1986) se describe una serie de extensiones, incluyendo la combinación hash híbrida, y un estudio más reciente realizado por Da- vison y Graefe (1994) describe técnicas de combinación hash que pueden adaptarse a la memoria disponible. I Ejemplo 21.5 Estimación de coste para una operación de combinación Para los propósitos de este ejemplo, hacemos las siguientes suposiciones: • Hay índices hash separados sin desbordamiento para los atributos de clave principal staftNode 8taft y branchNo de Branch. • Hay 100 bloques de búfer de base de datos. • El catálogo del sistema contiene las siguientes estadísticas: nTuples(Staff) = 6000= 30=}nBlocks(Staff) = 200= 500= 50=}nBlocks(Branch) = 10= 100.000 ForRent) = 50=}nBlocks(PropertyForRent) = 2000 En la Tabla 21.3 se muestra una comparación de las anteriores cuatro estrategias para las dos combi- naciones siguientes: 11: 8taft [><J staffNo PropertyForRent J2: Branch [><J b,anchNo PropertyForRent Tabla 21.3. Coste de E/S estimado para las operaciones de combinación del Ejemplo 21.5. Estrategias J1J2Comentarios 400,20020,010El búfer sólo tiene un bloque de R y 84282NIDa(nBuffer --'-2) bloques para R2010Todos los bloques R caben en el búfer de la base de datos 6200510Claves hash Combinación mediante 25,80024,240Desordenadas 22002010Ordenadas 66006030La tabla hash cabe en memoria aTodos los bloques de R pueden leerse en el búfer. bNo se pueden leer todos los bloques de R en el búfer.
  29. 29. Capítulo 21 Procesamiento de consultas 603 En ambos casos, sabemos que la cardinalidad de la relación resultante no puede ser mayor que la car- dinalidad de la primera relación, ya que estamos realizando una combinación sobre la clave de la pri- mera relación. Observe que ninguna de las estrategias es la mejor para ambas operaciones de combinación. La combinación mediante ordenación-mezcla funciona mejor para la primera combina- ción, dando por supuesto que ambas relaciones ya están ordenadas. Para la segunda combinación la mejor estrategia es la de combinación mediante bucle anidado indexado. 21.4.4 Operación de proyección (5 = TIA" Au """,AJR)) La operación de proyección es también una operación unaria que define una relación S que contiene un sub- conjunto vertical de una relación R, extrayendo los valores de los atributos especificados y eliminando los duplicados. Por tanto, para implementar una proyección, debemos llevar a cabo los siguientes pasos: (l) eliminar los atributos no requeridos; (2) eliminar cualesquiera tuplas duplicadas que hayan resultado del paso anterior. El segundo paso es el más problemático, aunque sólo es necesario si los atributos de proyección no inclu- yen ninguna clave de la relación. Hay dos técnicas principales para eliminar los duplicados: la ordenación y las funciones hash. Antes de considerar estas dos técnicas, estimemos primero la cardinalidad de la relación resultante. Estimación de la cardinalidad de la operación de proyección Cuando la proyección contiene un atributo clave, como no se requerirá la eliminación de duplicados, la car- dinalidad de la proyección será: nTuples(S) = nTuples(R) Si la proyección consiste en un único atributo no clave (S = IIA(R)), podemos estimar la cardinalidad de la proyección como: nTuples(S) = SCA(R) En caso contrario, si asumimos que la relación es un producto cartesiano de los valores de sus atributos, lo que en general es poco realista, podemos estimar la cardinalidad como: m nTuples(s) :::;min(nTuples(R), II nDistinct A(R))i=! I (1) Eliminación de los duplicados mediante ordenación El objetivo de esta técnica es ordenar las tuplas de la relación reducida utilizando todos los atributos restan- tes como clave de ordenación. Esto tiene el efecto de ordenar las tuplas de tal forma que los duplicados serán adyacentes y podrán eliminarse fácilmente a continuación. Para eliminar los atributos no deseados, tenemos que leer todas las tuplas de R y copiar los atributos requeridos a una relación temporal, lo que representa un coste nBlocks(R). El coste estimado de la ordenación es nBlocks(R)*[10g2(nBlocks(R))], por lo que el coste total será: nBlocks(R) + nBlocks(R)*[log2(nBlocks(R))] En la Figura 21.12 se muestra un resumen del algoritmo correspondiente a esta técnica.
  30. 30. 604 Sistemas de bases de datos 11 11 Proyección mediante ordenación 11 Suponemos que se está proyectando la relación R sobre los atributos aJ, a2, ... , 3m. 11 Devuelve la relación resultante S 11 11 Primero, se eliminan los atributos no deseados. for iblock = 1 to nBlocks(R) { block = read_block(R, iblock); for i = 1 to nTuples(block) { copy block.tuple[i].a¡, block.tuple[i].a2' ... , block.tuple[i].am, to output T 11 Ahora se ordena T en caso necesario. if {al' a2' ... , ami contains a key then S =T; else { sort(T); 11 Finalmente, se eliminan los duplicados. i= 1; j = 2; while (i <= nTuples(T)) { output T[i] to S; 11 Saltar los duplicados de esta tupla, si es que existen. while (T[i] = T[j]) { j = j + 1; i=j; j = i+ 1; Figura 21.12. Algoritmo de proyección mediante ordenación. (2) Eliminación de duplicados mediante funciones hash La técnica de las funciones hash puede ser útil si tenemos un gran número de bloques de búfer en relación con el número de bloques de R. Este método tiene dos fases: particionamiento y eliminación de duplicados. En la fase de particionamiento, asignamos un bloque de búfer para leer la relación R y (nBuffer - 1) blo- ques de búfer para la salida. Para cada tupla de R, eliminamos los atributos no deseados y luego aplicamos una función hash h a la combinación de los atributos restantes, escribiendo la tupla reducida en el valor hash. La función hash h debe regirse de modo tal que las tuplas estén uniformemente distribuidas entre las (nBuffer - 1) particiones. Dos tuplas que pertenezcan a particiones distintas no serán, evidentemente duplicados, ya que tienen diferentes valores hash, lo que reduce el área de búsqueda para eliminación de duplicados a las par- ticiones individuales. La segunda fase se lleva a cabo de la forma siguiente: • Se lee por turno cada una de las (nBuffer - 1) particiones. • Se aplica una segunda función hash (diferente de la anterior) h20 a cada tupla a medida que se la lee. • Se inserta el valor hash calculado en una tabla hash que se conserva en memoria. • Si la tupla tiene el mismo valor hash que alguna otra tupla, se comprueba si las dos son iguales y se elimina la nueva en caso de tratarse de un duplicado. • Una vez procesada una partición, se escriben las tuplas de la tabla hash en el archivo de resultados.
  31. 31. Capítulo 21 Procesamiento de consultas 605 Si el número de bloques requeridos para la tabla temporal resultante de la proyección de R antes de la eli- minación de duplicados es nb, el coste estimado será: nBlocks(R) + nb Esto no incluye la escritura de la relación resultante y presupone que la aplicación de la función hash no requiere particiones de desbordamiento. Dejamos el desarrollo de este algoritmo como ejercicio para el lector. 21.4.5 Operaciones de conjuntos de álgebra relacional (T = R u S, T = R ( S, T = R - S) Las operaciones de conjuntos binarias de unión (R u s), intersección (R n S) y diferencia de conjuntos (R - S) sólo se aplican a las relaciones que sean compatibles con respecto a la unión (véase la Sección 4.1.2). Podemos implementar estas operaciones ordenando primero ambas relaciones con respecto a los mismos atri- butos y luego explorando cada una de las relaciones ordenadas una vez para obtener el resultado deseado. En el caso de la unión, introduciremos en el resultado todas las tuplas que aparezcan en alguna de las dos rela- ciones originales, eliminando los duplicados según sea necesario. En el caso de la intersección, sólo incluire- mos en el resultado aquellas tuplas que aparezcan en ambas relaciones. En el caso de la diferencia de conjun- tos, examinaremos cada tupla de R y la incluiremos en el resultado sólo si no tiene ninguna tupla correspondiente en s. Para todas estas operaciones, podríamos desarrollar un algoritmo empleando el algorit- mo de combinación mediante ordenación-mezcla como base. El coste estimado en todos los casos es simple- mente: nBlocks(R) + nBlocks(S) + nBlocks(R)*[logz(nBlocks(R))] + nBlocks(S)*[logz(nBlocks(S))] También podríamos utilizar un algoritmo hash para implementar estas operaciones. Por ejemplo, para la unión podríamos construir un índice hash en memoria para R y luego añadir las tuplas de S al índice hash sólo si no están ya presentes. Al final de esta fase añadiríamos las tuplas del índice hash al resultado. Estimación de la cardinalidad de las operaciones de conjuntos De nuevo, puesto que los duplicados se eliminan al realizar la operación de unión, generalmente es bastante dificil estimar la cardinalidad de la operación, pero podemos dar sendos límites inferior y superior, que serán: max(nTuples(R), nTuples(S)) :5 nTuples(T) :5 nTuples(R) + nTuples(S) Para la diferencia de conjuntos, también podemos dar unos límites superior e inferior: o :5 nTuples(T) :5 nTuples(R) Considere la siguiente consulta SQL, que permite calcular el salario medio de los empleados: SELECT AVG(salary) FROM Staff; Esta consulta utiliza la función de agregación AVG. Para implementar esta consulta, podríamos explorar la relación Staff completa y llevar la cuenta del número de tuplas leídas y de la suma de todos los salarios. Al completar la operación, resulta fácil calcular la media a partir de estos dos valores de totalización. Ahora considere la siguiente consulta SQL, que calcula el salario medio de los empleados en cada su- cursal: SELECT AVG(salary) FROM Staff GROUP BY branchNo; De nuevo, esta consulta utiliza la función de agregación AVG pero, en este caso, en conjunción con una cláusula de agrupación. Para las consultas de agrupación, podemos utilizar algoritmos de ordenación o de
  32. 32. 606 Sistemas de bases de datos hash de forma similar para eliminar los duplicados. Podemos estimar la cardinalidad de la relación resultan- te en presencia de una agrupación utilizando las estimaciones que hemos calculado anteriormente para las operaciones de selección. Dejamos esto como ejercicio para el lector. 21.5 Numeración de las estrategias de ejecución alternativas Un aspecto fundamental para garantizar la eficiencia del proceso de optimización de consultas es el espacio de búsqueda de posibles estrategias de ejecución y el algoritmo de numeración que se utilice para explorar este espacio en búsqueda de una estrategia óptima. Para una consulta dada, este espacio puede ser extrema- damente grande. Por ejemplo, para una consulta que esté compuesta de tres combinaciones sobre las relacio- nes R, S Y T hay 12 diferentes ordenaciones posibles de combinación: RM(SMT) SM(RMT) TM(RMS) RM(TMS) SM(TMR) TM(SMR) (SMT)MR (RMT)MS (RMS)MT (TMS)MR (TMR)MS (SMR)MT En general, con n relaciones, hay (2(n - l))!/(n - l)! ordenaciones diferentes de las combinaciones. Si n es pequeña, este número es manejable; sin embargo, a medida que se incrementa n, este número se hace extre- madamente grande. Por ejemplo, si n = 4 el número de posibilidades es igual a 120; si n = 6 ese número es de 30.240; si n = 8, el número es superior a 17 millones y con n = 10, supera los 176.000 millones. Para agra- var todavía más el problema, el optimizador puede también soportar diferentes métodos de selección (por ejemplo, búsqueda lineal o búsqueda basada en índices) y métodos de combinación (por ejemplo, combina- ción mediante ordenación-mezcla, combinación hash, etc.). En esta sección, vamos a ver cómo puede redu- cirse el espacio de búsqueda y cómo se lo puede procesar de manera eficiente. Vamos a examinar primero dos cuestiones que tienen relevancia para nuestras explicaciones: el concepto de pipelining y los árboles lineales. 21.5.1 Pipelining En esta sección vamos a explicar otro concepto adicional que a veces se utiliza para mejorar las prestacio- nes de las consultas, el concepto de pipelining (algunas veces denominado procesamiento en cadena o pro- cesamiento de flujos). En los análisis que hemos realizado hasta ahora, hemos dado por supuesto que los resultados de las operaciones intermedias de álgebra relacional se escribían temporalmente en el disco. Este proceso se conoce con el nombre de materialización: la salida de una operación se almacena en una rela- ción temporal para ser procesada por la siguiente operación. Una técnica alternativa consiste en procesar en cadena los resultados de las distintas operaciones sin crear una relación temporal para almacenar el resulta- do intermedio. Obviamente, con esta técnica de pipelining podemos ahorramos el coste de crear relaciones temporales y volver a leer los resultados. Por ejemplo, al final de la Sección 21.4.2, hemos hablado de la implementación de la operación de selec- ción cuando el predicado era compuesto, como por ejemplo en: cr position='Managcr' Á salarY>2oo00(Staff) Si asumimos que hay un índice sobre el atributo salary, podríamos utilizar la regla de conexión en casca- da de operaciones de selección para transformar esta selección en dos operaciones: (JPOSitiOn=<Manager'( (Jsalary>2oo00(Staff)) Ahora, podemos utilizar el índice para procesar de manera eficiente la primera selección sobre salary, almacenar el resultado en una relación temporal y luego aplicar la segunda selección a la relación temporal. La técnica de procesamiento en cadena nos evita tener que crear la relación temporal y aplica en su lugar la segunda selección a cada tupla del resultado de la primera selección a medida que la generamos, añadiendo las tuplas que cumplan los criterios de la segunda operación al resultado final.
  33. 33. Capítulo 21 Procesamiento de consultas 607 Por regla general, una cadena de procesamiento (pipelining) se implementa como un proceso separado o área de procesamiento dentro del SGBD. Cada cadena de procesamiento toma un flujo continuo de tuplas como entrada y crea un flujo de tuplas como salida. Es necesario crear un búfer para cada pareja de operacio- nes adyacentes con el fin de almacenar las tuplas que están siendo pasadas de la primera operación a la segun- da. Una desventaja de la técnica de pipelining es que las entradas necesarias para las distintas operaciones no necesariamente tienen que estar disponibles simultáneamente para su procesamiento. Esto puede restringir la elección de algoritmos. Por ejemplo, si tenemos una operación de combinación y las tuplas de entrada a la cadena de procesamiento no están ordenadas según los atributos de combinación, no podremos usil[ el algo- ritmo estándar de combinación mediante ordenación-mezcla. De todos modos, son muchas las oportunidades de aplicación de la técnica de pipelining en las estrategias de ejecución. 21.5.2 Árboles lineales Todos los árboles de álgebra relacional que hemos creado en las secciones anteriores en este capítulo son de la forma que se muestra en la Figura 21.13(a). Este tipo de árbol de álgebra relacional se denomina árbol (de combinación) de profundidad izquierda. El término hace referencia al modo en que las operaciones se com- binan para ejecutar la consulta: por ejemplo, sólo se permite que el lado izquierdo de una combinación sea el resultado de otra combinación anterior y de aquí el nombre de árbol de profundidad izquierda. Para un algo- ritmo de combinación, el nodo hijo de la izquierda es la relación externa y el nodo derecho es la relación inter- na. Otros tipos posibles de árbol son el árbol de profundidad derecha, mostrado en la Figura 21.13(b) y el arbusto, mostrado en la Figura 21.13(d) (Graefe y DeWitt, 1987). Los arbustos también se denominan árbo- les no lineales, mientras que los árboles de profundidad izquierda y profundidad derecha se conocen con el nombre de árboles lineales. La Figura 21. 13(c) es un ejemplo de otro árbollíneal que no es ni de profundi- dad izquierda ni de profundidad derecha. Con los árboles lineales, la relación en uno de los lados en cada operador es siempre una relación base. Sin embargo, como necesitamos examinar la relación interna completa para cada tupla de la relación externa, "" "" / /"" D D"" /"" e e"" /B AB (b) "" DeB /~"" "" / /ABA /"" D /"" /e (e) (d) Figura 21.13. (a) Árbol de profundidad izquierda; (b) árbol de profundidad derecha; (c) otro árbol lineal; (d) arbusto (no lineal).
  34. 34. (4) IndexScan(R, A): (3) IndexScan(R, P): (1) TableScan(R): (2) SortScan(R, L): 608 Sistemas de bases de datos las relaciones internas deben siempre estar materializadas. Esto es lo que hace atractivos a los árboles de pro- fundidad izquierda, ya que las relaciones internas son siempre relaciones base (y por tanto están ya materia- lizadas). Los árboles de profundidad izquierda tienen las ventajas de reducir el espacio de búsqueda de la estrate- gia óptima y de permitir, por tanto, que el optimizador de consultas se base en técnicas de procesamiento diná- mico, como veremos en breve. Su principal desventaja es que, al reducir el espacio de búsqueda, no se tomen en consideración muchas estrategias de ejecución alternativas, algunas de las cuales pueden tener un coste inferior al que se haya podido determinar utilizando el árbol lineal. Los árboles de profundidad izquierda per- miten la generación de todas las estrategias completamente pipelinizadas, es decir, estrategias en las que todas las combinaciones se evalúan mediante la técnica de pipelining. 21.5.3 Operadores físicos y estrategias de ejecución El término operador físico se utiliza en ocasiones para referirse a un algoritmo específico que implemente una operación lógica de base de datos, como, por ejemplo, una selección o una combinación. Por ejemplo, podemos utilizar el operador físico de combinación mediante relación-mezcla para implementar la operación de combinación de álgebra relacional. Sustituir las operaciones lógicas en un árbol de álgebra relacional para operadores físicos produce una estrategia de ejecución (también denominada plan de evaluación de la con- sulta o plan de acceso) para la consulta. La Figura 21.14 muestra un árbol de álgebra relacional y una estra- tegia de ejecución correspondiente. Aunque los SGBD tienen sus propias implementaciones internas, podemos considerar los siguientes ope- radores abstractos para implementar las funciones correspondientes a las hojas del árbol: exploración de tabla. Todos los bloques de R se leen en un orden arbitrario. exploración ordenada. Las tuplas de R se leen por orden, ordenadas de acuerdo con los atributos enumerados en la lista L. exploración indexada. P es un predicado de la forma A e c, donde A es un atribu- to de R, e es uno de los operadores normales de comparación y c es un valor cons- tante. La forma de acceder a las tuplas de R es mediante un índice sobre el atri- buto A. exploración indexada. A es un atributo de R. Se extrae la relación completa R uti- lizando el índice definido sobre el atributo A. Es similar a TableScan, pero puede ser más eficiente bajo ciertas condiciones (por ejemplo, si R no utiliza clústeres). Además, el SGBD soporta usualmente una interfaz iteradora uniforme, ocultando así los detalles inter- nos de implementación de cada operador. La interfaz iteradora está compuesta de las siguientes tres fun- ClOnes: 7~""s.branchNo=b.branchNo PropertyForRent /~ O'~T-""" """T- Staff (a) Staff Branch Combinación hash ""s.staffNo=p.staffNo /, B+-tree sobreCombinación mediante / ~StaffNobucle anidado indexado 00" plp,!;,I'g 7~ Pmp'rty,,,",,1 Operación pipelining 0s.position='Manager" 0b.city='London' Operación utilizando el índice r r pipelining hash sobre position utilizando el índice hash Branch sobre city (b) Figura 21.14. (a) Ejemplo de árbol de álgebra relacional; (b) una estrategia de ejecución correspondiente.

×