metodos de optimizacion de consultas para el lenguaje ... - Blearning

UNIVERSIDAD DE SANTIAGO DE CHILE
FACULTAD DE CIENCIAS
DEPARTAMENTO DE MATEMATICA Y CIENCIA DE LA COMPUTACION
METODOS DE OPTIMIZACION DE CONSULTAS PARA EL
LENGUAJE SQL.
MARIO CISTERNA NEIRA
SANTIAGO - CHILE
2002

TABLA DE CONTENIDOS
DEFINICIÓN DEL PROBLEMA...........................................................................4
ESTRUCTURA DEL LIBRO..................................................................................6
CAPÍTULO 1. MODELO DE DATOS RELACIONAL.....................................8
1.1. INTRODUCCIÓN. ................................................................................................8
1.2. IMPLEMENTACIONES RELACIONALES................................................................9
1.3. CONCEPTOS GENERALES. ................................................................................10
CAPÍTULO 2. LENGUAJES DE CONSULTA PARA EL MODELO
RELACIONAL. ..........................................................................16
2.1. INTRODUCCIÓN. ..............................................................................................16
2.2. ALGEBRA RELACIONAL. ..................................................................................17
2.3. CÁLCULO RELACIONAL DE TUPLAS. ................................................................23
2.4. SQL COMO LENGUAJE DE CONSULTAS RELACIONALES. ..................................27
CAPÍTULO 3. SISTEMAS DE GESTIÓN DE BASES DE DATOS
RELACIONALES. .....................................................................31
3.1. INTRODUCCIÓN. ..............................................................................................31
3.2. TRANSACCIONES, CONCURRENCIA Y RECUPERACIÓN......................................33
3.3. TIPOS DE SGBD..............................................................................................40
CAPÍTULO 4. INTRODUCCIÓN AL PROCESAMIENTO DE
CONSULTAS, EL ENFOQUE DE SYSTEM R....................48
4.1. INTRODUCCIÓN. ..............................................................................................48
4.2. EL OPTIMIZADOR DE SYSTEM R. .....................................................................51
CAPÍTULO 5. OPTIMIZACIÓN DE CONSULTAS, FUNDAMENTO
TEÓRICO. ..................................................................................69
5.1. INTRODUCCIÓN. ..............................................................................................69
5.2. INFORMACIÓN DEL CATÁLOGO........................................................................70
5.3. MEDIDAS DE COSTO. .......................................................................................72
5.4. EVALUACIÓN DE EXPRESIONES. ......................................................................95
5.5. ORDENES DE JOIN. ........................................................................................107
5.6. ELECCIÓN DE LOS PLANES DE EVALUACIÓN. .................................................123
CAPÍTULO 6. EL OPTIMIZADOR DE CONSULTAS DE SYBASE
ADAPTIVE SERVER ENTERPRISE, UN EJEMPLO
PRÁCTICO...............................................................................128
6.1. INTRODUCCIÓN. ............................................................................................128
6.2. ANÁLISIS DE LA CONSULTA. .........................................................................129
1

6.3. SELECCIÓN DE ÍNDICES. ................................................................................135
6.4. SELECCIÓN DE LOS ORDENES DE JOIN............................................................137
6.5. USO DE TABLAS TEMPORALES.......................................................................147
6.6. SELECCIÓN DEL PLAN....................................................................................148
6.7. RESUMEN......................................................................................................152
RESUMEN Y CONCLUSIONES........................................................................154
RESUMEN.............................................................................................................154
CONCLUSIONES....................................................................................................157
BIBLIOGRAFÍA...................................................................................................160
APÉNDICES. 162
A. SINTAXIS DE SQL..................................................................162
A.1. DEFINICIONES DE DATOS EN SQL.................................................................162
A.2. MANIPULACIÓN DE DATOS EN SQL..............................................................167
B. INDICES B+..............................................................................178
C. MÉTODOS DE ALMACENAMIENTO DE DATOS...........181
C.1. DISCOS MAGNÉTICOS...................................................................................182
2

TABLA DE TABLAS
TABLA 2-1 - OPERADORES DEL ALGEBRA RELACIONAL ........................................................17
TABLA 4-1 - FACTORES DE SELECCIÓN PARA CAMINOS DE ACCESO A RELACIONES SIMPLES.58
TABLA 4-2 - FÓRMULAS DE COSTO PARA CAMINOS DE ACCESO A RELACIONES SIMPLES........61
TABLA 5-1 - INFORMACIÓN DEL CATÁLOGO PARA RELACIONES SIMPLES. .............................71
TABLA 5-2 - INFORMACIÓN DEL CATÁLOGO PARA ÍNDICES DE RELACIONES..........................72
TABLA 5-3 - REGLAS DE EQUIVALENCIA PARA EXPRESIONES RELACIONALES......................104
TABLA A-1 - TIPOS DE DATOS DE SQL................................................................................164
TABLA DE ALGORITMOS
ALGORITMO 5-1 - JOIN EN BUCLES ANIDADOS.......................................................................83
ALGORITMO 5-2 - JOIN EN BUCLES ANIDADOS POR BLOQUES.................................................84
ALGORITMO 5-3 - JOIN POR MEZCLA. ....................................................................................86
ALGORITMO 5-4 - JOIN POR ASOCIACIÓN...............................................................................89
ALGORITMO 5-5 - JOIN ENCAUZADO......................................................................................99
TABLA DE FIGURAS
FIGURA 2-1 - ESQUEMA DE RELACIONES DE EJEMPLO...........................................................18
FIGURA 4-1 - PASOS EN EL PROCESAMIENTO DE UNA CONSULTA SQL...................................50
FIGURA 5-1 - COMPORTAMIENTO DEL ALGORITMO DE SIMULACIÓN DE COCCIÓN ..............116
FIGURA 5-2 - EJEMPLO DEL PRINCIPIO DE SELECCIÓN PARA EL ALGORITMO GENÉTICO PARA LA
OPTIMIZACIÓN DE ORDENES DE JOIN ............................................................................120
FIGURA 5-3 - EJEMPLO DEL PRINCIPIO DE COMBINACIÓN PARA EL ALGORITMO GENÉTICO
PARA LA OPTIMIZACIÓN DE ORDENES DE JOIN..............................................................121
FIGURA 5-4 - UN PLAN DE EVALUACIÓN DE EJEMPLO ..........................................................123
3

Definición del problema.
En Bases de datos relacionales el lenguaje de consultas SQL es lo más
utilizado por el común de los programadores y desarrolladores para obtener
información desde la Base de datos. La complejidad que pueden alcanzar algunas
consultas puede ser tal, que el diseño de una consulta puede tomar un tiempo
considerable, obteniendo no siempre una respuesta optima.
Dada una consulta, generalmente existen varias maneras de calcular la
respuesta. En SQL una consulta puede expresarse de distintas maneras, todas
ellas diferentes, como lo expresa C. Date en [Date98], cada una de las formas
sugiere una estrategia para encontrar la respuesta y por lo tanto algunas pueden
ser más optimas que otras.
El problema que se plantea entonces es, el encontrar la manera más
apropiada de resolver la consulta, sin que, el proceso de determinar este resultado
exceda un tiempo razonable y un gasto de recursos adicional.
Como respuesta a este problema, nace el concepto de optimización de
consultas. El objetivo principal de este proceso es, encontrar o bien la mejor
alternativa para solucionar la consulta, o de lo contrario, la alternativa que mejor
cumpla las características de eficiencia, entre las estudiadas, cuando no sea
posible estudiarlas todas.
Este proceso tiene que ser lo bastante rápido como para que sea
conveniente para el motor efectuar este cálculo sin afectar el rendimiento en la
construcción del resultado de la consulta.
4

Uno de los primeros estudios relativo a optimización de consultas para SQL
se hizo sobre el prototipo de un motor de base de datos relacional desarrollado por
IBM llamado “system R”, en los laboratorios de San José (California) a mediados
de la década de 1970. Este estudio proporcionaría las bases para la construcción
de la mayoría de los optimizadores para motores de base de datos relacionales de
orden comercial en la actualidad.
Entre otras cosas, este estudio propone la descomposición del
procesamiento de una consulta SQL en 4 fases: el análisis sintáctico (parsing), la
optimización, la generación de código y la ejecución de la consulta.
Se entiende entonces como proceso de optimización de consultas al
conjunto de técnicas, algoritmos y reglas que le permiten, al motor de base de
datos, elegir una alternativa entre varias con la cual pueda rescatar los datos de la
manera más optima.
El objetivo principal de este trabajo es Investigar este proceso y develarlo,
con la finalidad de que deje de ser algo desconocido para quienes interactúan con
Sistemas de Gestión de bases de datos relacionales.
La idea de este trabajo es que le sirva de apoyo tanto al diseñador de base
de datos relacionales, como a los desarrolladores que ejecutan consultas,
quienes, al entender mas de cerca el proceso de optimización de consultas
puedan evitar los errores más comunes, que a la larga llevan muchas veces al
fracaso en la construcción e implementación de sistemas de Información sobre
bases de datos relacionales.
5

Estructura del libro.
El Capítulo 1 introduce el modelo relacional de datos, el cual es la base
para el desarrollo de este trabajo, se presentará un marco de trabajo teórico sobre
el cual desarrollar el problema.
El Capítulo 2 trata sobre los distintos lenguajes para recuperación de datos
que existen para el modelo relacional, otorgando un énfasis especial sobre el
álgebra relacional y el cálculo relacional de tuplas, fundamentales para la
presentación de SQL como lenguaje de consultas.
El procesamiento de una consulta SQL dependerá en gran medida de la
implemetación relacional en la cual se ejecute, por lo tanto, el Capítulo 3 presenta
la conceptualización sobre Sistemas de Gestión de base de datos relacionales
(SGBD), a modo de explicación de cómo se logran implementaciones relacionales
del modelo, en este capítulo se explicarán brevemente conceptos tales como
transacciones, concurrencia y repcuperación de datos.
El Capítulo 4 Introduce al tema del procesamiento de consultas, para tales
efectos se presenta el estudio del optimizador de consultas de System R. Este
SGBD se considera una de las primeras implementaciones relacionales y motivo
de investigación tanto como fundamento y guia para la construcción de la mayoría
de los optimizadores relacionales comerciales actuales. El estudio de este caso
introduce conceptos como medidas de costo, caminos de acceso y utilización de
heurísticas dentro de un optimizador.
El Capítulo 5 desarrolla el fundamento teórico del libro, estudia en profundidad el
proceso de optimización de consultas SQL. Este capítulo explica como los
optimizadores determinan sus medidas de costo y en que información se basan
6

para estos cálculos; como se produce la evaluación de expresiones y como
determinar los ordenes de Join.
Dado que este trabajo no tiene asociado un desarrollo práctico del tema, el
Capítulo 6 presenta un ejemplo de cómo trabaja en la práctica un optimizador de
consultas para un SGBD comercial, para tales efectos se presenta el caso de
Sybase Adaptive Server Enterprise (ASE). Este capítulo llevará al lector a
entender que existe una correspondencia entre lo presentado en el Capítulo 4, lo
explicado en el Capítulo 5, y como se logra esto en la práctica.
7

Capítulo 1. Modelo de Datos Relacional
1.1. Introducción.
El objetivo de todo modelo de datos es proveer conceptos y estructuras de
datos capaces de interpretar los aspectos relevantes que existen en una
determinada parcela del mundo real. Esto se logra mediante un conjunto bien
definido de estructuras, operadores y restricciones que actúan sobre dichas
estructuras.
El Modelo Relacional corresponde a un enfoque científico y tecnológico que
surgió entre la década de 1960 y la década de 1970. Su estrategia de abstracción
se basa en hacer una representación tabular de los objetos y sus asociaciones
entre ellos. Sin embargo, este enfoque tabular que se sustenta en la teoría de las
relaciones matemáticas no permite diferenciar entre los tipos de entidad y los tipos
de relación, lo que constituye una pérdida semántica significativa con respecto a
su antecesor, el modelo de Entidad-Relación.
Por otra parte, la representación tabular de la información y los mecanismos
utilizados para establecer vínculos entre las tablas que se representan de objetos
relacionados han contribuido enormemente a su masificación, a tal punto que en la
actualidad, el Modelo Relacional es un estándar de hecho en los que se
construyen los SGBD 1 comerciales.
Es importante notar que el modelo relacional es un modelo basado en el
papel y que no todas sus características son implementadas en los SGBD, como a
1 SGBD : Sistemas de Gestión de Bases de datos.
8

su vez muchas implementaciones tienen más características que las que
contempla el modelo.
1.2. Implementaciones Relacionales.
Una implementación del modelo relacional debe soportar todas las
facilidades prescritas por el modelo, sin embargo existen algunas características a
las cuales no hace referencia el modelo de datos relacional, dentro de estas se
incluyen operaciones aritméticas, funciones agregadas, actualizaciones explícitas,
modificaciones, eliminaciones, etc. Para esto el Modelo relacional incluye un
núcleo de funciones que deben ser incorporadas en un SGBD.
Sin embargo existe una distinción entre las implementaciones consideradas
relacionales y los que no lo son en su totalidad (Pseudo-Relacionales). Estas
últimas se pueden clasificar como sigue:
• Tabular : Un SGBD Tabular es una implementación de una Base de datos
relacional que soporta las estructuras de datos tabulares (tablas), pero no
los operadores de nivel de conjuntos.
• Relacional Mínimo: Un SGBD Mínimamente relacional es una
implementación de bases de datos relacionales que soporta sólo tablas, los
operadores de selección, proyección y el operador JOIN (pero no los otros
operadores relacionales).
• Relacional Completo: Un SGBD Completamente relacional es una
implementación de bases de datos relacionales que soporta sólo tablas y
todos los operadores del álgebra relacional.
9

• Relacional : Un SGBD Relacional es una implementación de Bases de
datos relacionales que soporta todos los aspectos del modelo relacional
incluidos los dominios y las dos reglas generales de Integridad (que se
explicarán más adelante, en el punto 1.3.12).
1.3. Conceptos generales.
1.3.1. Datos Atómicos
Todos los valores de datos en el modelo relacional son atómicos. Esto
implica que cada posición de fila-columna en cada tabla siempre tiene sólo un
dato, y nunca un conjunto de valores.
1.3.2. Tuplas
Una tupla de una relación o de una tabla corresponde a una fila de aquella
tabla. Las tuplas están comúnmente desordenadas puesto que matemáticamente
una relación se define como un conjunto y no como una lista. No Existen tuplas
duplicadas en una relación o tabla dado el hecho de que una relación es un
conjunto y los conjuntos por definición no permiten elementos duplicados. Un
corolario importante en este punto es que la llave primaria siempre existe dada la
condición de unicidad de las tuplas, por lo tanto, como mínimo la combinación de
todos los atributos de una tabla puede servir para la conformación de la llave
primaria, sin embargo usualmente no es necesario incluir todos los atributos,
comúnmente algunas combinaciones mínimas son suficientes.
1.3.3. Dominios.
Un dominio se define como un conjunto de valores del mismo tipo. Por
ejemplo el dominio que corresponde a la edad de una persona (en años) se puede
10

definir como el conjunto de todos los valores de números posibles de edades, por
ejemplo desde 0 hasta 120. Siempre y cuando dos atributos tomen sus valores del
mismo dominio estos pueden ser comparados aunque pertenezcan a distintas
tablas. Los dominios son especificados como parte de la definición de los datos,
estos pueden ser simples o compuestos. Un dominio compuesto se define como
el producto de alguna colección de dominios simples. Por ejemplo la fecha es
producto de el día, el mes y el año, donde el mes es el dominio simple de 1 a 12 y
así sucesivamente).
1.3.4. Atributos.
Un atributo de una relación o de una tabla corresponde a una columna de la
tabla. Los atributos están desordenados y se referencian por nombres y no por la
posición que ocupan. Esto significa que no se puede, por ejemplo, hacer
referencia al tercer atributo de una relación. Todos los valores de los atributos son
atómicos y una relación que satisfaga esta condición se llama relación
normalizada. Un atributo extrae sus valores desde un dominio simple.
Formalmente, un atributo es una función que se define entre un Dominio y
un determinado tipo de Entidad de la base de datos. Dicha función asocia una
ocurrencia de Tipo de Entidad con un determinado elemento del dominio.
1.3.5. Esquema de Relación.
Un esquema de relación es el conjunto que identifica todas las propiedades
(Atributos) de un objeto. Se representa por el conjunto :
{ A A , A A }
E = ,......
1,
2 3
donde , i = 1,...
n corresponde a un atributo y n el número de atributos de
A i
interés del objeto.
n
11

1.3.6. Relación
Formalmente, una relación R es un conjunto de n-tuplas tal que una n-tupla
cualquiera x es:
{ ( , a)
/ A ∈ E,
a ∈ Dom(
A ), ∀i,
i = 1,.....
n}
Ai i
i
donde E es el esquema de la relación.
Las propiedades fundamentales de una relación son :
• No hay tuplas repetidas.
• Las tuplas no están ordenadas.
• Los atributos no están ordenados.
• Todos los valores que toman las propiedades son atómicos.
1.3.7. Grado de una relación
El grado de una relación es el numero de atributos en la relación. Una
relación de grado 1 (uno) es llamada unaria, una relación de grado 2 es llamada
binaria, una relación de grado n es llamada de “grado n”. Los Grados de una
relación no cambian todo el tiempo, pero es posible que se agreguen nuevas
columnas y se creen nuevas relaciones.
12

1.3.8. Cardinalidades de una relación.
La cardinalidad de una relación en un determinado momento está definida
como el número de tuplas en la relación. Esta puede cambiar en cualquier
momento.
1.3.9. Compatibilidad de dos relaciones.
Sean A y B dos relaciones con esquemas = { A , A ,..... A } y
{ A , A ,..... A }
E2 21 22 2n
si :
E1 11 12 1n
= respectivamente. Se dice que A y B son compatibles si y sólo
1. ∀ P, P ∈E1∃!
P',
P'∈
E2
tal que Dom ( P)
= Dom(
P')
2. ∀ P, P ∈E
2∃!
P',
P'∈
E1
tal que Dom ( P)
= Dom(
P')
En la práctica, esto significa que ambas relaciones deben ser del mismo
grado n y que el i-esimo atributo de cada relación se debe basar en el mismo
dominio.
1.3.10. Llave Primaria / Llave Candidata
La llave primaria de una relación o tabla es de hecho un caso especial de
una construcción más general llamada la llave candidata. Una llave candidata es
un atributo que sirve como identificador único para una determinada tabla. Una de
las llaves candidatas es elegida para ser la llave primaria, las restantes pasarán a
llamarse claves alternativas. De todos modos, comúnmente sólo hay una sola
llave candidata. Las llaves primarias proporcionan un mecanismo de
direccionamiento único a nivel de tuplas para el modelo relacional. Garantizan un
único camino para llegar a una tupla individual y por lo tanto son fundamentales
para las operaciones sobre el modelo relacional.
13

Formalmente, una llave se define como:
Sea ε una relación con esquema E { A A , A ,...... A }
1,
2 3
n
14
= . Una Llave de la
relación ε es un atributo o un conjunto de atributos K { C , C ,..... C }
= que cumple :
• Unicidad: No existen dos tuplas de ε tales que para ellas, el conjunto
de atributos que componen K tienen los mismos valores.
• Minimalidad: Ninguno de los atributos que componen K puede ser
eliminado sin afectar la unicidad.
1.3.11. Llaves externas
Una Llave externa se define como un atributo (o combinación de atributos)
en una relación cuyos valores se requieren para emparejar a los valores de la llave
primaria de otra relación. La llave externa y su correspondiente llave primaria
deben ser definidas en el mismo dominio.
Una llave externa no tiene que ser componente de la llave primaria de la
relación que la contiene. El emparejamiento entre una llave externa y una llave
primaria representa una referencia entre dos relaciones, ellas son el “pegamento”
que mantiene la base de datos unida.
1.3.12. Reglas de Integridad.
Existen básicamente 2 reglas de integridad asociadas con el modelo
relacional, la Integridad de Entidad y la Integridad Referencial. Estas dos reglas
son generales, se aplican a toda base de datos relacional y tienen que ver con las
llaves primarias y externas respectivamente. Estas reglas se refieren a los estados
i
j
l

de la base de datos. Dado que no existe un acuerdo de como se deben evitar los
cambios de estado en la base de datos es que muchos SGBD detienen la
ejecución de la tarea en curso cada vez que se incurre en una violación a una de
estas reglas.
La regla de Integridad de Entidad norma sobre la imposibilidad de que un
atributo que componga la llave primaria de una relación base acepte valores nulos
(NULL) 2 .
La regla de integridad referencial para el modelo relacional formula que si
una relación R2 incluye una llave externa FK que empareja a una llave primaria
PK de alguna relación R1, entonces cada valor de FK en R2 debe:
a) Ser igual al valor de PK en alguna tupla de R1
o
b) Ser totalmente Nula, esto es, cada atributo en FK debe ser nulo.
2 Un Valor nulo en el modelo relacional es un valor especial distinto de cero o blanco
(dependiendo del tipo de dato) que significa “No aplicable” o “Desconocido”. Para mayor detalle,
ver la discusión sobre valores nulos en [McJones97].
15

Capítulo 2. Lenguajes de consulta para el Modelo
Relacional.
2.1. Introducción.
Un lenguaje de consulta es un lenguaje en el que el usuario solicita
información de la base de datos, Los lenguajes de consulta se pueden clasificar en
procedurales y no procedurales. Los lenguajes procedurales son aquellos en los
cuales el usuario instruye al sistema para que lleve a cabo una serie de
operaciones en la base de datos con el fin de calcular el resultado deseado. En
los lenguajes no procedurales, en cambio, el usuario describe la información
deseada sin dar un procedimiento concreto para obtener esta información.
Los lenguajes puros para la consulta de datos son 3. El álgebra relacional,
el cual es procedural y los cálculos relacionales tanto de tuplas como de dominios,
los cuales son lenguajes no procedurales. Estos 3 lenguajes son rígidos y
formales, por lo tanto la mayor parte de los sistemas comerciales de bases de
datos relacionales ofrecen lenguajes de consulta mixtos, que además de ser ricos
en sintaxis ofrecen adicionalmente sublenguajes de definición de datos,
administración de seguridad y otras características.
Se estudiarán brevemente dos de los tres lenguajes puros de consultas de base
de datos, con el fin de presentar una base teórica para introducir SQL. Se excluirá
el cálculo relacional de dominios dado que es una generalización del cálculo
relacional de tuplas y queda fuera del alcance de este trabajo. Para un estudio
más acabado del cálculo relacional de dominios se recomienda leer
[Silbercshatz93].
16

2.2. Algebra relacional.
El Algebra relacional es un lenguaje de consulta procedural. Consta de un
conjunto de operaciones que toman como entrada una o dos relaciones y
producen como resultado una nueva relación, por lo tanto, es posible anidar y
combinar operadores. Hay ocho operadores en el álgebra relacional que
construyen relaciones y manipulan datos, estos son:
1. Selección 2. Proyección 3. Producto
4. Unión 5. Intersección 6. Diferencia
7. JOIN 8. División
Tabla 2-1 - Operadores del Algebra relacional
Las operaciones de proyección, producto, unión, diferencia, y selección son
llamadas primitivas, puesto que las otras tres se pueden definir en términos de
estas.
Se hace necesario en este punto incluir un modelo de datos de ejemplo en
el cual trabajar para generar ejemplos de comandos y operadores. Para este
efecto se incluye un modelo básico de administración de RadioTaxis. El Gráfico
que se presenta a continuación representa el Modelo conceptual (Modelo Lógico)
o Diagrama de Entidad-Relación:
17

Vale
Correlativo
Hora desde
Hora Hasta
Metraje total
Tarifa Total
Dueño
Rut
Nombre
Teléfono
Dirección
Vigencia
posee es de un
por genera un
Movil
Patente
Marca
Modelo
Año
realiza
los hace un
Viaje
Hora Desde
Hora Hasta
Origen
Destino
Tarifa
Metraje
lo maneja
Figura 2-1 - Esquema de Relaciones de Ejemplo
maneja
Chofer
Rut
Nombre
Teléfono
Dirección
Fecha_licencia_desde
Fecha_licencia_hasta
Vigencia
Conceptual Data Model
Project : Control de RadioTaxis
Model : RadioTax
Author : Mario Cisterna Version 28/12/98
Los Esquemas de relaciones que se pueden construir a partir de este
modelo son los siguientes:
Dueño = {rut, nombre, teléfono, dirección, vigencia}
Chofer = {rut, nombre, teléfono, dirección, fecha_licencia_desde,
fecha_licencia_hasta, vigencia}
Vale = {correlativo, hora_desde, hora_hasta, metraje_total,
tarifa_total}
Móvil = {patente, rut_dueño, rut_chofer, marca, modelo, año}
Viaje = {correlativo_vale, patente_movil, Hora_Desde,
hora_hasta, origen, destino, tarifa, metraje}
2.2.1. Selección.
El operador de selección opta por tuplas que satisfagan cierto predicado, se
utiliza la letra griega sigma minúscula (σ) para señalar la selección. El predicado
18

aparece como subíndice de σ. La Relación que constituye el argumento se da
entre paréntesis después de la σ.
Ejemplos :
2.2.2. Proyección.
' ' ( ) Dueño
σ vigencia = S
σ
patente = 'HL−8483'
( Movil )
La operación de proyección permite quitar ciertos atributos de la relación,
esta operación es unaria, copiando su relación base dada como argumento y
quitando ciertas columnas, La proyección se señala con la letra griega pi
mayúscula (Π). Como subíndice de Π se coloca una lista de todos los atributos que
se desea aparezcan en el resultado. La relación argumento se escribe después de
Π entre paréntesis.
Ejemplos :
2.2.3. Producto.
Π nombre,
direccion ( Dueño)
Π rut,
vigencia ( Chofer )
En álgebra relacional el producto de dos relaciones A y B es:
A Veces B o A X B
19

Produce el conjunto de todas las tuplas t tales que t es el encadenamiento de una
tupla a perteneciente a A y de una b que pertenece a B. se utiliza el símbolo X
para representar el producto.
Ejemplos:
2.2.4. Unión.
Dueño × Movil
Movil × Chofer
En álgebra relacional la unión de dos relaciones compatibles 3 A y B es:
A UNION B o A ∪ B
Produce el conjunto de todas las tuplas que pertenecen ya sea a A o a B o a
Ambas. Al igual que en teoría de conjuntos el símbolo ∪ representa aquí la unión
de dos relaciones.
Ejemplo :
2.2.5. Intersección.
σ ∪ σ
rut,
vigencia(
Dueño) rut,
vigencia(
Chofer)
Devuelve todos los Dueños y los Choferes.
En álgebra relacional la intersección de dos relaciones compatibles A y B
3 Relaciones Compatibles : En el álgebra relacional la compatibilidad se aplica a las
operaciones de Unión, Intersección y Diferencia. Cada operación requiere dos relaciones que
deben ser compatibles, esto significa que deben ser del mismo grado, n, y el i-ésimo atributo de
cada una (i= 1, 2…n) se debe basar en el mismo dominio.
20

A INTERSECCION B o A ∩ B
Produce el conjunto de todas las tuplas pertenecientes a A y B. Al igual que en
teoría de conjuntos el símbolo ∩ representa aquí la intersección entre dos
relaciones.
Ejemplo:
2.2.6. Diferencia
σ ∩ σ
rut,
vigencia(
Dueño) rut,
vigencia(
Chofer)
Devuelve todos los dueños que también son choferes
En álgebra relacional la diferencia entre dos relaciones compatibles A y B
A MENOS B o A – B
Produce el conjunto de todas las tuplas t que pertenecen a A y no pertenecen a B.
Ejemplo:
2.2.7. Join o Reunión.
σ − σ
rut,
vigencia(
Dueño) rut,
vigencia(
Chofer)
Devuelve todos los dueños que NO son choferes
En álgebra relacional el JOIN entre el atributo X de la relación A con el
atributo Y de la relación B produce el conjunto de todas las tuplas t tal que t es el
encadenamiento de una tupla a perteneciente a A y una tupla b perteneciente a B
que cumplen con el predicado “A.X comp B.Y es verdadero” (siendo comp un
21

operador relacional y los atributos A.X y B.Y pertenecientes al mismo dominio). Si
el operador relacional “comp” es “=” entonces el conjunto resultante es un EQUI-
JOIN. Si se quita uno de éstos (usando una proyección) entonces el resultado es
un JOIN-NATURAL.
Ejemplo :
2.2.8. División
σ
Dueño . rut = Movil . rut _ dueño ( Dueño × Movil )
En álgebra relacional el operador de división divide la relación A con grado
m + n por la relación B entregando como resultado una relación con grado m. El
atributo m + i de A y el atributo i de B deben estar definidos dentro del mismo
dominio. Así el resultado de
A DIVIDIDO POR B o A / B
produce la relación C con un sólo atributo X, tal que cada valor de x de C.X
aparece como un valor de A.X, y el par de valores (x, y) aparece en A para todos
los valores y que aparecen en B.
Ejemplo:
Π ) / Π ( σ
( Chofer ) )
patente , rut _ chofer ( Movil rut fecha _ licencia _ hasta<
01/
01/
1999
Selecciona todos los autos a cuyos choferes les caduca la licencia el 01/01/1999
22

2.3. Cálculo relacional de tuplas.
El cálculo relacional de tuplas describe la información deseada sin dar un
procedimiento específico para obtenerla. Las consultas en el cálculo relacional de
tuplas se expresan como
{ t | P(t)},
es decir, son el conjunto de tuplas t tales que se cumple el predicado P para cada
t. Siguiendo la misma notación, se utiliza t[A] para el valor de la tupla t en el
atributo A.
{ t | t ∈ Dueño ∧ t[
vigencia]
= ' S '}
{ t | t ∈ Movil ∧ t[
patente]
= ' HL −
8483'
}
Si sólo se desea obtener un atributo de la tupla, se utiliza el constructor
“Existe” de la lógica matemática. Así, si lo que se desea es el Nombre de los
dueños de taxis que estén vigentes:
{ t | ∃ s ∈ Dueño(
t[
Nombre]
= s[
Nombre]
∧ s[
vigencia]
= ' S ' )}
"Conjunto de todas las tuplas t tales que existe una tupla s en la relación
Dueño para la que los valores de t y de s son iguales en el atributo Nombre y el
valor de s para el atributo vigencia = ‘S’ ". La variable de tupla t se define sólo en
el atributo Nombre, puesto que éste es el único atributo para el que se especifica
una condición para t. Así, el resultado es una relación sobre (Nombre).
23

Si lo que se desea es obtener las tarifas de todos los viajes que ha
efectuado todos los móviles de marca “chevrolet”, la consulta requiere de dos
cláusulas “Existe” conectadas por el operador de conjunción lógica “y”.
{ t | ∃s
∈ Viaje(
t[
tarifa ] = s[
tarifa ] ∧
∃u
∈ Movil ( s[
patente]
= u[
patente]
∧ u[
marca]
= " chevrolet"
))}
Que se lee como el conjunto de todas las tuplas(tarifa) correspondientes a los
viajes que han hecho todos los móviles de marca “chevrolet”.
Considérese ahora la consulta “obtener todos los RUT de los dueños de
móviles, cuyos móviles no hayan efectuado nunca un viaje”:
{ t | ∃s
∈ Movil ( t[
rut ] = s[
Rut ] ∧
¬∃u
∈ Viaje(
s[
patente]
= u[
patente]))}
que ocupa la cláusula “Existe” para exigir que el dueño posea un móvil y la
cláusula “no existe” para eliminar a aquellos móviles que tengan viajes realizados.
La consulta que se presenta a continuación utiliza la implicación, la fórmula “P
implica Q” significa que “si P es verdad entonces Q debe ser verdad”, se introduce
el constructor “para todo”. Se desea Selecciona todos los autos a cuyos choferes
les caduca la licencia el “01/01/1999”.
{ t | ∀u
∈ Chofer ( u[
fecha _ licencia _ hasta ] < " 01 / 01 / 1999"
⇒
∃s
∈ Movil ( t[
patente]
= s[
patente]
∧ s[
rut _ chofer ] = u[
rut ])) }
Que es equivalente al ejemplo dado en el punto 2.2.6 (Diferencia).
24

2.3.1. Definición Formal.
Una expresión del cálculo relacional de tuplas es de la forma:
{t|P(t)} donde P es una fórmula. En una fórmula pueden aparecer varias variables
de tuplas. Se dice que una variable de tupla es una variable libre a menos que
este cuantificada por un ∃ o por un ∀ que entonces se dice variable ligada.
Una fórmula en el cálculo relacional de tuplas se compone de átomos. Un
átomo tiene una de las siguientes formas:
1. s ∈ r, donde s es una variable de tupla y r es una relación. No se permite la
operación ∉.
2. s[x] Θ u[y], donde s y u son variables de tuplas, x e y son atributos sobre los
que están definidos s y u respectivamente, y Θ es un operador de comparación
(=). Se requiere que los atributos x e y tengan dominios cuyos
miembros puedan compararse por medio de Θ.
3. s[x] Θ c, donde s es una variable de tupla, x es una atributo sobre el que s esta
definida, Θ es un operador de comparación, y c es una constante en el dominio
del atributo x.
Ahora bien, Las fórmulas se construyen a partir de átomos usando las
siguientes reglas:
1. Un átomo es una fórmula.
2. Si P1 es una fórmula, entonces también lo son ¬P1 y (P1).
25

3. Si P1 y P2 son fórmulas, entonces también lo son P1∨P2, P1∧P2 y P1⇒P2.
4. Si P1(s) es una fórmula que contiene una variable de tupla libre s y r es una
relación, entonces:
también son fórmulas.
∃ s ∈ r (P1(s)) y ∀ s ∈ r (P1(s))
2.3.2. Seguridad de expresiones.
Una expresión del cálculo relacional de tuplas puede generar relaciones
infinitas. Si por ejemplo se utiliza la construcción {t | ¬(t ∈ Dueño)} hay infinitas
tuplas de personas que no son dueños de algún móvil, de hecho la mayoría de
estas tuplas ni siquiera pertenecen a la base de datos.
Para ayudar a definir las ligaduras del cálculo relacional de tuplas se
introduce el concepto de dominio de fórmulas. De forma intuitiva, el dominio de la
fórmula P (dom(p)) es el conjunto de todos los valores a los que P hace referencia.
Esto incluye a todos los valores mencionados en P como todos los valores que
aparezcan en las relaciones referenciadas por P.
Se dice que una expresión {t | P(t)} es segura si todos los valores que
aparecen en el resultado son valores del dominio de P.
2.3.3. Potencia expresiva de los lenguajes.
El cálculo relacional de tuplas restringido a expresiones seguras es
equivalente en potencia expresiva al álgebra relacional. Por lo tanto, para cada
expresión del álgebra relacional hay una expresión equivalente en el cálculo
relacional de tuplas y viceversa. La demostración de este hecho queda fuera de
los alcances de este trabajo, una prueba formal de la equivalencia entre el cálculo
26

elacional de tuplas y el álgebra relacional propuesta por E.F. Codd se puede
encontrar en [Codd71].
2.4. SQL como lenguaje de consultas relacionales.
2.4.1. Introducción.
Los lenguajes formales presentados en las secciones 2.2 y 2.3
proporcionan una notación concisa para la representación de consultas. Sin
embargo, los sistemas de base de datos necesitan un lenguaje de consultas más
cómodo para el usuario. Aunque SQL se considere un lenguaje de consultas,
contiene muchas otras capacidades que incluyen características para definir
estructuras de datos, modificación de datos y la especificación de restricciones de
integridad.
SQL se ha establecido como el lenguaje estándar de base de datos
relacionales. Hay numerosas versiones de SQL. La versión original se desarrollo
en el laboratorio de investigación de San Jose, California (San Jose Research
Center) de IBM, este lenguaje originalmente denominado Sequel, se implementó
como parte del proyecto System R, a principios de 1970 [McJones97]. Desde
entonces ha evolucionado a lo que ahora se conoce como SQL (Structured Query
Language, o lenguaje estructurado de consultas).
En 1986, ANSI (American National Standards Institute, Instituto Nacional
Americano de Normalización) e ISO (International Standards Organization,
Organización Internacional de Normalización) Publicaron una norma de SQL
denominada SQL-86. En 1987 IBM publicó su propia norma de SQL denominada
SAA-SQL(System Application Architecture Database Interfaz, Interfaz de base de
datos para arquitecturas de aplicación de sistemas). En 1989 se publicó una
27

norma extendida para SQL (SQL-89) y actualmente los SGBD son compatibles al
menos con esta norma. La norma actual de SQL de ANSI/ISO es la SQL-92. Se
debe tener en cuenta que algunas implementaciones de SQL pueden ser
compatibles sólo con SQL-89, no siéndolo con SQL-92.
SQL proporciona dos tipos de lenguajes diferentes: uno para especificar el
esquema relacional y el otro para expresar las consultas y actualizaciones de la
base de datos.
2.4.2. Lenguaje de definición de datos (DDL – Data Definition
Language)
Un esquema de bases de datos se representa mediante un sublenguaje
especial llamado lenguaje de definición de datos. El resultado de la compilación de
estas instrucciones es un conjunto de tablas, relaciones y reglas cuyas
definiciones quedan almacenadas en un archivo (tabla u otro medio de
almacenamiento) que contiene “metadatos”, esto es, datos acerca de datos. Este
archivo comúnmente llamado diccionario de datos (o catalogo del sistema) es el
que se consulta toda vez que se quiere leer, modificar o eliminar los datos de la
base de datos.
28

2.4.3. Lenguaje de manipulación de datos (DML – Data Manipulation
Language)
Un D.M.L. es un sublenguaje de consulta y manipulación de datos.
Se entenderá por manipulación de datos la :
• Recuperación de Información.
• Inserción de nueva Información.
• Eliminación (Borrado) de información existente.
• Modificación de Información Almacenada.
2.4.4. Otras características de SQL.
Además de los dos tipos de sublenguajes mencionados anteriormente, SQL
puede ser utilizado para otras características propias que no poseen los lenguajes
formales de consultas, estas son:
• Definición de vistas. El DDL de SQL incluye instrucciones para la
definición de vistas.
• Autorización. El DDL de SQL incluye instrucciones para la
especificación de los derechos de acceso a los objetos de la base de
datos.
• Integridad. El DDL de SQL también incluye un conjunto de sentencias
para la especificación de restricciones de integridad.
• Control de transacciones. SQL incluye ordenes para la especificación
de los estados de una transacción, algunas implementaciones permiten
29

además el bloqueo explicito de objetos de datos con el fin de manejar
control de concurrencia.
Para los efectos de este trabajo se anexa en el apéndice A una breve
descripción de los sublenguajes de Definición y manipulación de datos.
30

Capítulo 3. Sistemas de Gestión de Bases de datos
Relacionales.
3.1. Introducción.
Un Sistema de Gestión de Bases de datos (SGBD) consiste en una
colección de datos interrelacionados y una colección de programas para acceder a
esos datos. El objetivo principal de un SGBD es proporcionar un entorno que sea
tanto conveniente como eficiente para las personas que lo ocupan en el
almacenamiento y recuperación de la información.
Los sistemas de bases de datos se diseñan para almacenar grandes
volúmenes de información, la gestión de los datos implica entonces la definición
de estructuras para el almacenamiento de la información y la provisión de
mecanismos para la manipulación de estos. Además deben proporcionar
mecanismos de seguridad de los datos que protejan al sistema frente a caídas o a
intentos de acceso de personas no autorizadas. Si los datos están compartidos
por varios usuarios, el sistema debe asegurar la consistencia de los datos evitando
posibles resultados anómalos.
Un propósito principal de un sistema de bases de datos es proporcionar a
los usuarios una visión abstracta de los datos. Esto se logra mediante la definición
de 3 niveles de abstracción que pueden ser observados: el nivel físico, el nivel
lógico y el nivel de vistas.
El nivel físico es el nivel más bajo de abstracción, es el que describe como
se almacenan los datos, a su vez, el nivel lógico describe que datos se
almacenan realmente en la base de datos y que relaciones existen entre estos
31

datos. El nivel más alto de abstracción de datos es el nivel de vistas, el cual sólo
presenta una determinada porción de la base de datos, dependiendo del tipo de
usuario que la consulta, así, el sistema puede proporcionar muchas vistas para la
base de datos.
Una base de datos sufre constantes cambios en el contenido de la
información que contiene en el transcurso del tiempo. La colección de datos
almacenada en un momento particular se denomina ejemplar de la base de datos.
El diseño completo de la base de datos se llama esquema de la base de datos.
La capacidad de modificar la definición del esquema en un nivel sin que
afecte a una definición de esquema en el nivel inmediatamente superior se
denomina independencia de datos. Existen 2 niveles de independencia de datos:
La independencia física de datos y la independencia lógica.
La Independencia física de los datos se describe como la capacidad de
modificar el nivel físico de la base de datos sin tener que rescribir los programas
de aplicación. En tanto la independencia lógica se define como la capacidad de
modificar el esquema lógico sin causar que los programas de aplicación tengan
que rescribirse.
Un esquema de base de datos se especifica mediante un conjunto de
definiciones expresadas en un DDL (Lenguaje de definición de datos). El resultado
de esta definición es un conjunto de tablas y relaciones que se almacenan en una
tabla (o un conjunto de tablas) especial que se identifica como el diccionario de
datos o el catálogo de la base de datos.
Una transacción de base de datos se define como colección de operaciones
que se lleva a cabo como una función lógica simple en una aplicación de base de
datos. Cada transacción es una unidad de atomicidad y consistencia. La
32

atomicidad aquí se entiende como la capacidad de que muchas instrucciones se
entiendan en ciertos casos como una sola, la consistencia se refiere a la
capacidad de respetar las restricciones de consistencia de datos que posee la
base de datos antes y después de ejecutar una transacción. El gestor de
transacciones es el responsable de asegurar que la base de datos permanezca en
un estado consistente a pesar de los fallos del sistema. El gestor de transacciones
también asegura que la ejecución de transacciones concurrentes ocurran sin
conflictos. El gestor de almacenamiento de la base de datos es un programa (o
modulo) que proporciona la interfaz entre los datos de bajo nivel almacenados en
la base de datos y los programas de aplicación y las consultas enviadas al
sistema. El gestor de almacenamiento es el responsable de la interacción con los
datos almacenados en disco.
3.2. Transacciones, concurrencia y recuperación.
3.2.1. Transacciones.
Una transacción es una unidad de la ejecución de un programa que accede
y posiblemente actualiza varios elementos de datos. Se delimita dependiendo del
lenguaje por las sentencias inicio transacción y fin transacción y se compone de
todas las instrucciones que se encuentran entre estos dos delimitadores.
Para asegurar la consistencia de los datos se necesita que el sistema de
base de datos tengan las propiedades llamadas ACID: (Atomicity, Consistency,
Isolation, Durability - Atomicidad, Consistencia, Aislamiento, Durabilidad
[Silberschatz97].
La atomicidad asegura que o bien todos los efectos de la transacción se
reflejan en la base de datos, o bien ninguno de ellos; un fallo no puede dejar a la
base de datos en un estado en el cual una transacción se haya ejecutado
33

parcialmente. La consistencia asegura que si la base de datos es consistente
inicialmente, la ejecución de la transacción deja la base de datos en un estado
consistente. El aislamiento asegura que en la ejecución concurrente de
transacciones, estas están aisladas unas de otras, de tal manera que cada una
tiene la impresión de que ninguna otra transacción se ejecuta concurrentemente
con ella. La durabilidad asegura que una vez que la transacción se ha
comprometido, las actualizaciones hechas por la transacción no se pierden,
incluso si hay un fallo en el sistema.
Una transacción que termina con éxito se dice que está comprometida
(commited), una transacción que haya sido comprometida llevará a la base de
datos a un nuevo estado consistente que debe permanecer incluso si hay un fallo
en el sistema. En cualquier momento una transacción sólo puede estar en uno de
los siguientes estados.
• Activa (Active): el estado inicial; la transacción permanece en este estado
durante su ejecución.
• Parcialmente comprometida (Uncommited): Después de ejecutarse la ultima
transacción.
• Fallida (Failed): tras descubrir que no se puede continuar la ejecución normal.
• Abortada (Rolled Back): después de haber retrocedido la transacción y
restablecido la base de datos a su estado anterior al comienzo de la
transacción.
• Comprometida (Commited): tras completarse con éxito.
Cuando varias transacciones se ejecutan concurrentemente, existe la
posibilidad de que se pierda la consistencia de datos. Se hace necesario por lo
tanto un sistema que controle la interacción entre las transacciones concurrentes.
Puesto que una transacción por definición conserva la consistencia, una ejecución
34

lineal de transacciones la garantiza también. Un sistema que asegure esta
propiedad se dice que asegura la secuencialidad.
3.2.2. Concurrencia.
Existen varios esquemas de control de concurrencia que aseguran la
secuencialidad, todos estos esquemas o bien retrasan una operación o bien
abortan la transacción que ha realizado la operación. Los más conocidos son los
protocolos de bloqueo, el esquema de ordenación por marcas temporales, las
técnicas de validación, el esquema de granularidad múltiple y los esquemas
multiversión.
Un protocolo de bloqueo es un conjunto de reglas que indican el momento
en que una transacción puede bloquear o desbloquear un objeto de la base de
datos. El protocolo de bloqueo de dos fases permite que una transacción bloquee
un objeto sólo después de que haya desbloqueado otro objeto distinto, este
método asegura la secuencialidad.
El esquema de ordenación por marcas temporales asegura la
secuencialidad seleccionando previamente un orden en todo par de transacciones.
Existen 2 formas de implementar este esquema, uno es por medio de valores
timestamp (dependientes del reloj del sistema) y por medio de un contador lógico
que se incrementa cada vez que asigna una nueva marca temporal. Este
protocolo asegura la secuencialidad en cuanto a conflictos y la ausencia de
interbloqueos, si una de las transacciones viola la norma la transacción se retrasa
y se le asigna una nueva marca temporal. Por ejemplo, una operación leer se
puede retrasar porque todavía no se ha escrito el valor apropiado o incluso
rechazar si ha sobrescrito el valor que supuestamente se iba a leer.
35

Un esquema de validación es un método de control de concurrencia
adecuado para transacciones de sólo lectura y en las cuales la tasa de conflictos
es baja. Se basa en dividir una transacción en 3 etapas (lectura, validación y
escritura) y trabajar con el esquema de marcas temporales sobre la etapa de
validación. De esta manera se quita una sobrecarga en la etapa de lectura, en la
cual no se necesita un esquema de control de concurrencia dado que toda lectura
lleva a la base de datos al mismo estado de consistencia.
Una manera distinta manejar la concurrencia es por medio de la
granularidad, este concepto permite agrupar varios elementos de datos y definirlos
como un todo para efectos de sincronización. Se define como una jerarquía de
distintos niveles, donde el nivel superior puede representar toda la base de datos,
se esquematiza como estructura de árbol donde los nodos hijos de un nodo
interno representan las dependencias de datos asociadas. Se utilizan los tipos de
bloqueos Compartidos y Exclusivos más un nuevo tipo de bloqueo llamado el
bloqueo intencional, el cual indica que existen nodos descendientes que tienen
bloqueos compartidos o exclusivos.
El esquema multiversión se basa en la creación de nuevas versiones de los
elementos de datos cada vez que una transacción vaya a escribir dicho elemento.
Cuando se va a realizar una escritura el sistema elige una de las versiones para
que se lea. El esquema de control de versiones garantiza que la versión que se va
a leer se elige de forma que asegure la secuencialidad por medio de marcas
temporales. En este esquema una operación de lectura tiene éxito siempre, sin
embargo, una operación de escritura puede provocar el retroceso de una
transacción.
Un sistema está en estado de interbloqueo si existe un conjunto de
transacciones tal que toda transacción del conjunto está esperando a otra
transacción del conjunto. En tal situación, ninguna de las transacciones puede
36

progresar. Existen 2 métodos para tratar los interbloqueos y ambos provocan un
retroceso de las transacciones, la diferencia radica en que uno es preventivo y otro
curativo. El protocolo de prevención de interbloqueos asegura que el sistema
nunca llegará a un estado de interbloqueos mientras que el método de detección y
recuperación de interbloqueos permite que el sistema llegue a un estado de
interbloqueos para luego tratar de recuperarse. La prevención se usa normalmente
cuando la probabilidad de que el sistema llegue a un estado de interbloqueo es
relativamente alta, de lo contrario lo más conveniente es usar la detección y
recuperación.
3.2.3. Recuperación.
Los fallos que ocurren en un computador pueden darse por diferentes
motivos (fallos de disco, cortes de energía o fallos en el software). En cada uno de
estos casos puede perderse información concerniente a la base de datos. Existen
varios tipos de fallas, a considerar:
• Fallo en la transacción, que a su vez se dividen en errores lógicos y errores del
sistema. Un error lógico ocurre cuando una transacción no puede continuar con
su ejecución normal a causa de una condición interna como lo es un
desbordamiento o un exceso de recursos. Un error del sistema ocurre cuando
el sistema se encuentra en un estado no deseado como en el caso de los
interbloqueos.
• Caída del sistema, provocado ya sea por el hardware, el sistema operativo o
por el software de base de datos. Comúnmente causa la pérdida del contenido
de la memoria primaria y aborta el procesamiento de una transacción.
37

• Fallo de disco, para el cual sólo sirve la recuperación por medio de copias
existentes en medios de almacenamiento secundario como cintas magnéticas.
La forma más aceptada de lograr un tipo de almacenamiento lo más estable
posible es replicando la información en varios medios de almacenamiento no
volátil, con modos de fallos independientes. Los sistemas RAID (disposición
redundante de discos independientes) garantizan que el fallo de un sólo disco no
conduzca a la perdida de datos. Sin embargo los sistemas RAID, no pueden
proteger al sistema de una pérdida de datos en el caso de una catástrofe
geográfica, para tales efectos muchos sistemas de almacenamiento guardan
copias de seguridad en cintas en otros lugares, no obstante, como las cintas no
pueden ser trasladadas continuamente, los últimos cambios realizados luego del
traslado de cintas no se pueden volver a recuperar en el caso de tales desastres.
Los sistemas más seguros guardan copias de cada bloque de almacenamiento en
otra disposición geográfica, datos que se transmiten por medios de redes de
computadores al sistema de respaldo remoto.
El estado de un sistema de base de datos puede no volver a ser consistente
en caso de que ocurran fallos, para preservar la consistencia es necesario que
cada transacción sea atómica. Garantizar la propiedad de atomicidad es
responsabilidad del esquema de recuperación.
Existen básicamente 2 esquemas que garantizan la atomicidad.
Basados en el registro histórico 4 . Todas las modificaciones se graban en el
registro histórico, el cual debe estar guardado en almacenamiento estable. En el
esquema de modificación diferida, durante la ejecución de una transacción, se
difieren todas las operaciones de escritura hasta que la transacción se
4 Comúnmente llamado log de transacciones.
38

compromete parcialmente, momento en el cual se utiliza la información del registro
histórico asociado con la transacción para ejecutar las escrituras diferidas. Con la
técnica de modificación inmediata todas las modificaciones se aplican
directamente en la base de datos. Si ocurre una caída se utiliza la información del
registro histórico para llevar a la base de datos a un estado estable previo.
Paginación en la sombra. Durante la vida de una transacción se mantienen
2 tablas de páginas: la tabla actual de páginas y la tabla de páginas sombra.
Ambas tablas son idénticas al principio de la transacción, sin embargo, la tabla
actual de páginas puede ir cambiando luego de cada operación escribir. Todas las
operaciones de lectura y escritura utilizan la tabla de páginas actual, cuando una
transacción se compromete parcialmente se desecha la tabla de páginas sombra y
la tabla actual se convierte en la nueva tabla de páginas. Si la transacción fracasa,
simplemente se desecha la tabla actual de páginas.
El procesamiento de transacciones se basa en un modelo de
almacenamiento en el cual la memoria principal contiene una memoria intermedia
para el registro histórico, una memoria intermedia para la base de datos y una
memoria intermedia para el sistema. Una implementación eficiente de un
esquema de recuperación de datos requiere que sea mínimo el número de
escrituras de la base de datos y que sea realizado en almacenamiento estable.
Los registros del registro histórico pueden guardarse inicialmente en la memoria
intermedia del registro histórico pero deben ser llevados a almacenamiento estable
bajo dos situaciones:
a) deben escribirse en almacenamiento estable todos los registros del registro
histórico que referencien a la transacción Ti antes de grabar el registro que
indique que la transacción Ti ha sido comprometida
39

) deben escribirse en almacenamiento estable todos los registros del registro
histórico pertenecientes a los datos de un bloque antes de que ese bloque de
datos se escriba desde la memoria intermedia a la base de datos.
3.3. Tipos de SGBD.
La arquitectura de un sistema de base de datos está influenciada por el
sistema informático que soporta la instalación del SGBD, lo que reflejará muchas
de las características propias del sistema subyacente en el SGBD.
La redes de computadores permiten separar tareas en un esquema de
clientes y servidores, el procesamiento paralelo dentro del computador permite
acelerar algunas de las tareas de la base de datos así como la posibilidad de
ejecutar más transacciones por segundo. Las consultas se pueden paralelizar
permitiendo así que una consulta se pueda ejecutar por más de un procesador al
mismo tiempo, esta característica ha llevado al estudio de las bases de datos
paralelas.
La distribución de datos a través de distintos departamentos de una
organización permite que ellos residan donde han sido generados (y donde se
entiende que son más requeridos); la idea de mantener una copia de estos datos
en otros lugares permite que puedan seguir las operaciones sobre los datos aún si
alguno de estos sitios sufre algún desastre. El estudio de este tipo de
descentralización de los datos lleva al desarrollo de los sistemas de base de datos
distribuidos.
3.3.1. SGBD centralizados.
40

Un sistema de base de datos centralizado es aquel que se ejecuta en un
único sistema computacional sin tener, para tal efecto, que interactuar con otros
computadores. El rango de estos sistemas comprende desde los sistemas de
bases de datos monousuario ejecutándose en computadores personales hasta los
sistemas de bases de datos ejecutándose en sistemas de alto rendimiento.
Normalmente los sistemas de base de datos monousuarios no suelen
proporcionar muchas de las facilidades que ofrecen los sistemas multiusuario, en
particular no tienen control de concurrencia y tienen precarios o inexistentes
sistemas de recuperación.
Dado que las maquinas en las cuales se utilizan los sistemas monousuarios
son comúnmente computadores de propósito general, la arquitectura de estas
maquinas es siempre parecida(de 1 a 2 procesadores que comparten la memoria
principal) por tanto los sistemas de base de datos que se ejecutan sobre estas
maquinas no intentan dividir una consulta simple entre los distintos procesadores,
sino que ejecutan cada consulta en un único procesador posibilitando así la
concurrencia de varias consultas. Este tipo de sistemas dan la sensación de una
mayor productividad (puesto que pueden ejecutar un mayor número de
transacciones por segundo) a pesar de que cada transacción individualmente no
se ejecute más rápido. Por el contrario las máquinas paralelas tienen un gran
número de procesadores y los sistemas de base de datos que ahí se ejecutan
siempre tenderán a paralelizar las tareas simples (consultas) que solicitan los
usuarios.
3.3.2. SGBD Cliente-Servidor.
Con el crecimiento de los computadores personales (PC) y de las redes de
área local (LAN), se han ido desplazando hacia el lado del cliente la funcionalidad
de la parte visible al usuario de la base de datos (interfaces de formularios, gestión
41

de informes, etc.) de modo que los sistemas servidores provean la parte
subyacente que tiene que ver con el acceso a las estructuras de datos, evaluación
y procesamiento de consultas, control de concurrencia y recuperación. Los
sistemas servidores pueden dividirse en 2 tipos: los servidores transaccionales
(que sirven para agrupar la lógica del negocio en un servicio aparte, proveen una
interfaz a través de la cual los clientes pueden enviar peticiones como lo son
ODBC 5 o RPC 6 ) y los servidores de datos(los cuales envían datos a más bajo nivel
y que descansan en la capacidad de procesamiento de datos de las maquinas
clientes).
Existen 2 arquitecturas dominantes en la construcción de motores de base
de datos cliente-servidor: los motores multiprocesos y los motores multihilos.
3.3.2.1. Motores de base de datos multiprocesos (Multi-process database
engines).
Algunos motores de base de datos confían en múltiples aplicaciones para
realizar su trabajo. En este tipo de arquitectura, cada vez que un usuario se
conecta a la base de datos, ésta inicia una nueva instancia de la aplicación de
base de datos. Con el fin de coordinar a muchos usuarios que accesan los mismos
conjuntos de datos estos ejecutables trabajan con un coordinador global de tareas
que planifica operaciones para todos los usuarios. La comunicación entre
aplicaciones de este tipo se realiza por medio de un sistema propietario de
comunicaciones interprocesos (IPC).
5 Open database conectivity: API de acceso a datos que soporta el acceso a cualquier
fuente de datos para la cual exista un driver ODBC. ODBC se encuadra dentro de los estándares
ANSI e ISO para la Interfaz de llamadas de datos (CLI).
6 Remote procedure call: Una forma de comunicación entre aplicaciones que esconde la
complejidad de la red utilizando un mecanismo de llamada de procedimientos ordinario. Es un
proceso sincrónico firmemente acoplado.
42

El ejemplo más popular de motores de base de datos multiprocesos es el
Oracle Server (Oracle corporation) el cual carga 16 tipos de ejecutables distintos
que realizan distintas tareas. El sistema ejecuta sus aplicaciones que sirven para
administrar el acceso de múltiples usuarios a las tablas, el registro y control de
versiones de una transacción y otras características como la replicación de datos,
transacciones distribuidas. Por otro lado, cuando una conexión a la base de datos
se establece, el sistema carga los ejecutables relacionados a tareas de usuario.
Cada vez que un usuario se conecta a una base de datos Oracle, esta
carga un ejecutable con una nueva instancia de la base de datos, las consultas de
usuario son transmitidas a este ejecutable, el cual trabaja en conjunto con otros
ejecutables en el servidor que retornan conjuntos de datos, manejan los bloqueos
y ejecutan todas las funciones necesarias para el acceso de datos.
La mayoría de los motores de base de datos multiprocesos fueron
desarrollados antes de que los sistemas operativos soportaran características
tales como hilos o planificación de tareas (scheduling). Como resultado de esto, el
hecho de descomponer una operación significaba escribir un ejecutable distinto
para manejar esta operación. Esta característica proporciona el beneficio de la
fácil escalabilidad a través de la adición de más CPUs.
En un ambiente de multitarea el sistema operativo divide el tiempo de
procesamiento entre múltiples aplicaciones asignándoles una porción de tiempo
de CPU (“slice”) a cada una. De esta manera siempre hay una sola tarea
ejecutándose a la vez, sin embargo el resultado es que múltiples aplicaciones
aparenten estar corriendo simultáneamente en una sola CPU. La ventaja real, sin
embargo, viene cuando el sistema operativo cuenta con múltiples CPUs.
43

3.3.2.2. Motores de base de datos multihilos (Single-Process multi-threaded
database engines).
Los motores de base de datos multihilos abordan el problema del acceso
multiusuario de una manera distinta, pero con principios similares. En lugar de
confiar en que el sistema operativo comparta los recursos de procesamiento, el
motor toma la responsabilidad por sí mismo, lo que en la práctica se asocia a una
mejor portabilidad del sistema. Motores de base de datos comerciales como
Sybase Adaptive Server o Microsoft Sql Server son ejemplos de este enfoque.
Las ventajas de este tipo de motores radican en una mayor eficiencia en el
uso de recursos para determinadas plataformas. Mientas un sistema
multiprocesos consume entre 500 Kb y 1 Mb por conexión, un motor multihilos
consume entre 50 y 100 Kb de RAM diferencia que puede ser utilizada en caché
de datos y procedimientos. Otra ventaja es que no hay necesidad de un
mecanismo de comunicación interprocesos.
De esta manera, la base de datos utiliza un elemento finito de trabajo, (el
hilo) para una variedad de operaciones (instrucciones de usuarios, bloqueos de
datos, E/S de disco, administración del caché, etc.) en vez de utilizar aplicaciones
especializadas para cada tarea.
Las desventajas más reconocidas son dos: escalabilidad y portabilidad. La
escalabilidad se centra en la habilidad que tengan los distintos motores de base de
datos multihilos de descomponer una operación de manera que múltiples tareas
puedan ejecutar esta operación.
Los problemas de portabilidad guardan relación con el SMP
(multiprocesamiento simétrico) y se originan en el hecho de que dado que
diferentes fabricantes de hardware dan soporte a SMP de diferentes maneras,
44

estos motores de base de datos han tenido que implementar técnicas neutras que
buscan funcionar bien en cualquier implementación física, lo que conlleva una
sobrecarga en el motor y una limitación en la habilidad de escalar a un gran
número de procesadores.
3.3.3. SGBD Paralelos.
Los sistemas paralelos de base de datos constan de varios procesadores y
varios discos conectados a través de una red de interconexión de alta velocidad.
Para medir el rendimiento de los sistemas de base de datos existen 2 medidas
principales: la primera es la productividad (throughput) que se entiende como el
número de tareas que pueden completarse en un intervalo de tiempo determinado.
La segunda es el tiempo de respuesta (response time) que es la cantidad de
tiempo que necesita para completar una única tarea a partir del momento en que
se envíe. Un sistema que procese un gran número de pequeñas transacciones
puede mejorar su productividad realizando muchas transacciones en paralelo. Un
sistema que procese transacciones más largas puede mejorar tanto su
productividad como sus tiempos de respuesta realizando en paralelo cada una de
las subtareas de cada transacción.
Las ganancias en este tipo de SGBD se pueden dar en términos de velocidad
(menor tiempo de ejecución para una tarea dada) y ampliabilidad (capacidad de
procesar tareas más largas en el mismo tiempo).
Existen varios modelos de arquitecturas para maquinas paralelas, los más
mencionados son:
• Memoria Compartida : Todos los procesadores comparten una memoria
común.
45

• Disco Compartido: Todos los procesadores comparten una disposición de
discos común.
• Sin Compartimiento: Los procesadores no comparten ni memoria ni disco.
• Jerárquico: Compartimiento tanto de memoria como de disco.
3.3.4. SGBD Distribuidos.
En un SGBD distribuido, la base de datos se almacena en varios
computadores que se pueden comunicar a sus vez por distintos medios de
comunicación (desde redes de alta velocidad a líneas telefónicas). No comparten
memoria ni discos y sus tamaños pueden variar tanto como sus funciones
pudiendo abarcar desde PC hasta grandes sistemas. Se denomina con el término
de emplazamientos o nodos a todos aquellos computadores que pertenecen a un
sistema distribuido.
Las principales diferencias entre las bases de datos paralelas y las bases
de datos distribuidas son las siguientes: las bases de datos distribuidas se
encuentran normalmente en varios lugares geográficos distintos, se administran
de forma separada y poseen una interconexión más lenta. Otra diferencia es que
en un sistema distribuido se dan dos tipos de transacciones, las locales y las
globales. Una transacción local es aquella que accede a los datos del único
emplazamiento en el cual se inició la transacción. Por otra parte una transacción
global es aquella que o bien accede a los datos situados en un emplazamiento
diferente de aquel en el que se inició la transacción, o bien accede a datos de
varios emplazamientos distintos.
Un sistema de base de datos distribuido se conoce por:
• Los distintos emplazamientos están informados de los demás.
46

• Aunque algunas relaciones pueden estar almacenadas sólo en algunos
emplazamientos, éstos comparten un esquema global común.
• Cada emplazamiento proporciona un entorno para la ejecución de
transacciones tanto locales como globales.
47

Capítulo 4. Introducción al Procesamiento de Consultas,
El enfoque de System R.
4.1. Introducción.
El Procesamiento de consultas hace referencia a la serie de actividades a
seguir para llevar a cabo la recuperación de datos desde una base de datos. Estas
actividades incluyen la traducción de consultas en lenguajes de consultas de alto
nivel (Ej: SQL) a expresiones que se puedan implementar en un nivel físico, así
como también los algoritmos de evaluación y optimización de consultas.
Una de las ventajas principales del modelo relacional presentado por Codd
en 1970 es la que tiene relación con la independencia de los datos que se
entiende aquí como la separación entre el modelo (lógico) y la implementación
(física). Esta separación nos permite desarrollar una poderosa semántica lógica
independiente de una implementación física particular.
Uno de los desafíos de la independencia de datos es que la codificación de
una consulta para la base de datos se componga de 2 fases:
1. La descripción lógica de la consulta (que se supone que debe hacer).
2. La definición del plan de ejecución físico (el que muestra como implementar la
consulta).
Antes de empezar el Procesamiento de la consulta el sistema debe traducir
la consulta a un medio de representación interno con el cual le sea fácil operar.
48

Así, por ejemplo para SQL la representación más útil es la del álgebra relacional
extendida (árbol relacional). Este proceso cumple la misma función que el
analizador léxico y sintáctico de un compilador, es decir, revisa la sintaxis de la
consulta y chequea que todos lo identificadores sean nombres de objetos de la
base de datos, en el caso de las vistas reemplaza el nombre de la vista por la
expresión relacional que la representa.
El plan de ejecución es un árbol relacional armado a partir de la consulta y
que sólo puede ser entendido por el motor de ejecución de consultas. La
transformación de la consulta a un plan puede ser hecha efectivamente a mano y
en algunos casos de consultas simples que se ejecutan miles de veces esta
podría ser la mejor estrategia, sin embargo, una de las ventajas que nos ofrece el
modelo relacional es la capacidad de usar la información del catalogo de la base
de datos, que como se verá más adelante, podrá responder una gran cantidad de
preguntas distintas.
Por otro lado, aunque una consulta simple pueda ser ejecutada miles de
veces, no existe un camino mecánico que garantice que el plan de ejecución
elegido satisfaga la consulta que se quiere implementar, puesto que:
1. Un Plan calculado a mano (o un plan precalculado) será invalidado por
cambios lógicos dentro del esquema o por cambios físicos en el camino de
acceso a la información o en el almacenamiento físico.
2. Si los parámetros de la consulta (o los datos) cambian, la relación optima que
asocia a un plan con una consulta por sobre otros puede cambiar.
La siguiente figura nos muestra los pasos en el procesamiento de una
consulta.
49

Consulta
Resultado
de la Consulta
Analizador y
traductor
(parser)
Datos
Motor de
Ejecución
Información del
Catalogo
Figura 4-1 - Pasos en el procesamiento de una consulta SQL
Expresión en Algebra
Relacional
(Arbol relacional)
Optimizador
Plan de
Ejecución
Después de enviar la consulta, la base de datos debe producir su
correspondiente plan de ejecución. El primer paso en este proceso es traducir la
consulta desde SQL a un árbol lógico en álgebra relacional, proceso comúnmente
llamado parser.
El Próximo paso es traducir el árbol de la consulta en el plan de ejecución.
Generalmente existe un gran número de planes que implementan al árbol de la
consulta; el proceso de encontrar el mejor de estos planes se le denomina
optimización de consultas, entendiéndose que esta optimización viene dada por
una medida de rendimiento para la ejecución de consultas (como por ejemplo el
tiempo de ejecución), queremos encontrar entonces la consulta que tenga el mejor
rendimiento de ejecución. El objetivo es que el plan sea el óptimo (o el más
cercano a) dado el espacio de búsqueda del optimizador.
50

Finalmente el optimizador envía el plan óptimo al motor de ejecución. El
motor de ejecución ejecuta el plan usando como entrada las relaciones
almacenadas en las base de datos y produce una tabla con los datos solicitados
como salida.
Los primeros optimizadores de consultas fueron descritos para System R
[Selinger79] y para Ingress [Wong76] en los años 1979 y 1976 respectivamente.
Estos fueron implementados para variantes particulares del modelo Relacional y
funcionan lo suficientemente bien en la medida de sus implementaciones físicas
del modelo. El Optimizador de System R ha sido la base de otros optimizadores de
bases de datos comerciales.
4.2. El optimizador de System R.
[Selinger79] propone una descomposición de 4 fases en el procesamiento
de una consulta SQL: parsing, optimización, generación de código y ejecución. Al
principio cada sentencia SQL es enviada al parser (analizador sintáctico), quien se
encarga de chequear la sintaxis de la consulta; si no hay errores, el parser llama
al optimizador, quien toma todos los nombres de tablas y columnas referenciadas
por la consulta y las busca en el catalogo de la BD para verificar su existencia y
rescatar estadísticas y caminos de accesos almacenados. Es el optimizador quien
también analiza los tipos de datos y tamaños de cada columna con el fin de revisar
en la lista SELECT 7 como en el Arbol WHERE 8 la existencia de errores de
semántica e incompatibilidades de tipos de datos.
7 Lista de todos los elementos que están en una cláusula select.
8
Estructura de árbol que contiene todos los predicados contenidos en la clausula
WHERE.
51

Finalmente realiza la selección de los caminos de acceso. Si una consulta
tiene más de un query block 9 (en adelante bloque) determina el orden de
evaluación de estos a lo largo de la consulta, luego procesa para cada bloque las
relaciones enunciadas en la lista FROM 10 . Si en el bloque existe más de una
relación, el optimizador realiza permutaciones de los métodos de join, por tanto, se
elige el camino de acceso que minimice el costo para el bloque. Esta solución
recibe el nombre de “plan de ejecución” [Selinger79] el cual se representa en el
lenguaje de especificación de accesos (ASL) cuya definición queda fuera de los
alcances de este trabajo. Para mayor Información consultar [Lorie78].
El generador de código es un programa que traslada árboles ASL en
lenguaje de máquina para ejecutar el plan escogido por el optimizador, para hacer
esto utiliza un pequeño número de plantillas de código para representar todos los
casos posibles, durante esta fase se reemplaza el árbol generado por el parser en
código de maquina ejecutable y sus estructuras de datos asociadas.
4.2.1. RSS (research storage system)
El RSS es el subsistema de almacenamiento de system R, este es el
responsable de mantener el almacenamiento físico de las relaciones, de los
caminos de acceso a ellas, bloqueos (en un ambiente multiusuario), y de las
capacidades de registro de transacciones y recuperación. El RSI (Research
Storage Interface) es la interfaz orientada a la tupla que system R presenta al
usuario final.
9
Un query block es un bloque de cláusulas que conforman una consulta sql de la forma
SELECT, FROM, WHERE, GROUP BY, ORDER BY.
10 Lista de todas las relaciones enunciadas en la clausula FROM de una consulta sql.
52

Una Relación se almacena en el RSS como una colección de tuplas que
cumplen con las siguientes características:
• sus columnas son contiguas,
• se almacenan en páginas de 4 Kb,
• una tupla no puede rebasar una página.
Las páginas se organizan en segmentos, los segmentos pueden contener
una o más relaciones pero una relación no puede rebasar un segmento.
La manera de accesar tuplas de una relación es por medio de un proceso
llamado RSS scan, este retorna una tupla a la vez a lo largo del camino de acceso
indicado. Los comandos principales son: OPEN, NEXT y CLOSE.
Existen 2 tipos de recorridos (scan), el primero es un segment scan, el cual
encuentra todas las tuplas de una relación dada, consiste básicamente de una
serie de NEXT que recorren todas las páginas del segmento (que pueden
contener tuplas para cualquier relación) y de donde rescatan aquellas tuplas que
pertenecen a la relación dada.
El segundo tipo de recorrido es un index scan 11 , los índices se almacenan
en páginas distintas a las páginas de datos y son implementados como B-tree
cuyas hojas del árbol son páginas que contienen conjuntos de ya sea claves,
identificadores, o tuplas que contienen la clave; por lo tanto una serie de NEXT
sobre un “index scan”, realiza una lectura secuencial a lo largo de las hojas
obteniendo las tuplas de identificadores que se igualan a la clave de búsqueda o
usándolas para encontrar y retornar las tuplas de datos en el orden de las claves
11 un índice puede ser creado por un usuario de system R en una o más columnas de una
relación, y una relación puede cero o más índices asociados a esta.
53

dadas. Las paginas de índices están encadenas juntas, por lo tanto las sentencias
NEXT no necesitan referenciar paginas que se encuentren más arriba del índice.
En un “segment scan” todas las páginas no vacías de un segmento se
accesan sólo una vez sin importar si tienen o no tuplas que pertenezcan a la
relación. En un “index scan” las páginas de índices se accesan sólo una vez, sin
embargo las páginas de datos se pueden tocar más de una vez.
Si las tuplas han sido insertadas en las paginas del segmento en el orden
del índice y si este orden se mantiene diremos que el índice es un índice en
cluster, este tipo de índices tiene la propiedad de que además de las paginas de
índices, también las paginas de datos se accesan solamente una vez en un “index
scan”. Cabe destacar de que un “index scan” no necesita recorrer toda la relación,
pues puede recibir llaves de inicio y fin.
Ambos tipos de scan pueden recibir un conjunto de predicados llamados
predicados sargables o SARGS (“search arguments”) los cuales tiene la
particularidad de que son aplicados a las tuplas antes de que sean devueltas al
RSI. Un predicado sargable es uno de la forma:
“columna operador_de_comparación valor”.
4.2.2. Costos para los caminos de acceso de relaciones simples.
El optimizador de System trata de manera distinta a las consultas que
hacen referencia a una sola tabla (relaciones simples) de las que se deben tratar
como un Join. Para el primer caso, el optimizador examina tanto los predicados de
la consulta como también los caminos de acceso disponibles para la relación
referenciada y evalúa una fórmula de costo para cada plan de acceso usando la
siguiente fórmula:
54

COSTO = Páginas Rescatadas + W * (RSI calls)
Este costo es una medida de peso entre las E/S (páginas rescatadas) y la
utilización de CPU (instrucciones ejecutadas). W es un factor de peso ajustable
entre E/S y la CPU 12 . RSI calls es la estimación del número de tuplas a retornar.
Dada esta formula la elección del camino de costo mínimo para procesar una
consulta tiende a minimizar el total de recursos requeridos.
La ejecución de la validación semántica del optimizador examina cada
bloque WHERE (el respectivo árbol debe estar en la forma normal conjuntiva) con
el objetivo de identificar los factores booleanos.
Se llama factor booleano a cada uno de los predicados del Arbol WHERE (o
conjunciones) que ha sido previamente normalizado.
Se dice que un índice calza un factor booleano si el factor booleano es un
predicado sargable cuya columna referenciada es la clave del índice.
Se dice que un predicado o un conjunto de predicados calza a un camino
de acceso por índice cuando los predicados son sargables y las columnas
mencionadas en los predicados son un substring inicial del conjunto de columnas
de la clave del índice. Si un índice calza un factor booleano entonces un camino
de acceso que ocupe este índice será una manera eficiente de satisfacer el factor
booleano.
12 Una forma de calcularlo puede ser tomar los MIPS de una determinada CPU y por otro
lado tomar el número de instrucciones que se utilizan en una llamada RSS. W podría ser el
producto de estos 2 valores medidos durante el tiempo transcurrido en una búsqueda típica a
disco. Por lo tanto W tendrá diferentes valores dependiendo de distintas configuraciones de
hardware. (Don Chamberlin, 12/09/2001)
55

Durante la mirada al catálogo, el optimizador recupera estadísticas para las
relaciones de la consulta y caminos de acceso disponibles para cada relación. Las
estadísticas son las siguientes:
Para cada relación T.
• NCARD(T), cardinalidad de la relación T.
• TCARD(T), número de páginas del segmento que contienen tuplas
de la relación T.
• P(T), fracción de paginas de datos que contienen tuplas de la
relación T.
P(T) = TCARD(T)/Número_de_páginas_no_vacías_en_el_segmento.
Para Cada índice en la relación T.
• ICARD(I), Número de claves distintas en el índice I
• NINDEX(I), Número de páginas en el índice I.
Estas estadísticas son mantenidas por el catálogo de System R, y
provienen de distintas fuentes, son actualizadas periódicamente por el comando
UPDATE STATISTICS, el cual puede ser ejecutado por cualquier usuario.
Usando estas estadísticas, el optimizador asigna un factor de selección “F”
para cada factor booleano en la lista de predicados. Este factor es la estimación
de la cantidad de tuplas que satisfacen el predicado. Se asume que una falta de
estadísticas implica la elección de un factor arbitrario.
56

La siguiente tabla muestra los factores a utilizar para los distintos tipos de
predicados:
columna = valor
F = 1 / ICARD(índice) si existe un índice para la columna. Esto asume
una distribución uniforme de los datos a lo largo del dominio de la
columna.
F = 1 / 10 en otro caso.
columna1 = columna2
F = 1 / MAX(ICARD(índice_columna1), ICARD(índice_columna2)) si existen
índices tanto en columna1 como en columna2. Esto asume que cada valor
en el dominio del índice con menor cardinalidad se iguala a un valor
en el otro índice.
F = 1 / ICARD(indice_columna-i) si sólo existe un índice sobre la
columna-i
F = 1 / 10 en otro caso
Columna > valor (o cualquier otra comparación abierta)
F = (mayor_valor_dominio – valor) / (mayor_valor_dominio –
menor_valor_dominio) si la columna es de tipo aritmético y el valor
es conocido en el momento de escoger el camino de acceso.
mayor_valor y menor_valor son los límites del dominio.
F = 1 / 3 en otro caso. Responde a la hipótesis de que son menos las
consultas que usan predicados que son satisfechos por más de la mitad
de las tuplas.
Columna between valor1 and valor2
F = (valor2 – valor1) / (mayor_valor_dominio – menor_valor_dominio)
que corresponde a una razón entre el rango de valores de la cláusula
57

BETWEEN con respecto al rango de valores del dominio siempre que la
columna sea aritmética y ambos valores sean conocidos al momento de
escoger el camino de acceso.
F = 1 / 4 en otro caso.
Columna in (lista_de_valores)
F = (numero_de_elementos_de_la_lista) * (factor_de_selección para
columna = valor) siempre y cuando no sea mayor que ½.
Columna in subconsulta
F = (cardinalidad estimada de la subconsulta) / (producto de las
cardinalidades
subconsulta)
de todas las relaciones de la lista FROM de la
El cálculo de la cardinalidad de una subconsulta se explica más
adelante.
Predicado1 OR predicado2
F = F(predicado1) + F(predicado2) – F(predicado1) * F(predicado2)
Predicado1 AND predicado2
F = F(predicado1) * F(predicado2)
NOT predicado
F = 1 – F(predicado)
Tabla 4-1 - Factores de Selección para caminos de acceso a Relaciones Simples.
La cardinalidad de una consulta (QCARD) es el producto de las
cardinalidades de cada relación involucrada multiplicado por el producto de todos
los factores de selección. El número esperado de llamadas RSI (RSICARD) es el
producto de las cardinalidades de las relaciones por los factores de selección de
58

todos los factores booleanos sargables (dado que estos argumentos son los que
se aplican antes de ser retornadas a la RSI).
El escoger el camino de acceso óptimo para una relación consiste entonces
en usar estos factores de selección junto con las estadísticas del catalogo en
fórmulas definidas. Para llegar a estas fórmulas se presentara entonces la
siguiente definición.
Se dice que un determinado orden de tuplas es un “interesting order” si este
orden es uno de los especificados en las cláusulas GROUP BY u ORDER BY.
Para una relación simple, la solución óptima se obtiene evaluando el costo
para cada camino de acceso (cada índice en la relación más un “segment scan”).
Si no hay cláusulas GROUP BY u ORDER BY en la consulta no hay “interesting
orders”, por lo tanto se deberá elegir el camino de acceso más barato. Si estas
sentencias existen, se necesita examinar los caminos de acceso más baratos que
produzcan tuplas en cada uno de los “insteresting orders”, luego, el costo de
producir estos ordenamientos debe compararse al costo del más barato de los
caminos “sin orden” más el costo de ordenar las QCARDS tuplas de la consulta
en el orden dado. La más barata de estas alternativas será la elegida como el plan
de ejecución para el bloque.
La siguiente tabla muestra las fórmulas de costo para caminos de acceso a
relaciones simples. Estas fórmulas se calculan basándose en la suma del número
de páginas de índices y las paginas de datos más el factor de peso multiplicado
por las “RSI call”. En algunos casos se dan varias alternativas dependiendo de si
el conjunto de tuplas rescatadas “cabe” completamente en el RSS buffer pool.
Para índices en cluster se asume que una página permanecerá en el buffer lo
suficiente como para que todas las tuplas puedan ser rescatadas de ella. Para
índices que no son en cluster y en el caso de aquellas relaciones que no caben en
59

el buffer, se asume que la relación es suficientemente grande con respecto al
buffer de manera que se requiere una lectura de página por cada tupla rescatada.
Situación
Indice único que calza con
un predicado de igualdad
Indice en cluster I que
calza con uno o más
factores booleanos
Indice I que calza uno o
más factores boléanos
Indice en cluster I que no
calza con ningún factor
booleano
Indice I que no calza con
ningún factor booleano
Costo
1 + 1 + W
F(preds) * (NINDX(I) + TCARD) + W * RSICARD
60
F(preds) * (NINDX(I) + NCARD) + W * RSICARD
o
F(preds) * (NINDX(I) + TCARD) + W * RSICARD
si este número cabe en el buffer de System R
(NINDX(I) + TCARD) + W * RSICARD
(NINDX(I) + NCARD) + W * RSICARD
o
(NINDX(I) + TCARD) + W * RSICARD si este
número cabe en el buffer de System R

Segment Scan
TCARD/P + W * RSICARD
Tabla 4-2 - Fórmulas de costo para caminos de acceso a relaciones simples
4.2.3. Selección del camino de acceso para joins.
El optimizador de system R tiene 2 métodos de selección de caminos de
acceso para los joins de dos relaciones (join de orden 2), primero se describirán
estos métodos y luego se discutirá como ellos pueden ser extendidos para joins
con más de 2 relaciones (join de orden n). Para el primer caso, la relación base
recibirá el nombre de relación outer, la segunda relación se le llamará inner y
corresponderá a la relación de la cual se sacarán las tuplas dependiendo de los
valores obtenidos de la relación outer. Un predicado que relaciona columnas de 2
relaciones de un join se llamará un predicado de join, las columnas referenciadas
en estos predicados se llamaran columnas de join.
El primer método se llama nested loops (ciclos anidados) y consiste en
recorrer ambas relaciones en cualquier orden. Primero se abre un scan sobre la
relación outer y se rescata la primera tupla, para cada tupla de esta relación se
abre un “segment scan” en la relación inner para rescatar, una a la vez, las tuplas
que coinciden con el predicado de join.
El segundo método se llama merging scans (recorrido por mezcla), requiere
que las dos relaciones se recorran en el orden de las columnas de join. Esto
implica que, junto con las columnas mencionadas en las cláusulas ORDER BY y
GROUP BY, las columnas de un predicado equi-join (aquellos de la forma
tabla1.columna1 = tabla2.columna2) también definen “interesting orders”.
Si hay más de un predicado de join, uno de ellos es usado como predicado de join
y los restantes son tratados como predicados ordinarios. Este método solamente
61

se aplica a equi-joins, si una o ambas relaciones del join no tienen índices en las
columnas de join, estas deben ser ordenadas en una lista temporal por las
columnas de join.
Este método saca provecho del ordenamiento de las columnas de join
evitando recorrer la relación inner por cada tupla de la relación outer. Esto se hace
sincronizando ambos scans y recordando donde se encuentran las tuplas que
satisfacen el predicado de join. Un mayor ahorro de esfuerzos se logra si la
relación inner está en cluster sobre la columna de join (como debería si esta fuese
la salida de un sort sobre la columna de join). “Clustering” sobre una columna
significa que las tuplas que tienen el mismo valor en esta columna están
almacenadas físicamente cerca una de la otra de manera que el acceso a una
página traiga varias tuplas.
Un “join de orden n” se puede visualizar como una secuencia de joins de
orden 2. En esta visualización 2 relaciones formarán un join, el resultado de estos
se cruzara con una tercera relación para formar el segundo join y así
sucesivamente. En cada paso es posible identificar la relación outer (la que
generalmente es la composición del paso anterior) y la relación inner como la
relación que está siendo agregada al join. Es importante notar que no es necesario
que termine el primer join para que empiece el segundo. Tan pronto como se
tenga una tupla producto del primer join de orden 2, esta puede ser cruzada con
tuplas de la tercera relación con el fin de obtener tuplas que sirven para el tercer
join y así sucesivamente.
Otro factor a considerar en un join es el orden en que se escogen las
relaciones. Aunque la cardinalidad de una consulta de n relaciones sea la misma
indiferente del orden de elección, el costo de cruzarlas en distinto orden puede ser
substancialmente diferente. Si un bloque tiene n relaciones en su lista FROM
entonces existe n! (n factorial) formas de permutar el orden de las relaciones (la
62

explicación de esto se puede encontrar más adelante, en la sección 5.5). Una vez
que las primeras k relaciones han sido unidas, el método para cruzar esta
composición con la k+1 ésima relación es independiente del orden en que se
unieron las k anteriores. Usando esta propiedad, una forma eficiente de organizar
la búsqueda es encontrar el mejor ordenamiento para conjuntos sucesivamente
más grandes.
La heurística que se utiliza para reducir el número de permutaciones es
considerar sólo los ordenamientos los cuales tienen predicados de join que
relacionan la relación inner con el resto de las relaciones que participan en el join.
Esta heurística permite que todos los joins que requieran productos cartesianos se
realicen lo más tarde posible. Por ejemplo, si T1, T2 y T3 son las 3 relaciones de
una lista FROM y hay predicados de join entre T1 T2, y entre T2 y T3 pero sobre
columnas distintas, entonces las permutaciones siguientes no serán consideradas.
T1 – T3 – T2
T3 – T1 – T2
Para encontrar el plan óptimo para un join de orden n se construye un árbol
de posibles soluciones. Una solución consiste en una lista ordenada de relaciones
a ser unidas, el método de join y un plan que indique como se accesa cada
relación. Si una de las dos relaciones necesita ser ordenada antes del join,
entonces se guarda el costo de este ordenamiento en el plan. Para minimizar la
cantidad de “interesting orders” y con esto también el número de soluciones, se
calcularán clases de equivalencia para los “interesting orders”, y sólo la mejor
solución de cada una de las clases de equivalencia será guardada en el árbol.
El árbol de búsqueda se construye por medio de la iteración de las
relaciones que han sido juntadas hasta el momento. Primero, se encuentra la
mejor manera de accesar a cada relación simple para cada “interesting order” y
63

para el caso sin orden. Luego para cada una de las relaciones se elige la mejor
manera de juntar otra relación a esta (sujeta a las heurísticas para el
ordenamiento de join), esto produce soluciones para juntar pares de relaciones.
Luego se elige la mejor manera de juntar conjuntos de 3 relaciones, considerando
todos los conjuntos de 2 relaciones y agregándole una tercera relación
considerando las heurísticas para el ordenamiento de joins. Para cada plan que
juntará un conjunto de relaciones se guarda en el árbol el orden de la
composición. Esto ayuda a la consideración de usar un “merge join” que
eventualmente no requiera ordenamiento adicional de tuplas. Luego de que se
tienen todas las posibles soluciones, el optimizador elige la solución más barata
que da el orden requerido (si se ha especificado algún orden). Nótese que si existe
una solución con el orden correcto, no se necesitará efectuar un sort para
satisfacer las cláusulas ORDER BY o GROUP BY, a menos que la solución
ordenada sea más costosa que la más barata de las sin orden más el costo de
ordenarlas en el orden requerido.
4.2.4. Cálculo de costos para joins.
El costo para un join se calcula dado el costo de los scans en cada una de
las relaciones que participan y las respectivas cardinalidades. El costo de un scan
en las relaciones participantes se calcula con la fórmula de costo de relaciones
simples expuestas en el punto 4.2.2.
Sea C-outer(path1) el costo de recorrer la relación outer vía path1. Sea N la
cardinalidad de tuplas que satisfacen los predicados de la relación outer. N se
calcula como:
N = (producto de las cardinalidades de todas las relaciones T incluidas
hasta el momento).
64

Sea C-inner(path2) el costo de recorrer la relación inner aplicando todos los
predicados aplicables. Sea el costo de un “join nested loop”:
c-nested-loop-join(path1, path2) = C-outer(path1) + N * C-inner(path2)
El costo de un merge join se puede separar en el costo de hacer el join más
el costo del ordenamiento en cada una de las relaciones si fuese necesario. El
costo de efectuar el merge join es:
c-merge-join(path1, path2) = C-outer(path1) + N * C-inner(path2)
Para el caso en que la relación inner es ordenada en una relación temporal
no se aplica ninguna de las fórmulas dadas para caminos de acceso a relaciones
simples. En este caso el inner scan es como un “segment scan” a excepción de
que el método de “merging scan” hace uso del hecho de que la relación inner está
ordenada, por lo tanto no es necesario realizar un scan a toda la relación
buscando una coincidencia. Para este caso se utilizará la siguiente formula para el
costo de un “inner scan”:
C-inner(sorted list) = TEMPPAGES / N + W * RSICARD
Donde TEMPAGES es el número de paginas que se requieren para
mantener la relación inner. Esta formula asume que durante el “merge scan” cada
página de la relación inner se rescata una vez.
Es interesante observar que las formulas de costo para el “nested-loop-join”
y “merge-join” son esencialmente las mismas, la razón de porque algunas veces el
“merge-join” puede ser más eficiente es que el costo del inner scan puede ser
mucho más bajo. Una vez ordenada, la relación inner está en cluster sobre la
65

columna de join lo que minimiza el número de paginas rescatadas y, por lo tanto,
no es necesario hacer un scan sobre toda la relación con fin el de obtener una
coincidencia.
4.2.5. Costos de consultas anidadas.
Una consulta puede aparecer como operando de un predicado de la forma
“expresión operando consulta”, tal consulta es llamada consulta anidada o
subconsulta. Si el operador es uno de los cinco operadores escalares ( =, >, >=,

consultas son llamadas subconsultas correlacionadas. Una consulta
correlacionada debe, en principio ser re-evaluada para cada tupla candidata del
bloque referenciado. Esta re-evaluación debe ser hecha antes de que el predicado
padre de la consulta correlacionada pueda ser testeado para aceptación o rechazo
de la tupla candidata. Como ejemplo considérese la siguiente consulta:
SELECT NAME
FROM EMPLOYEE X
WHERE SALARY > (SELECT SALARY
FROM EMPLOYEE
WHERE EMPLOYEE_NUMBER = X.MANAGER)
Esta consulta selecciona los nombres de empleados que ganan más que
sus Jefes. Aquí X identifica el bloque y la relación que proporciona tuplas
candidatas para la correlación. Para cada tupla candidata de la consulta de primer
nivel, se utilizará el valor de MANAGER para la evaluación de la subconsulta, el
valor de la subconsulta se le retorna al predicado “SALARY >” con el fin de aceptar
o rechazar la tupla candidata.
Si una subconsulta de correlación no está directamente debajo del bloque
que referencia, sino que está separada por medio de uno o más bloques, entonces
la evaluación de la subconsulta de correlación debe ser hecha antes de la
evaluación del más alto de los bloques intermedios.
Por ejemplo:
67

Nivel 1 SELECT NAME
FROM EMPLOYEE X
WHERE SALARY > (
Nivel 2 SELECT SALARY
FROM EMPLOYEE
WHERE EMPLOYEE_NUMBER = (
Nivel 3 SELECT MANAGER
FROM EMPLOYEE
WHERE EMPLOYEE_NUMBER = X.MANAGER))
Esta consulta selecciona los nombres de los empleados que ganan más
que los Jefes de sus Jefes. Como antes se vio, para cada tupla candidata del
bloque de nivel 1 el valor de EMPLOYEE.MANAGER se usará para la evaluación
del bloque de nivel 3. En este caso, dado que la subconsulta de nivel 3 referencia
a una valor de nivel 1 pero no referencia a valores de nivel 2, esta es evaluada
una vez para cada tupla candidata de nivel 1 pero no para las tuplas candidatas de
nivel 2.
Si el valor referenciado por la subconsulta de correlación no es único en el
conjunto de tuplas candidatas entonces este procedimiento causará que la
consulta sea re-evaluada para cada ocurrencia de los valores repetidos. Sin
embargo si la relación a la que se hace referencia está ordenada por la columna
referenciada la re-evaluación puede ser condicional, y dependerá de saber si el
valor actual es el mismo que el de la tupla candidata procesada anteriormente. Si
son iguales entonces se puede utilizar la evaluación anterior, en algunos casos
incluso se puede ordenar la relación por la columna referenciada con el fin de
evitar la innecesaria re-evaluación de subconsultas. Con el fin de determinar si los
valores de una columna referenciada son únicos se pueden utilizar pistas como
NCARD > ICARD, donde NCARD es la cardinalidad de la relación y ICARD es la
cardinalidad del índice sobre la columna referenciada.
68

Capítulo 5. Optimización de consultas, Fundamento
teórico.
5.1. Introducción.
En Los modelos de Red y Jerárquico la optimización de consultas es tarea
propia del programador de aplicaciones, puesto que las instrucciones de
manipulación de datos son propietarias del lenguaje anfitrión. Por el contrario las
consultas de base de datos relacionales son o bien declarativas o algebraicas. Los
lenguajes algebraicos permiten la transformación algebraica de la consulta, luego,
basándose en la especificación algebraica de la consulta es relativamente fácil
para el optimizador generar diversos planes equivalentes para la consulta y elegir
el menos costoso.
Dado este nivel de generalidad, el optimizador puede ser visto como el
generador de código de un compilador para el lenguaje SQL, que produce el
código que será interpretado por el motor de ejecución de consultas, excepto que
el optimizador marca énfasis en la capacidad de producir el código más eficiente,
haciendo uso para tales efectos del catálogo de la base de datos, de donde
obtiene información estadística de las relaciones referenciadas por la consulta,
algo que los lenguajes de programación tradicionales no hacen.
Un aspecto de la optimización de consultas se sitúa en el nivel del álgebra
relacional. Dado un conjunto de reglas se trata de encontrar una expresión que
sea equivalente a la expresión dada pero que sea más eficiente en la ejecución.
69

Con el fin de seleccionar la mejor estrategia para la recuperación de datos
el optimizador “estima” un costo que estará relacionado a cada plan de ejecución.
Este costo está determinado por fórmulas predefinidas en base a información que
se posee de la tabla y que se ha rescatado previamente del catálogo de la base de
datos, en realidad el optimizador no siempre escoge el plan más óptimo, ya que
encontrar la estrategia óptima puede consumir mucho tiempo, por lo tanto se dice
que el optimizador “sólo escoge una estrategia razonablemente eficiente”. La
manera con la que el optimizador utiliza esa información, las distintas técnicas y
algoritmos que aplica y las transformaciones algebraicas que se realizan son las
que diferencian a los optimizadores de bases de datos.
Un optimizador basado en el costo genera una serie de planes de
evaluación para una consulta y luego elige el que tiene un menor costo asociado,
las medidas de costo comúnmente tienen que ver con la E/S y el tiempo de CPU
utilizado en ejecutar la consulta, sin embargo, es cuestión de cada SGBD el elegir
las medidas de costo que mejor representen el criterio de minimización en la
utilización de recursos.
5.2. Información del catálogo.
Como se ha mencionado anteriormente, la información del catálogo de la
base de datos le sirve al SGBD para estimar el costo de los planes de ejecución
de una consulta. La precisión de esta información esta ligada directamente a la
periodicidad con la que se actualizan las estadísticas del catálogo. En un caso
ideal, cada vez que se compromete una transacción de base de datos se deberían
actualizar las estadísticas del sistema, sin embargo, esto no es posible en un
70

entorno OLTP 13 dada la sobrecarga que estas operaciones le dan al sistema
(básicamente bloqueos en las tablas del catálogo). La solución está entonces en la
posibilidad de actualizar estas estadísticas en periodo de poca carga del sistema,
algunos SGBD tienen técnicas de optimización automáticas de las estadísticas
(como es el caso de MS-SQLServer [Bjeletich99]) pero en general se recomienda
que esta tarea la ejecute el DBA con la periodicidad que le dicte la experiencia. En
todo caso, la información será más precisa cuanto más bajo sea el nivel de
actualizaciones en el intervalo de tiempo entre actualizaciones de Estadísticas.
Cada SGBD tiene distinta información que guardar en el catálogo y por
ende, el catálogo de la base de datos es distinto entre cada uno de estos motores,
sin embargo, hay información que todo optimizador debe guardar:
n r Número de tuplas de la relación r
b r Número de bloques que contienen tuplas de la relación r
t r Tamaño en bytes de una tupla de r
f r Factor de bloqueo de r. Número de tuplas de r que caben en un bloque.
V ( A,
r)
Número de valores distintos del atributo A de la relación r
CS ( A,
r)
Número medio de tuplas de r que satisfacen una condición de igualdad
sobre el atributo A de la relación r
CS ( A,
r)
= 1 Si A es clave de r
nr
CS(
A,
r)
=
V ( A,
r)
Si A no es clave de r, se asume una distribución
71
uniforme de los datos de A sobre r
Tabla 5-1 - Información del Catálogo para relaciones simples.
13 On Line Transaction Processing: tipo de procesamiento en el cual el computador
responde los requerimientos de usuario inmediatamente, cada requerimiento es considerado una
transacción. Un ejemplo de este tipo de procesamiento es el de los cajeros automáticos.

Por ejemplo, si n r = 10 y V(sexo,r) = 2 entonces CS(sexo,r) = 10 / 2 = 5, se
asume por lo tanto que el atributo sexo se distribuye homogéneamente sobre r.
n r ⎡n
⎤ r
Se asume además que si = f r entonces b r = ⎢ ⎥
br
⎢ f r ⎥
Además de la información del catálogo para las relaciones, se utiliza
información acerca de los índices:
g Grado de salida de los nodos internos del índice i (para índices con
i
estructura de Arbol B+)
AA i
Altura del índice para el atributo A de r.
AAi =
i
⎡log f ( V ( A,
r))
⎤
MB Número de bloques que ocupa el nivel más bajo (nivel de hojas) del índice i
i
5.3. Medidas de costo.
Tabla 5-2 - Información del catálogo para índices de Relaciones.
El costo de un plan de ejecución se puede expresar en términos de distintos
recursos de hardware, por ejemplo, en el caso de system R se hace en función de
la cantidad de CPU utilizada y de la cantidad de páginas de disco rescatadas. En
los SGBD distribuidos se agrega a las medidas el costo de la comunicación de
redes. En los sistemas que no son centralizados conviene creer que una buena
medida del costo de utilización de recursos es la que está dada por la
transferencia de datos desde el disco a la memoria. Para simplificar los cálculos
de costo se asume que toda operación que recupere datos de disco tiene el
mismo costo, obviando, por simplicidad, los tiempos involucrados en latencia
rotacional y el tiempo de búsqueda (ver apéndice C apartado C.1.1) .
72

El costo de todos los algoritmos de optimización depende en gran manera
del tamaño de la memoria intermedia (caché) que tenga la memoria principal. En
el mejor de los casos todos los datos requeridos se encuentran en la memoria
principal por lo que no se hace necesario acceder al disco.
Al igual que en el caso del optimizador de system R, este trabajo presenta
los algoritmos de optimización considerando el peor caso, en el cual sólo algunos
datos caben en la memoria principal, más bien dicho, sólo un bloque por relación.
5.3.1. Caminos de acceso a selecciones simples.
5.3.1.1. Exploraciones sin índices.
Los siguientes algoritmos implementan la operación de selección sobre una
relación cuyas tuplas están almacenadas de manera contigua en un archivo 14 .
A1. Búsqueda lineal (Full scan o table scan): Se examina cada bloque del
archivo y se comprueba si los registros cumplen con la condición de selección. El
costo estimado de este algoritmo es :
C = b
A2. Búsqueda binaria: Si la tabla esta ordenada físicamente por el atributo A y la
condición de selección es una igualdad sobre el atributo entonces se puede utilizar
búsqueda binaria [Kruse84].
14 Se entenderá como archivo al medio de almacenamiento físico en disco ya sea por
medio de sistemas de archivos o como device de datos (raw devices) dependiendo de las
características del motor de base de datos y del sistema operativo que lo soporta.
A1
r
73

⎡CS(
A,
r)
⎤
⎢ ⎥
⎢ f r ⎥
El costo estimado será : = ⎡ ( ) ⎤+ −1
Basado en la suposición de que los bloques de la relación se almacenan de
manera contigua en el disco, donde ⎡log 2 ( r ) ⎤
C
A2
log 2
b
r
74
b es el costo de localizar la primera
⎡CS(
A,
r)
⎤
tupla por medio de búsqueda binaria, y ⎢ ⎥ −1
es el número de bloques que
⎢ f r ⎥
cumplen la condición de igualdad sobre el atributo A menos el bloque que se ha
rescatado con la búsqueda binaria.
5.3.1.2. Exploraciones con índices.
Se denomina “camino de acceso” (access path) a cada una de las formas
de acceder a los registros de una tabla por medio de la utilización de índices. Se
entiende como índice primario al índice que permite recorrer los registros de una
tabla en un orden que coincide con el orden físico de la tabla, un índice que no es
primario se denomina índice secundario. En sybase, un índice en cluster siempre
recibe el número 1 dentro del conjunto de índices que pertenecen a una tabla en
estrecha relación con la definición de índice primario.
Los algoritmos de búsqueda que utilizan un índice reciben el nombre de
“exploraciones de índice” o “index scan”. Aunque los índices aseguran la mayor
velocidad de acceso a los datos, su utilización implica el acceso a los bloques
propios del índice, lo que se puede considerar como un gasto adicional y el cual
debe ser tomado en cuenta en la elaboración de algoritmos de acceso a los datos.
Los siguientes algoritmos son los algoritmos de acceso a datos por medio
de índices, ya sea primarios o secundarios.

A3. (índice primario, igualdad en la clave): Dado que el índice está construido
sobre el (los) atributos claves, la búsqueda puede utilizar este índice para rescatar
los datos. Por lo tanto para recuperar el único registro que cumple con la condición
se necesita leer sólo un bloque.
El costo estimado será:
C
A3
= AAi
+ 1
A4. (índice primario, igualdad basada en un atributo no clave): El costo está
determinado por la cantidad de bloques que contienen registros que cumplen con
la condición de igualdad más la altura del índice.
Ejemplo: supóngase que
n viaje = 36000,
b viaje = 2391,
t viaje = 136,
f viaje = 15,
⎡CS(
A,
r)
⎤
El costo estimado será: C A4
= ⎢ ⎥ + AAi
⎢ fr
⎥
que existe un índice B+ primario para las columnas PATENTE+CORRELATIVO.
Se desea seleccionar todos las tuplas de la tabla viajes que tengan como patente
= ‘HL-8483’.
Como V(PATENTE,VIAJES) =30, se estima que 36000/30=1200 tuplas de la
relación viajes sean del móvil con patente ‘HL-8483’. Se puede utilizar el índice
primario para leer los 1200/15=80 bloques que cumplen con la condición.
75

Ahora bien, supongamos que el índice tiene un tamaño del puntero a disco
de 8 bytes, sabiendo que el tamaño de la clave del índice es de 12 bytes es lógico
pensar que para un bloque de 2 Kb. El número de claves por bloque de índice es
aproximadamente 100. Entonces, una búsqueda por el índice necesitará a lo sumo
⎡log50 ( 36000)
⎤
= 3 accesos a bloques de disco, por lo tanto el número total de
bloques a disco a leer es de 83 (Una explicación acerca de los cálculos realizados
para la estimación de accesos a bloques se puede encontrar en el apéndice B).
A5. (Índice secundario, igualdad): Si el campo indexado no es clave se asume
que se rescatará CS(A,r) registros, como el índice es secundario se estudia el peor
caso, el cual propone que cada uno de los registros se encuentra en un bloque
diferente, por lo tanto el costo de este caso es :
C A 5 = AAi
+ CS(
A,
r)
o
C A5
= AAi
+ 1 si el atributo es clave.
A6. (Índice primario, desigualdad): Si lo que se desea es una selección del tipo
σ (r)
con v disponible en el momento de la estimación del costo y asumiendo
A≤v
que los datos del atributo A se distribuyen uniformemente entonces, el número de
registros que cumplen con la desigualdad es :
n σ = 0 si v < min(A,r)
n = n r si v > max(A,r)
σ
n σ =
v − min( A,
r)
nr ⋅ en otro caso.
max( A,
r)
− min( A,
r)
76

En cuanto al costo:
Dado que el índice es primario se sabe que la tabla está ordenada por el
valor de la clave, por lo tanto, si el operador es > ó >= se realiza una búsqueda por
el índice primario para encontrar a v en A y luego se realiza un recorrido lineal
partiendo desde esta tupla y hasta el fin de la tabla, lo que devolverá todas las
tuplas que cumplen con la condición A >= v. Para una desigualdad del tipo < ó

No siempre es conveniente utilizar los índices para recuperar rangos de
valores, considérese el siguiente ejemplo:
Supóngase que la la información estadística es la misma que se
proporcionó anteriormente, que existe un índice B+ secundario para la columna
TARIFA de la tabla viajes y que se desea seleccionar todas las tuplas de la tabla
viajes que tengan una tarifa menor a 5000.
Como el tamaño de la clave del índice es de 4 bytes, es lógico pensar que
en una página de índice caben 170 claves. Por lo tanto el índice necesita
⎡log85 ( 36000)
⎤
= 3 accesos a bloques de disco para recuperar la primera hoja del
índice que se va a ocupar. Suponiendo que existen 600 valores distintos de tarifas,
entonces existen entre 600/170 ≅ 4 a 8 nodos hojas en el árbol, por lo que, en el
peor de los casos se deben leer 8/2 = 4 bloques de índices más 36000/2 = 18000
accesos a bloques de datos. Por lo tanto, el costo de este camino de acceso es de
18000+4+3 = 18007.
Por el contrario un full scan sobre la tabla empleará solamente b viaje = 2391
bloques en vez de los 18007 calculados para el camino de acceso por índice
secundario, por lo tanto, de presentarse este ejemplo, el optimizador de consultas
optará por un full scan.
5.3.2. Conjunción, Disyunción y Negación.
Conjunción.
Una selección conjuntiva es expresión una de la forma
σ θ 1∧
θ 2...
∧θm
78
( r)
Suponiendo que cada una de las condiciones θi es independiente de las otras se
.

puede estimar el tamaño de cada selección = σ (r ) . La probabilidad de que
ti θi
una tupla satisfaga la condición de selección es
t
n
i
r
79
(llamada selectividad de la
selección) y la probabilidad de que una tupla satisfaga la conjunción de
selecciones es el producto de todas estas probabilidades.
Como
Por lo tanto se estima el tamaño de la selección completa como:
Disyunción.
n
r
t
⋅
1
⋅ t
2
⋅ t
n
3
m
r
⋅ ... ⋅ t
Una selección disyuntiva es una expresión de la forma
ti denota la probabilidad de que una tupla cumpla i
n
r
m
σ θ 1∨
θ 2...
∨θm
( r)
θ entonces, la
probabilidad de que una tupla cumpla la disyunción es 1 menos la probabilidad de
que no cumpla ninguna de las condiciones.
1 −
( 1
t1
t 2 t m
− ) ⋅ ( 1 − ) ⋅ ... ⋅ ( 1 − )
n n n
r
por lo tanto, al multiplicar este valor por n r se obtiene el número de tuplas
que satisfacen la relación.
Negación.
r
r
.

Como el resultado de una negación son simplemente las tuplas de r que no
están en σ (r)
, entonces el número de tuplas que cumplen con la condición de
θ
negación es:
tamaño θ
( r)
− tamaño(
σ ( r))
Algoritmos para la conjunción y disyunción.
A8.(selección conjuntiva utilizando un índice simple): primero hay que
determinar si hay disponible un camino de acceso a una de las condiciones
simples, de ser así, se puede utilizar cualquier algoritmo del A1 al A7. Luego, en
memoria intermedia se verifica que los registros cumplan el resto de las
condiciones. Se utiliza la selectividad de las condiciones para determinar en que
orden efectuar las selecciones. La condición más selectiva (la que tiene la
selectividad más pequeña) recupera un mayor número de registros, por lo tanto
esta condición se debe comprobar en primer lugar.
A9.(selección conjuntiva, índice compuesto): si la selección especifica una
condición de igualdad en dos o más atributos y existe un índice compuesto en
estos campos, se podría buscar en el índice directamente. El tipo de índice
determina cual de los algoritmos A3, A4 o A5 se utilizará.
A10.(selección conjuntiva, intersección de identificadores): este algoritmo
utiliza índices con punteros a registros en los campos involucrados para cada
condición individual. De este modo se examina cada índice en busca de punteros
cuyas tuplas cumplan alguna condición individual. La intersección de todos los
punteros recuperados forma el conjunto de punteros a tuplas que satisfacen la
condición conjuntiva.
80

A11. (selección disyuntiva mediante la unión de identificadores): al igual que
en el caso anterior se utilizan los caminos de acceso en cada una de las
condiciones, la unión de los punteros forma el conjunto de punteros a tuplas que
satisfacen la condición disyuntiva, sin embargo se deberá efectuar una búsqueda
lineal si sólo una de las condiciones (o más) no tiene caminos de acceso.
Ejemplo:
Dada la consulta :
SELECT * FROM VIAJES WHERE PATENTE = ‘HL-8483’ AND TARIFA = 2000
Suponiendo que la información estadística es la misma de los ejemplos
anteriores, si se utiliza el índice que contiene el atributo PATENTE se necesitan 83
accesos a disco como se observo anteriormente.
Si se utiliza el índice en TARIFA, como hay 600 valores diferentes en el
atributo tarifa, significa que CS(TARIFA,VIAJES) = 36000/600 = 60; por lo que en el
peor de los casos hay que leer 60 bloques de disco para recuperar cada una de
las tuplas. Se sabe además que la altura del índice en el atributo tarifa es de 3, por
lo tanto se necesitan sólo 60+3=63 accesos a disco a diferencia de las 83 que se
necesitan por medio del uso del índice primario.
Otra técnica que se puede utilizar es la de intersección de identificadores.
Para este efecto se sabe que ambos índices tienen altura = 3. para el índice
primario, el número de punteros a recuperar es 1200 los cuales caben en
1200/100 = 12 bloques de índice, para el índice secundario el número de punteros
a rescatar es de 60 los cuales caben en una sola página. Por lo que hasta el
momento se necesitan 6 + 12 + 1 = 19 bloques. Para los bloques de datos se
81

necesita estimar la cantidad de tuplas que cumplen con la conjunción, como
CS(PATENTE,VIAJES)=1200 y CS(TARIFA,VIAJES)=60 entonces se sabe que
(1200*60)/36000 = 2 registros cumplen con la condición conjuntiva, los que en el
peor de los casos se rescatan con 2 accesos a bloques de disco, por lo tanto este
algoritmo ocupa un total de 21 accesos a disco a diferencia de los 63 que ocupa el
camino de acceso del índice secundario. Esta estimación se fundamenta en la
suposición de que la distribución de los datos en PATENTES y en TARIFAS es
independiente y de que ambos atributos están distribuidos uniformemente en la
relación.
5.3.3. JOIN.
Estimación del tamaño.
Sean r(R) y s(S) dos relaciones:
Si R I S=∅ entonces r s es lo mismo que r x s, y por lo tanto se puede
utilizar la estimación del producto cartesiano.
Si R I S es una clave de R entonces el número de tuplas en r s no es
mayor que el número de tuplas en S. Si R I S es una clave externa de R entonces el
número de tuplas de r s es exactamente el número de tuplas de S.
Si R I S no es clave de R ni de S entonces se supone que cada valor
aparece con la misma probabilidad , por lo tanto, sea t una tupla de r y sea
R I S={A}, entonces se estima que la tupla t produce :
ns
CS(
A,
s)
=
V ( A,
s)
82

tuplas en s, por lo tanto se estima el tamaño de r s =
al cambiar los papeles de r y s se tiene
nr ⋅ ns
V ( A,
r)
nr ⋅ ns
V ( A,
s)
Estos valores serán distintos si y sólo si V(A,r) ≠ V(A,s), si este es el caso, la
más baja estimación de ambas será la más conveniente.
Algoritmos.
5.3.3.1. Join en bucles anidados.
Si z = r s, r recibirá el nombre de relación externa y s se llamará relación
interna, el algoritmo de bucles anidados se puede presentar como sigue.
resultado
para cada tupla tr en r
para cada tupla ts en s
si (tr,ts) satisface la condición θ entonces añadir tr • ts al
Algoritmo 5-1 - Join en bucles anidados.
Donde tr • ts será la concatenación de las tuplas tr y ts .
Como para cada registro de r se tiene que realizar una exploración
completa de s, y suponiendo el peor caso, en el cual la memoria intermedia sólo
puede concatenar un bloque de cada relación, entonces el número de bloques a
acceder es de br + nr
⋅ bs
. Por otro lado, en el mejor de los casos si se pueden
(a)
(b)
83

contener ambas relaciones en la memoria intermedia entonces sólo se
necesitarían b r + bs
accesos a bloques.
Ahora bien, si la más pequeña de ambas relaciones cabe completamente
en la memoria, es conveniente utilizar esta relación como la relación interna,
utilizando así sólo b r + bs
accesos a bloques.
5.3.3.2. Join en bucles anidados por bloques.
Una variante del algoritmo anterior puede lograr un ahorro en el acceso a
bloques si se procesan las relaciones por bloques en vez de por tuplas.
para cada bloque Br de r
para cada bloque Bs de s
para cada tupla tr en Br
para cada tupla ts en Bs
si (tr,ts) satisface la condición θ entonces añadir tr • ts
al resultado
Algoritmo 5-2 - Join en bucles anidados por bloques.
La diferencia principal en costos de este algoritmo con el anterior es que en
el peor de los casos cada bloque de la relación interna s se lee una vez por cada
bloque de r y no por cada tupla de la relación externa, de este modo el número de
bloques a acceder es de br + br
⋅ bs
donde además resulta más conveniente utilizar
la relación más pequeña como la relación externa.
84

5.3.3.3. Join en bucles anidados por índices.
Este algoritmo simplemente sustituye las búsquedas en tablas por
búsquedas en índices, esto puede ocurrir siempre y cuando exista un índice en el
atributo de join de la relación interna. Este método se utiliza cuando existen
índices así como cuando se crean índices temporales con el único propósito de
evaluar la reunión.
El costo de este algoritmo se puede calcular como sigue: para cada tupla de
la relación externa r se realiza una búsqueda en el índice de s para recuperar las
tuplas apropiadas, sea c = costo de la búsqueda en el índice, el cual se puede
calcular con cualquiera de los algoritmos A3, A4 o A5. Entonces el costo del join
es + n ⋅ c ; si hay índices disponibles para el atributo de join en ambas
br r
relaciones, es conveniente utilizar la relación con menos tuplas.
5.3.3.4. Join por mezcla.
El algoritmo de Join por mezcla se pude utilizar para calcular un Join natural
o un equi-join. Para tales efectos ambas relaciones deben estar ordenadas por los
atributos en común.
Este algoritmo asocia un puntero a cada relación, al principio estos punteros
apuntan al inicio de cada una de la relaciones. Según avanza el algoritmo, el
puntero se mueve a través de la relación. De este modo se leen en memoria un
grupo de tuplas de una relación con el mismo valor en los atributos de la reunión.
85

Pr = dirección de la primera tupla de r;
ps = dirección de la primera tupla de s;
mientras (ps nulo y pr nulo)
inicio
ts = tupla a la que apunta ps;
S = {ts};
ps = puntero a la siguiente tupla de s;
hecho = falso;
mientras (not hecho y ps nulo)
inicio
ts' = tupla a la que apunta ps;
si (ts'[AtribsReunión] = ts[AtribsReunión])
S = S union {ts'};
ps = puntero a la siguiente tupla de s;
sino
hecho = verdadero;
fin mientras;
tr = tupla a la que apunta pr;
mientras (pr nulo y tr[AtribsReunión] < ts[AtribsReunión])
inicio
pr = puntero a la siguiente tupla de r;
tr = tupla a la que apunta pr;
fin mientras;
mientras (pr nulo y tr[AtribsReunión] = ts[AtribsReunión])
inicio
para cada ts en S
añadir ts x tr al resultado
pr = puntero a la siguiente tupla de r;
tr = tupla a la que apunta pr;
fin mientras
fin mientras
Algoritmo 5-3 - Join por mezcla.
86

Dado que las relaciones están ordenadas, las tuplas con el mismo valor en
los atributos de la reunión aparecerán consecutivamente. De este modo solamente
es necesario leer cada tupla en el orden una sola vez. Puesto que sólo se hace un
ciclo en ambas tablas, este método resulta eficiente; el número de accesos a
bloques de disco es igual a la suma de los bloques de las dos tablas b r + bs
. Si
una de las relaciones no está ordenada según los atributos comunes del join, se
puede ordenar primero para luego utilizar el algoritmo de join por mezcla. En este
caso hay que considerar también el costo de ordenar la o las relaciones y sumarlo
al costo de este algoritmo. Como se menciono anteriormente este algoritmo
necesita que el conjunto S de tuplas quepa completamente en la memoria
principal, este requisito se puede alcanzar normalmente, incluso si la relación s es
grande. De no poder cumplirse este requisito se deberá efectuar un join en bucle
anidado por bloques entre {S} y r con los mismos valores en los atributos del join,
con lo que el costo del join aumenta.
Una variación de este algoritmo se puede realizar aún en tuplas
desordenadas si existen índices secundarios en los atributos de join de cada una
de las relaciones, sin embargo, dada la naturaleza de este tipo de caminos de
acceso existe una alta probabilidad de que se necesite un acceso a bloque de
disco por cada tupla, lo que lo hace sustancialmente más costoso. Para evitar este
costo se puede utilizar un algoritmo de join por mezcla híbrido, que combina
índices con un join por mezcla. Si sólo una de las relaciones está desordenada
pero existe un índice secundario en el atributo de join, el algoritmo de join por
mezcla híbrido combina la relación ordenada con las entradas hojas del índice
secundario. El resultado de esta operación se debe ordenar según las direcciones
del índice secundario permitiendo así una recuperación eficiente de las tuplas,
según el orden físico de almacenamiento.
87

5.3.3.5. Join por asociación.
Al igual que el algoritmo de join por mezcla, el algoritmo de join por
asociación se puede utilizar para un Join natural o un equi-join. Este algoritmo
utiliza una función de asociación h para dividir las tuplas de ambas relaciones. La
idea fundamental es dividir las tuplas de cada relación en conjuntos con el mismo
valor de la función de asociación en los atributos de join.
Se supone que:
• h es una función de asociación que asigna a los atributos de join los valores
•
{0,1,...max}
• r , H ,...
0 r H 1 rmax
H denotan las particiones de las tuplas de r, inicialmente todas
vacías. Cada tupla r t se pone en la partición H r donde
i
( t [ Atributos _ de Join]
)
i = h r _
• H s , H s ,... H s denotan las particiones de las tuplas de s, inicialmente todas
0 1
max
vacías. Cada tupla ts se pone en la partición H s donde
i
( t [ Atributos _ de Join]
)
i = h s _
La idea detrás del algoritmo es la siguiente, supóngase que una tupla de r y
una tupla de s satisfacen la condición de join y por lo tanto tienen los mismos
valores en los atributos de join. Si estos valores se asocian con algún valor i,
entonces la tupla de r tiene que estar en H r y la tupla de s tiene que estar en H i
s , i
de este modo sólo será necesario comparar las tuplas de r en H r con las tuplas
i
de s en H s y no con las tuplas de s de otra partición.
i
88

tuplas
t r
El algoritmo es el siguiente.
para cada tupla t s en s
fin para;
( t [ Atributos _ de Join]
)
i = h s _ ;
= H s U{
ts}
;
H si
i
para cada tupla tr en r
( t [ Atributos _ de Join]
)
i = h r _ ;
= H r U{
tr}
;
H ri
i
fin para;
para i = 1 hasta max
[ Atributos de _ Join]
leer H s y construir un índice asociativo en memoria sobre él;
i
para cada tupla tr en H ri
_ ;
fin para;
fin para;
fin para;
explorar el índice asociativo en H s para localizar todas las
i
tales que [ Atributos de _ Join]
para cada tupla ts que concuerde en H si
añadir tr x ts al resultado;
t s
Algoritmo 5-4 - Join por asociación.
_ =
89

El índice asociativo (ver Apéndice B) en H s se construye en memoria por lo
i
que no se hace necesario acceder al disco para recuperar las tuplas, la función de
asociación utilizada para construir este índice es distinta a la función h utilizada
para construir las particiones. Después de la división de las relaciones el resto del
código realiza un join en bucle anidado por índices en cada una de las particiones.
Para lograr esto primero se construye un índice asociativo en cada H s y luego se
i
prueba (se busca en H s ) con las tuplas de H i
r . i
Se tiene que elegir el valor de max lo suficientemente grande como para
que, para cada i, las tuplas de la partición H s junto con el índice asociativo de la
i
relación quepan completamente en la memoria. Claramente será más conveniente
utilizar la relación más pequeña como la relación s. Si el tamaño de la relación s es
bs bloques, entonces para que cada una de las max particiones tengan un tamaño
menor o igual a M, max debe ser al menos ⎡bs / M ⎤ más el espacio adicional
ocupado por el índice asociativo. Una consideración a seguir para que las
divisiones de las relaciones se efectúe en un solo paso es que M>max+1 o
equivalentemente si M>( b/M)+1 s que de manera aproximada se simplifica a
M > bs
. Por ejemplo, si una relación contiene 440 bloques de 2KB cada uno,
entonces M > 440 , osea M > 20. De tal manera sólo se necesitarán 40 Kb. de
espacio de memoria (más el espacio requerido por el índice asociativo) para el
particionamiento de la relación.
El cálculo del costo de un join por asociación tiene la siguiente lógica: el
particionamiento de ambas relaciones reclama una lectura completa de cada
relación, como también su posterior escritura, esta operación necesita 2( b r + bs
)
accesos a bloques. Las fases de construcción y prueba (como se le denomina al
join en bucle anidado por índices) lee cada una de las particiones una vez
90

empleando b r + bs
accesos adicionales. El número de bloques ocupados por las
particiones podría ser ligeramente mayor que b r + bs
. Debido a que los bloques no
están completamente llenos,. El acceso a estos bloques puede añadir un gasto
adicional de 2·max a lo sumo, ya que cada una de las particiones podría tener un
bloque parcialmente ocupado que se tiene que leer y escribir de nuevo. Así el
costo estimado para un join por asociación es :
3( b r + bs
) + 2 ⋅ max
5.3.3.6. Join por asociación híbrida.
El algoritmo de join por asociación híbrida realiza otra optimización; es útil
cuando el tamaño de la memoria es relativamente grande paro aún así, no cabe
toda la relación s en memoria. Dado que el algoritmo de join por asociación
necesita max +1 bloques de memoria para dividir ambas relaciones se puede
utilizar el resto de la memoria (M – max – 1 bloques) para guardar en la memoria
intermedia la primera partición de la relación s, esto es H s , así no es necesaria
0
leerla ni escribirla nuevamente y se puede construir un índice asociativo en H s . 0
Cuando r se divide, las tuplas de H r tampoco se escriben en disco; en su
0
lugar, según se van generando, el sistema las utiliza para examinar el índice
asociativo en H s y así generar las tuplas de salida del join. Después de utilizarlas,
0
estas tuplas se descartan, así que la partición H r no ocupa espacio en memoria.
0
De este modo se ahorra un acceso de lectura y uno de escritura para cada bloque
de H r y H 0 s . Las tuplas de otras particiones se escriben de la manera usual para
0
reunirlas más tarde.
91

5.3.3.7. Join Complejos.
Los join en bucle anidado y en bucle anidado por bloques son útiles
siempre, sin embargo, las otras técnicas de join son más eficientes que estas,
pero sólo se pueden utilizar en condiciones particulares tales como join natural o
equi-join. Se pueden implementar join con condiciones más complejas tales como
conjunción o disyunción, aplicando las técnicas desarrolladas en la sección 5.3.2
para el manejo de selecciones complejas.
Dado un join de las forma r θ ∧ θ ∧...
∧θ
s se pueden aplicar una o más de las
1 2 n
técnicas de join descritas anteriormente en cada condición individual r θ s , el
i
resultado total consiste en las tuplas del resultado intermedio que satisfacen el
resto de las condiciones. Estas condiciones se pueden ir comprobado según se
generen las tuplas de r θ s . La implementación de la disyunción es homóloga a
i
la conjunción.
Outer Join (Join externos)
Un outer join es una extensión del operador join que se utiliza a menudo
para trabajar con la información que falta. Por ejemplo, suponiendo que se desea
generar una lista con todos los choferes y los autos que manejan (si manejan
alguno) entonces se debe cruzar la relación Chofer con la relación Movil. Si se
efectúa un join corriente se perderán todas aquellas tuplas que pertenecen a los
choferes, en cambio con un outer join se pueden desplegar las tuplas resultado
incluyendo a aquellos choferes que no tengan a cargo un auto. El outer join tiene
tres formas distintas: por la izquierda, por la derecha y completo. El join por la
izquierda ( ]x )toma todas las tuplas de la relación de la izquierda que no
92

coincidan con ninguna tupla de la relación de la derecha , las rellena con valores
nulos en los demás atributos de la relación de la derecha y las añade al resultado
del join natural. Un outer join por la derecha ( x [ ) ) es análogo al procedimiento
anterior y el outer join completo es aquel que efectúa ambas operaciones.
Se puede implementar un outer join empleando una de las dos estrategias
siguientes. La primera efectúa un join natural y luego añade más tuplas al
resultado hasta obtener el join externo. Sea r(R) y s(S) , para evaluar r ] x s se
calcula primero r s y se guarda este resultado en la relación temporal q1, a
continuación se calcula (q1)
∏ − que produce las tuplas de r que no participan
r R
del join, estas tuplas se rellenan con valores nulos en los atributos de s y se
añaden a q1 para obtener el resultado deseado. El procedimiento es homólogo
para los outer join por la derecha o completo.
La segunda estrategia significa modificar el algoritmo de join. Se pude
extender el algoritmo de join en bucles anidados para calcular el outer join por la
izquierda. Las tuplas de la relación externa que no concuerden con ninguna tupla
de la relación interna se completan con valores nulos y se escriben en la salida.
Para el caso de un outer join completo se puede calcular mediante
extensiones de los algoritmos de join por mezcla y join por asociación. En el caso
del algoritmo de join por mezcla, cuando se está produciendo la mezcla de ambas
relaciones, las tuplas de la relación que no encajan con ninguna tupla de la otra
relación se rellenan con valores nulos y se escriben en la salida. Puesto que las
relaciones están ordenadas, es fácil detectar si una tupla coincide o no con alguna
tupla de la otra relación. El costo estimado para realizar un outer join utilizando el
algoritmo de join por mezcla es el mismo que si fuera un join normal, la única
diferencia es el tamaño del resultado, por lo tanto el número de bloques a escribir
en el resultado puede aumentar.
93

5.3.3.8. Agregación.
La agregación es otra de las características del álgebra de relaciones
extendida. La idea de este tipo de funciones es que tomen un conjunto de valores
y que retornen un solo valor. se utilizan comúnmente para información agregada
(de ahí su nombre), analizan una agrupación de registros y rescatan el valor
solicitado, se aplican sobre un atributo o sobre una composición de atributos, el
valor retornado puede ser min, max, count, sum, avg, que corresponden
respectivamente a el mínimo valor del subconjunto; el máximo valor; una cuenta
de valores; la suma sobre algún atributo o composición de atributos y el promedio.
Para la implementación de la operación de agregación se puede utilizar un
algoritmo de ordenación o uno de asociación, para el caso de la asociación, lo que
se hace es agrupar las tuplas que tengan el mismo valor en los atributos de la
agregación y luego se aplica la función de agregación en cada uno de los grupos
para obtener el resultado.
El tamaño de la agregación sobre A es simplemente V(A,r). El costo
estimado de la implementación de la agregación es el mismo de una ordenación
(cualquiera sea el algoritmo).
En lugar de reunir todas las tuplas en grupos y aplicar entonces las
funciones de agregación, se pueden implementar sobre la marcha según se
construyen los grupos. Si las V(A,r) tuplas del resultado caben en memoria, las
implementaciones basadas en ordenación y las basadas en asociación no
requieren escribir bloques adicionales a disco, según se leen las tuplas se pueden
ir insertando en una estructura ordenada de árbol o en un índice asociativo, de
esta manera sólo se necesitan b r transferencias de bloques.
94

5.4. Evaluación de expresiones.
En este apartado se considerará como evaluar una expresión que contiene
varias operaciones, la forma intuitiva de evaluar una expresión es evaluar una
operación a la vez en un orden apropiado, el resultado de cada operación se
materializa en una relación temporal para su inmediata utilización. El
inconveniente de esta aproximación es la creación de relaciones temporales que
implican la escritura y lectura de disco. Una aproximación alternativa es evaluar
operaciones de manera simultanea en un cauce, con los resultados de una
operación pasados a la siguiente sin la necesidad de almacenarlos en relaciones
temporales.
5.4.1. Materialización.
Este enfoque de implementación toma la expresión y la representa en una
estructura anexa (comúnmente un árbol de operadores). Luego se comienza por
las operaciones de más bajo nivel, las entradas a estas operaciones son las
relaciones de la base de datos, estas operaciones se ejecutan utilizando los
algoritmos ya estudiados y almacenando sus resultados en relaciones temporales.
Luego se utilizan estas relaciones temporales para ejecutar las operaciones del
siguiente nivel en el árbol.
Una evaluación como la descrita se llama evaluación materializada, puesto
que los resultados de cada operación intermedia se crean (materializan) con el fin
de ser utilizados en la evaluación de las operaciones del siguiente nivel.
95

El costo de una evaluación materializada no es simplemente la suma de los
costos de las operaciones involucradas. Dado que los costos estimados de los
algoritmos presentados anteriormente no consideran el resultado de la operación
en disco, por lo tanto, al costo de las operaciones involucradas hay que añadir el
costo de escribir los resultados intermedios en disco. Suponiendo que los registros
del resultado se almacenan en una memoria intermedia y que cuando esta se
llena, los registros se escriben en el disco. El costo de copiar los resultados se
puede estimar en r r b n donde nr es el número aproximado de tuplas de la relación
resultado y fr es el factor de bloqueo de la relación resultado.
5.4.2. Encauzamiento.
Se puede mejorar la evaluación de una consulta mediante la reducción del
número de archivos temporales que se producen. Por ejemplo, considérese el join
de dos relaciones seguida de una proyección. Si se aplicara materialización en la
evaluación de esta expresión implicaría la creación de una relación temporal para
guardar el resultado del join y la posterior lectura de esta para realizar la
proyección. Estas operaciones se pueden combinar como sigue. Cuando la
operación de join genera una tupla del resultado, esta se pasa inmediatamente al
operador de proyección para su procesamiento. Mediante la combinación del join y
de la proyección, se evita la creación de resultados intermedios, creando en su
lugar el resultado final directamente.
La implementación del encauzamiento se puede realizar de dos formas:
1. Bajo demanda (enfoque top-down)
2. Desde los procedimientos (enfoque bottom-up)
96

En un encauzamiento bajo demanda el sistema reitera peticiones de tuplas
desde la operación de la cima del encauzamiento. Cada vez que un operador
recibe una petición de tuplas calcula la siguiente tupla a devolver y la envía al
procesador de consultas. En un encauzamiento desde los procedimientos, los
operadores no esperan a que se produzcan peticiones para producir las tuplas, en
su lugar generan las tuplas impacientemente. Cada operación del fondo del
encauzamiento genera continuamente tuplas de salida y las coloca en las
memorias intermedias de salida hasta que se llenan. Asi, cuando un operador en
cualquier nivel del encauzamiento obtiene sus tuplas de entrada de un nivel
inferior del encauzamiento, produce las tuplas de salida hasta llenar su memoria
intermedia de salida.
El sistema necesita cambiar de una operación a otra solamente cuando se
llena una memoria intermedia de salida o cuando una memoria intermedia de
entrada está vacía y se necesitan más tuplas de entrada para generar las tuplas
de salida. Las operaciones de encauzamiento se pueden ejecutar
concurrentemente en distintos procesadores.
El encauzamiento bajo demanda se utiliza comúnmente más que el
encauzamiento desde los procedimientos dada su facilidad de implementación.
5.4.3. Algoritmos de encauzamiento.
Supóngase un join cuya entrada del lado izquierdo esta encauzada, dado
que esta entrada no está completamente disponible, implica la imposibilidad e
utilizar un join por mezcla (dado que no se sabe si la esta entrada viene o no
ordenada). El ordenar la relación significa transformar el procedimiento en
materialización. Este ejemplo ilustra que la elección respecto al algoritmo a utilizar
97

para una operación y las elecciones respecto del encauzamiento son
dependientes una de la otra.
El uso eficiente del encauzamiento necesita la utilización de algoritmos de
evaluación que puedan generar tuplas de salida según se están recibiendo tuplas
por la entrada de la operación. Se pueden distinguir dos casos:
1. Solamente una de las entradas está encauzada.
2. Las dos entradas de un join están encauzadas.
Si únicamente una de las entradas está encauzada, un join en bucle
anidado indexado es la elección más natural, ahora bien, si se sabe de antemano
que las tuplas de la entrada encauzada están ordenadas por los atributos de join y
la condición de join es un equi-join también se puede usar un join por mezcla. Se
puede utilizar un join por asociación híbrida con la entrada encauzada como la
relación para probar (relación r). Sin embargo, las tuplas que no están en la
primera partición se enviarán a la salida solamente después de que la relación de
entrada encauzada se reciba por completo. Un join por asociación híbrida es útil si
la entrada no encauzada cabe completamente en memoria, o si al menos la
mayoría de las entradas caben en memoria.
Si ambas entradas están encauzadas, la elección de los algoritmos de join
se limita. Si ambas entradas están ordenadas por el atributo de join y la condición
de join es un equi-join entonces se puede utilizar el método de join por mezcla.
Otra técnica alternativa es el join por encauzamiento que se presenta a
continuación. El algoritmo supone que las tuplas de entrada de ambas relaciones r
y s están encauzadas. Las tuplas disponibles de ambas relaciones se dejan listas
para su procesamiento en una estructura de cola simple. Asimismo se generan
marcas especiales llamadas Fin r y Fin s , que sirven como marcas de fin de
98

archivo y que se insertan en la cola después de que se hayan generado todas las
tuplas de r y de s (respectivamente). Para una evaluación eficaz, se deberían
construir los índices apropiados en las relaciones r y s. Según se añaden las tuplas
a ambas relaciones se deben mantener los índices actualizados.
El algoritmo de join encauzado es el siguiente :
hechor = falso;
hechos = falso;
r = ∅ ;
s = ∅ ;
resultado = ∅ ;
mientras not hechor or not hechos
si la cola está vacía entonces esperar hasta que la cola no este vacía;
t = primera entrada de la cola;
si t = Finr entonces
sino
fin si
fin mientras
hechor = verdadero;
si t = Fins entonces
sino
fin si
hechos = verdadero;
si t es de la entrada r entonces
sino
fin si
r = r U {t};
resultado = resultado U ({t} s);
s = s U {t};
resultado = resultado U (r {t});
Algoritmo 5-5 - Join encauzado.
99

5.4.4. Transformación de expresiones relacionales.
100
Hasta ahora se han estudiado algoritmos para evaluar extensiones de
operaciones del álgebra relacional y se han estimado sus costos. Dado que una
consulta se puede evaluar de distintas maneras y por lo tanto con distintos costos
estimados, este apartado considerará formas alternativas y equivalentes a sus
expresiones.
5.4.4.1. Equivalencia de expresiones.
Cada implementación de base de datos tiene su forma de representación
interna de consultas independientes del lenguaje de consultas utilizado. La
representación interna debe cumplir con la característica de ser relacionalmente
completo, es por eso que comúnmente los motores de BD eligen la
representación del álgebra relacional en forma de árbol sintáctico abstracto para
su representación interna.
Dada una expresión del álgebra relacional, es trabajo del optimizador
alcanzar un plan de evaluación que calcule el mismo resultado que la expresión
dada pero de la manera menos costosa de generar. Para encontrar este plan de
evaluación el optimizador necesita generar planes alternativos que produzcan el
mismo resultado que la expresión dada y elegir el más económico de ellos. para
implementar este paso el optimizador debe generar expresiones que sean
equivalente a la expresión dada por medio del uso de las reglas de equivalencia
que se explican a continuación.

5.4.4.2. Reglas de equivalencia.
101
Una regla de equivalencia dice que las expresiones de dos formas son
equivalentes, por lo tanto se puede transformar una en la otra mientras se
preserva la equivalencia. Se entiende como preservar la equivalencia al hecho de
que las relaciones generadas por ambas expresiones tienen el mismo conjunto de
atributos y contienen el mismo conjunto de tuplas.
Formalmente se dice que se representa una expresión en su forma
canónica.
La noción de forma canónica es central a muchos brazos de la matemática
y otras disciplinas relacionadas. Esta puede ser definida como sigue:
Dado un conjunto de Q objetos (digamos consultas) y una noción de
equivalencias entre objetos (digamos, la noción de que q1 y q2 son equivalentes
si y sólo si ellas producen el mismo resultado), un subconjunto C de Q se dice la
forma canónica de Q (bajo la definición de equivalencia expuesta anteriormente) si
y sólo si cada objeto q en Q es equivalente a sólo un objeto c en C. El objeto c es
llamado la forma canónica de el objeto q. Todas las propiedades de interés que se
aplican al objeto q también se aplican a su forma canónica c; por lo tanto es
suficiente estudiar sólo el pequeño conjunto de formas canónicas C y no el
conjunto Q con el fin de probar una variedad de resultados.
las reglas de equivalencia para llevar la expresión relacional a una
equivalente son:

1. Cascada de proyecciones:
Π
2. Cascada de selecciones:
L1
3. Conmutación de selecciones:
( Π L2
(...( Π Ln ( E))...)) = Π L1(
E)
σ θ1
∧ σ θ 2(
E) = σ θ1(
σ θ 2(
E))
σ θ1(
σ θ 2(
E)) = σ θ 2(
σ θ1(
E))
4. Conmutación de selección y proyección.
5. Conmutación del Join.
Π L θ E θ L
( σ ( )) = σ ( Π ( E))
E = E
E
E1 θ 2 2 θ
1
102

6. Asociatividad del Join Natural.
caso1.
(E )
1
E = E (E 2 E 3)
E2 3 1
caso 2. θ 2 involucra sólo atributos de 2 E y E 3 .
(E )
1
θ1 E2
θ 2∧θ
3 E 3 = E1
θ1 ∧ θ 3 (E2
7. Distributividad de la selección con respecto al join.
E 2
caso 1. θ 0 involucra sólo atributos de E 1.
σ θ 0(E 1 θ E2 ) σ θ 0(
E1)
= θ E2
θ 2 E3)
103
caso 2. θ 1 involucra sólo atributos de 1 E y θ 2 involucra sólo atributos de
σ θ1∧
θ 2(
E
θ E2 ) θ1
1
= ( σ ( E )) ( ))
8. Distributividad de la proyección con respecto al join.
θ ( σ θ 2 E2
Si 1 L y 2 L son los atributos de 1 E y E2 respectivamente.
Π (E = ( Π ( E ))
L1 UL
2
1
θ E2 ) L1
1
θ
( Π L2
( E2
))

9. Conmutatividad de la unión y la intersección.
E U E = E U E
1
1
2
E I E = E I E
La diferencia de conjuntos no es conmutativa.
10. Asociatividad de la unión e intersección.
1
2
2
( E1
U E2
) U E3
= E1
U ( E2
U E3)
( E I E ) I E = E I ( E I E )
3
2
2
1
1
1
2
3
104
11. Distributividad de la selección con respecto a la unión, intersección y
diferencia.
σ ( E U E ) = σ ( E ) U σ ( E )
θ
1
1
1
2
σ ( E I E ) = σ ( E ) I σ ( E )
θ
2
2
1
1
σ ( E − E ) = σ ( E ) − σ ( E ) = σ ( E ) − E
θ
12. Distributividad de la proyección con respecto a la unión.
Ejemplo:
θ
θ
θ
1
∏ L ( E1 U E2
) = ( ∏ L ( E2
)) U ( ∏ L ( E1))
Tabla 5-3 - Reglas de equivalencia para expresiones relacionales.
θ
θ
θ
2
2
2
θ
1
2

105
Supóngase que lo que se desea es notificar a todos los dueños de
vehículos del año, que estén siendo conducidos por los choferes con menos
experiencia (supóngase un año o menos); la expresión relacional sería :
Π σ (( Dueños Moviles ) Choferes )
Dueño . nombre ( Moviles.
año=
2001∧Choferes.
Fecha _ licencia _ desde>
Fecha()
−1_
año
Se puede utilizar la regla 6.1 con el fin de asociar el Join.
Π σ ( Dueños ( Moviles Choferes ))
Dueño . nombre ( Moviles.
año=
2001∧Choferes.
Fecha _ licencia _ desde>
Fecha()
−1_
año
Aplicando la regla 5 se puede conmutar el Join.
Π σ (( Moviles Choferes ) Dueños )
Dueño . nombre ( Moviles.
año=
2001∧Choferes.
Fecha _ licencia _ desde>
Fecha()
−1_
año
Luego se aplica la regla 7.1 con el fin de distribuir la selección sobre el join.
Π σ ( Moviles Choferes )) Dueños )
Dueño . nombre (( Moviles.
año=
2001∧Choferes.
Fecha _ licencia _ desde>
Fecha()
−1_
año
Aplicando la regla 7.2 se obtiene :
Π σ ( Moviles))
σ ( Choferes)))
Dueños
)
Dueño . nombre ((( año=
2001
( Fecha _ licencia _ desde>
Fecha()
−1_
año

106
Las siguientes figuras muestran la expresión inicial y la final en una
estructura de árbol sintáctico.

107
Así, los optimizadores generan de manera sistemática expresiones
equivalentes a la consulta dada. El proceso se entiende como sigue: dada una
expresión, se analiza cada subexpresión para saber si se puede aplicar una regla
de equivalencia. De ser así se genera una nueva expresión donde la subexpresión
que concuerda con una regla de equivalencia se reemplaza por su equivalente.
Este proceso continúa hasta que no se pueden generar más expresiones nuevas.
Una optimización en términos de espacio se puede lograr como sigue. Si se
genera una expresión E1 de una expresión E2 mediante una regla de
equivalencia, entonces E1 y E2 son equivalentes en su estructura y por lo tanto
sus subexpresiones son idénticas. Las técnicas de representación de expresiones
que permiten a ambas expresiones apuntar a la subexpresión compartida pueden
reducir el espacio de búsqueda significativamente.
5.5. Ordenes de Join.
En los sistemas de base de datos relacionales tradicionales raramente se
encuentra una consulta que involucre más de 5 tablas, de este modo, el cálculo de
un orden de Join óptimo con el menor costo de evaluación por medio de una
búsqueda exhaustiva es perfectamente posible. Sin embargo, cuando esta
consulta involucra 8 o más tablas el problema no se puede determinar de esta
forma. Por lo tanto lo que se espera son algoritmos que calculen la mejor
aproximación a la solución. Estos algoritmos pueden ser separados en dos clases.
1. Heurísticas: Construyen un plan de evaluación paso a paso de acuerdo a
ciertos criterios predefinidos.

108
2. Aleatorios: Realizan una especie de “caminata aleatoria” a través del
espacio de todas las posibles soluciones.
Generalmente el espacio de soluciones se define como el conjunto de todos
los árboles que calculan el resultado del Join y que contienen cada relación base
exactamente una vez. Las hojas de estos árboles consisten en las relaciones
base, mientras que los nodos internos corresponden a los resultados de Join de
los correspondientes hijos. Dado que la operación Join es conmutativa y asociativa
(ver equivalencia de expresiones algebraicas en la sección 5.4.4.1) el número de
posibles árboles de proceso se incrementa rápidamente a medida que se
incrementa el número de relaciones bases que participan en el Join. Existe un
subconjunto de este espacio de soluciones, comúnmente llamado “árboles en
profundidad por la izquierda” que ha sido de especial interés en los estudios de
optimizadores de consultas [Steinbrunn93].
Árboles en profundidad por la izquierda.
Este subconjunto de soluciones consiste en todos los árboles donde la
relación interna de cada Join es una relación base. Para un número fijo de
relaciones base, la especificación de profundidad por la izquierda no deja ningún
grado de libertad concerniente a la forma del árbol, sin embargo, se sabe a ciencia
cierta que existen n! formas de agrupar n relaciones base en las hojas del árbol
[Steinbrunn93].
Árboles de disposición General.
La solución en este espacio no es restringida de ninguna manera, dado que
la forma de todos los posibles árboles puede ser arbitraria , la cardinalidad de este

109
⎛2(
n −1)
⎞
conjunto es mucho más alta: para n relaciones base existen ⎜ ⎟(
n −1)!
⎝ n −1
⎠
soluciones diferentes.
El problema de encontrar un buen orden de anidamiento puede ser
abordado de diferentes formas:
1. Algoritmos Determinísticos. Cada algoritmo en esta clase construye una
solución paso a paso de una forma determinística, ya sea aplicando
heurísticas o por medio de una búsqueda exhaustiva.
2. Algoritmos Aleatorios. Para estos algoritmos se define un conjunto de
movimientos.
Estos movimientos constituyen un “margen” entre las diferentes soluciones
del espacio de soluciones. Dos soluciones son conectadas por un “margen”
si y sólo si, ellas pueden ser transformadas una en la otra por medio de un
sólo movimiento. Cada uno de estos algoritmos realizan una “caminata
aleatoria” a lo largo de los “márgenes” de acuerdo a ciertas reglas,
terminando ya sea si no existen más movimientos a realizar o si se ha
excedido un lapso de tiempo predeterminado. La mejor solución encontrada
hasta ese momento es la solución elegida.
3. Algoritmos Genéticos. Estos algoritmos hacen uso de la estrategia
aleatoria, muy similar a la evolución biológica. La idea básica es comenzar
con una población base y generar descendencia por medio de cruces
aleatorios, el más “digno” de los miembros de la población (de acuerdo a
una función de costo) sobrevive a la selección y la siguiente generación
estará basada en él. El algoritmo terminará ya sea si no hay mayor

110
perfeccionamiento o después de un determinado número de generaciones.
El miembro más digno de la población actual en el momento de terminar el
algoritmo será la solución elegida.
4. Algoritmos híbridos. Los algoritmos híbridos combinan las estrategias de los
algoritmos determinísticos y de los aleatorios. La idea es que la solución
obtenida por medio de algoritmos determinísticos sirva como punto de
partida para los algoritmos aleatorios o como población base para los
algoritmos genéticos.
5.5.1. Algoritmos Determinísticos.
5.5.1.1. Selectividad mínima.
Las buenas soluciones comúnmente se caracteriza porque los resultados
intermedios tienen una pequeña cardinalidad. La heurística de selectividad mínima
construye un árbol de profundidad por la izquierda paso a paso mientras trata de
mantener relaciones intermedias tan pequeñas como sea posible. El factor de
selectividad s de R1 R2 se define como:

111
Al principio, el conjunto de relaciones a ser unidas se dividen en dos
subconjuntos. El conjunto de relaciones ya incorporados en el resultado intermedio
denotado como Rusados y el conjunto de relaciones que aun quedan por unir con el
resultado intermedio que se denota como Rrestantes. Entonces, en cada paso de el
algoritmo la Relación Ri ∈ Rrestantes con el menor factor de selectividad
Rusados .
será mezclada con el resultado intermedio y será movida desde Rrestantes a
5.5.1.2. Heurística Top-Down.
El principio de esta técnica esta basado en la observación de que los
últimos Join son los más importantes para la expresión en términos de costo,
simplemente porque los resultados intermedios tienden a ser algo más largos
hacia el fin de la evaluación. Así, esta estrategia selecciona las relaciones del
conjunto que pueden ser mezcladas con menor costo con el resto de las
relaciones. Esta estrategia se aplicará repetidamente hasta que no queden
relaciones disponibles.
Ejemplo: suponiendo que existen 6 tablas (O, B, A, P, W, C) a ser unidas,
la primera relación en el orden será la que tiene el menor costo si se une con el
resto, suponiendo un costo h como medida mínima, el costo de cada una de las 6
combinaciones sería:

C(OBAPW C) = h
C(CBAPW O) = 35h
C(COAPW B) = 5h
C(COBPW A) = h
C(COBAW P) = h
C(COBAP W) = h
112
El costo para C, A, P y W es el mismo, por lo tanto se escogerá
arbitrariamente C, las 5 alternativas restantes del segundo paso son:
C(BAPW O) = 7h
C(OAPW B) = 5h
C(OBPW A) = h
C(OBAW P) = h
C(OBAP W) = h
Al escoger A como la siguiente relación, el tercer paso será:
El cuarto paso luego de escoger P:
C(BPW O) = 7h
C(OPW B) = 5h
C(OBW P) = h
C(OBP W) = h
C(BW O) = 7h
C(OW B) = 5h
C(OB W) = h

113
Luego de escoger W como la cuarta relación en el orden las alternativas
restantes son:
Así, el orden final de Join es :
C(B O) = 7h
C(O B) = 5h
((((O B) W ) P) A) C
Con un costo total de : (5+1+1+1+1) = 9h
5.5.2. Algoritmos Aleatorios.
Los Algoritmos aleatorios ven soluciones como puntos en un espacio de
soluciones y conecta estos puntos por márgenes que se definen como un conjunto
de movimientos. Este tipo de algoritmos realizan una suerte de caminata aleatoria
a través del espacio de soluciones a lo largo de los márgenes definidos como
movimientos. El tipo de movimientos que son considerados dependerá mucho del
tipo de espacio de soluciones. Si lo que se desea son árboles de profundidad por
la izquierda, cada solución sólo se puede representar por medio de una lista
ordenada de relaciones que participan en el Join.
5.5.2.1. Caminata aleatoria.
El algoritmo aleatorio más simple realiza una caminata a través del espacio
de soluciones empezando en un punto seleccionado aleatoriamente. En cada

114
paso del algoritmo se realiza un movimiento aleatorio y si el nuevo punto
constituye una mejor solución (en términos de la función de costo elegida) este se
almacenará como el nuevo resultado. El algoritmo terminará después de un
predeterminado número de movimientos y la mejor solución encontrada hasta el
momento será la solución elegida como resultado. En principio, este algoritmo
traza una muestra aleatoria desde el conjunto de todas las soluciones posibles y
entrega la mejor solución desde esta muestra. El rendimiento de este algoritmo
depende fuertemente del factor de buenas / malas soluciones y del tamaño de la
muestra elegida. Sin embargo, es obvio que esta estrategia es una perdida de
recursos dado que sólo cubre una pequeña área en la proximidad del punto de
partida y no se hace nunca un intento siquiera de encontrar un mínimo local.
5.5.2.2. Mejora Iterativa.
Un acercamiento más sofisticado es el algoritmo de mejora iterativa
[Swami88]. Luego de seleccionar una punto de partida aleatorio el algoritmo busca
un punto de costo mínimo. comenzando en el punto de partida, se elige al azar un
vecindario próximo (esto es, puntos que puedan ser alcanzados por exactamente
un movimiento), si el costo asociados a los vecinos es menor que el costo del
punto actual entonces el movimiento se lleva a cabo y se busca un nuevo vecino
con un menor costo. Un punto se definirá como mínimo local si no se han
encontrado vecinos con menor costo después de un cierto número de intentos.
Este procedimiento se repite hasta que se hayan procesado un número
predeterminado de puntos de partida o se haya excedido un límite de tiempo. El
menor de los mínimos locales encontrados será el resultado.

5.5.2.3. Simulación de cocción.
115
El algoritmo de mejora iterativa sufre de un gran inconveniente: dado que
los movimientos son aceptados sólo si mejoran el resultado obtenido hasta el
momento, es posible que aún con un alto número de puntos de partida el resultado
final sea inaceptable. Este será el caso cuando el espacio de solución no muestra
un mínimo global, sino que una gran número de mínimos locales de alto costo. En
este caso el algoritmo puede quedar fácilmente atrapado en uno de estos mínimos
locales.
El algoritmo de Simulación de cocción es un refinamiento de la Mejora
Iterativa que quita esta restricción. En el algoritmo de Simulación de cocción se
puede efectuar un movimiento aún si los puntos del vecindario son de costos altos.
Así este algoritmo no queda tan fácilmente atrapado en mínimos locales como el
algoritmo de Mejora Iterativa.
El nombre de este algoritmo viene del estudio del proceso de cocción de los
cristales, en este proceso natural el sistema eventualmente alcanza un estado de
mínima energía que se relaciona directamente con la temperatura que toman los
cristales.
La siguiente figura muestra este comportamiento. Mientras que el Algoritmo
de Mejora Iterativa se detiene en el primer mínimo local que encuentra, el
algoritmo de Simulación de cocción se salta la barrera de costo que separa este
punto del punto mínimo global, dado que este algoritmo siempre acepta
movimientos que lleven a una estado de menor costo, mientras que los
movimientos que incrementan el costo se aceptan con una probabilidad que
dependerá de la temperatura y de la diferencia entre el estado de costo actual y el
nuevo.

Figura 5-1 - Comportamiento del Algoritmo de Simulación de Cocción
116
En cualquier caso, el comportamiento exacto del algoritmo está
determinado por parámetros tales como la temperatura inicial, los pasos de
reducción de temperatura y la condición de fin. La literatura al respecto presenta
distintas variantes que no viene al caso estudiarlas acá. Para encontrar
referencias se recomienda consultar [Steinbrunn93].

5.5.3. Algoritmos Genéticos.
117
Los Algoritmos genéticos están diseñados para simular el proceso natural
de evolución. Al igual que en la naturaleza, donde el miembro más digno de una
población es el que tiene la mayor probabilidad de sobrevivir y de heredar sus
características a su descendencia, los algoritmos genéticos propagan soluciones
para un determinado problema de generación en generación, combinándolos para
alcanzar mejoras. A continuación se presenta una breve terminología, para una
compresión más detallada se recomienda consultar [Steinbrunn93].
Una de las características más importantes de los algoritmos genéticos es
que trabajan sobre un conjunto de soluciones (población). Las soluciones son
representadas como cadenas de caracteres (cromosomas) compuestos de
caracteres (genes) que pueden tomar diferentes valores. Por lo tanto el problema
que soluciona un algoritmo genético tiene una solución representada como una
cadena de caracteres con una codificación apropiada.
La “dignidad” de una solución se medirá de acuerdo a una función objetivo
que debe ser minimizada o maximizada. Generalmente, en un algoritmo genético
bien diseñado ya sea el índice de dignidad promedio como el de la mejor solución
se deben incrementar con cada nueva generación.

5.5.3.1. Algoritmo genético para la optimización de ordenes de Join.
El principio de este algoritmo es el siguiente.
118
Primero, se genera una población aleatoria de cadenas de caracteres, Esta
será la generación “cero” de soluciones. Luego, cada generación se determina
como sigue.
• Una fracción de los miembros más dignos de la población se propaga a la
siguiente generación (Principio de selección).
• Una fracción de los miembros más dignos de la población se combina
generando descendencia. (principio de combinación)
• Una fracción de la población (no necesariamente la más digna) se altera de
forma aleatoria (Principio de Mutación)
Estas fracciones son elegidas de modo que el número total de soluciones
permanezca invariante.
Este ciclo se itera hasta que la mejor solución en la población ha alcanzado
la calidad deseada, se ha producido un número predeterminado de generaciones
o hasta que la mejora entre una generación y otra ha caído por debajo de un cierto
umbral predeterminado.
Antes de que se pueda aplicar un cierto algoritmo se debe elegir una
codificación apropiada y una función objetivo. Para la optimización de ordenes de
join las soluciones son árboles ya sea de profundidad por la izquierda o de

119
disposición general. La función objetivo es la evaluación de costo a ser
minimizada.
Una codificación para el caso de los árboles de profundidad por la izquierda
puede ser representada únicamente por medio de una lista ordenada de sus
hojas.
Por ejemplo:
((((R1 R4) R3) R2) R5) produce la cadena “14325”.
Principio de Selección.
El operador de selección se utiliza para separar buenas y malas soluciones
de la población, la motivación de este ejercicio es el poder remover del espacio de
soluciones a las malas soluciones. En la Figura 5-2 se muestra un ejemplo de
selección. La población de muestra consiste de 4 soluciones, la función objetivo
dice que el costo debe ser minimizado. El costo para cada una de la soluciones se
lista en la tabla de la Figura 5-2. A cada solución se le asigna un sector en una
ruleta de tamaño inversamente proporcional al costo. Al cabo de 4 vueltas a la
ruleta se obtienen los resultados que se muestran en la segunda tabla de la Figura
5-2 donde la solución 4 se ha “extinguido debido a falta de adaptación”.

Figura 5-2 - Ejemplo del principio de selección para el algoritmo genético para la optimización de ordenes de Join
120
Este esquema se basa en el factor de “dignidad” de los miembros de la
población. Mientras mejor se satisfaga la función objetivo más posibilidades tiene
en la ruleta.
Principio de Combinación.
El operador de combinación es un medio para combinar parcialmente las
buenas soluciones con el fin de obtener un resultado superior. La realización de
una combinación dependerá fuertemente de la codificación escogida dado que, el
operador de combinación tiene que tener la certeza de que las características de
una codificación en particular no se han violado. Para el caso estándar de la

121
codificación estudiada en los árboles de profundidad por la izquierda se utiliza el
operador de combinación llamado “Intercambio de subsecuencias”.
Para cada uno de los dos padres se selecciona una subsecuencia aleatoria,
esta secuencia se quita de la cadena y el espacio dejado se reemplaza con los
caracteres del otro padre en orden de procedencia.
Figura 5-3 - Ejemplo del principio de combinación para el algoritmo genético para la optimización de ordenes de Join
En el ejemplo de la Figura 5-3 se selecciona la subsecuencia “532” de la
cadena “45321”, el primer caracter de su descendencia permanece igual que su
padre (4), el segundo caracter se toma del primer caracter del otro padre (3), el
segundo caracter del otro padre no puede se utilizado pues ya está presente (1),
por lo tanto el tercer caracter de la descendencia se sacará del tercer caracter del
otro padre, continuando este proceso se llega a “43521”. El proceso de determinar
la segunda descendencia de efectúa de igual forma.
Principio de Mutación.
El operador de mutación se utiliza para introducir características que no
están presentes en ningún miembro de la población. La mutación se lleva a cabo
por medio de la alteración aleatoria de una cadena seleccionada aleatoriamente.
Una forma básica de mutación es el intercambio (swap) de 2 caracteres aleatorios
dentro de una cadena.

122
Debido al carácter de la mutación como algo poco deseado en un proceso
evolutivo, este no debe ser aplicado sin control sobre una generación dado que
puede ser dañada severamente. Usualmente se realizan muy pocas mutaciones
en una generación.

5.6. Elección de los planes de evaluación.
123
Un plan de evaluación define exactamente que algoritmo utilizar para cada
operación y como coordinar la ejecución de las operaciones.
La Figura 5-4 muestra un plan de evaluación para la expresión analizada en
el ejemplo de la sección 5.4.4.2. Se hace la suposición respecto a algunos índices
con el fin de lograr encauzamiento.
Figura 5-4 - Un plan de evaluación de ejemplo

124
Una forma de elegir los planes de evaluación es simplemente elegir para
cada operación el algoritmo más económico para luego elegir cualquier
ordenación. Sin embargo, la elección independiente del algoritmo más económico
no es necesariamente la mejor elección. Por ejemplo, en una operación de Join,
bajo ciertas circunstancias puede ser más costosa con el algoritmo de join por
mezcla de lo que podría ser con un algoritmo de Join por asociación. Sin embargo,
la primera alternativa puede producir una salida ordenada que puede ayudar a la
evaluación de una operación posterior (como una eliminación de duplicados o la
entrada para otro join por mezcla) por lo tanto, para elegir el mejor algoritmo
genérico habrá que considerar incluso los algoritmos no óptimos de las
operaciones individuales.
Como en el caso de las expresiones equivalentes, se pueden utilizar reglas
parecidas para definir los posibles algoritmos de una operación, incluyendo aquí
las decisiones de encauzamiento de esta operación con otra a evaluar.
Existen 2 grandes aproximaciones para elegir el mejor plan de evaluación
de una consulta. La primera examina todos los planes y elige el mejor basándose
en el costo estimado. La segunda aproximación utiliza heurísticas.
La mayoría de los optimizadores actuales incorporan elementos de ambas
aproximaciones en la elección de los planes de ejecución.
5.6.1. Heurísticas.
Aunque sea paradojal, el mayor inconveniente de la optimización por costos
es precisamente el cálculo del costo, para aliviar este cálculo muchos

125
optimizadores utilizan heurísticas que ayudan a reducir el número de elecciones a
realizar en la optimización por costos.
Algunas de estas son utilizadas y aceptadas por la mayoría de los
optimizadores, a decir :
• Realizar las selecciones tan pronto como sea posible. Un optimizador
basado sólo en heurísticas debería aplicar esta regla al pie de la letra. Sin
embargo, un poco de estudio indica que existe la posibilidad de que el uso
de esta regla no ayude siempre a reducir el costo. Como ejemplo de lo
anterior, considérese la expresión σ ( r | x | s)
donde la condición θ se
refiere solamente a los atributos de s. Supóngase además que r es
extremadamente pequeño, y que existe un índice en los atributos de join,
pero no en los atributos de θ . Claramente en ese ejemplo es mala idea
realizar lo antes posible la selección, puesto que al no existir índices en los
atributos de θ aplicar la selección significaría recorrer todas las tuplas de s
(full scan), siendo que es más barato realizar el join (por medio de los
índices) y luego rechazar las tuplas que no cumplen la selección.
• Realizar las proyecciones al principio. Esta heurística se ocupa
comúnmente en el caso de que sea necesario generar una relación
temporal, se reduce la cantidad de atributos a seleccionar, lo que implica
reducir el tamaño de estas relaciones en gran medida.
Una revisión de las reglas de equivalencia del apartado 5.4.4.2 puede llevar a la
construcción de un algoritmo heurístico que reordene los componentes del árbol
sintáctico inicial con el fin de mejorar la ejecución de la consulta.
1. Deshacer las selecciones conjuntivas en una serie de selecciones simples,
basándose en la regla de equivalencia número 2 (ver apartado 5.4.4.2).
θ

126
2. Mover las operaciones de selección hacia abajo en el árbol de la consulta
para una ejecución tan pronto como sea posible. Esto se hace posible
aplicando las reglas de equivalencia 3, 7.1, 7.2 y 11 (ver apartado 5.4.4.2).
3. Determinar que operaciones de selección y join producirán las relaciones
temporales más pequeñas. Utilizando la asociatividad del join se reforma el
árbol de tal manera que las relaciones de los nodos hojas con estas
selecciones restrictivas se ejecuten primero. Este paso considera la
selectividad de una relación o de un join y tiene en cuenta la asociatividad
de las operaciones binarias consideradas en las reglas de equivalencia 6 y
10 (ver apartado 5.4.4.2).
4. Deshacer y mover tan abajo en el árbol como sea posible las listas de
atributos y proyecciones y crear nuevas proyecciones donde sea necesario
(atributos de join). Este paso incorpora las reglas de equivalencia 3, 8 y 12
(ver apartado 5.4.4.2).
5. Identificar aquellos subárboles cuyas operaciones se pueden encauzar y
ejecutarlas utilizando encauzamiento (ver apartado 5.4.2).
En resumen : estas heurísticas reordenan la representación inicial del árbol de una
consulta de tal modo que las operaciones que reducen el tamaño de los resultados
intermedios se apliquen primero; las selecciones anticipadas reducen el tamaño
de tuplas y las proyecciones reducen el número de atributos. Las transformaciones
heurísticas también reestructuran el árbol para que las selecciones y los joins más
restrictivos se realicen antes que otras operaciones similares.

127
La optimización heurística también hace corresponder la expresión de la
consulta heurísticamente transformada con secuencias alternativas de
operaciones para producir un conjunto candidato de planes evaluación.
Un plan de evaluación incluye no sólo las operaciones relacionales a
realizar, sino también los índices a utilizar, el orden en que se acceden las tuplas y
el orden en que se tienen que producir las operaciones.

128
Capítulo 6. El Optimizador de Consultas de Sybase
Adaptive Server Enterprise, un ejemplo práctico.
6.1. Introducción.
El optimizador de consultas de Sybase Adaptive Server Enterprise (ASE -
llamado antiguamente SQL-Server) se basa en estimaciones de costos, el objetivo
principal es, entonces, encontrar el camino de acceso más barato que minimice el
tiempo total de una consulta. Para alcanzar este objetivo, el optimizador de
consultas de ASE buscará caminos de acceso que:
en:
• Minimicen el acceso a páginas lógicas
• Minimicen el acceso a páginas físicas.
Los pasos que el optimizador ocupa para analizar una consulta son :
1. Análisis sintáctico (Parser) de la consulta validando además las referencias
de objetos.
2. Optimización de la consulta y generación del plan de la consulta.
3. Compilación del plan de la consulta.
4. Ejecución del plan y devolución del resultado al usuario.
Un estudio más detallado sobre el paso 2 llevará a una subdivisión de este

1. Análisis de la consulta.
2. Selección de Índices.
3. Selección de los ordenes de Join.
4. Uso de tablas temporales (Worktables).
5. Selección del plan.
6.2. Análisis de la Consulta.
129
El primer paso que realiza ASE es analizar cada tabla de la consulta con el
fin de reconocer los SARG (argumentos de búsqueda), las cláusulas OR y las
cláusulas de JOIN. La identificación de estas cláusulas sirve para que se utilicen
en la siguiente etapa para seleccionar índices.
Cláusulas SARG : La existencia de SARG en una consulta habilita al optimizador
a limitar el número de filas que satisfacen la consulta. El objetivo general es calzar
un SARG con un índice para evitar un table scan. Los operadores validos de un
SARG son =, >, =, y

130
Se recomienda, siempre que se pueda, reescribir una consulta que tenga
un operador de desigualdad a una que contenga SARG. Por ejemplo, si se tiene la
consulta
SELECT NOMBRE FROM DUEÑO WHERE VIGENCIA 0
Se puede rescribir como :
SELECT NOMBRE FROM DUEÑO WHERE VIGENCIA = 1
La cual contiene un SARG valido que el optimizador reconocerá y lo
considerará para calzarlo con algún índice.
Algunas sentencias no se ven como SARG, sin embargo, pueden ser
transformadas a SARG por el optimizador, estas son :
• BETWEEN se transforma en >= AND = ’01-01-2001’ AND FECHA = AND <
NOMBRE LIKE “Sm%”

se transforma en:
NOMBRE >= “Sm” AND NOMBRE

TABLA1.COLUMNA operador TABLE2.COLUMNA
132
Comúnmente un join involucra 2 tablas al menos que sea un Join recursivo
(aunque en este caso se debe especificar la tabla 2 veces).
Existen casos en que una subconsulta se puede expresar como Join. En
general ASE intentará transformar una subconsulta en un Join para permitirle al
optimizador seleccionar el orden de Join más apropiado. Cuando ASE encuentra
una subconsulta del tipo IN, ANY o EXISTS tratará de transformarla en un tipo
especial de Join denominado Join de existencia. Un Join de existencia se puede
optimizar de la misma forma que un Join Normal, excepto que para el caso de los
Join de existencia, tan pronto como se cumpla el predicado de Join para la
relación interna, el optimizador detiene la búsqueda de valores coincidentes en la
relación interna y devuelve un valor TRUE (verdadero).
Si ASE no puede transformar la subconsulta en un Join de existencia, la
consulta debe ser procesada desde adentro hacia fuera, esto es, se debe ejecutar
la subconsulta y luego efectuar el Join con la Relación externa, se plantea como
ejemplo la siguiente consulta extraída de la Base de datos de ejemplo PUBS2 de
ASE:
select pub_name
from publishers
where pub_id not in (
select pub_id
from titles
where type = 'business')

será procesada por el optimizador de ASE de la siguiente forma :
select p.pub_id,
tmp_field = t.pub_id
into #worktable
from publishers p,
titles t
where p.pub_id *= t.pub_id and
t.type = 'business'
select pub_name
from publishers p,
#worktable w
where p.pub_id = w.pub_id and
tmp_field = NULL
drop table #worktable
133
Una subconsulta correlacionada contiene una referencia a una tabla externa
en la cláusula de join en la subconsulta, Por ejemplo, la subconsulta siguiente:
select col_a
from table_1 t1
where col_b = ( select sum(col_x
from table_2
where col_y = t1.col_c)

134
ASE procesará esta subconsulta desde adentro hacia fuera usando una
tabla intermedia al igual que en el ejemplo anterior, la consulta anterior quedará
dela siguiente manera:
select t1.col_c,
suma = sum(t2.col_x)
into #worktable
from table_1 t1,
table_2 t2
where t2.col_c = t1.col_c
select t1.col_a
from table1 t1,
#worktable w
where t1.col_c w.col_c and
t1.col_b = w.suma
drop table #worktable
Para el procesamiento de algunas subconsultas ASE usa un una porción
del caché de memoria que almacena los resultados para cada una de las
ejecuciones subsecuentes de la subconsulta. Esto ayuda a mejorar el rendimiento
cuando hay valores duplicados en las columnas de Join.

135
Mientras se procesa la consulta, el optimizador evalúa la efectividad del
caché, si este índice se ve bajo, el optimizador determina que el caché de
subconsultas es inútil y lo reduce en tamaño.
6.3. Selección de Índices.
Una vez que la fase de análisis de la consulta se ha completado el próximo
paso es hacer calzar las cláusulas identificadas anteriormente con los índices
disponibles en la base de datos y estimar los costos de entrada y salida. Al igual
que en el caso de System R, el costo de cada uno de los caminos de accesos por
índices se comparan entre ellos y se comparan con el costo de un table scan con
el fin de determinar el menor de ellos.
Al igual que System R, Sybase usa las estadísticas de distribución de datos
del catálogo para estimar el costo de los caminos de acceso, en el caso de que no
existan estadísticas Sybase también ocupa los “números mágicos”, estos números
son:
Operador Porcentaje estimado de filas
= 10%
BETWEEN, > y < 25%
>, =,

136
Si la consulta contiene una cláusula de Join ASE buscará los índices que
calcen con los atributos de Join, para este caso utiliza las estadísticas de densidad
de índices las cuales estiman el número de ocurrencias de un valor en un índice.
Si esta estadística no está disponible el optimizador estima el número de filas
coincidentes con la fórmula:
1 / número de filas en la tablas con menos filas
por ejemplo, si tenemos una tabla A de 1.000.000 de filas y una tabla B con
5.000 filas, la selectividad del Join será de 1 / 5.000 = 0,0002; así para cada fila de
la tabla B se deberían esperar 1.000.000 * 0,0002 = 200 filas coincidentes con la
tabla A.
Ahora bien, en el caso de haber índices en los atributos de Join, ASE
estimará la densidad de un índice como el porcentaje de valores únicos en un
índice, si se tienen 1.000 valores distintos en el índice de la tabla A, la densidad
del índice debería ser : 1 / 1.000 = 0,001; usando este valor de densidad, para
cada fila de la tabla B se esperan 1.000.000 * 0,001 = 1000 filas coincidentes con
la cláusula de join.
A menos que se utilice una cláusula OR, ASE utilizará un solo índice por
tabla para satisfacer la consulta, el índice elegido debe ser el que requiera el
menor número de E/S para resolver la consulta.
Como se ha visto anteriormente, hay instancias donde un table scan puede
ser la mejor estrategia para la recuperación de los datos.
Para cualquier caso el cálculo de la estimación de E/S es el mismo que se
explicó en la sección 5.3.1, este es, el número de paginas de la tabla para el caso

137
de un table scan, valor que se rescata de la página OAM [Rankins96] (object
allocation map) de la tabla.
En el caso de que exista un índice en cluster el costo se estimará como el
número de niveles del índice más el número de páginas a recorrer; este último
valor a su vez se determina como el producto entre el número estimado de filas a
recuperar y el número de filas por página.
Para un índice que no sea en cluster, el costo se estima como:
Número de niveles del índice +
El número de página del nivel de hojas +
El número de filas estimadas a rescatar (peor caso)
Para índices únicos y para equi-join el costo de E/S e estima como una
página de datos más el número de niveles de índices que se deben recorrer para
acceder a la página de datos.
Adicionalmente ASE utiliza la técnica de “cubrimiento del índice” (index
covering) la cual usa el nivel de hojas del índice normal (no en cluster) de la
misma manera que lo hace con el nivel de hoja de los índices en cluster, siempre y
cuando todos los atributos que se necesitan se encuentren en la definición del
índice. De esta manera el optimizador no accede a las páginas de datos dado que
tiene todos lo necesario en las páginas de índices.
6.4. Selección de los ordenes de Join.

138
El optimizador de consultas evalúa todos los posibles ordenes de join y para
cada orden de join considerado estima el costo de las diferentes alternativas de
índices para cada una de las tablas que participan en el Join.
En el caso de que no hayan índices útiles para la consulta en una o más de
las tablas involucradas en el join, ASE considerará aplicar la estrategia de
reformateo para resolver la consulta eficientemente.
De aquí que, el plan de consulta más optimo para un join involucra elegir los
mejores índices para cada tabla y el orden más eficiente para procesar las tablas
en el join.
6.4.1. Determinación de los ordenes de Join.
Dado que el optimizador de ASE se basa en costos, el orden de las tablas
en la cláusula FROM no dicta el orden en el cual las tablas deben ser procesadas.
Cuando se procesa un Join, el optimizador evalúa todas las permutaciones
razonables y estima el costo total de E/S en términos de tiempo de E/S.
El plan que resulta producto de la estimación más baja de los tiempos de
E/S será el plan elegido.
Para minimizar el número de permutaciones que deben ser examinadas, el
optimizador desintegra el join de más de 4 tablas en todos los posibles grupos de
4 con el fin de evaluar las permutaciones de Join dentro de cada uno de estos
grupos.

139
Esta alternativa es una solución iterativa, que se repite hasta que se
determinen los ordenes de Join para todas las tablas. El propósito de este alcance
es limitar el número de permutaciones que el optimizador tenga que considerar.
El algoritmo usado por ASE para procesar los Joins de más de 4 tablas es
como sigue:
1. Agrupar las tablas en todos los posibles grupos de 4.
2. Para cada uno de estos grupos estimar el costo de join para cada una de
las permutaciones (4! = 24).
3. determinar el grupo con la permutación de menor costo, la primera tabla de
esta permutación se deja como la tabla más externa del join y se extrae de
la lista de tablas.
4. Repetir los pasos 1, 2, 3 para las tablas que quedan, hasta que queden sólo
4 tablas. Estas 4 tablas sirven de entrada para la ultima estimación de costo
de Join.
Ejemplo:
Supóngase una consulta que involucre 6 tablas, sean estas tablas T1, T2,
T3, T4, T5, T6; Agrupando estas 6 tablas en todos los posibles grupos de 4 se
tendrán :
T1T2T3T4
⎛6
⎞
⎜ ⎟ = 15 grupos
⎝4⎠
T1T2T3T5 T1T2T3T6 T1T2T4T5 T1T2T4T6

T1T2T5T6 T1T3T4T5 T1T3T4T6 T1T3T5T6 T1T4T5T6
T2T3T4T5 T2T3T4T6 T2T3T5T6 T2T4T5T6 T3T4T5T6
140
Para cada grupo de 4 encontrar la permutación con costo más bajo y tomar
la primera tabla de esa permutación, extraerla de la lista de tablas y dejarla como
la tabla más externa del Join.
Asumiendo que la mejor permutación es: T3T5T4T2, la tabla T3 será la
tablas más externa. Las tablas que quedan son reagrupadas en todos los posibles
grupos de 4, la cantidad de grupos resultantes es:
⎛5
⎞
⎜ ⎟ = 5 grupos
⎝4⎠
T1T2T4T5 T1T2T4T6 T1T2T5T6 T1T4T5T6 T2T4T5T6
Si la permutación de costo más bajo es T4T2T5T6; será entonces la tabla
T4 la segunda tabla más externa en la consulta. De aquí en adelante quedan 4
tablas por lo tanto se encuentra la permutación con menor costo de estas,
supóngase que esta permutación es T5T2T1T6, este orden de Join se agrega a
las 2 tablas extraídas anteriormente quedando el orden de Join de la consulta
como :
T3 T4 T5 T2 T1 T6
El número de permutaciones examinadas con este algoritmo puede ser
sustancialmente menor especialmente cuando el número de tablas en la consulta
excede las 8 tablas.

141
El beneficio principal de este algoritmo es economizar tiempo de CPU en la
identificación del mejor orden de Join. El número resultante de combinaciones
⎛ n!
⎞
examinadas con este alcance es la suma de ⎜ ⎟ para cada iteración.
⎝ ( n − 4)!
⎠
Para este ejemplo el número de permutaciones consideradas debería ser:
6!
5 4!
+ + = 360 + 120 + 24 = 504
( 6 − 4)!
( 5 − 4)!
( 4 − 4)!
Valor que es mucho menor que las 6! = 720 permutaciones.
Esto representa, para este ejemplo, un ahorro de un 30%. En la medida que
el número de tablas se incrementa el ahorro se hace cada vez más significativo
como se muestra en la siguiente tabla:
Número
de Tablas
N! Método
Optimizado
Ahorro
6 720 504 30%
7 5040 1344 73.3%
8 40320 3024 92.5%
9 362880 6048 98.3%
10 3628800 11088 99.7%
16 20922789888000 148512 99.999%
6.4.2. Estimación de los costos.
Para cada permutación estudiada el optimizador de ASE debe estimar el
costo de ese orden de Join particular en términos de E/S total. Con propósitos de
comparación, ASE estima el total de E/S lógicas por tabla y el número de E/S

142
físicas por tabla, luego las suma y lo transforma en un estimado del tiempo total
transcurrido.
ASE tasa una lectura lógica en 2 ms. (milisegundos) y una lectura física en
18 ms. Por lo tanto la razón entre las lecturas lógicas y las físicas es de 1 a 9.
Estos valores son físicos e independientes de la plataforma en la cual se ejecuta el
motor.
Ejemplos :
Sea la siguiente consulta de la Base de Datos PUBS2 de ASE:
Select *
From titles t, titleauthor ta
Where t.title_id = ta.title_id and ta.royaltyper < 50
Se hacen las siguientes suposiciones.
• 15.000 filas en titles (15 filas por página), 1.000 páginas.
• 25.000 filas en titleauthor (50 filas por página), 500 páginas.
• Las estadísticas del Índice en cluster sobre el atributo royaltyper de la
tabla titleauthor indican que el 20% de las filas cumplen con
royaltyper < 50.
• Hay suficiente tamaño en el caché para mantener ambas tablas en
memoria.

Ejemplo 1: tabla titles como tabla externa, estudio sin índices.
143
Para la tabla externa hay un costo de 1.000 páginas para leer la tabla
completa con un table scan, al usar bucles anidados se necesita leer la tabla
titleautor por cada fila de la tabla author, como hay 15.000 filas en la tabla
externa, ASE deberá recorrer 15.000 veces las 500 páginas de la tabla interna.
El número total de E/S para esta consulta se estima como:
1.000 + (15.000 * 500) = 7.501.000 E/S.
Luego ASE calcula los costos relativos para cada permutación, el primer
scan en la tabla titles realiza 1.000 lecturas lógicas y 1.000 lecturas físicas.
Para la tabla titleauthor, como cabe enteramente en el caché sólo se
necesitan 500 lecturas físicas y 15.000 lecturas lógicas para cada una de las
iteraciones. Por lo tanto:
(1.000 * 18 + 1.000 * 2) + 500 * 18 + 15.000 * 500 * 2 = 15.029.000 ms =
15.029 segundos ≈ 4 horas.
Ejemplo 2: tabla titleauthor como tabla externa, sin índices
500 paginas del table-scan de la tabla externa.
Dado que existe un SARG en la tabla titleauthor y asumiendo que no
hay índices y por lo tanto no hay información estadística, ASE asume que un 33%
de las filas deberían calzar con el argumento de búsqueda. Así ASE estima que
sólo se deberían realizar 8.250 iteraciones en la tabla titles (si una fila de la
tabla titleuthor no cumple con el SARG no se debe efectuar la iteración para esa
fila).

Por lo tanto el costo relativo de la consulta es:
144
(500 * 18 + 500 * 2) + 1.000 * 18 + 8.250 * 1.000 * 2 = 16.528.000 ms =
16.528 segundos ≈ 4.5 horas.
Ejemplo 3: tabla titleauthor como tabla externa, índice en cluster sobre el
campo titleauthor.royaltyper, índice único en cluster sobre el campo titles.title_id.
Dada la información estadística que indica que sólo el 20% de las tuplas de
titleauthor cumplen con el SARG, entonces ASE estima que 25.000 * 0,2 =
5.000 filas de la tabla titleauthor cumplen con el SARG. Como el índice en
cluster permite búsquedas por rango, ASE sólo deberá recorrer las tuplas que
cumplen con la condición, estas son 5.000 filas / 50 filas por página = 100 páginas.
Además, como hay un índice único en cluster en la tabla titles sólo una
fila debe calzar con cada fila iterada de la tabla titleauthor, osea 5.000 filas. A
15 filas por página se tienen 5.000 / 15 = 334 páginas de datos a acceder en
titles mientras se procesa la consulta. Cada búsqueda simple todavía cuesta 3
accesos a disco más. Con esta información ASE estima que la consulta debería
costar:
100 páginas en titleauthor + (5.000 filas en titleauthor * 3 páginas
por búsqueda en titles) = 15.500
100 lecturas físicas en titleauthor: 18 * 100 = 1.800 ms.
100 lecturas lógicas en titleauthor: 2 * 100 = 200 ms.
334 lecturas físicas en titles: 18 * 334 = 6.012 ms.
15000 lecturas lógicas en titles: 2 * 15.000 = 30.000 ms.

Total = 38.012 ms. ≈ 38 segundos.
6.4.3. Estrategia de Reformateo.
145
Como se vio en los ejemplos anteriores, el escenario de costo en el peor
caso para un join es el que implementa un table-scan en ambas tablas, la fórmula
de costo resultante es:
número de paginas de la tabla externa +
(número de filas de la tabla externa *
número de paginas de la tabla interna)
Ocasionalmente puede resultar más barato construir un índice temporal en
cluster en la tabla interna y utilizarlo para procesar la consulta que recorre
repetidas veces la tabla. Cuando esto ocurre, ASE es copia el contenido de la
tabla en una tabla temporal en la base de datos tempdb y crea un índice en
cluster en la(s) columnas de join, luego utiliza este índice para recorrer la tabla y
así sólo recuperar las filas que califican para con la condición de Join.
El costo de aplicar la estrategia de reformateo es el costo de las E/S
requeridas para crear la tabla temporal más el costo de crear el índice en ella.
Sybase calcula esta fórmula como sigue:
P2 + log2 P2 * P2; donde P2 es el número de páginas de la tabla interna.
Esta estrategia no se usará a menos que el costo estimado sea menor que
el costo de hacer un join con table scan en la tabla interna. El costo total de
procesar la consulta debería ser el costo de reformateo más el número de páginas
de la tabla externa (P1) más el número de filas de la tabla externa (R1)

146
multiplicado por el número de scans en la tabla externa. La ecuación completa que
estima el costo de E/S para una consulta utilizando la estrategia de reformateo
sería:
(P2 + log2 P2 * P2) + P1 + R1
Como ejemplo, supóngase que se tiene una tabla externa de 300 filas y 200
páginas y una tabla interna que consiste en 100 páginas, el costo de reformateo
será entonces :
(100 + log2 100 * 100) + 200 + 300 ≈ 1300 E/S.
Mientras que el costo de procesar la consulta usando table scan sería
200 + (300 * 100) = 30.200 E/S.
El uso de la estrategia de reformateo por parte del optimizador de ASE,
indica al usuario que seguramente no tiene definidos los índices apropiados para
las tablas. Es válido pensar que la estrategia de reformateo es más efectiva que
un table scan, sin embargo, no es menos cierto que una buena definición de
índices es mucho más apropiada y de mejor resultado.
6.4.4. Outer Joins.
La sintaxis de un outer join en ASE se define con un asterisco (*) en el lado
de la cláusula de join donde se desea que se incluyan todas las filas.

147
Tal y como se ha explicado en la sección 5.3.3.7 un outer join indicara que
todas las filas de la tabla del lado del * tienen que ser incluidas en el resultado sin
importar si la fila calce o no con la cláusula de join.
En estos casos la tabla del lado del asterisco será forzada a ser tratada
como la tabla externa (outer) y por lo tanto para este tipo de join, ASE no evaluará
un join de orden inverso.
6.5. Uso de tablas temporales.
Cuando el optimizador encuentra cláusulas ORDER BY, GROUP BY y
DISTINCT comúnmente determinará la creación de tablas temporales
(worktables). Dado que las tablas temporales producen un procesamiento
adicional y consumo de E/S el optimizador debe decidir si debe crear o no estas
tablas.
Para el caso de la cláusula GROUP BY, siempre se debe crear una tabla
temporal para realizar el agrupamiento y guardar cualquier valor agregado que se
está generando para cada uno de los grupos solicitados.
Para el caso de la cláusula DISTINCT, y como esta cláusula se aplica a
todos los atributos de una fila, se debe crear una tabla que ordene los valores y
elimine los duplicados. Si existe un índice único en la tabla y todos los atributos de
este índice se han incluidos en el SELECT, se evitará la creación de la tabla
temporal dado que el índice único garantiza la que cada fila es distinta.
Para el caso de la cláusula ORDER BY, la utilización de una tabla
dependerá de los índices sobre la tabla.

148
Considérese la situación en la cual existe un índice en cluster sobre una
tabla, la cláusula ORDER BY especifica como mínimo la primera columna del
índice en cluster y no especifica columnas que no sean parte del índice. En este
caso no se requiere crear una tabla temporal dado que la consulta se puede
resolver ya sea por la exploración del índice en cluster o por medio de un table
scan. Sin embargo, si existe un índice que no sea en cluster y que además fue
utilizado para resolver la consulta, se requiere una tabla temporal que ordene los
datos extraídos por medio del índice no en cluster.
No se necesitará la creación de una tabla temporal si la cláusula ORDER
BY especifica al menos la primera columna de un índice normal (no en cluster)
donde no hay columnas que no sean parte del índice, y además sea este el índice
que se utiliza para satisfacer un SARG.
Ejemplo: select * from table where text like “texto%”
order by text
6.6. Selección del plan.
La selección del plan de ejecución de una consulta estará entonces
determinada por la solución que tenga el menor costo estimado para la consulta
referenciada, dado que esta elección se estima, hay veces en que el usuario
puede estar un tanto escéptico acerca de si es el plan elegido el más optimo para
la consulta. Se hace necesaria entonces, información técnica específica acerca del
plan de ejecución que ayude al usuario a responder las siguiente preguntas.
• ¿ Consideró el optimizador los índices que se definieron para cada una
de las tablas o está realizando un table scan ? ( punto 6.3)

• ¿ Se utilizan tablas temporales para procesar la consulta ? (punto 6.5)
• ¿ Se aplicó la estrategia de reformateo si es el caso ? (punto 6.4.3)
149
• ¿ Cuales son los órdenes de Join que utiliza el optimizador para resolver
la consulta ? (punto 6.4)
• ¿ Como son las estimaciones de costo con respecto a los costos
originales?
Con el fin de conocer las respuestas a estas preguntas ASE proporciona
una herramienta llamada set showplan on que devuelve al cliente un detalle
del plan de ejecución elegido para resolver la consulta. El análisis de la
información que entrega esta opción escapa al alcance de este trabajo, para un
estudio más detallado del tema se recomienda leer [Rankins96].
6.6.1. Potenciales problemas del optimizador y sus soluciones.
Luego de escribir la consulta y leer el plan de ejecución, es posible que el
usuario determine que el optimizador no esté eligiendo el plan más óptimo. A
continuación se detallan los problemas más comunes que llevan al optimizador a
elegir un plan de ejecución pobre en términos de eficacia.
Estadísticas actualizadas. Uno de los problemas más comunes
encontrados en ambientes de producción es que, ya sea, las estadísticas no están
disponibles para los índices, o bien, están desactualizadas. Se recomienda
entonces actualizar las estadísticas y re-ejecutar la consulta.

150
Cláusulas SARG. Revisar la existencia de cláusulas SARG dentro del
WHERE. Fijar atención en operadores de desigualdad, operaciones sobre
columnas y expresiones constantes que no puedan ser evaluadas en el momento
de la compilación de la consulta.
Índices que cubren consultas. Si lo que se espera es una cobertura de
índice, chequear que todos los campos del índice estén presentes en la consulta.
La falta de uno de ellos lleva a una recuperación de datos que involucra toda la
fila.
Estrategia de reformateo. Si se está efectuando una estrategia de
reformateo, significa que, ya sea no existen índices para la consulta, o la consulta
contiene SARGSs no optimizados que no pueden utilizar los índices disponibles.
Se recomienda reevaluar la indexación de tablas o rescribir la consulta de manera
que utilice los índices disponibles.
6.6.2. Mejoras propias del optimizador de ASE.
En cada versión que se lanza al mercado, los motores de base de datos
tradicionales tienden a mejorar las características de optimización de consultas, en
el caso de ASE, estas mejorías tienen que ver con el manejo de memoria y con las
estadísticas del catálogo.
Ya en la versión 11, una de las mejoras está en la habilidad de poder
particionar el caché de datos y asignar objetos a diferentes particiones del caché.
Otra mejora está en el hecho de realizar E/S de hasta 16 Kb. de tamaño (el
tamaño de un extent) y no en bloques de 2 Kb. (el tamaño de la página de datos
de Sybase).

151
Una lectura de datos en bloques de 16 Kb. puede ayudar a mejorar el
rendimiento de las consultas que rescatan un alto número de paginas
secuenciales de datos minimizando así el número de accesos a disco. Las
consultas que se pueden beneficiar con este tipo de estrategia son las consultas
del tipo:
• Table scan.
• Consultas por rango que utilizan índices en cluster.
• Consultas cubiertas por índices simples (no en cluster)
Por lo tanto, si el caché que utiliza para leer la tabla o índice está
configurado para lecturas largas, el optimizador tomará ventaja de esto e intentará
realizar lecturas de este tipo.
Otra característica de esta versión es la habilidad que tiene el optimizador
de usar la llamada estrategia de fetch-and-discard para las páginas que se leen de
disco. Un caché de ASE se compone de dos cadenas, el MRU(Most Recently
Used - más recientemente usado) y LRU (Least Recently Used - menos
recientemente usado), en versiones anteriores a la versión 11 de ASE la estrategia
del uso del caché era del tipo FIFO (first in- first out), lo que significaba que toda
página cargada en el caché debía recorrerlo completamente efectuando el mismo
número de saltos antes de ser reemplazada. Esto muchas veces dañaba el
rendimiento, sobre todo cuando se debía leer una tabla grande y las paginas (que
seguramente sólo se iban a utilizar una sola vez) quedaban en el caché,
colocando a las paginas que si necesitaban estar frecuentemente en el caché al
final del LRU.
La estrategia de fetch-and-discard le permite al optimizador determinar si
una consulta es del tipo de consultas que lee los datos una sola vez y no los

152
necesita nuevamente. Si la consulta es de este tipo, el optimizador colocará la
página al final del LRU, de manera que no “empuje” fuera del caché a las paginas
que deberían permanecer en él. La versión 12 de ASE además le permite al
usuario determinar que estrategia de reemplazo utilizar para cada una de las
tablas que se consideran en un join.
Las consultas con las cuales el optimizador de ASE le aplica la estrategia
de fetch-and-discard son las consultas del tipo:
• Table scan
• Consultas por rango que utilizan índices en cluster.
• Consultas cubiertas por índices simples (no en cluster)
• La tabla externa en un Join (sólo se requiere un scan para recorrerla)
• La tabla interna de un join, si esta no cabe completamente en el cache.
6.7. Resumen.
A lo largo de los años, el optimizador de ASE ha sufrido continuas mejoras
(al igual que la mayoría de los optimizadores para motores comerciales), en esta
sección se ha verificado la correspondencia entre la teoría expuesta a lo largo del
capítulo Capítulo 5 y la implementación comercial de uno de los motores de base
de datos más conocidos en la actualidad.
Se demuestra además que en la mayoría de las oportunidades el
optimizador toma la decisión correcta, sin embargo, hay ocasiones en las que el
optimizador puede tomar una mala decisión debido a una imprecisa o incompleta
información en las estadísticas del catálogo como también en algunas
consideraciones de cómo se escribe la consulta.

153
Ahora bien, cuando existen sospechas acerca de la elección del plan, ASE
(como los demás motores de base de datos comerciales) disponen de
herramientas que proporcionan información acerca de las decisiones tomadas
para la elección del plan más óptimo.

Resumen y Conclusiones.
Resumen
154
El procesamiento de consultas tiene varias etapas a seguir para resolver
una consulta SQL, las características del modelo relacional permiten que cada
motor de base de datos elija su propia representación que, comúnmente, resulta
ser el álgebra relacional. La optimización de consultas es, entonces, una de estas
etapas (que por cierto otros modelos de bases de datos no poseen).
Existen distintos métodos para optimizar consultas relacionales, sin
embargo el enfoque de optimización basada en costos combinado con heurísticas
que permitan reducir el espacio de búsqueda de la solución es el método
mayormente utilizado por los motores de base de datos relaciones de la
actualidad, en todo caso, independiente del método elegido para optimizar la
consulta, la salida de este proceso debe ser un plan de ejecución, el cual
comúnmente es representado en su forma de árbol relacional.
La optimización de consultas en base a costos supone la utilización de una
medida de costo que sea común a lo largo del proceso, esta medida debe
representar el criterio de minimización en la utilización de recursos del sistema, la
medida estándar para bases de datos relacionales es usualmente la cantidad de
E/S (tanto de disco como de la memoria intermedia). Este enfoque estima un costo
que estará determinado por formulas predefinidas y por la información del catalogo
inherente a la consulta. Sin embargo el optimizador no siempre escoge el plan
más optimo, ya que una búsqueda exhaustiva de la estrategia óptima puede
consumir demasiado tiempo de proceso. Se dice entonces que el optimizador
escoge una estrategia “razonablemente eficiente”.

155
El catálogo de la base de datos guarda información estadística de cada una
de las relaciones como también de los índices de cada una de la relaciones, estas
estadísticas permiten estimar los tamaños de los resultados de varias
operaciones. Esta información es particularmente útil cuando se dispone de
índices para auxiliar el procesamiento de la consulta, sin embargo, la existencia de
estas estructuras influencia de manera significativa en la elección del plan de
ejecución de la consulta.
Una mala administración de la información que contiene el catálogo
conducirá inevitablemente a una desafortunada elección del plan de ejecución.
Para ayudar a solucionar este problema existen varios enfoques que conjunta o
separadamente pueden asistir al optimizador en su elección. Uno de estos
consiste en la actualización automática de las estadísticas que algunos motores
de base de datos incluyen como opción. Otro enfoque es la opción de guardar en
el catálogo planes de ejecución precalculados que además le ahorran al motor el
tiempo de cálculo del plan. Obviamente estos planes son vulnerables a ser
invalidados si se producen cambios lógicos en el esquema de la base de datos o
si hay un cambio en la distribución de los datos a ser recuperados.
Uno de los primeros optimizadores de consultas y el que se conoce como
base para la mayoría de los optimizadores tradicionales es el optimizador de
System R. System R es un optimizador basado en costos pero que utiliza
heurísticas para desplazar selecciones y proyecciones hacia abajo en el árbol de
la consulta, la resolución de joins se realiza mediante el uso de árboles de
profundidad por la izquierda O(n!) lo que permite el uso de evaluaciones
encauzadas cuando sea posible. La estimación de los caminos de acceso para
índices secundarios supone que se necesita un acceso a disco por cada tupla de
la relación lo que supone el peor caso. Es probable que la estimación sea precisa

156
con tamaños de buffer pequeños, sin embargo con un buffer de mayor tamaño la
página que contiene la tupla podria estar todavía en memoria.
Las contribuciones del optimizador de system R con respecto a otras
investigaciones hechas hasta ese entonces se basan en un mejor
aprovechamiento de las estadísticas del catálogo, la inclusión de la utilización de
CPU en las fórmulas del cálculo de costos y los métodos para determinar ordenes
de join. El concepto de “factor de selección” le permite al optimizador estimar
cuantas tuplas satisfacen los predicados de antemano, el concepto de “interesting
orders” agrega una importancia relativa al orden en que se solicito la salida, por lo
tanto agrega un nivel de importancia a todos aquellos ordenamientos que
respondan al orden solicitado permitiendo evitar (cuando sea posible) un
reordenamiento del resultado final.
En General, la teoría expuesta en el capítulo Capítulo 5 valida las
investigaciones hechas a partir de system R, planteando el proceso de
optimización de consultas como sigue.
El primer paso de un optimizador de consultas es encontrar una expresión
del álgebra de relaciones que sea equivalente a la expresión dada y cuyo costo
estimado de ejecución sea menor. En el apartado 5.4.4.2 se presenta una lista de
equivalencia de expresiones que se pueden utilizar para transformar una
expresión en otra equivalente, se usan estas reglas para generar
sistemáticamente todas las expresiones equivalentes de la consulta y luego elegir
la más barata. Dado que generalmente esta evaluación se basa en costos, se
presentan en el apartado 5.3.1, 5.3.2 y 5.3.3 distintos algoritmos para la selección
de caminos de acceso a relaciones simples, a joins y consultas complejas, estas
medidas están determinadas por la información que se tiene en el catálogo de la
base de datos.

157
Para el caso de consultas a relaciones simples se utilizará entonces la
evaluación de cada una de las expresiones equivalentes con su evaluación de
costos para elegir el plan de acceso a la consulta más barato.
Para el caso de Joins es necesario incluir el cálculo de ordenes de join, que
considerará ordenamientos y encauzamientos en la medida de los posible. Dado
que el cálculo de estos ordenamientos puede ser costoso mientras más relaciones
estén involucradas en un Join, se presenta en el apartado 5.5 distintas técnicas
para el cálculo de estos ordenamientos, estas técnicas comúnmente iterativas
introducen distintas heurísticas para reducir el espacio de búsqueda de soluciones
buscando mejorarlo en cada iteración.
Bajo este alero de teoría, se presenta en el capítulo Capítulo 6 un ejemplo
práctico de cómo un motor de base de datos relacional comercial enfrenta estos
problema en la actualidad.
Conclusiones.
El lenguaje de consultas SQL tiene la gran particularidad de que (a menos
que se exprese directamente) le deja la tarea la elección de caminos de accesos y
técnicas de recuperación de datos al motor de procesamiento de consultas. Al
independizar de esta tarea al usuario final, se hacen necesarios un conjunto de
técnicas que permitan asegurar al motor que los datos serán rescatados de la
manera “más optima posible”. Este componente es el optimizador de consultas, el
cual se encarga de elegir el plan de evaluación más apropiado dada la información
con la que cuenta de el catalogo y una serie de técnicas y algoritmos predefinidos
para estos efectos.

158
Por muy importante que sea el la etapa de optimización en una consulta (y
de hecho lo es), existen casos en que la búsqueda del plan más optimo de
ejecución de una consulta puede tomar mucho tiempo, para solucionar este
problema, los optimizadores se apoyan en heurísticas, en técnicas de búsquedas
aleatorias y en reglas predefinidas, con el fin de que, no abarcando todo el espacio
de búsqueda, se dé con una solución que sea “razonablemente aceptable”
Existen distintos enfoques para optimizar una consulta, sin embargo, y a
partir de conclusiones hechas por las investigaciones de system R, la mayoría de
los optimizadores han elegido el enfoque de optimización basada en costos como
predeterminada. La utilización de el enfoque de optimización basada en costos se
fundamenta en la necesidad de contar con una medida que sea representativa del
criterio de minimización en la utilización de recursos del sistema. Esta medida
puede no ser la misma, dependiendo del tipo de SGBD y de los avances
tecnológicos que se han logrado con el pasar del tiempo, por ejemplo, system R
utilizaba como medida de costo una medida de peso entre costos de E/S y
utilización del uso de CPU, actualmente, existe una tendencia (cuestionable a mi
parecer) a obviar el uso de CPU como medida representativa de costos, dado los
avances tecnológicos en este campo.
Una de las ventajas que se logra comprendiendo el proceso de optimización
de consultas es la de entender que es lo que hace realmente un optimizador y con
esto evitar la construcción de malas consultas.
Sin Embargo, nada de esto cobra mucha importancia si el diseño de la base
de datos es pobre, estudios indican que el 65% de los problemas de tunning en
bases de datos en ambientes de producción es debido a un pobre diseño de la
base de datos. En estos casos, por mucho capacidad e hardware que se le
agregue al sistema no se logrará un mayor índice de rendimiento en la base de
datos.

son:
159
Algunas consideraciones que ayudan al buen diseño de una base de datos
• Seguir los estándares de normalización de base de datos.
• Tratar de maximizar el uso de índices en cluster
• Tratar de reducir el número de índices secundarios (no en cluster)
• Si existen consultas que involucren más de 4 tablas en un Join se
recomienda desnormalizar algunas tablas.
• Para tablas potencialmente grandes se recomienda el particionamiento
horizontal de tablas (varias tablas con la misma estructura original pero con
datos distribuidos por cierto criterio predefinido).

Bibliografía.
[Bjeletich99]
[Comer79]
[Codd71]
[Date98]
[Ioannidis96]
[Kline99]
[Kruse84]
[Lorie78]
160
S. Bjeletich, G. Mable, “Microsoft SQL Server 7 Al descubierto”, Prentice
Hall, Madrid 1999, Traducción de “Microsoft SQL Server 7.0 Unleashed”
,SAMS 1999.
D. Comer, "The Ubiquitous B-tree", ACM Computer Surveys, Volumen
11, Número 2, Junio 1979, pp. 121-137.
E. F. Codd, “Relational completeness of data base sublanguages”. In
Courant Computer Science Symposium on Data Base Systems, volumen
6, paginas 65 -- 98. Prentice-Hall, Mayo 1971.
C. Date, “Fifty Ways to Quote Your Query”, Miller Freeman Inc, USA
1998.
URL http://www.dbpd.com/vault/9807xtra.htm
Y. Ioannidis, "Query Optimization", ACM Computing Surveys,
symposium issue on the 50th Anniversary of ACM, Volumen 28, Número
1, Marzo 1996, pp. 121-123.
K. Kline, L. Gould, A. Zanevsky, “Transact-SQL Programming”, O’Reilly,
USA 1999.
R. L. Kruse, “Estructura de datos y diseño de programas”, Prentice Hall,
Mexico 1988, traducción de “Data Structures and Program Design”,
Prentice-Hall, 1984.
R.A. Lorie, and J.F. Nilsson, “An Access Specification Language for a
Relational Data Base System”. IBM Research Report RJ2218, Abril,
1978.

[McJones97]
[Rankins96]
[Selinger79]
[Silberschatz97]
[Steinbrunn93]
[Swami88]
[Sybase01]
[Wong76]
Paul McJones, SRC Technical Note 1997 – 018 “The 1995 SQL
Reunión: People, Projects, and Politics”, Agosto 1997.
R. Rankins, J. R. Garbus, D. Salomon, B. W. McEwan, “Sybase
SQLServer 11 UNLEASHED”, SAMS 1996.
161
P. G. Selinger, , M. M. Astrahan, R. Chamberlain, R. A. Lorie, T. Price,
"Access Path Selection in a Relational Database Management System”.
Procedente de la conferencia “ACM SIGMOD Conference”, Junio, 1979.
A. Silberschatz, H. F. Korth, S. Sudarshan, “Fundamentos de Bases de
datos – Tercera Edición”, McGraw – Hill, España 1998, Traducción de
“Database System Concepts”, McGraw – Hill, USA 1997.
M. Steinbrunn and G. Moerkotte and A. Kemper,"Optimizing Join
Orders", Passau, Alemania, "1993",
URL
http://citeseer.nj.nec.com/steinbrunn93optimizing.html
A. Swami y A.Gupta. Optimization of large join queries. conferencia ACM
SIGMOD de administración de datos, USA, 1988
Sybase, “Performance and Tunning guide: Volume 2 – Optimizing and
Abstract Plans”, Sybase, USA 2001.
E. Wong, K. Youssefi, Decomposition – “A Strategy for Query
Processing. ACM Transactions on Database Systems”, 1,3 (Septiembre)
1976.

Apéndices.
A. Sintaxis de SQL
A.1. Definiciones de datos en SQL
162
Las Sentencias del lenguaje de definición de datos (DDL) que posee SQL
operan en base a tablas. Las Principales sentencias DDL son las siguientes:
• CREATE TABLE
• DROP TABLE
• ALTER TABLE
• CREATE INDEX
• DROP INDEX
Las sentencias antes mencionadas restringen la atención a los aspectos
que son de directo interés para el usuario y no los aspectos que tienen que ver
con el nivel interno del sistema (tales detalles son de importancia para el DBA 15 ).
Una tabla base se define en los sistemas relacionales como una fila de
encabezados de columnas más cero o más filas con valores de datos. Esta tabla
es creada usando la sentencia CREATE TABLE del DDL de SQL. La fila de
encabezados de columna especifica una o más columnas asociadas cada una a
sus respectivos tipos de datos. Cada fila de datos contiene exactamente un valor
de dato para cada columna.
15 DataBase Administrator . Administrador de la base de datos.

163
No existe un orden de filas, pero es posible imponer un orden sobre ellas.
Las columnas están ordenadas de izquierda a derecha pero este orden no es
parte del modelo relacional. Las Tablas son autónomas e independientes a
diferencia de las vistas las cuales no existen en su propio espacio pero si se
derivan de una o más tablas.
A.1.1. Comando CREATE TABLE
El comando CREATE TABLE se usa para especificar una nueva relación
por medio de un nombre y especificando cada uno de sus atributos. A cada
atributo se le da un nombre, un tipo de datos (para especificar su dominio) y
algunas constraints 16 sobre el atributo.
La sintaxis del comando es :
CREATE TABLE nombre_de_tabla
(definicion_de_columna [,definicion_de_columna ] ...)
donde la definición de columna es de la forma :
nombre_de_columna tipo_de_dato [ NOT NULL ]
Ejemplo :
create table DUENOS
(
RUT INTEGER not null,
NOMBRE CHAR(30) not null,
TELEFONO CHAR(10) ,
DIRECCION CHAR(50)
);
16 Una Constraint es una regla que se debe aplicar a un atributo de una tabla. Las
constraints proveen un mecanismo rápido y eficiente para asegurar la integridad de la base de
datos sin importar los cambios que requiera el usuario.

A.1.1.1. Definición de NOT NULL (no nulo)
164
Puesto que SQL permite valores nulos como valores de atributos, una
constraint NOT NULL puede ser especificada en un atributo para indicar que no se
permiten valores nulos para este atributo. En general NOT NULL debe ser
especificado para los atributos que componen la llave primaria de cada relación.
A.1.1.2. Tipos de datos SQL
Los siguientes tipos de datos son los comúnmente soportados por el
estándar SQL.
Datos Numéricos INTEGER Entero con signo de 31 bits
SMALLINT Entero con signo de 15 bits
DECIMAL(p,q) Número con signo de p dígitos, q decimales
FLOAT(p) Número de punto flotante, p bits de precisión
Datos String CHAR(n) Cadena de texto de largo fijo de n bytes
VARCHAR(n) Cadena de texto de largo variante, hasta los n bytes
GRAPHIC(n) Cadena de texto de largo fijo, n*2 bytes
VARGRAPHIC(n
)
Datos de Fecha y Hora DATE Fecha (aaaammmdd)
A.1.2. Comando DROP TABLE
TIME Hora (hhmmss)
Cadena de texto de largo variante, hasta los n*2 bytes
TIMESTAMP Combinación de fecha y hora
Tabla A-1 - Tipos de datos de SQL
El comando DROP TABLE se usa para eliminar una relación y su definición
de atributos como también borra del catálogo la tupla relacionada a esta.
La sintaxis de la Instrucción es :

DROP TABLE nombre_de_tabla;
Ejemplo :
drop table DUENOS;
A.1.3. Comando ALTER TABLE
165
El comando ALTER TABLE es usado para agregar un atributo a una de las
tablas de la base de datos. Además cambia las tuplas en el catalogo de sistema
de la BD. El nuevo atributo tendrá el valor nulo (NULL) en todas la tuplas de la
relación inmediatamente después de ejecutada la instrucción, puesto que no se
permite la constraint NOT NULL. La sintaxis de este comando es :
ALTER TABLE nombre_de_tabla
ADD nombre_de_columna tipo_de_dato;
Ejemplo:
alter table DUENOS add VIGENCIA CHAR(1);
A.1.4. Comando CREATE INDEX
El Comando CREATE INDEX se usa para crear un índice. Cada índice
tiene un nombre el cual será usado para borrarlo en caso de que no se necesite
más. La sintaxis de este comando es la siguiente:
CREATE [ UNIQUE ] INDEX nombre_de_indice
ON nombre_de_tabla ( nombre_de_columna [orden]
[,nombre_de_columna [orden] ] ... )
[CLUSTER];

166
CLUSTER: La especificación opcional CLUSTER 17 en un comando CREATE INDEX indica
si este índice estará el cluster. Una tabla dada puede tener un sólo índice
en cluster en un momento dado.
ORDER: Toda especificación ORDER en una sentencia SQL CREATE INDEX debe ser
ya sea ASC (ascendente) o DESC (descendente) y por lo tanto especifica el
orden en que se organizarán los datos, el valor por defecto para ORDER es
ASC.
UNIQUE: La opción UNIQUE en una sentencia SQL CREATE INDEX especifica que no
se permitirán dos registros en la tabla a indexar que tengan el mismo valor
para el campo (o la combinación de estos) para el cual se está creando el
índice.
Ejemplo:
create unique index DUENO_PK on DUENOS (RUT asc);
A.1.5. Comando DROP INDEX
El comando SQL DROP INDEX se usa para soltar el índice de la tabla
relacionada y borrar la tupla correspondiente desde el catalogo de sistema de la
base de datos. Una razón para borrar índices es que es costoso mantenerlos cada
vez que la relación base es actualizada y por lo tanto se requiere espacio
adicional. Los índices que especifican una constraint de llave (primaria, alterna o
externa) no se pueden borrar a menos que se quiera borrar también la constraint
asociada. La sintaxis de la cláusula DROP INDEX es:
DROP INDEX nombre_de_indice;
Ejemplo:
drop index DUENO_PK;
17 La técnica de clustering involucra el tratar de almacenar en disco lo más cerca posible
los registros que están relacionados lógicamente, de manera de poder mejorar el rendimiento.

A.2. Manipulación de datos en SQL
SQL provee cuatro sentencias de manipulación de datos (DML). Esas son:
• SELECT
• UPDATE
• DELETE
• INSERT
A.2.1. Comando SELECT
167
El comando DML SELECT es la sentencia SQL básica para la recuperación
de información desde una base de datos. (nótese que el comando SELECT de
SQL no guarda relación con el operador de selección del álgebra relacional). La
sintaxis del comando es la siguiente:
SELECT [DISTINCT] ítem(s)
FROM tabla(s)
[ WHERE condición ]
[ GROUP BY campo(s) ]
[ HAVING condición ]
[ ORDER BY campos]
[ UNION SQL_SELECT]

168
La palabra clave DISTINCT se usa para indicar que los valores duplicados o
redundantes deben ser eliminados antes que la función sea ejecutada. DISTINCT
puede ser especificada con las funciones agregadas COUNT y AVG pero es
totalmente irrelevante para las funciones MAX y MIN. No se puede usar esta
cláusula junto con la función especial COUNT(*). La palabra Clave UNIQUE es un
sinónimo para DISTINCT y las dos se pueden usar sin distinción.
Ejemplo:
select COUNT(DISCTINCT MARCA)
FROM MOVIL;
Retorna el número de Marcas de autos que tiene la empresa
A.2.1.1. Funciones Agregadas de la cláusula SELECT
SQL provee algunas funciones especiales que pueden ser usadas con el
comando SELECT. Esas funciones son las siguientes:
• COUNT
• SUM
• AVG
• MAX
• MIN
• COUNT(*)
COUNT : La función COUNT se usa para obtener el número de valores en la columna. Opera
sobre una colección de valores en una columna de la tabla. La palabra clave

169
DISTINCT se puede usar conjuntamente con COUNT. Si el resultado del argumento es
el conjunto vacío la función COUNT retorna el valor cero. Un ejemplo de COUNT es:
SELECT COUNT (DISTINCT MARCA)
FROM MOVIL;
SUM : La función SUM se usa para sumar los valores de una columna. La función opera sobre
una colección de valores en una columna de la tabla. Los valores deben ser numéricos.
Si el resultado del argumento es el conjunto vacío, SUM retorna NULL. Un ejemplo de
SUM es:
SELECT SUM (HORA_HASTA - HORA_DESDE)
FROM VIAJE
WHERE PATENTE_MOVIL = 'HL-8483';
AVG : La Función AVG se usa para promediar todos los valores seleccionados en una columna,
opera sobre una colección de valores (numéricos) en una sola columna de la tabla. La
función AVG puede ir precedida por la palabra clave DISTINCT lo cual promediará sólo
los valores únicos. Si el resultado del argumento es el conjunto vacío, AVG retorna NULL.
Ejemplo :
SELECT AVG (HORA_HASTA - HORA_DESDE)
FROM VIAJE
WHERE PATENTE_MOVIL = 'HL-8483';
MIN (MAX): La función MIN (MAX) se usa para obtener el menor (mayor) valor en una
columna. Ambas funciones operan sobre una colección de valores en una
columna. Los valores no necesitan ser numéricos. Si el resultado del argumento
es el conjunto vacío, ambas retornan NULL.
Ejemplo:
SELECT MAX (HORA_HASTA - HORA_DESDE)

FROM VIAJE;
SELECT MIN (HORA_HASTA - HORA_DESDE)
FROM VIAJE;
170
COUNT(*): La función COUNT(*) se usa para contar la cardinalidad de una tabla sin
eliminación de valores duplicados. En las funciones anteriores, cualquier valor
nulo en el argumento se elimina antes que la función se aplique
(indiferentemente de si se usa o no la cláusula DISTINCT) . COUNT(*) retorna
cero si el resultado del argumento es el conjunto vacío.
Ejemplo:
SELECT COUNT(*)
FROM VIAJES
WHERE PATENTE_MOVIL = 'HL-8483';
A.2.1.2. Cláusula GROUP BY
La cláusula GROUP BY en una sentencia SELECT reordena lógicamente la
tabla representada por la cláusula FROM en grupos, tal que dentro de cada grupo
todas las filas tienen el mismo valor para el campo dado en la cláusula GROUP
BY (esto es conceptual; la tablas no se reordena físicamente en la base de datos).
Cada expresión en la cláusula SELECT debe ser reducible a valor simple dentro
de un grupo, es decir, que puede ser ya sea el mismo campo evaluado en la
Cláusula GROUP BY (o talvez una expresión que lo contenga), un literal, o una
función tal como SUM que opera sobre todos los valores de un grupo dentro de un
campo y que reduce todos aquellos valores a un valor simple.

171
GROUP BY no implica ORDER BY; para garantizar que el resultado
aparezca en un determinado orden se debe especificar también la cláusula
ORDER BY.
Ejemplo:
SELECT PATENTE_MOVIL, SUM(HORA_HASTA - HORA_DESDE)
FROM VIAJE
GROUP BY PATENTE_MOVIL;
A.2.1.3. Cláusula HAVING
La cláusula HAVING en una sentencia SELECT se usa para eliminar
grupos, (tal como se usa WHERE para eliminar filas). Si se especifica, debe existir
una cláusula GROUP BY también. La Expresión en la cláusula HAVING debe ser
reducible a valor simple dentro de un grupo.
Ejemplo :
SELECT PATENTE_MOVIL, SUM(HORA_HASTA - HORA_DESDE)
FROM VIAJE
GROUP BY PATENTE_MOVIL
HAVING SUM(HORA_HASTA - HORA_DESDE) > 10;
A.2.1.4. Cláusula ORDER BY
Esta cláusula se utiliza en un comando SELECT para producir como
resultado una relación en un orden específico. En general, la relación resultado no

172
se garantiza que esté en un orden particular. De ahí que la cláusula ORDER BY
se utilice para ordenar el resultado en alguna secuencia particular antes de que los
datos sean desplegados.
AL igual que la cláusula ORDER del comando CREATE INDEX el
argumento puede ser ya sea ASC o DESC. ASC es el valor por defecto.
También es posible identificar columnas por su número de columna en lugar
de su nombre, esto es, por la posición ordinal (de izquierda a derecha) de la
columna en cuestión dentro de la tabla resultado. Esta característica hace posible
ordenar un resultado en base a una columna que no tiene nombre.
Ejemplo:
SELECT RUT, NOMBRE
FROM CHOFER
WHERE SYSDATE < FECHA_LCENCIA_HASTA
ORDER BY 2 DESC;
A.2.1.5. Cláusula EXIST
La cláusula EXISTS en un comando SELECT representa el calificador de
existencia. La expresión se avaluara como verdadera, si y sólo si, el resultado de
evaluar la sentencia “SELECT … FROM …” no es vacía, esto es, si y sólo si,
existe un registro en la tabla dada en FROM desde el nivel más externo de la
consulta. La negación (NOT EXISTS) es especialmente importante para una cierta
clase de consultas bastante más complejas que el común.
Ejemplo :

SELECT PATENTE
FROM MOVIL
WHERE EXISTS (
A.2.1.6. Subconsultas.
SELECT *
FROM VIAJE
WHERE MOVIL.PATENTE =
VIAJE.PATENTE_MOVIL);
173
Una Subconsulta en una cláusula SELECT es una expresión de la forma
“SELECT - FROM - WHERE - GROUP BY - HAVING” que se anida dentro de otra
expresión. Las Subconsultas se usan comúnmente para representar un conjunto
de valores que se buscan por medio de una condición “IN condición”. El sistema
evalúa toda la consulta evaluando la Subconsultas anidadas.
Ejemplos :
* Retorna todos los móviles que tienen más de 10 horas de viaje.
SELECT CHOFER.NOMBRE, MOVIL.PATENTE
FROM MOVIL, CHOFER
WHERE PATENTE IN (
SELECT PATENTE_MOVIL
FROM VIAJE
WHERE (HORA_HASTA - HORA_DESDE) > 10)
AND
MOVIL.RUT_CHOFER = CHOFER.RUT;

A.2.2. Comando UPDATE
174
El comando DML UPDATE se usa para modificar valores de atributos de
una o más tuplas seleccionadas. Al igual que con el comando SELECT la cláusula
WHERE es la que selecciona la o las tuplas que serán modificadas desde una
relación simple. La cláusula adicional SET especifica los atributos que serán
modificados y sus nuevos valores.
La Sintaxis de UPDATE es la siguiente
UPDATE nombre_de_tabla
SET campo = expresion_escalar
[, campo = expresion_escalar ] ...
[ WHERE condicion ] ;
Todos los registros en la tabla que satisfagan la condición serán
modificados de acuerdo a sus asignaciones (“campo = expresion_escalar”) en la
cláusula SET.
El siguiente ejemplo demuestra el uso del comando UPDATE en un
Registro.
UPDATE CHOFER
SET DIRECCION = ‘Otra Dirección’,
TELEFONO = 5555555
WHERE RUT = 12657378
El siguiente ejemplo demuestra el uso del comando UPDATE para un
conjunto de registros.

UPDATE CHOFER
A.2.3. Comando DELETE
SET VIGENCIA = ‘N’
WHERE SYSDATE > FECHA_LICENCIA_HASTA;
175
El comando DML DELETE borra tuplas desde una relación. Al igual que el
comando UPDATE puede incluir la cláusula WHERE para seleccionar las tuplas a
ser eliminadas. Las tuplas son borradas sólo desde una tabla a la vez.
Dependiendo del número de tuplas seleccionadas por la condición en la cláusula
WHERE será la cantidad (cero, una o más) de tuplas que serán eliminadas con un
sólo comando DELETE. Si se omite la cláusula WHERE se asume que todas las
tuplas de la relación deben ser borradas, sin embargo la tabla permanece en la
base de datos como una tabla vacía. (el comando DROP TABLE se usa para
eliminar completamente la tabla, aún si esta no está vacía).
La sintaxis del comando DELETE es la siguiente :
DELETE
FROM table
[ WHERE condition ] ;
El siguiente ejemplo borra una sola tupla en la tabla base:
DELETE
FROM MOVIL
WHERE PATENTE = 'HL-8205' ;

El siguiente ejemplo borra todas las tuplas que satisfagan la condición
DELETE
A.2.4. Comando INSERT
FROM MOVIL
WHERE ANO

El siguiente es un ejemplo de la inserción de un sólo registro.
INSERT
INTO DUENO ( RUT, NOMBRE, VIGENCIA )
VALUES ( 12657378, ‘MARIO CISTERNA’, ‘S’);
El siguiente ejemplo muestra la inserción por medio de una Subconsultas.
INSERT INTO CHOFER
(RUT, NOMBRE, TELEFONO, DIRECCION, VIGENCIA)
SELECT RUT, NOMBRE, TELEFONO, DIRECCION, VIGENCIA
FROM DUENO WHERE VIGENCIA = ‘S’
177

B. Indices B+
178
Los índices B + son índices multinivel, que contienen n punteros P1, P2, … Pn
y que pueden contener hasta n-1 claves de búsqueda K1, K2, … Kn-1. Los valores
de las claves de búsqueda se mantienen ordenados, así si i < j entonces Ki < Kj.
Nodos Hoja: para i = 1, 2, … , n-1 el puntero Pi apunta a un registro de la tabla
con clave Ki o a un cajón de punteros cada uno de los cuales apuntan a registros
con clave Ki que se utiliza sólo si la clave de búsqueda no forma una clave
primaria y el archivo no está ordenado según la clave de búsqueda. Está permitido
que los nodos hojas guarden a lo menos ⎡(n-1)/2⎤ valores, los rangos en cada hoja
no se solapan, así si Li < Lj son nodos hojas y i < j entonces cada valor de
búsqueda de Li es menor que cada valor de Lj. El puntero Pn apunta al siguiente
nodo hoja en el orden de la clave de búsqueda, eso permite un mejor desempeño
en búsquedas secuenciales.
Nodos Internos: Los nodos internos tienen la misma estructura que los nodos
hoja, excepto que todos los punteros son punteros a nodos del árbol. Cada nodo
puede guardar hasta n punteros y debe guardar a lo menos ⎡n/2⎤ punteros. El
número de punteros de un nodo se llama grado de salida del nodo.
Si un nodo tiene m punteros, para i = 2, … m-1, el puntero Pi apunta al
subárbol que contiene los valores de clave de búsqueda menores que Ki y
mayores que Ki-1. Pm apunta a la parte del subarbol que contiene los valores de la
clave que son mayores o iguales a Km-1 y a su vez P1 apunta a la parte del
subarbol que contiene los valores de clave menores o iguales a K1. El requisito de

que todos los nodos tengan ⎡n/2⎤ punteros se impone a todos los nodos internos
menos a la raíz.
179
Otro requisito de los árboles B + es que estén equilibrados. Es decir, la
longitud de cada camino desde la raíz hasta un nodo hoja es la misma.
Para procesar una consulta sobre el árbol se tiene que recorrer un camino
en el árbol desde la raíz hasta algún nodo hoja. Si hay K valores de la clave de
búsqueda en e archivo, este camino no será más largo que ⎡log[n/2](K)⎤ En la
práctica sólo se accede a algunos nodos, Generalmente un nodo se construye
para tener el mismo tamaño que un bloque de disco, el cual ocupa normalmente
4Kb. Con una clave de búsqueda del tamaño de 12 bytes y un tamaño de puntero
a disco de 8 bytes, n está alrededor de 200. Incluso con una estimación más
conservadora de 32 bytes para el tamaño de la clave de búsqueda, n está próximo
a 100.
Con n = 100, si se tiene 1.000.000 de la clave de búsqueda en la tabla, una
búsqueda necesita solamente ⎡log50(1.000.000)⎤ = 4 accesos a nodos. Por lo tanto
se necesita leer a lo sumo cuatro bloques del disco para realizar la búsqueda.
Índices asociativos.
En una organización de archivos por asociación se obtiene la dirección del
bloque de disco mediante el cálculo de una función de asociación sobre el valor de
la clave del registro. Se utiliza el término cajón (bucket) para indicar una unidad de
almacenamiento que puede guardar uno o más registros. Formalmente, sea K el
conjunto de todos los valores de claves de búsqueda y sea B el conjunto de todas
las direcciones de cajón, una función de asociación h es una función de K a B.
Para realizar una búsqueda con valor Ki en la clave de búsqueda simplemente se
calcula h(Ki), y luego se busca en el cajón al que apunta esa dirección, como
existe la posibilidad de que dos claves de búsqueda tengan el mismo valor de

180
asociación, se debe buscar luego en el cajón las tuplas que coincidan con los
valores de búsqueda de la clave.
La peor función de asociación posible asigna todos los valores de la clave
de búsqueda al mismo cajón, una función ideal es aquella que distribuye las
claves almacenadas uniformemente a traves de los cajones de manera que cada
uno de estos tenga el mismo número de registros.
Un índice asociativo (hash index) organiza las claves de búsqueda con sus
punteros asociados dentro de una estructura de archivo asociativo. Se usa el
termino índice asociativo para denotar las estructuras de archivo asociativo, asi
como los índices secundarios asociativos. En rigor, los índices asociativos son
sólo estructuras de índices secundarios.
Para más referencias se recomienda consultar [Silberschatz97] capítulo 11
(Indexación y Asociación) y [Comer79].

C. Métodos de almacenamiento de Datos.
181
En la mayor parte de los sistemas informáticos hay varios tipos de
almacenamiento de datos. Estos medios de almacenamiento se pueden clasificar
por la velocidad con que se puede tener acceso a los datos, por el costo de
adquisición del medio y por la fiabilidad del medio.
La clasificación más general y la que se presentará a continuación es una mezcla
entre las medidas de velocidad y la fiabilidad del medio.
Almacenamiento Primario.
• Caché: La forma de almacenamiento más rápida y más costosa, se
gestiona por hardware.
• Memoria Principal : Es el medio donde operan las instrucciones de
maquina y los datos disponibles para los programas, este tipo de
almacenamiento es voluble a fallos.
• Memoria Flash: (Ellectrically Erasable Programmable Read Only Memory)
EEPROM, medio de almacenamiento que puede aguantar los fallos
eléctricos. La lectura toma menos de 100 nanosegundos, pero la escritura
tarda de 4 a 10 microsegundos. Se borra por bancos de memoria. Este tipo
de memoria se ha hecho popular como sustituta de discos magnéticos para
guardar pequeños volúmenes de datos.
Almacenamiento secundario (en conexión)

182
• Discos magnéticos: Principal medio de almacenamiento a largo plazo que
resiste los fallos de energía. Generalmente se guarda toda la base de datos
en discos magnéticos, pero para tener acceso a los datos hay que
trasladarlos hacia la memoria principal. El almacenamiento en disco se
llama tambien almacenamiento de acceso directo dado que los discos
pueden leer en cualquier orden a diferencia de los medios de
almacenamiento secuencial.
Almacenamiento terciario (sin conexión)
• Almacenamiento óptico: CDROM (Compact Disc Read Only Memory) y
WORM (Write Once Read Only memory), permiten la grabación una sola
vez pero no el borrado o sobre-escritura.
• Almacenamiento en Cinta: Almacenamiento secuencial comúnmente
utilizado para respaldos de la información puesto que es más lento tanto en
lecturas como escrituras.
C.1. Discos Magnéticos.
Los discos magnéticos proporcionan la parte principal del almacenamiento
secundario de los SGBD. La capacidad de almacenamiento de un sólo disco varía
actualmente desde los 10 Mb hasta los 100 Gb. Una Base de datos comercial
grande típicamente puede necesitar decenas o centenas de discos.
Físicamente, un disco esta compuesto por platos, cada plato es de metal o vidrio
cubierto por un material magnético, giran a 60, 90 o 120 Revoluciones por
segundo. La superficie se divide lógicamente en pistas y las pistas en sectores.

183
Cada cara del plato tiene una cabeza de lectura escritura, cada una de estas
cabezas están montadas en un dispositivo llamado brazo del plato. Al conjunto de
pistas i-ésimas de cada plato se le denomina cilindro.
Una unidad controladora de disco es una interfaz entre el sistema informático y el
hardware. Esta unidad acepta ordenes de alto nivel para leer o escribir en un
sector e inicia las acciones tales como desplazar el brazo de disco a la pista
adecuada o leer y/o escribir los datos. Un controlador de disco posee además una
unidad de comprobación de suma (checksum) para cada sector que se escribe,
cuando se vuelve a leer un sector de disco se vuelve a calcular la suma a partir de
los datos recuperados y se compara con la suma de comprobación guardada; si
los datos se han deteriorado, resulta muy probable que las sumas no coincidan, si
este es el caso, el controlador volverá a intentar varias veces la lectura; si el error
persiste el controlador informará al sistema de un fallo de lectura.
Un disco se conecta a un sistema informático o a un controlador por medio de una
conexión de alta velocidad, suele utilizarse la Interfaz de conexión para sistemas
informáticos pequeños (Small Computer-System Interconnect Interface, “escasi”)
sin embargo los sistemas de alto rendimiento suelen disponer de un bus más
rápido para conectarse a los discos (fibra u otro medio combinado).
C.1.1. Medidas de rendimiento para los discos.
Las principales medidas de la calidad de un disco son la capacidad, el tiempo de
acceso, la velocidad de transferencia y la fiabilidad.
• Tiempo de búsqueda. Tiempo que le toma al disco desplazar el brazo para
que se ubique sobre la pista correcta.

184
• Tiempo medio de búsqueda. Media estadística de los tiempos de
búsqueda medido en una sucesión de búsquedas aleatorias uniformemente
distribuidas y que es aproximadamente 1/3 del peor de los tiempos (2 a 30
milisegundos)
• Tiempo de latencia rotacional. Tiempo transcurrido hasta que aparece el
sector que se desea bajo la cabeza de lectura/escritura.
• Tiempo de Acceso. Tiempo medio de búsqueda + tiempo de latencia
rotacional.
• Velocidad de transferencia de datos. Velocidad a la que se pueden
recuperar o guardar datos luego del tiempo de acceso.
• Tiempo medio entre fallos. Cantidad de tiempo que se puede esperar que
el sistema funcione de manera continua sin tener que fallar (entre 30.000 a
800.000 horas)