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 DEFINICIN DEL PROBLEMA...........................................................................4 ESTRUCTURA DEL LIBRO. .................................................................................6 CAPTULO 1. MODELO DE DATOS RELACIONAL.....................................8 1.1. INTRODUCCIN. ................................................................................................8 1.2. IMPLEMENTACIONES RELACIONALES................................................................9 1.3. CONCEPTOS GENERALES. ................................................................................10 CAPTULO 2. LENGUAJES DE CONSULTA PARA EL MODELO RELACIONAL. ..........................................................................16 2.1. INTRODUCCIN. ..............................................................................................16 2.2. ALGEBRA RELACIONAL. ..................................................................................17 2.3. CLCULO RELACIONAL DE TUPLAS. ................................................................23 2.4. SQL COMO LENGUAJE DE CONSULTAS RELACIONALES. ..................................27 CAPTULO 3. SISTEMAS DE GESTIN DE BASES DE DATOS RELACIONALES. .....................................................................31 3.1. INTRODUCCIN. ..............................................................................................31 3.2. TRANSACCIONES, CONCURRENCIA Y RECUPERACIN......................................33 3.3. TIPOS DE SGBD..............................................................................................40 CAPTULO 4. INTRODUCCIN AL PROCESAMIENTO DE CONSULTAS, EL ENFOQUE DE SYSTEM R....................48 4.1. INTRODUCCIN. ..............................................................................................48 4.2. EL OPTIMIZADOR DE SYSTEM R. .....................................................................51 CAPTULO 5. OPTIMIZACIN DE CONSULTAS, FUNDAMENTO TERICO. ..................................................................................69 5.1. INTRODUCCIN. ..............................................................................................69 5.2. INFORMACIN DEL CATLOGO........................................................................70 5.3. MEDIDAS DE COSTO. .......................................................................................72 5.4. EVALUACIN DE EXPRESIONES. ......................................................................95 5.5. ORDENES DE JOIN. ........................................................................................107 5.6. ELECCIN DE LOS PLANES DE EVALUACIN. .................................................123 CAPTULO 6. EL OPTIMIZADOR DE CONSULTAS DE SYBASE ADAPTIVE SERVER ENTERPRISE, UN EJEMPLO PRCTICO. ..............................................................................128 6.1. INTRODUCCIN. ............................................................................................128 6.2. ANLISIS DE LA CONSULTA. .........................................................................129

6.3. SELECCIN DE NDICES. ................................................................................135 6.4. SELECCIN DE LOS ORDENES DE JOIN............................................................137 6.5. USO DE TABLAS TEMPORALES. ......................................................................147 6.6. SELECCIN DEL PLAN....................................................................................148 6.7. RESUMEN. .....................................................................................................152 RESUMEN Y CONCLUSIONES........................................................................154 RESUMEN .............................................................................................................154 CONCLUSIONES. ...................................................................................................157 BIBLIOGRAFA...................................................................................................160 APNDICES. A. 162 SINTAXIS DE SQL..................................................................162 A.1. DEFINICIONES DE DATOS EN SQL.................................................................162 A.2. MANIPULACIN DE DATOS EN SQL..............................................................167 B. C. INDICES B+..............................................................................178 MTODOS DE ALMACENAMIENTO DE DATOS...........181 C.1. DISCOS MAGNTICOS...................................................................................182

TABLA DE TABLAS TABLA 2-1 - OPERADORES DEL ALGEBRA RELACIONAL ........................................................17 TABLA 4-1 - FACTORES DE SELECCIN PARA CAMINOS DE ACCESO A RELACIONES SIMPLES.58 TABLA 4-2 - FRMULAS DE COSTO PARA CAMINOS DE ACCESO A RELACIONES SIMPLES ........61 TABLA 5-1 - INFORMACIN DEL CATLOGO PARA RELACIONES SIMPLES. .............................71 TABLA 5-2 - INFORMACIN DEL CATLOGO 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 ASOCIACIN. ..............................................................................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 SIMULACIN DE COCCIN ..............116 FIGURA 5-2 - EJEMPLO DEL PRINCIPIO DE SELECCIN PARA EL ALGORITMO GENTICO PARA LA OPTIMIZACIN DE ORDENES DE JOIN ............................................................................120 FIGURA 5-3 - EJEMPLO DEL PRINCIPIO DE COMBINACIN PARA EL ALGORITMO GENTICO PARA LA OPTIMIZACIN DE ORDENES DE JOIN ..............................................................121 FIGURA 5-4 - UN PLAN DE EVALUACIN DE EJEMPLO ..........................................................123

Definicin del problema.

En Bases de datos relacionales el lenguaje de consultas SQL es lo ms utilizado por el comn de los programadores y desarrolladores para obtener informacin desde la Base de datos. La complejidad que pueden alcanzar algunas consultas puede ser tal, que el diseo 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 ms optimas que otras. El problema que se plantea entonces es, el encontrar la manera ms 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 optimizacin 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 caractersticas de eficiencia, entre las estudiadas, cuando no sea posible estudiarlas todas. Este proceso tiene que ser lo bastante rpido como para que sea conveniente para el motor efectuar este clculo sin afectar el rendimiento en la construccin del resultado de la consulta.

Uno de los primeros estudios relativo a optimizacin 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 dcada de 1970. Este estudio proporcionara las bases para la construccin de la mayora de los optimizadores para motores de base de datos relacionales de orden comercial en la actualidad. Entre otras cosas, este estudio propone la descomposicin del

procesamiento de una consulta SQL en 4 fases: el anlisis sintctico (parsing), la optimizacin, la generacin de cdigo y la ejecucin de la consulta. Se entiende entonces como proceso de optimizacin de consultas al conjunto de tcnicas, 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 ms 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 interactan con Sistemas de Gestin de bases de datos relacionales. La idea de este trabajo es que le sirva de apoyo tanto al diseador de base de datos relacionales, como a los desarrolladores que ejecutan consultas, quienes, al entender mas de cerca el proceso de optimizacin de consultas puedan evitar los errores ms comunes, que a la larga llevan muchas veces al fracaso en la construccin e implementacin de sistemas de Informacin sobre bases de datos relacionales.

Estructura del libro.

El Captulo 1 introduce el modelo relacional de datos, el cual es la base para el desarrollo de este trabajo, se presentar un marco de trabajo terico sobre el cual desarrollar el problema. El Captulo 2 trata sobre los distintos lenguajes para recuperacin de datos que existen para el modelo relacional, otorgando un nfasis especial sobre el lgebra relacional y el clculo relacional de tuplas, fundamentales para la presentacin de SQL como lenguaje de consultas. El procesamiento de una consulta SQL depender en gran medida de la implemetacin relacional en la cual se ejecute, por lo tanto, el Captulo 3 presenta la conceptualizacin sobre Sistemas de Gestin de base de datos relacionales (SGBD), a modo de explicacin de cmo se logran implementaciones relacionales del modelo, en este captulo se explicarn brevemente conceptos tales como transacciones, concurrencia y repcuperacin de datos. El Captulo 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 investigacin tanto como fundamento y guia para la construccin de la mayora de los optimizadores relacionales comerciales actuales. El estudio de este caso introduce conceptos como medidas de costo, caminos de acceso y utilizacin de heursticas dentro de un optimizador. El Captulo 5 desarrolla el fundamento terico del libro, estudia en profundidad el proceso de optimizacin de consultas SQL. Este captulo explica como los optimizadores determinan sus medidas de costo y en que informacin se basan

para estos clculos; como se produce la evaluacin de expresiones y como determinar los ordenes de Join. Dado que este trabajo no tiene asociado un desarrollo prctico del tema, el Captulo 6 presenta un ejemplo de cmo trabaja en la prctica un optimizador de consultas para un SGBD comercial, para tales efectos se presenta el caso de Sybase Adaptive Server Enterprise (ASE). Este captulo llevar al lector a entender que existe una correspondencia entre lo presentado en el Captulo 4, lo explicado en el Captulo 5, y como se logra esto en la prctica.

Captulo 1. Modelo de Datos Relacional

1.1. Introduccin. 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 actan sobre dichas estructuras. El Modelo Relacional corresponde a un enfoque cientfico y tecnolgico que surgi entre la dcada de 1960 y la dcada de 1970. Su estrategia de abstraccin se basa en hacer una representacin tabular de los objetos y sus asociaciones entre ellos. Sin embargo, este enfoque tabular que se sustenta en la teora de las relaciones matemticas no permite diferenciar entre los tipos de entidad y los tipos de relacin, lo que constituye una prdida semntica significativa con respecto a su antecesor, el modelo de Entidad-Relacin. Por otra parte, la representacin tabular de la informacin y los mecanismos utilizados para establecer vnculos entre las tablas que se representan de objetos relacionados han contribuido enormemente a su masificacin, a tal punto que en la actualidad, el Modelo Relacional es un estndar de hecho en los que se construyen los SGBD1 comerciales. Es importante notar que el modelo relacional es un modelo basado en el papel y que no todas sus caractersticas son implementadas en los SGBD, como a

SGBD : Sistemas de Gestin de Bases de datos.

su vez muchas implementaciones tienen ms caractersticas que las que contempla el modelo.

1.2. Implementaciones Relacionales. Una implementacin del modelo relacional debe soportar todas las facilidades prescritas por el modelo, sin embargo existen algunas caractersticas a las cuales no hace referencia el modelo de datos relacional, dentro de estas se incluyen operaciones aritmticas, funciones agregadas, actualizaciones explcitas, modificaciones, eliminaciones, etc. Para esto el Modelo relacional incluye un ncleo de funciones que deben ser incorporadas en un SGBD. Sin embargo existe una distincin 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 implementacin de una Base de datos relacional que soporta las estructuras de datos tabulares (tablas), pero no los operadores de nivel de conjuntos. Relacional Mnimo: Un SGBD Mnimamente relacional es una

implementacin de bases de datos relacionales que soporta slo tablas, los operadores de seleccin, proyeccin y el operador JOIN (pero no los otros operadores relacionales). Relacional Completo: Un SGBD Completamente relacional es una implementacin de bases de datos relacionales que soporta slo tablas y todos los operadores del lgebra relacional.

10

Relacional : Un SGBD Relacional es una implementacin 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 explicarn ms adelante, en el punto 1.3.12).

1.3. Conceptos generales.

1.3.1. Datos Atmicos

Todos los valores de datos en el modelo relacional son atmicos. Esto implica que cada posicin de fila-columna en cada tabla siempre tiene slo un dato, y nunca un conjunto de valores.

1.3.2. Tuplas

Una tupla de una relacin o de una tabla corresponde a una fila de aquella tabla. Las tuplas estn comnmente desordenadas puesto que matemticamente una relacin se define como un conjunto y no como una lista. No Existen tuplas duplicadas en una relacin o tabla dado el hecho de que una relacin es un conjunto y los conjuntos por definicin no permiten elementos duplicados. Un corolario importante en este punto es que la llave primaria siempre existe dada la condicin de unicidad de las tuplas, por lo tanto, como mnimo la combinacin de todos los atributos de una tabla puede servir para la conformacin de la llave primaria, sin embargo usualmente no es necesario incluir todos los atributos, comnmente algunas combinaciones mnimas 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 aos) se puede

11

definir como el conjunto de todos los valores de nmeros 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 definicin de los datos, estos pueden ser simples o compuestos. Un dominio compuesto se define como el producto de alguna coleccin de dominios simples. Por ejemplo la fecha es producto de el da, el mes y el ao, donde el mes es el dominio simple de 1 a 12 y as sucesivamente).

1.3.4. Atributos.

Un atributo de una relacin o de una tabla corresponde a una columna de la tabla. Los atributos estn desordenados y se referencian por nombres y no por la posicin que ocupan. Esto significa que no se puede, por ejemplo, hacer referencia al tercer atributo de una relacin. Todos los valores de los atributos son atmicos y una relacin que satisfaga esta condicin se llama relacin normalizada. Un atributo extrae sus valores desde un dominio simple. Formalmente, un atributo es una funcin que se define entre un Dominio y un determinado tipo de Entidad de la base de datos. Dicha funcin asocia una ocurrencia de Tipo de Entidad con un determinado elemento del dominio.

1.3.5. Esquema de Relacin.

Un esquema de relacin es el conjunto que identifica todas las propiedades (Atributos) de un objeto. Se representa por el conjunto : E = {A1 , A2 , A3 ,...... An } donde Ai , i = 1,...n corresponde a un atributo y n el nmero de atributos de inters del objeto.

12

1.3.6. Relacin

Formalmente, una relacin R es un conjunto de n-tuplas tal que una n-tupla cualquiera x es:

{( Ai , a ) / Ai E , a Dom( Ai ), i, i = 1,.....n}
donde E es el esquema de la relacin. Las propiedades fundamentales de una relacin son : No hay tuplas repetidas. Las tuplas no estn ordenadas. Los atributos no estn ordenados. Todos los valores que toman las propiedades son atmicos.

1.3.7. Grado de una relacin

El grado de una relacin es el numero de atributos en la relacin. Una relacin de grado 1 (uno) es llamada unaria, una relacin de grado 2 es llamada binaria, una relacin de grado n es llamada de grado n. Los Grados de una relacin no cambian todo el tiempo, pero es posible que se agreguen nuevas columnas y se creen nuevas relaciones.

13

1.3.8. Cardinalidades de una relacin.

La cardinalidad de una relacin en un determinado momento est definida como el nmero de tuplas en la relacin. Esta puede cambiar en cualquier momento.

1.3.9. Compatibilidad de dos relaciones.

Sean

dos

relaciones

con

esquemas

E1 = {A11 , A12 ,..... A1n }

E2 = {A21 , A22 ,..... A2 n } respectivamente. Se dice que A y B son compatibles si y slo si : 1. P, P E 1! 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 prctica, esto significa que ambas relaciones deben ser del mismo grado n y que el i-esimo atributo de cada relacin se debe basar en el mismo dominio.
1.3.10. Llave Primaria / Llave Candidata

La llave primaria de una relacin o tabla es de hecho un caso especial de una construccin ms 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 pasarn a llamarse claves alternativas. De todos modos, comnmente slo 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.

14

Formalmente, una llave se define como: Sea una relacin con esquema E = {A1 , A2 , A3 ,...... An }. Una Llave de la relacin es un atributo o un conjunto de atributos K = {Ci , C j ,.....Cl } 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 combinacin de atributos) en una relacin cuyos valores se requieren para emparejar a los valores de la llave primaria de otra relacin. 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 relacin 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 bsicamente 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

15

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 ejecucin de la tarea en curso cada vez que se incurre en una violacin 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 relacin base acepte valores nulos (NULL)2. La regla de integridad referencial para el modelo relacional formula que si una relacin R2 incluye una llave externa FK que empareja a una llave primaria PK de alguna relacin 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.

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 discusin sobre valores nulos en [McJones97].

16

Captulo 2. Lenguajes Relacional.

2.1. Introduccin.

de

consulta

para

el

Modelo

Un lenguaje de consulta es un lenguaje en el que el usuario solicita informacin 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 informacin deseada sin dar un procedimiento concreto para obtener esta informacin. Los lenguajes puros para la consulta de datos son 3. El lgebra relacional, el cual es procedural y los clculos relacionales tanto de tuplas como de dominios, los cuales son lenguajes no procedurales. Estos 3 lenguajes son rgidos y formales, por lo tanto la mayor parte de los sistemas comerciales de bases de datos relacionales ofrecen lenguajes de consulta mixtos, que adems de ser ricos en sintaxis ofrecen adicionalmente sublenguajes de definicin de datos, administracin de seguridad y otras caractersticas. Se estudiarn brevemente dos de los tres lenguajes puros de consultas de base de datos, con el fin de presentar una base terica para introducir SQL. Se excluir el clculo relacional de dominios ms acabado del clculo dado que es una generalizacin del clculo de dominios se recomienda leer relacional de tuplas y queda fuera del alcance de este trabajo. Para un estudio relacional [Silbercshatz93].

17

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 relacin, 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. Seleccin 4. Unin 7. JOIN 2. Proyeccin 5. Interseccin 8. Divisin
Tabla 2-1 - Operadores del Algebra relacional

3. Producto 6. Diferencia

Las operaciones de proyeccin, producto, unin, diferencia, y seleccin son llamadas primitivas, puesto que las otras tres se pueden definir en trminos 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 bsico de administracin de RadioTaxis. El Grfico que se presenta a continuacin representa el Modelo conceptual (Modelo Lgico) o Diagrama de Entidad-Relacin:

18

Dueo
Rut Nombre Telfono Direccin Vigencia
posee es de un

Chofer Movil
Patente Marca Modelo Ao
lo maneja maneja

Rut Nombre Telfono Direccin Fecha_licencia_desde Fecha_licencia_hasta Vigencia

realiza

los hace un

Conceptual Data Model

Vale
Correlativo Hora desde Hora Hasta Metraje total Tarifa Total
por genera un

Viaje
Hora Desde Hora Hasta Origen Destino Tarifa Metraje

Project : Control de RadioTaxis Model : RadioTax Author : Mario Cisterna Version 28/12/98

Figura 2-1 - Esquema de Relaciones de Ejemplo

Los Esquemas de relaciones que se pueden construir a partir de este modelo son los siguientes:

Dueo

= {rut, nombre, telfono, direccin, vigencia}

Chofer = {rut, nombre, telfono, direccin, fecha_licencia_desde, fecha_licencia_hasta, vigencia} Vale = {correlativo, hora_desde, hora_hasta, metraje_total, tarifa_total} Mvil Viaje = {patente, rut_dueo, rut_chofer, marca, modelo, ao} = {correlativo_vale, patente_movil, Hora_Desde, hora_hasta, origen, destino, tarifa, metraje}

2.2.1. Seleccin.

El operador de seleccin opta por tuplas que satisfagan cierto predicado, se utiliza la letra griega sigma minscula () para sealar la seleccin. El predicado

19

aparece como subndice de . La Relacin que constituye el argumento se da entre parntesis despus de la . Ejemplos :

vigencia = ' S ' ( Dueo ) patente = ' HL 8483 ' ( Movil )

2.2.2. Proyeccin.

La operacin de proyeccin permite quitar ciertos atributos de la relacin, esta operacin es unaria, copiando su relacin base dada como argumento y quitando ciertas columnas, La proyeccin se seala con la letra griega pi mayscula (). Como subndice de se coloca una lista de todos los atributos que se desea aparezcan en el resultado. La relacin argumento se escribe despus de
entre parntesis.

Ejemplos :

nombre , direccion ( Dueo ) rut , vigencia ( Chofer )

2.2.3. Producto.

En lgebra relacional el producto de dos relaciones A y B es: A Veces B o AXB

20

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 smbolo X para representar el producto. Ejemplos:

Dueo Movil Movil Chofer

2.2.4. Unin.

En lgebra relacional la unin de dos relaciones compatibles 3A y B es: AB

A UNION B

Produce el conjunto de todas las tuplas que pertenecen ya sea a A o a B o a Ambas. Al igual que en teora de conjuntos el smbolo de dos relaciones. Ejemplo :

representa aqu la unin

rut,vigencia( Dueo) rut,vigencia(Chofer)

Devuelve todos los Dueos y los Choferes

2.2.5. Interseccin.

En lgebra relacional la interseccin de dos relaciones compatibles A y B

3 Relaciones Compatibles : En el lgebra relacional la compatibilidad se aplica a las operaciones de Unin, Interseccin y Diferencia. Cada operacin 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, 2n) se debe basar en el mismo dominio.

21

A INTERSECCION B

oAB

Produce el conjunto de todas las tuplas pertenecientes a A y B. Al igual que en teora de conjuntos el smbolo relaciones. Ejemplo:

representa aqu la interseccin entre dos

rut,vigencia( Dueo) rut,vigencia(Chofer)

Devuelve todos los dueos que tambin son choferes

2.2.6. Diferencia

En lgebra relacional la diferencia entre dos relaciones compatibles A y B A MENOS B o AB

Produce el conjunto de todas las tuplas t que pertenecen a A y no pertenecen a B. Ejemplo:

rut,vigencia ( Dueo) rut,vigencia (Chofer)

Devuelve todos los dueos que NO son choferes

2.2.7. Join o Reunin.

En lgebra relacional el JOIN entre el atributo X de la relacin A con el atributo Y de la relacin 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

22

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 EQUIJOIN. Si se quita uno de stos (usando una proyeccin) entonces el resultado es un JOIN-NATURAL. Ejemplo :

Dueo .rut = Movil .rut _ dueo ( Dueo Movil )

2.2.8. Divisin

En lgebra relacional el operador de divisin divide la relacin A con grado m + n por la relacin B entregando como resultado una relacin 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 relacin C con un slo 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:

patente , rut _ chofer ( Movil ) / rut ( fecha _ licencia _ hasta < 01 / 01 / 1999 (Chofer ))
Selecciona todos los autos a cuyos choferes les caduca la licencia el 01/01/1999

23

2.3. Clculo relacional de tuplas. El clculo relacional de tuplas describe la informacin deseada sin dar un procedimiento especfico para obtenerla. Las consultas en el clculo 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 notacin, se utiliza t[A] para el valor de la tupla t en el atributo A.

{t |t Dueo t [ vigencia ] = ' S ' } {t | t Movil t [ patente ] = ' HL 8483 ' }

Si slo se desea obtener un atributo de la tupla, se utiliza el constructor Existe de la lgica matemtica. As, si lo que se desea es el Nombre de los dueos de taxis que estn vigentes:

{t |s Dueo ( t [ Nombre ] = s[ Nombre ] s[ vigencia ] = ' S ' )}

"Conjunto de todas las tuplas t tales que existe una tupla s en la relacin Dueo 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 slo en el atributo Nombre, puesto que ste es el nico atributo para el que se especifica una condicin para t. As, el resultado es una relacin sobre (Nombre).

24

Si lo que se desea es obtener las tarifas de todos los viajes que ha efectuado todos los mviles de marca chevrolet, la consulta requiere de dos clusulas Existe conectadas por el operador de conjuncin lgica 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 mviles de marca chevrolet. Considrese ahora la consulta obtener todos los RUT de los dueos de mviles, cuyos mviles no hayan efectuado nunca un viaje:

{t |s Movil ( t [ rut ] =s[ Rut ] u Viaje ( s[ patente ] =u [ patente ]))}

que ocupa la clusula Existe para exigir que el dueo posea un mvil y la clusula no existe para eliminar a aquellos mviles que tengan viajes realizados. La consulta que se presenta a continuacin utiliza la implicacin, la frmula 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).

25

2.3.1. Definicin Formal.

Una expresin del clculo relacional de tuplas es de la forma: {t|P(t)} donde P es una frmula. En una frmula 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 frmula en el clculo 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 relacin. No se permite la operacin . 2. s[x] u[y], donde s y u son variables de tuplas, x e y son atributos sobre los que estn definidos s y u respectivamente, y es un operador de comparacin (<, <=, =, <>, >, >=). 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 comparacin, y c es una constante en el dominio del atributo x. Ahora bien, Las frmulas se construyen a partir de tomos usando las siguientes reglas: 1. Un tomo es una frmula. 2. Si P1 es una frmula, entonces tambin lo son P1 y (P1).

26

3. Si P1 y P2 son frmulas, entonces tambin lo son P1P2, P1P2 y P1!P2. 4. Si P1(s) es una frmula que contiene una variable de tupla libre s y r es una relacin, entonces:

s r (P1(s))
tambin son frmulas.

s r (P1(s))

2.3.2. Seguridad de expresiones.

Una expresin del clculo relacional de tuplas puede generar relaciones infinitas. Si por ejemplo se utiliza la construccin {t | (t Dueo)} hay infinitas tuplas de personas que no son dueos de algn mvil, de hecho la mayora de estas tuplas ni siquiera pertenecen a la base de datos. Para ayudar a definir las ligaduras del clculo relacional de tuplas se introduce el concepto de dominio de frmulas. De forma intuitiva, el dominio de la frmula 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 expresin {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 clculo relacional de tuplas restringido a expresiones seguras es equivalente en potencia expresiva al lgebra relacional. Por lo tanto, para cada expresin del lgebra relacional hay una expresin equivalente en el clculo relacional de tuplas y viceversa. La demostracin de este hecho queda fuera de los alcances de este trabajo, una prueba formal de la equivalencia entre el clculo

27

relacional 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. Introduccin.

Los lenguajes formales presentados en las secciones 2.2 y 2.3 proporcionan una notacin concisa para la representacin de consultas. Sin embargo, los sistemas de base de datos necesitan un lenguaje de consultas ms cmodo para el usuario. Aunque SQL se considere un lenguaje de consultas, contiene muchas otras capacidades que incluyen caractersticas para definir estructuras de datos, modificacin de datos y la especificacin de restricciones de integridad.

SQL se ha establecido como el lenguaje estndar de base de datos relacionales. Hay numerosas versiones de SQL. La versin original se desarrollo en el laboratorio de investigacin 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 Normalizacin) e ISO (International Standards Organization, Organizacin Internacional de Normalizacin) 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 aplicacin de sistemas). En 1989 se public una

28

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 slo con SQL-89, no sindolo 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 definicin de datos (DDL Data Definition Language)

Un esquema de bases de datos se representa mediante un sublenguaje especial llamado lenguaje de definicin de datos. El resultado de la compilacin 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 comnmente 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.

29

2.4.3. Lenguaje de manipulacin de datos (DML Data Manipulation Language)

Un D.M.L. es un sublenguaje de consulta y manipulacin de datos. Se entender por manipulacin de datos la :

Recuperacin de Informacin. Insercin de nueva Informacin. Eliminacin (Borrado) de informacin existente. Modificacin de Informacin Almacenada.

2.4.4. Otras caractersticas de SQL.

Adems de los dos tipos de sublenguajes mencionados anteriormente, SQL puede ser utilizado para otras caractersticas propias que no poseen los lenguajes formales de consultas, estas son:

Definicin de vistas. El DDL de SQL incluye instrucciones para la definicin de vistas.

Autorizacin. datos.

El

DDL

de

SQL

incluye

instrucciones

para

la

especificacin de los derechos de acceso a los objetos de la base de

Integridad. El DDL de SQL tambin incluye un conjunto de sentencias para la especificacin de restricciones de integridad.

Control de transacciones. SQL incluye ordenes para la especificacin de los estados de una transaccin, algunas implementaciones permiten

30

adems 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 apndice A una breve descripcin de los sublenguajes de Definicin y manipulacin de datos.

31

Captulo 3. Sistemas Relacionales.

3.1. Introduccin.

de

Gestin

de

Bases

de

datos

Un Sistema de Gestin de Bases de datos (SGBD) consiste en una coleccin de datos interrelacionados y una coleccin 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 recuperacin de la informacin. Los sistemas de bases de datos se disean para almacenar grandes volmenes de informacin, la gestin de los datos implica entonces la definicin de estructuras para el almacenamiento de la informacin y la provisin de mecanismos para la manipulacin de estos. Adems deben proporcionar mecanismos de seguridad de los datos que protejan al sistema frente a cadas o a intentos de acceso de personas no autorizadas. Si los datos estn compartidos por varios usuarios, el sistema debe asegurar la consistencia de los datos evitando posibles resultados anmalos.

Un propsito principal de un sistema de bases de datos es proporcionar a los usuarios una visin abstracta de los datos. Esto se logra mediante la definicin de 3 niveles de abstraccin que pueden ser observados: el nivel fsico, el nivel lgico y el nivel de vistas.

El nivel fsico es el nivel ms bajo de abstraccin, es el que describe como se almacenan los datos, a su vez, el nivel lgico describe que datos se almacenan realmente en la base de datos y que relaciones existen entre estos

32

datos. El nivel ms alto de abstraccin de datos es el nivel de vistas, el cual slo presenta una determinada porcin 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 informacin que contiene en el transcurso del tiempo. La coleccin de datos almacenada en un momento particular se denomina ejemplar de la base de datos. El diseo completo de la base de datos se llama esquema de la base de datos. La capacidad de modificar la definicin del esquema en un nivel sin que afecte a una definicin de esquema en el nivel inmediatamente superior se denomina independencia de datos. Existen 2 niveles de independencia de datos: La independencia fsica de datos y la independencia lgica. La Independencia fsica de los datos se describe como la capacidad de modificar el nivel fsico de la base de datos sin tener que rescribir los programas de aplicacin. En tanto la independencia lgica se define como la capacidad de modificar el esquema lgico sin causar que los programas de aplicacin tengan que rescribirse. Un esquema de base de datos se especifica mediante un conjunto de definiciones expresadas en un DDL (Lenguaje de definicin de datos). El resultado de esta definicin 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 catlogo de la base de datos. Una transaccin de base de datos se define como coleccin de operaciones que se lleva a cabo como una funcin lgica simple en una aplicacin de base de datos. Cada transaccin es una unidad de atomicidad y consistencia. La

33

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 despus de ejecutar una transaccin. 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 tambin asegura que la ejecucin 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 aplicacin y las consultas enviadas al sistema. El gestor de almacenamiento es el responsable de la interaccin con los datos almacenados en disco.

3.2. Transacciones, concurrencia y recuperacin.

3.2.1. Transacciones.

Una transaccin es una unidad de la ejecucin de un programa que accede y posiblemente actualiza varios elementos de datos. Se delimita dependiendo del lenguaje por las sentencias inicio transaccin y fin transaccin 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 transaccin 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 transaccin se haya ejecutado

34

parcialmente. La consistencia asegura que si la base de datos es consistente inicialmente, la ejecucin de la transaccin deja la base de datos en un estado consistente. El aislamiento asegura que en la ejecucin concurrente de transacciones, estas estn aisladas unas de otras, de tal manera que cada una tiene la impresin de que ninguna otra transaccin se ejecuta concurrentemente con ella. La durabilidad asegura que una vez que la transaccin se ha comprometido, las actualizaciones hechas por la transaccin no se pierden, incluso si hay un fallo en el sistema.

Una transaccin que termina con xito se dice que est comprometida (commited), una transaccin 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 transaccin slo puede estar en uno de los siguientes estados.

Activa (Active): el estado inicial; la transaccin permanece en este estado durante su ejecucin. Parcialmente comprometida (Uncommited): Despus de ejecutarse la ultima transaccin. Fallida (Failed): tras descubrir que no se puede continuar la ejecucin normal. Abortada (Rolled Back): transaccin. despus de haber retrocedido la transaccin y restablecido la base de datos a su estado anterior al comienzo de la

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 interaccin entre las transacciones concurrentes. Puesto que una transaccin por definicin conserva la consistencia, una ejecucin

35

lineal de transacciones la garantiza tambin. 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 operacin o bien abortan la transaccin que ha realizado la operacin. Los ms conocidos son los protocolos de bloqueo, el esquema de ordenacin por marcas temporales, las tcnicas de validacin, el esquema de granularidad mltiple y los esquemas multiversin. Un protocolo de bloqueo es un conjunto de reglas que indican el momento en que una transaccin puede bloquear o desbloquear un objeto de la base de datos. El protocolo de bloqueo de dos fases permite que una transaccin bloquee un objeto slo despus de que haya desbloqueado otro objeto distinto, este mtodo asegura la secuencialidad. El esquema de ordenacin 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 lgico 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 transaccin se retrasa y se le asigna una nueva marca temporal. Por ejemplo, una operacin leer se puede retrasar porque todava no se ha escrito el valor apropiado o incluso rechazar si ha sobrescrito el valor que supuestamente se iba a leer.

36

Un esquema de validacin es un mtodo de control de concurrencia adecuado para transacciones de slo lectura y en las cuales la tasa de conflictos es baja. Se basa en dividir una transaccin en 3 etapas (lectura, validacin y escritura) y trabajar con el esquema de marcas temporales sobre la etapa de validacin. 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 sincronizacin. Se define como una jerarqua 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 ms un nuevo tipo de bloqueo llamado el bloqueo intencional, el cual indica que existen nodos descendientes que tienen bloqueos compartidos o exclusivos. El esquema multiversin se basa en la creacin de nuevas versiones de los elementos de datos cada vez que una transaccin 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 versin que se va a leer se elige de forma que asegure la secuencialidad por medio de marcas temporales. En este esquema una operacin de lectura tiene xito siempre, sin embargo, una operacin de escritura puede provocar el retroceso de una transaccin. Un sistema est en estado de interbloqueo si existe un conjunto de transacciones tal que toda transaccin del conjunto est esperando a otra transaccin del conjunto. En tal situacin, ninguna de las transacciones puede

37

progresar. Existen 2 mtodos 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 prevencin de interbloqueos asegura que el sistema nunca llegar a un estado de interbloqueos mientras que el mtodo de deteccin y recuperacin de interbloqueos permite que el sistema llegue a un estado de interbloqueos para luego tratar de recuperarse. La prevencin se usa normalmente cuando la probabilidad de que el sistema llegue a un estado de interbloqueo es relativamente alta, de lo contrario lo ms conveniente es usar la deteccin y recuperacin.

3.2.3. Recuperacin.

Los fallos que ocurren en un computador pueden darse por diferentes motivos (fallos de disco, cortes de energa o fallos en el software). En cada uno de estos casos puede perderse informacin concerniente a la base de datos. Existen varios tipos de fallas, a considerar:

Fallo en la transaccin, que a su vez se dividen en errores lgicos y errores del sistema. Un error lgico ocurre cuando una transaccin no puede continuar con su ejecucin normal a causa de una condicin 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.

Cada del sistema, provocado ya sea por el hardware, el sistema operativo o por el software de base de datos. Comnmente causa la prdida del contenido de la memoria primaria y aborta el procesamiento de una transaccin.

38

Fallo de disco, para el cual slo sirve la recuperacin por medio de copias existentes en medios de almacenamiento secundario como cintas magnticas. La forma ms aceptada de lograr un tipo de almacenamiento lo ms estable

posible es replicando la informacin en varios medios de almacenamiento no voltil, con modos de fallos independientes. Los sistemas RAID (disposicin redundante de discos independientes) garantizan que el fallo de un slo disco no conduzca a la perdida de datos. Sin embargo los sistemas RAID, no pueden proteger al sistema de una prdida de datos en el caso de una catstrofe geogrfica, 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 ms seguros guardan copias de cada bloque de almacenamiento en otra disposicin geogrfica, 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 transaccin sea atmica. Garantizar la propiedad de atomicidad es responsabilidad del esquema de recuperacin. Existen bsicamente 2 esquemas que garantizan la atomicidad. Basados en el registro histrico4. Todas las modificaciones se graban en el registro histrico, el cual debe estar guardado en almacenamiento estable. En el esquema de modificacin diferida, durante la ejecucin de una transaccin, se difieren todas las operaciones de escritura hasta que la transaccin se
4

Comnmente llamado log de transacciones.

39

compromete parcialmente, momento en el cual se utiliza la informacin del registro histrico asociado con la transaccin para ejecutar las escrituras diferidas. Con la tcnica de modificacin inmediata todas las modificaciones se aplican directamente en la base de datos. Si ocurre una cada se utiliza la informacin del registro histrico para llevar a la base de datos a un estado estable previo. Paginacin en la sombra. Durante la vida de una transaccin se mantienen 2 tablas de pginas: la tabla actual de pginas y la tabla de pginas sombra. Ambas tablas son idnticas al principio de la transaccin, sin embargo, la tabla actual de pginas puede ir cambiando luego de cada operacin escribir. Todas las operaciones de lectura y escritura utilizan la tabla de pginas actual, cuando una transaccin se compromete parcialmente se desecha la tabla de pginas sombra y la tabla actual se convierte en la nueva tabla de pginas. Si la transaccin fracasa, simplemente se desecha la tabla actual de pginas. El procesamiento de transacciones se basa en un modelo de

almacenamiento en el cual la memoria principal contiene una memoria intermedia para el registro histrico, una memoria intermedia para la base de datos y una memoria intermedia para el sistema. Una implementacin eficiente de un esquema de recuperacin de datos requiere que sea mnimo el nmero de escrituras de la base de datos y que sea realizado en almacenamiento estable. Los registros del registro histrico pueden guardarse inicialmente en la memoria intermedia del registro histrico pero deben ser llevados a almacenamiento estable bajo dos situaciones: a) deben escribirse en almacenamiento estable todos los registros del registro histrico que referencien a la transaccin Ti antes de grabar el registro que indique que la transaccin Ti ha sido comprometida

40

b) deben escribirse en almacenamiento estable todos los registros del registro histrico 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 informtico que soporta la instalacin del SGBD, lo que reflejar muchas de las caractersticas 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 ms transacciones por segundo. Las consultas se pueden paralelizar permitiendo as que una consulta se pueda ejecutar por ms de un procesador al mismo tiempo, esta caracterstica ha llevado al estudio de las bases de datos paralelas. La distribucin de datos a travs de distintos departamentos de una organizacin permite que ellos residan donde han sido generados (y donde se entiende que son ms requeridos); la idea de mantener una copia de estos datos en otros lugares permite que puedan seguir las operaciones sobre los datos an si alguno de estos sitios sufre algn desastre. El estudio de este tipo de descentralizacin de los datos lleva al desarrollo de los sistemas de base de datos distribuidos.

3.3.1. SGBD centralizados.

41

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 ejecutndose en computadores personales hasta los sistemas de bases de datos ejecutndose 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 recuperacin. Dado que las maquinas en las cuales se utilizan los sistemas monousuarios son comnmente computadores de propsito 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 sensacin de una mayor productividad (puesto que pueden ejecutar un mayor nmero de transacciones por segundo) a pesar de que cada transaccin individualmente no se ejecute ms rpido. Por el contrario las mquinas paralelas tienen un gran nmero de procesadores y los sistemas de base de datos que ah se ejecutan siempre tendern 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, gestin

42

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, evaluacin y procesamiento de consultas, control de concurrencia y recuperacin. Los sistemas servidores pueden dividirse en 2 tipos: los servidores transaccionales (que sirven para agrupar la lgica del negocio en un servicio aparte, proveen una interfaz a travs de la cual los clientes pueden enviar peticiones como lo son ODBC5 o RPC6) y los servidores de datos(los cuales envan datos a ms bajo nivel y que descansan en la capacidad de procesamiento de datos de las maquinas clientes). Existen 2 arquitecturas dominantes en la construccin 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 confan en mltiples 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 aplicacin 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 comunicacin 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 estndares ANSI e ISO para la Interfaz de llamadas de datos (CLI). 6 Remote procedure call: Una forma de comunicacin entre aplicaciones que esconde la complejidad de la red utilizando un mecanismo de llamada de procedimientos ordinario. Es un proceso sincrnico firmemente acoplado.

43

El ejemplo ms 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 mltiples usuarios a las tablas, el registro y control de versiones de una transaccin y otras caractersticas como la replicacin de datos, transacciones distribuidas. Por otro lado, cuando una conexin 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 mayora de los motores de base de datos multiprocesos fueron desarrollados antes de que los sistemas operativos soportaran caractersticas tales como hilos o planificacin de tareas (scheduling). Como resultado de esto, el hecho de descomponer una operacin significaba escribir un ejecutable distinto para manejar esta operacin. Esta caracterstica proporciona el beneficio de la fcil escalabilidad a travs de la adicin de ms CPUs. En un ambiente de multitarea el sistema operativo divide el tiempo de procesamiento entre mltiples aplicaciones asignndoles una porcin de tiempo de CPU (slice) a cada una. De esta manera siempre hay una sola tarea ejecutndose a la vez, sin embargo el resultado es que mltiples aplicaciones aparenten estar corriendo simultneamente en una sola CPU. La ventaja real, sin embargo, viene cuando el sistema operativo cuenta con mltiples CPUs.

44

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 prctica 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 conexin, 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 comunicacin 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, administracin del cach, etc.) en vez de utilizar aplicaciones especializadas para cada tarea. Las desventajas ms 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 operacin de manera que mltiples tareas puedan ejecutar esta operacin. Los problemas de portabilidad guardan relacin con el SMP

(multiprocesamiento simtrico) y se originan en el hecho de que dado que diferentes fabricantes de hardware dan soporte a SMP de diferentes maneras,

45

estos motores de base de datos han tenido que implementar tcnicas neutras que buscan funcionar bien en cualquier implementacin fsica, lo que conlleva una sobrecarga en el motor y una limitacin en la habilidad de escalar a un gran nmero de procesadores.

3.3.3. SGBD Paralelos.

Los sistemas paralelos de base de datos constan de varios procesadores y varios discos conectados a travs de una red de interconexin 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 nmero 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 enve. Un sistema que procese un gran nmero de pequeas transacciones puede mejorar su productividad realizando muchas transacciones en paralelo. Un sistema que procese transacciones ms largas puede mejorar tanto su productividad como sus tiempos de respuesta realizando en paralelo cada una de las subtareas de cada transaccin.

Las ganancias en este tipo de SGBD se pueden dar en trminos de velocidad (menor tiempo de ejecucin para una tarea dada) y ampliabilidad (capacidad de procesar tareas ms largas en el mismo tiempo). Existen varios modelos de arquitecturas para maquinas paralelas, los ms mencionados son:

Memoria Compartida : Todos los procesadores comparten una memoria comn.

46

Disco Compartido: Todos los procesadores comparten una disposicin de discos comn.

Sin Compartimiento: Los procesadores no comparten ni memoria ni disco. Jerrquico: 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 comunicacin (desde redes de alta velocidad a lneas telefnicas). No comparten memoria ni discos y sus tamaos pueden variar tanto como sus funciones pudiendo abarcar desde PC hasta grandes sistemas. Se denomina con el trmino 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 geogrficos distintos, se administran de forma separada y poseen una interconexin ms lenta. Otra diferencia es que en un sistema distribuido se dan dos tipos de transacciones, las locales y las globales. Una transaccin local es aquella que accede a los datos del nico emplazamiento en el cual se inici la transaccin. Por otra parte una transaccin global es aquella que o bien accede a los datos situados en un emplazamiento diferente de aquel en el que se inici la transaccin, o bien accede a datos de varios emplazamientos distintos. Un sistema de base de datos distribuido se conoce por:

Los distintos emplazamientos estn informados de los dems.

47

Aunque algunas relaciones pueden estar almacenadas slo en algunos emplazamientos, stos comparten un esquema global comn. Cada emplazamiento proporciona un entorno para la ejecucin de transacciones tanto locales como globales.

48

Captulo 4. Introduccin al Procesamiento de Consultas, El enfoque de System R.

4.1. Introduccin. El Procesamiento de consultas hace referencia a la serie de actividades a seguir para llevar a cabo la recuperacin de datos desde una base de datos. Estas actividades incluyen la traduccin de consultas en lenguajes de consultas de alto nivel (Ej: SQL) a expresiones que se puedan implementar en un nivel fsico, as como tambin los algoritmos de evaluacin y optimizacin de consultas.

Una de las ventajas principales del modelo relacional presentado por Codd en 1970 es la que tiene relacin con la independencia de los datos que se entiende aqu como la separacin entre el modelo (lgico) y la implementacin (fsica). Esta separacin nos permite desarrollar una poderosa semntica lgica independiente de una implementacin fsica particular. Uno de los desafos de la independencia de datos es que la codificacin de una consulta para la base de datos se componga de 2 fases: 1. La descripcin lgica de la consulta (que se supone que debe hacer). 2. La definicin del plan de ejecucin fsico (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 representacin interno con el cual le sea fcil operar.

49

As, por ejemplo para SQL la representacin ms til es la del lgebra relacional extendida (rbol relacional). Este proceso cumple la misma funcin que el analizador lxico y sintctico 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 expresin relacional que la representa. El plan de ejecucin es un rbol relacional armado a partir de la consulta y que slo puede ser entendido por el motor de ejecucin de consultas. La transformacin 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 podra ser la mejor estrategia, sin embargo, una de las ventajas que nos ofrece el modelo relacional es la capacidad de usar la informacin del catalogo de la base de datos, que como se ver ms 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 mecnico que garantice que el plan de ejecucin elegido satisfaga la consulta que se quiere implementar, puesto que: 1. Un Plan calculado a mano (o un plan precalculado) ser invalidado por cambios lgicos dentro del esquema o por cambios fsicos en el camino de acceso a la informacin o en el almacenamiento fsico. 2. Si los parmetros de la consulta (o los datos) cambian, la relacin 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.

50

Consulta

Analizador y traductor (parser)

Expresin en Algebra Relacional (Arbol relacional)

Informacin del Catalogo

Optimizador

Datos

Resultado de la Consulta

Motor de Ejecucin

Plan de Ejecucin

Figura 4-1 - Pasos en el procesamiento de una consulta SQL

Despus de enviar la consulta, la base de datos debe producir su correspondiente plan de ejecucin. El primer paso en este proceso es traducir la consulta desde SQL a un rbol lgico en lgebra relacional, proceso comnmente llamado parser. El Prximo paso es traducir el rbol de la consulta en el plan de ejecucin. Generalmente existe un gran nmero de planes que implementan al rbol de la consulta; el proceso de encontrar el mejor de estos planes se le denomina optimizacin de consultas, entendindose que esta optimizacin viene dada por una medida de rendimiento para la ejecucin de consultas (como por ejemplo el tiempo de ejecucin), queremos encontrar entonces la consulta que tenga el mejor rendimiento de ejecucin. El objetivo es que el plan sea el ptimo (o el ms cercano a) dado el espacio de bsqueda del optimizador.

51

Finalmente el optimizador enva el plan ptimo al motor de ejecucin. El motor de ejecucin 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 aos 1979 y 1976 respectivamente. Estos fueron implementados para variantes particulares del modelo Relacional y funcionan lo suficientemente bien en la medida de sus implementaciones fsicas 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 descomposicin de 4 fases en el procesamiento de una consulta SQL: parsing, optimizacin, generacin de cdigo y ejecucin. Al principio cada sentencia SQL es enviada al parser (analizador sintctico), 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 estadsticas y caminos de accesos almacenados. Es el optimizador quien tambin analiza los tipos de datos y tamaos de cada columna con el fin de revisar en la lista SELECT7 como en el Arbol WHERE8 la existencia de errores de semntica e incompatibilidades de tipos de datos.

Lista de todos los elementos que estn en una clusula select. Estructura de rbol que contiene todos los predicados contenidos en la clausula

WHERE.

52

Finalmente realiza la seleccin de los caminos de acceso. Si una consulta tiene ms de un query block9 (en adelante bloque) determina el orden de evaluacin de estos a lo largo de la consulta, luego procesa para cada bloque las relaciones enunciadas en la lista FROM10. Si en el bloque existe ms de una relacin, el optimizador realiza permutaciones de los mtodos de join, por tanto, se elige el camino de acceso que minimice el costo para el bloque. Esta solucin recibe el nombre de plan de ejecucin [Selinger79] el cual se representa en el lenguaje de especificacin de accesos (ASL) cuya definicin queda fuera de los alcances de este trabajo. Para mayor Informacin consultar [Lorie78]. El generador de cdigo es un programa que traslada rboles ASL en lenguaje de mquina para ejecutar el plan escogido por el optimizador, para hacer esto utiliza un pequeo nmero de plantillas de cdigo para representar todos los casos posibles, durante esta fase se reemplaza el rbol generado por el parser en cdigo 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 fsico de las relaciones, de los caminos de acceso a ellas, bloqueos (en un ambiente multiusuario), y de las capacidades de registro de transacciones y recuperacin. El RSI (Research Storage Interface) es la interfaz orientada a la tupla que system R presenta al usuario final.

Un query block es un bloque de clusulas 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.

53

Una Relacin se almacena en el RSS como una coleccin de tuplas que cumplen con las siguientes caractersticas:

sus columnas son contiguas, se almacenan en pginas de 4 Kb, una tupla no puede rebasar una pgina.
Las pginas se organizan en segmentos, los segmentos pueden contener una o ms relaciones pero una relacin no puede rebasar un segmento. La manera de accesar tuplas de una relacin 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 relacin dada, consiste bsicamente de una serie de NEXT que recorren todas las pginas del segmento (que pueden contener tuplas para cualquier relacin) y de donde rescatan aquellas tuplas que pertenecen a la relacin dada. El segundo tipo de recorrido es un index scan11, los ndices se almacenan en pginas distintas a las pginas de datos y son implementados como B-tree cuyas hojas del rbol son pginas 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 bsqueda o usndolas para encontrar y retornar las tuplas de datos en el orden de las claves

un ndice puede ser creado por un usuario de system R en una o ms columnas de una relacin, y una relacin puede cero o ms ndices asociados a esta.

11

54

dadas. Las paginas de ndices estn encadenas juntas, por lo tanto las sentencias NEXT no necesitan referenciar paginas que se encuentren ms arriba del ndice. En un segment scan todas las pginas no vacas de un segmento se accesan slo una vez sin importar si tienen o no tuplas que pertenezcan a la relacin. En un index scan las pginas de ndices se accesan slo una vez, sin embargo las pginas de datos se pueden tocar ms 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 adems de las paginas de ndices, tambin 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 relacin, 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_comparacin 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 tambin los caminos de acceso disponibles para la relacin referenciada y evala una frmula de costo para cada plan de acceso usando la siguiente frmula:

55

COSTO = Pginas Rescatadas + W * (RSI calls) Este costo es una medida de peso entre las E/S (pginas rescatadas) y la utilizacin de CPU (instrucciones ejecutadas). W es un factor de peso ajustable entre E/S y la CPU12. RSI calls es la estimacin del nmero de tuplas a retornar. Dada esta formula la eleccin del camino de costo mnimo para procesar una consulta tiende a minimizar el total de recursos requeridos. La ejecucin de la validacin semntica 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.

Una forma de calcularlo puede ser tomar los MIPS de una determinada CPU y por otro lado tomar el nmero de instrucciones que se utilizan en una llamada RSS. W podra ser el producto de estos 2 valores medidos durante el tiempo transcurrido en una bsqueda tpica a disco. Por lo tanto W tendr diferentes valores dependiendo de distintas configuraciones de hardware. (Don Chamberlin, 12/09/2001)

12

56

Durante la mirada al catlogo, el optimizador recupera estadsticas para las relaciones de la consulta y caminos de acceso disponibles para cada relacin. Las estadsticas son las siguientes: Para cada relacin T.

NCARD(T), cardinalidad de la relacin T. TCARD(T), nmero de pginas del segmento que contienen tuplas de la relacin T.

P(T), fraccin de paginas de datos que contienen tuplas de la relacin T.

P(T) = TCARD(T)/Nmero_de_pginas_no_vacas_en_el_segmento.

Para Cada ndice en la relacin T.

ICARD(I), Nmero de claves distintas en el ndice I NINDEX(I), Nmero de pginas en el ndice I.

Estas estadsticas son mantenidas por el catlogo de System R, y provienen de distintas fuentes, son actualizadas peridicamente por el comando UPDATE STATISTICS, el cual puede ser ejecutado por cualquier usuario. Usando estas estadsticas, el optimizador asigna un factor de seleccin F para cada factor booleano en la lista de predicados. Este factor es la estimacin de la cantidad de tuplas que satisfacen el predicado. Se asume que una falta de estadsticas implica la eleccin de un factor arbitrario.

57

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 distribucin 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 slo existe un ndice sobre la columna-i

F = 1 / 10 en otro caso

Columna > valor (o cualquier otra comparacin abierta) F = (mayor_valor_dominio valor) / (mayor_valor_dominio

menor_valor_dominio)

si la columna es de tipo aritmtico y el valor

es conocido en el momento de escoger el camino de acceso. mayor_valor y menor_valor son los lmites del dominio.

F = 1 / 3 en otro caso. Responde a la hiptesis de que son menos las consultas que usan predicados que son satisfechos por ms de la mitad de las tuplas.

Columna between valor1 and valor2 F = (valor2 valor1) / (mayor_valor_dominio menor_valor_dominio) que corresponde a una razn entre el rango de valores de la clusula

58

BETWEEN con respecto al rango de valores del dominio siempre que la columna sea aritmtica 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_seleccin para

columna = valor) siempre y cuando no sea mayor que .

Columna in subconsulta F = (cardinalidad de estimada todas de la subconsulta) de la / (producto lista FROM de de las la

cardinalidades subconsulta)

las

relaciones

El

clculo

de

la

cardinalidad

de

una

subconsulta

se

explica

ms

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 Seleccin para caminos de acceso a Relaciones Simples.

La cardinalidad de una consulta (QCARD) es el producto de las cardinalidades de cada relacin involucrada multiplicado por el producto de todos los factores de seleccin. El nmero esperado de llamadas RSI (RSICARD) es el producto de las cardinalidades de las relaciones por los factores de seleccin de

59

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 relacin consiste entonces en usar estos factores de seleccin junto con las estadsticas del catalogo en frmulas definidas. Para llegar a estas frmulas se presentara entonces la siguiente definicin. Se dice que un determinado orden de tuplas es un interesting order si este orden es uno de los especificados en las clusulas GROUP BY u ORDER BY. Para una relacin simple, la solucin ptima se obtiene evaluando el costo para cada camino de acceso (cada ndice en la relacin ms un segment scan). Si no hay clusulas GROUP BY u ORDER BY en la consulta no hay interesting orders, por lo tanto se deber elegir el camino de acceso ms barato. Si estas sentencias existen, se necesita examinar los caminos de acceso ms baratos que produzcan tuplas en cada uno de los insteresting orders, luego, el costo de producir estos ordenamientos debe compararse al costo del ms barato de los caminos sin orden ms el costo de ordenar las QCARDS tuplas de la consulta en el orden dado. La ms barata de estas alternativas ser la elegida como el plan de ejecucin para el bloque. La siguiente tabla muestra las frmulas de costo para caminos de acceso a relaciones simples. Estas frmulas se calculan basndose en la suma del nmero de pginas de ndices y las paginas de datos ms 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 pgina 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

60

el buffer, se asume que la relacin es suficientemente grande con respecto al buffer de manera que se requiere una lectura de pgina por cada tupla rescatada.

Situacin

Costo

Indice nico que calza con un predicado de igualdad

1 + 1 + W

Indice en cluster I que calza con uno o ms factores booleanos

F(preds) * (NINDX(I) + TCARD) + W * RSICARD

Indice I que calza uno o ms factores bolanos

F(preds) * (NINDX(I) + NCARD) + W * RSICARD o F(preds) * (NINDX(I) + TCARD) + W * RSICARD si este nmero cabe en el buffer de System R

Indice en cluster I que no calza con ningn factor booleano

(NINDX(I) + TCARD) + W * RSICARD

Indice I que no calza con ningn factor booleano

(NINDX(I) + NCARD) + W * RSICARD o (NINDX(I) + TCARD) + W * RSICARD si este nmero cabe en el buffer de System R

61

Segment Scan

TCARD/P + W * RSICARD

Tabla 4-2 - Frmulas de costo para caminos de acceso a relaciones simples

4.2.3. Seleccin del camino de acceso para joins.

El optimizador de system R tiene 2 mtodos de seleccin de caminos de acceso para los joins de dos relaciones (join de orden 2), primero se describirn estos mtodos y luego se discutir como ellos pueden ser extendidos para joins con ms de 2 relaciones (join de orden n). Para el primer caso, la relacin base recibir el nombre de relacin outer, la segunda relacin se le llamar inner y corresponder a la relacin de la cual se sacarn las tuplas dependiendo de los valores obtenidos de la relacin 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 mtodo se llama nested loops (ciclos anidados) y consiste en recorrer ambas relaciones en cualquier orden. Primero se abre un scan sobre la relacin outer y se rescata la primera tupla, para cada tupla de esta relacin se abre un segment scan en la relacin inner para rescatar, una a la vez, las tuplas que coinciden con el predicado de join. El segundo mtodo 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 clusulas ORDER BY y GROUP BY, las columnas de un predicado equi-join (aquellos de la forma tabla1.columna1 = tabla2.columna2) tambin definen interesting orders. Si hay ms de un predicado de join, uno de ellos es usado como predicado de join y los restantes son tratados como predicados ordinarios. Este mtodo solamente

62

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 mtodo saca provecho del ordenamiento de las columnas de join evitando recorrer la relacin inner por cada tupla de la relacin 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 relacin inner est en cluster sobre la columna de join (como debera 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 estn almacenadas fsicamente cerca una de la otra de manera que el acceso a una pgina traiga varias tuplas. Un join de orden n se puede visualizar como una secuencia de joins de orden 2. En esta visualizacin 2 relaciones formarn un join, el resultado de estos se cruzara con una tercera relacin para formar el segundo join y as sucesivamente. En cada paso es posible identificar la relacin outer (la que generalmente es la composicin del paso anterior) y la relacin inner como la relacin 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 relacin 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 eleccin, 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

63

explicacin de esto se puede encontrar ms adelante, en la seccin 5.5). Una vez que las primeras k relaciones han sido unidas, el mtodo para cruzar esta composicin con la k+1 sima relacin es independiente del orden en que se unieron las k anteriores. Usando esta propiedad, una forma eficiente de organizar la bsqueda es encontrar el mejor ordenamiento para conjuntos sucesivamente ms grandes. La heurstica que se utiliza para reducir el nmero de permutaciones es considerar slo los ordenamientos los cuales tienen predicados de join que relacionan la relacin inner con el resto de las relaciones que participan en el join. Esta heurstica permite que todos los joins que requieran productos cartesianos se realicen lo ms 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 sern 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 solucin consiste en una lista ordenada de relaciones a ser unidas, el mtodo de join y un plan que indique como se accesa cada relacin. 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 tambin el nmero de soluciones, se calcularn clases de equivalencia para los interesting orders, y slo la mejor solucin de cada una de las clases de equivalencia ser guardada en el rbol. El rbol de bsqueda se construye por medio de la iteracin de las relaciones que han sido juntadas hasta el momento. Primero, se encuentra la mejor manera de accesar a cada relacin simple para cada interesting order y

64

para el caso sin orden. Luego para cada una de las relaciones se elige la mejor manera de juntar otra relacin a esta (sujeta a las heursticas 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 agregndole una tercera relacin considerando las heursticas para el ordenamiento de joins. Para cada plan que juntar un conjunto de relaciones se guarda en el rbol el orden de la composicin. Esto ayuda a la consideracin 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 solucin ms barata que da el orden requerido (si se ha especificado algn orden). Ntese que si existe una solucin con el orden correcto, no se necesitar efectuar un sort para satisfacer las clusulas ORDER BY o GROUP BY, a menos que la solucin ordenada sea ms costosa que la ms barata de las sin orden ms el costo de ordenarlas en el orden requerido.

4.2.4. Clculo 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 frmula de costo de relaciones simples expuestas en el punto 4.2.2. Sea C-outer(path1) el costo de recorrer la relacin outer va path1. Sea N la cardinalidad de tuplas que satisfacen los predicados de la relacin outer. N se calcula como:

N = (producto de las cardinalidades de todas las relaciones T incluidas

hasta el momento).

65

Sea C-inner(path2) el costo de recorrer la relacin 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 ms 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 relacin inner es ordenada en una relacin temporal no se aplica ninguna de las frmulas dadas para caminos de acceso a relaciones simples. En este caso el inner scan es como un segment scan a excepcin de que el mtodo de merging scan hace uso del hecho de que la relacin inner est ordenada, por lo tanto no es necesario realizar un scan a toda la relacin 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 nmero de paginas que se requieren para mantener la relacin inner. Esta formula asume que durante el merge scan cada pgina de la relacin 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 razn de porque algunas veces el merge-join puede ser ms eficiente es que el costo del inner scan puede ser mucho ms bajo. Una vez ordenada, la relacin inner est en cluster sobre la

66

columna de join lo que minimiza el nmero de paginas rescatadas y, por lo tanto, no es necesario hacer un scan sobre toda la relacin 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 expresin operando consulta, tal consulta es llamada consulta anidada o subconsulta. Si el operador es uno de los cinco operadores escalares ( =, >, >=, <, <=) entonces la subconsulta debe retornar un slo valor. Si el operador es IN o NOT IN entonces la subconsulta puede retornar un conjunto de valores. En ambos casos la subconsulta slo se evala una vez y antes que se evale la consulta que la contiene. Si la subconsulta retorna un slo elemento, este es incorporado en la consulta de primer nivel como si hubiera sido parte la sentencia de consulta original. Si la subconsulta retorna un conjunto de valores, ellos sern retornados en una lista temporal, una forma de representacin interna que es ms eficiente que una relacin, pero que slo puede ser accesada de manera secuencial. Una subconsulta puede tener un predicado que a su vez tenga una subconsulta, en general el anidamiento de consultas se puede desarrollar hasta un (terico) nivel arbitrario. Cuando tales subconsultas no referencian columnas de tablas que estn en un bloque de nivel superior, ellas son evaluadas antes de que la consulta de nivel superior sea evaluada. En este caso la ms profunda de las subconsultas anidadas es evaluada primero, dado que toda subconsulta debe ser evaluada antes de que su consulta padre. Una subconsulta puede contener una referencia a un valor obtenido de una tupla candidata perteneciente a un bloque de una consulta de mayor nivel. Tales

67

consultas

son

llamadas

subconsultas

correlacionadas.

Una

consulta

correlacionada debe, en principio ser re-evaluada para cada tupla candidata del bloque referenciado. Esta re-evaluacin debe ser hecha antes de que el predicado padre de la consulta correlacionada pueda ser testeado para aceptacin o rechazo de la tupla candidata. Como ejemplo considrese 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 ms que sus Jefes. Aqu X identifica el bloque y la relacin que proporciona tuplas candidatas para la correlacin. Para cada tupla candidata de la consulta de primer nivel, se utilizar el valor de MANAGER para la evaluacin 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 correlacin no est directamente debajo del bloque que referencia, sino que est separada por medio de uno o ms bloques, entonces la evaluacin de la subconsulta de correlacin debe ser hecha antes de la evaluacin del ms alto de los bloques intermedios. Por ejemplo:

68

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 ms 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 evaluacin 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 correlacin 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 relacin a la que se hace referencia est ordenada por la columna referenciada la re-evaluacin 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 evaluacin anterior, en algunos casos incluso se puede ordenar la relacin por la columna referenciada con el fin de evitar la innecesaria re-evaluacin 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 relacin y ICARD es la cardinalidad del ndice sobre la columna referenciada.

69

Captulo 5. Optimizacin terico.

de

consultas,

Fundamento

5.1. Introduccin.

En Los modelos de Red y Jerrquico la optimizacin de consultas es tarea propia del programador de aplicaciones, puesto que las instrucciones de manipulacin de datos son propietarias del lenguaje anfitrin. Por el contrario las consultas de base de datos relacionales son o bien declarativas o algebraicas. Los lenguajes algebraicos permiten la transformacin algebraica de la consulta, luego, basndose en la especificacin algebraica de la consulta es relativamente fcil 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 cdigo de un compilador para el lenguaje SQL, que produce el cdigo que ser interpretado por el motor de ejecucin de consultas, excepto que el optimizador marca nfasis en la capacidad de producir el cdigo ms eficiente, haciendo uso para tales efectos del catlogo de la base de datos, de donde obtiene informacin estadstica de las relaciones referenciadas por la consulta, algo que los lenguajes de programacin tradicionales no hacen. Un aspecto de la optimizacin de consultas se sita en el nivel del lgebra relacional. Dado un conjunto de reglas se trata de encontrar una expresin que sea equivalente a la expresin dada pero que sea ms eficiente en la ejecucin.

70

Con el fin de seleccionar la mejor estrategia para la recuperacin de datos el optimizador estima un costo que estar relacionado a cada plan de ejecucin. Este costo est determinado por frmulas predefinidas en base a informacin que se posee de la tabla y que se ha rescatado previamente del catlogo de la base de datos, en realidad el optimizador no siempre escoge el plan ms ptimo, ya que encontrar la estrategia ptima puede consumir mucho tiempo, por lo tanto se dice que el optimizador slo escoge una estrategia razonablemente eficiente. La manera con la que el optimizador utiliza esa informacin, las distintas tcnicas 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 evaluacin para una consulta y luego elige el que tiene un menor costo asociado, las medidas de costo comnmente tienen que ver con la E/S y el tiempo de CPU utilizado en ejecutar la consulta, sin embargo, es cuestin de cada SGBD el elegir las medidas de costo que mejor representen el criterio de minimizacin en la utilizacin de recursos.

5.2. Informacin del catlogo.

Como se ha mencionado anteriormente, la informacin del catlogo de la base de datos le sirve al SGBD para estimar el costo de los planes de ejecucin de una consulta. La precisin de esta informacin esta ligada directamente a la periodicidad con la que se actualizan las estadsticas del catlogo. En un caso ideal, cada vez que se compromete una transaccin de base de datos se deberan actualizar las estadsticas del sistema, sin embargo, esto no es posible en un

71

entorno OLTP13 dada la sobrecarga que estas operaciones le dan al sistema (bsicamente bloqueos en las tablas del catlogo). La solucin est entonces en la posibilidad de actualizar estas estadsticas en periodo de poca carga del sistema, algunos SGBD tienen tcnicas de optimizacin automticas de las estadsticas (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 informacin ser ms precisa cuanto ms bajo sea el nivel de actualizaciones en el intervalo de tiempo entre actualizaciones de Estadsticas. Cada SGBD tiene distinta informacin que guardar en el catlogo y por ende, el catlogo de la base de datos es distinto entre cada uno de estos motores, sin embargo, hay informacin que todo optimizador debe guardar:
nr br tr fr

Nmero de tuplas de la relacin r Nmero de bloques que contienen tuplas de la relacin r Tamao en bytes de una tupla de r Factor de bloqueo de r. Nmero de tuplas de r que caben en un bloque. Nmero de valores distintos del atributo A de la relacin r sobre el atributo A de la relacin r

V ( A, r )

CS ( A, r ) Nmero medio de tuplas de r que satisfacen una condicin de igualdad CS ( A, r ) = 1 CS ( A, r ) =

Si A es clave de r

Si A no es clave de r, se asume una distribucin nr V ( A, r ) uniforme de los datos de A sobre r

Tabla 5-1 - Informacin del Catlogo para relaciones simples.

On Line Transaction Processing: tipo de procesamiento en el cual el computador responde los requerimientos de usuario inmediatamente, cada requerimiento es considerado una transaccin. Un ejemplo de este tipo de procesamiento es el de los cajeros automticos.

13

72

Por ejemplo, si nr = 10 y V(sexo,r) = 2 entonces CS(sexo,r) = 10 / 2 = 5, se asume por lo tanto que el atributo sexo se distribuye homogneamente sobre r.
%n # nr = f r entonces br = $ r " br $ fr "

Se asume adems que si

Adems de la informacin del catlogo para las relaciones, se utiliza informacin acerca de los ndices:

gi

Grado de salida de los nodos internos del ndice i (para ndices con estructura de Arbol B+)

AAi Altura del ndice para el atributo A de r. AAi = %log fi (V ( A, r ))# MBi Nmero de bloques que ocupa el nivel ms bajo (nivel de hojas) del ndice i
Tabla 5-2 - Informacin del catlogo para ndices de Relaciones.

5.3. Medidas de costo.

El costo de un plan de ejecucin se puede expresar en trminos de distintos recursos de hardware, por ejemplo, en el caso de system R se hace en funcin de la cantidad de CPU utilizada y de la cantidad de pginas de disco rescatadas. En los SGBD distribuidos se agrega a las medidas el costo de la comunicacin de redes. En los sistemas que no son centralizados conviene creer que una buena medida del costo de utilizacin de recursos es la que est dada por la transferencia de datos desde el disco a la memoria. Para simplificar los clculos de costo se asume que toda operacin que recupere datos de disco tiene el mismo costo, obviando, por simplicidad, los tiempos involucrados en latencia rotacional y el tiempo de bsqueda (ver apndice C apartado C.1.1) .

73

El costo de todos los algoritmos de optimizacin depende en gran manera del tamao 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 optimizacin considerando el peor caso, en el cual slo algunos datos caben en la memoria principal, ms bien dicho, slo un bloque por relacin.

5.3.1. Caminos de acceso a selecciones simples.

5.3.1.1. Exploraciones sin ndices.

Los siguientes algoritmos implementan la operacin de seleccin sobre una relacin cuyas tuplas estn almacenadas de manera contigua en un archivo14. A1. Bsqueda lineal (Full scan o table scan): Se examina cada bloque del archivo y se comprueba si los registros cumplen con la condicin de seleccin. El costo estimado de este algoritmo es :

C A1 = br
A2. Bsqueda binaria: Si la tabla esta ordenada fsicamente por el atributo A y la condicin de seleccin es una igualdad sobre el atributo entonces se puede utilizar bsqueda binaria [Kruse84].

Se entender como archivo al medio de almacenamiento fsico en disco ya sea por medio de sistemas de archivos o como device de datos (raw devices) dependiendo de las caractersticas del motor de base de datos y del sistema operativo que lo soporta.

14

74

% CS ( A, r ) # El costo estimado ser : C A 2 = %log 2 (br )# + $ " 1 fr " $

Basado en la suposicin de que los bloques de la relacin se almacenan de manera contigua en el disco, donde %log 2 (br )# es el costo de localizar la primera
% CS ( A, r ) # tupla por medio de bsqueda binaria, y $ " 1 es el nmero de bloques que fr " $

cumplen la condicin de igualdad sobre el atributo A menos el bloque que se ha rescatado con la bsqueda 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 utilizacin 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 fsico de la tabla, un ndice que no es primario se denomina ndice secundario. En sybase, un ndice en cluster siempre recibe el nmero 1 dentro del conjunto de ndices que pertenecen a una tabla en estrecha relacin con la definicin de ndice primario. Los algoritmos de bsqueda 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 utilizacin 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 elaboracin 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.

75

A3. (ndice primario, igualdad en la clave): Dado que el ndice est construido sobre el (los) atributos claves, la bsqueda puede utilizar este ndice para rescatar los datos. Por lo tanto para recuperar el nico registro que cumple con la condicin se necesita leer slo 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 condicin de igualdad ms la altura del ndice. El costo estimado ser: C A 4 = $

% CS ( A, r ) # " + AAi f r $ "

Ejemplo: supngase que

nviaje = 36000, bviaje = 2391, t viaje = 136, f viaje = 15,

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 relacin viajes sean del mvil con patente HL-8483. Se puede utilizar el ndice primario para leer los 1200/15=80 bloques que cumplen con la condicin.

76

Ahora bien, supongamos que el ndice tiene un tamao del puntero a disco de 8 bytes, sabiendo que el tamao de la clave del ndice es de 12 bytes es lgico pensar que para un bloque de 2 Kb. El nmero de claves por bloque de ndice es aproximadamente 100. Entonces, una bsqueda por el ndice necesitar a lo sumo

%log 50 (36000)# = 3 accesos a bloques de disco, por lo tanto el nmero total de

bloques a disco a leer es de 83 (Una explicacin acerca de los clculos realizados para la estimacin de accesos a bloques se puede encontrar en el apndice 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 A5 = 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 seleccin del tipo

Av (r ) con v

disponible en el momento de la estimacin del costo y asumiendo

que los datos del atributo A se distribuyen uniformemente entonces, el nmero de registros que cumplen con la desigualdad es :

n = 0 si v < min(A,r) n = nr si v > max(A,r) n = nr v min( A, r ) en otro caso. max( A, r ) min( A, r )

77

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 bsqueda 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 condicin A >= v. Para una desigualdad del tipo < <= no es necesario utilizar el ndice, simplemente se inicia el recorrido lineal por el archivo que terminar cuando A = v (excluyendo a A = v si el operador es <) En cualquiera de los dos casos, el costo es :
br si v no se conoce en el momento de la optimizacin. 2

C A6 = AAi +

%n C A6 = AAi + $ $ fr

# " si v es conocido en el momento de la optimizacin. "

A7. (ndice secundario, desigualdad): al igual que en el caso anterior si v es desconocido se asume que al menos la mitad de los registros cumplen la condicin, por lo tanto, el costo de este camino de acceso ser :
MBi nr si v no se conoce en el momento de la optimizacin. + 2 2

C A7 = AAi +

que se entiende como el costo de recorrer el ndice hasta encontrar la primera hoja del ndice que se va a usar, sumarle la mitad de los bloques del nivel de hojas del ndice y sumarle (para el caso de los bloques de datos) la mitad de la cantidad de tuplas que tiene la tabla asumiendo en el peor de los casos que se todos los registros se encontraran en bloques diferentes.

78

No siempre es conveniente utilizar los ndices para recuperar rangos de valores, considrese el siguiente ejemplo: Supngase que la la informacin estadstica 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 tamao de la clave del ndice es de 4 bytes, es lgico pensar que en una pgina 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 ms 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 bviaje = 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. Conjuncin, Disyuncin y Negacin.

Conjuncin. Una seleccin conjuntiva es expresin una de la forma

1 2...m ( r ) .

Suponiendo que cada una de las condiciones i es independiente de las otras se

79

puede estimar el tamao de cada seleccin t i = i ( r ) . La probabilidad de que una tupla satisfaga la condicin de seleccin es

ti (llamada selectividad de la nr

seleccin) y la probabilidad de que una tupla satisfaga la conjuncin de selecciones es el producto de todas estas probabilidades. Por lo tanto se estima el tamao de la seleccin completa como:

nr

t1 t 2 t 3 ... t m m nr

Disyuncin. Una seleccin disyuntiva es una expresin de la forma Como

1 2...m ( r ) .

ti denota la probabilidad de que una tupla cumpla i entonces, la nr

probabilidad de que una tupla cumpla la disyuncin es 1 menos la probabilidad de que no cumpla ninguna de las condiciones.

1 (1

t1 t t ) (1 2 ) ... (1 m ) nr nr nr

por lo tanto, al multiplicar este valor por nr se obtiene el nmero de tuplas que satisfacen la relacin.

Negacin.

80

Como el resultado de una negacin son simplemente las tuplas de r que no estn en

(r ) , entonces el nmero de tuplas que cumplen con la condicin de

tamao(r ) tamao( (r ))

negacin es:

Algoritmos para la conjuncin y disyuncin. A8.(seleccin 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 condicin ms selectiva (la que tiene la selectividad ms pequea) recupera un mayor nmero de registros, por lo tanto esta condicin se debe comprobar en primer lugar. A9.(seleccin conjuntiva, ndice compuesto): si la seleccin especifica una condicin de igualdad en dos o ms atributos y existe un ndice compuesto en estos campos, se podra buscar en el ndice directamente. El tipo de ndice determina cual de los algoritmos A3, A4 o A5 se utilizar. A10.(seleccin conjuntiva, interseccin de identificadores): este algoritmo utiliza ndices con punteros a registros en los campos involucrados para cada condicin individual. De este modo se examina cada ndice en busca de punteros cuyas tuplas cumplan alguna condicin individual. La interseccin de todos los punteros recuperados forma el conjunto de punteros a tuplas que satisfacen la condicin conjuntiva.

81

A11. (seleccin disyuntiva mediante la unin de identificadores): al igual que en el caso anterior se utilizan los caminos de acceso en cada una de las condiciones, la unin de los punteros forma el conjunto de punteros a tuplas que satisfacen la condicin disyuntiva, sin embargo se deber efectuar una bsqueda lineal si slo una de las condiciones (o ms) no tiene caminos de acceso. Ejemplo: Dada la consulta :

SELECT * FROM

VIAJES WHERE PATENTE = HL-8483 AND TARIFA = 2000

Suponiendo que la informacin estadstica 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 adems que la altura del ndice en el atributo tarifa es de 3, por lo tanto se necesitan slo 60+3=63 accesos a disco a diferencia de las 83 que se necesitan por medio del uso del ndice primario. Otra tcnica que se puede utilizar es la de interseccin de identificadores. Para este efecto se sabe que ambos ndices tienen altura = 3. para el ndice primario, el nmero de punteros a recuperar es 1200 los cuales caben en 1200/100 = 12 bloques de ndice, para el ndice secundario el nmero de punteros a rescatar es de 60 los cuales caben en una sola pgina. Por lo que hasta el momento se necesitan 6 + 12 + 1 = 19 bloques. Para los bloques de datos se

82

necesita estimar la cantidad de tuplas que cumplen con la conjuncin, como

CS(PATENTE,VIAJES)=1200

CS(TARIFA,VIAJES)=60

entonces

se

sabe

que

(1200*60)/36000 = 2 registros cumplen con la condicin 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 estimacin se fundamenta en la suposicin de que la distribucin de los datos en PATENTES y en TARIFAS es independiente y de que ambos atributos estn distribuidos uniformemente en la relacin.

5.3.3. JOIN.

Estimacin del tamao. Sean r(R) y s(S) dos relaciones: Si R ! S= entonces r

s es lo mismo que r x s, y por lo tanto se puede

utilizar la estimacin del producto cartesiano. Si R ! S es una clave de R entonces el nmero de tuplas en r nmero de tuplas de r
s es exactamente el nmero de tuplas de S. s no es

mayor que el nmero de tuplas en S. Si R ! S es una clave externa de R entonces el

Si R ! 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 ! S={A}, entonces se estima que la tupla t produce :

CS ( A, s ) =

ns V ( A, s )

83

tuplas en s, por lo tanto se estima el tamao de r al cambiar los papeles de r y s se tiene

s=

nr n s V ( A, s )

(a) (b)

nr n s V ( A, r )

Estos valores sern distintos si y slo si V(A,r) V(A,s), si este es el caso, la ms baja estimacin de ambas ser la ms conveniente.

Algoritmos.

5.3.3.1. Join en bucles anidados.

Si z = r

s, r recibir el nombre de relacin externa y s se llamar relacin

interna, el algoritmo de bucles anidados se puede presentar como sigue. para cada tupla tr en r para cada tupla ts en s si (tr,ts) satisface la condicin entonces aadir tr ts al resultado
Algoritmo 5-1 - Join en bucles anidados.

Donde tr ts ser la concatenacin de las tuplas tr y ts . Como para cada registro de r se tiene que realizar una exploracin completa de s, y suponiendo el peor caso, en el cual la memoria intermedia slo puede concatenar un bloque de cada relacin, entonces el nmero de bloques a acceder es de br + nr bs . Por otro lado, en el mejor de los casos si se pueden

84

contener ambas relaciones en la memoria intermedia entonces slo se necesitaran br + bs accesos a bloques. Ahora bien, si la ms pequea de ambas relaciones cabe completamente en la memoria, es conveniente utilizar esta relacin como la relacin interna, utilizando as slo br + 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 condicin entonces aadir 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 relacin interna s se lee una vez por cada bloque de r y no por cada tupla de la relacin externa, de este modo el nmero de bloques a acceder es de br + br bs donde adems resulta ms conveniente utilizar la relacin ms pequea como la relacin externa.

85

5.3.3.3. Join en bucles anidados por ndices.

Este algoritmo simplemente sustituye las bsquedas en tablas por bsquedas en ndices, esto puede ocurrir siempre y cuando exista un ndice en el atributo de join de la relacin interna. Este mtodo se utiliza cuando existen ndices as como cuando se crean ndices temporales con el nico propsito de evaluar la reunin. El costo de este algoritmo se puede calcular como sigue: para cada tupla de la relacin externa r se realiza una bsqueda en el ndice de s para recuperar las tuplas apropiadas, sea c = costo de la bsqueda en el ndice, el cual se puede calcular con cualquiera de los algoritmos A3, A4 o A5. Entonces el costo del join es br + nr c ; si hay ndices disponibles para el atributo de join en ambas relaciones, es conveniente utilizar la relacin 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 comn. Este algoritmo asocia un puntero a cada relacin, al principio estos punteros apuntan al inicio de cada una de la relaciones. Segn avanza el algoritmo, el puntero se mueve a travs de la relacin. De este modo se leen en memoria un grupo de tuplas de una relacin con el mismo valor en los atributos de la reunin.

86

Pr = direccin de la primera tupla de r; ps = direccin 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'[AtribsReunin] = ts[AtribsReunin]) 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[AtribsReunin] < ts[AtribsReunin]) inicio pr = puntero a la siguiente tupla de r; tr = tupla a la que apunta pr; fin mientras; mientras (pr <> nulo y tr[AtribsReunin] = ts[AtribsReunin]) inicio para cada ts en S aadir 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.

87

Dado que las relaciones estn ordenadas, las tuplas con el mismo valor en los atributos de la reunin aparecern consecutivamente. De este modo solamente es necesario leer cada tupla en el orden una sola vez. Puesto que slo se hace un ciclo en ambas tablas, este mtodo resulta eficiente; el nmero de accesos a bloques de disco es igual a la suma de los bloques de las dos tablas br + bs . Si una de las relaciones no est ordenada segn los atributos comunes del join, se puede ordenar primero para luego utilizar el algoritmo de join por mezcla. En este caso hay que considerar tambin 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 relacin 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 variacin de este algoritmo se puede realizar an 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 ms costoso. Para evitar este costo se puede utilizar un algoritmo de join por mezcla hbrido, que combina ndices con un join por mezcla. Si slo una de las relaciones est desordenada pero existe un ndice secundario en el atributo de join, el algoritmo de join por mezcla hbrido combina la relacin ordenada con las entradas hojas del ndice secundario. El resultado de esta operacin se debe ordenar segn las direcciones del ndice secundario permitiendo as una recuperacin eficiente de las tuplas, segn el orden fsico de almacenamiento.

88

5.3.3.5. Join por asociacin.

Al igual que el algoritmo de join por mezcla, el algoritmo de join por asociacin se puede utilizar para un Join natural o un equi-join. Este algoritmo utiliza una funcin de asociacin h para dividir las tuplas de ambas relaciones. La idea fundamental es dividir las tuplas de cada relacin en conjuntos con el mismo valor de la funcin de asociacin en los atributos de join. Se supone que:

h es una funcin de asociacin que asigna a los atributos de join los valores {0,1,...max}

H r0 , H r1 ,...H rmax denotan las particiones de las tuplas de r, inicialmente todas

vacas. Cada tupla
t r se

pone

en

la

particin

H ri

donde

i =h(tr [Atributos _ de _ Join])

H s0 , H s1 ,...H smax denotan las particiones de las tuplas de s, inicialmente todas

vacas. Cada tupla

ts se

pone

en

la

particin

H si

donde

i =h(t s [Atributos _ de _ Join])

La idea detrs del algoritmo es la siguiente, supngase que una tupla de r y una tupla de s satisfacen la condicin de join y por lo tanto tienen los mismos valores en los atributos de join. Si estos valores se asocian con algn valor i, entonces la tupla de r tiene que estar en H ri y la tupla de s tiene que estar en H si , de este modo slo ser necesario comparar las tuplas de r en H ri con las tuplas de s en H si y no con las tuplas de s de otra particin.

89

El algoritmo es el siguiente. para cada tupla t s en s

i =h(t s [Atributos _ de _ Join]) ; H si = H si " {t s } ;

fin para; para cada tupla t r en r
i =h(tr [Atributos _ de _ Join]) ;

H ri = H ri " {t r } ;
fin para; para i = 1 hasta max leer H si y construir un ndice asociativo en memoria sobre l; para cada tupla t r en H ri explorar el ndice asociativo en H si para localizar todas las tuplas tales
t r [Atributos _ de _ Join] ;

que

t s [Atributos _ de _ Join]

para cada tupla t s que concuerde en H si aadir t r x t s al resultado; fin para; fin para; fin para;
Algoritmo 5-4 - Join por asociacin.

90

El ndice asociativo (ver Apndice B) en H si se construye en memoria por lo que no se hace necesario acceder al disco para recuperar las tuplas, la funcin de asociacin utilizada para construir este ndice es distinta a la funcin h utilizada para construir las particiones. Despus de la divisin de las relaciones el resto del cdigo 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 si y luego se prueba (se busca en H si ) con las tuplas de H ri . Se tiene que elegir el valor de max lo suficientemente grande como para que, para cada i, las tuplas de la particin H si junto con el ndice asociativo de la relacin quepan completamente en la memoria. Claramente ser ms conveniente utilizar la relacin ms pequea como la relacin s. Si el tamao de la relacin s es

bs bloques, entonces para que cada una de las max particiones tengan un tamao
menor o igual a M, max debe ser al menos %bs / M # ms el espacio adicional ocupado por el ndice asociativo. Una consideracin a seguir para que las divisiones de las relaciones se efecte en un solo paso es que M>max+1 o equivalentemente si M>( bs /M)+1 que de manera aproximada se simplifica a

M > bs . Por ejemplo, si una relacin contiene 440 bloques de 2KB cada uno,
entonces M > 440 , osea M > 20. De tal manera slo se necesitarn 40 Kb. de espacio de memoria (ms el espacio requerido por el ndice asociativo) para el particionamiento de la relacin. El clculo del costo de un join por asociacin tiene la siguiente lgica: el particionamiento de ambas relaciones reclama una lectura completa de cada relacin, como tambin su posterior escritura, esta operacin necesita 2(br + bs ) accesos a bloques. Las fases de construccin y prueba (como se le denomina al join en bucle anidado por ndices) lee cada una de las particiones una vez

91

empleando br + bs accesos adicionales. El nmero de bloques ocupados por las particiones podra ser ligeramente mayor que br + bs . Debido a que los bloques no estn completamente llenos,. El acceso a estos bloques puede aadir un gasto adicional de 2max a lo sumo, ya que cada una de las particiones podra tener un bloque parcialmente ocupado que se tiene que leer y escribir de nuevo. As el costo estimado para un join por asociacin es :

3(br + bs ) + 2 max

5.3.3.6. Join por asociacin hbrida.

El algoritmo de join por asociacin hbrida realiza otra optimizacin; es til cuando el tamao de la memoria es relativamente grande paro an as, no cabe toda la relacin s en memoria. Dado que el algoritmo de join por asociacin 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 particin de la relacin s, esto es H s0 , as no es necesaria leerla ni escribirla nuevamente y se puede construir un ndice asociativo en H s0 . Cuando r se divide, las tuplas de H r0 tampoco se escriben en disco; en su lugar, segn se van generando, el sistema las utiliza para examinar el ndice asociativo en H s0 y as generar las tuplas de salida del join. Despus de utilizarlas, estas tuplas se descartan, as que la particin H r0 no ocupa espacio en memoria. De este modo se ahorra un acceso de lectura y uno de escritura para cada bloque de H r0 y H s0 . Las tuplas de otras particiones se escriben de la manera usual para reunirlas ms tarde.

92

5.3.3.7. Join Complejos.

Los join en bucle anidado y en bucle anidado por bloques son tiles siempre, sin embargo, las otras tcnicas de join son ms eficientes que estas, pero slo se pueden utilizar en condiciones particulares tales como join natural o equi-join. Se pueden implementar join con condiciones ms complejas tales como conjuncin o disyuncin, aplicando las tcnicas desarrolladas en la seccin 5.3.2 para el manejo de selecciones complejas. Dado un join de las forma r

1 2 ... n

s se pueden aplicar una o ms de las

i

tcnicas de join descritas anteriormente en cada condicin individual r

s , el

resultado total consiste en las tuplas del resultado intermedio que satisfacen el resto de las condiciones. Estas condiciones se pueden ir comprobado segn se generen las tuplas de r la conjuncin. Outer Join (Join externos) Un outer join es una extensin del operador join que se utiliza a menudo para trabajar con la informacin 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 relacin Chofer con la relacin Movil. Si se efecta un join corriente se perdern 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 relacin de la izquierda que no
i

s . La implementacin de la disyuncin es homloga a

93

coincidan con ninguna tupla de la relacin de la derecha , las rellena con valores nulos en los dems atributos de la relacin de la derecha y las aade al resultado del join natural. Un outer join por la derecha ( x[ ) ) es anlogo al procedimiento anterior y el outer join completo es aquel que efecta ambas operaciones. Se puede implementar un outer join empleando una de las dos estrategias siguientes. La primera efecta un join natural y luego aade ms 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 relacin temporal q1, a

continuacin se calcula r R (q1) que produce las tuplas de r que no participan del join, estas tuplas se rellenan con valores nulos en los atributos de s y se aaden a q1 para obtener el resultado deseado. El procedimiento es homlogo 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 relacin externa que no concuerden con ninguna tupla de la relacin 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 asociacin. En el caso del algoritmo de join por mezcla, cuando se est produciendo la mezcla de ambas relaciones, las tuplas de la relacin que no encajan con ninguna tupla de la otra relacin se rellenan con valores nulos y se escriben en la salida. Puesto que las relaciones estn ordenadas, es fcil detectar si una tupla coincide o no con alguna tupla de la otra relacin. 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 tamao del resultado, por lo tanto el nmero de bloques a escribir en el resultado puede aumentar.

94

5.3.3.8. Agregacin.

La agregacin es otra de las caractersticas 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 comnmente para informacin agregada (de ah su nombre), analizan una agrupacin de registros y rescatan el valor solicitado, se aplican sobre un atributo o sobre una composicin de atributos, el valor retornado puede ser min, max, count, sum, avg, que corresponden respectivamente a el mnimo valor del subconjunto; el mximo valor; una cuenta de valores; la suma sobre algn atributo o composicin de atributos y el promedio. Para la implementacin de la operacin de agregacin se puede utilizar un algoritmo de ordenacin o uno de asociacin, para el caso de la asociacin, lo que se hace es agrupar las tuplas que tengan el mismo valor en los atributos de la agregacin y luego se aplica la funcin de agregacin en cada uno de los grupos para obtener el resultado. El tamao de la agregacin sobre A es simplemente V(A,r). El costo estimado de la implementacin de la agregacin es el mismo de una ordenacin (cualquiera sea el algoritmo). En lugar de reunir todas las tuplas en grupos y aplicar entonces las funciones de agregacin, se pueden implementar sobre la marcha segn se construyen los grupos. Si las V(A,r) tuplas del resultado caben en memoria, las implementaciones basadas en ordenacin y las basadas en asociacin no requieren escribir bloques adicionales a disco, segn se leen las tuplas se pueden ir insertando en una estructura ordenada de rbol o en un ndice asociativo, de esta manera slo se necesitan br transferencias de bloques.

95

5.4. Evaluacin de expresiones.

En este apartado se considerar como evaluar una expresin que contiene varias operaciones, la forma intuitiva de evaluar una expresin es evaluar una operacin a la vez en un orden apropiado, el resultado de cada operacin se materializa en una relacin temporal para su inmediata utilizacin. El inconveniente de esta aproximacin es la creacin de relaciones temporales que implican la escritura y lectura de disco. Una aproximacin alternativa es evaluar operaciones de manera simultanea en un cauce, con los resultados de una operacin pasados a la siguiente sin la necesidad de almacenarlos en relaciones temporales.

5.4.1. Materializacin.

Este enfoque de implementacin toma la expresin y la representa en una estructura anexa (comnmente un rbol de operadores). Luego se comienza por las operaciones de ms 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 evaluacin como la descrita se llama evaluacin materializada, puesto que los resultados de cada operacin intermedia se crean (materializan) con el fin de ser utilizados en la evaluacin de las operaciones del siguiente nivel.

96

El costo de una evaluacin 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 operacin en disco, por lo tanto, al costo de las operaciones involucradas hay que aadir 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 nr br donde nr es el nmero aproximado de tuplas de la relacin resultado y f r es el factor de bloqueo de la relacin resultado.

5.4.2. Encauzamiento.

Se puede mejorar la evaluacin de una consulta mediante la reduccin del nmero de archivos temporales que se producen. Por ejemplo, considrese el join de dos relaciones seguida de una proyeccin. Si se aplicara materializacin en la evaluacin de esta expresin implicara la creacin de una relacin temporal para guardar el resultado del join y la posterior lectura de esta para realizar la proyeccin. Estas operaciones se pueden combinar como sigue. Cuando la operacin de join genera una tupla del resultado, esta se pasa inmediatamente al operador de proyeccin para su procesamiento. Mediante la combinacin del join y de la proyeccin, se evita la creacin de resultados intermedios, creando en su lugar el resultado final directamente. La implementacin del encauzamiento se puede realizar de dos formas: 1. Bajo demanda (enfoque top-down) 2. Desde los procedimientos (enfoque bottom-up)

97

En un encauzamiento bajo demanda el sistema reitera peticiones de tuplas desde la operacin de la cima del encauzamiento. Cada vez que un operador recibe una peticin de tuplas calcula la siguiente tupla a devolver y la enva 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 operacin 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 operacin a otra solamente cuando se llena una memoria intermedia de salida o cuando una memoria intermedia de entrada est vaca y se necesitan ms 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 comnmente ms que el encauzamiento desde los procedimientos dada su facilidad de implementacin.

5.4.3. Algoritmos de encauzamiento.

Supngase 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 relacin significa transformar el procedimiento en materializacin. Este ejemplo ilustra que la eleccin respecto al algoritmo a utilizar

98

para una operacin y las elecciones respecto del encauzamiento son dependientes una de la otra. El uso eficiente del encauzamiento necesita la utilizacin de algoritmos de evaluacin que puedan generar tuplas de salida segn se estn recibiendo tuplas por la entrada de la operacin. Se pueden distinguir dos casos: 1. Solamente una de las entradas est encauzada. 2. Las dos entradas de un join estn encauzadas.

Si nicamente una de las entradas est encauzada, un join en bucle anidado indexado es la eleccin ms natural, ahora bien, si se sabe de antemano que las tuplas de la entrada encauzada estn ordenadas por los atributos de join y la condicin de join es un equi-join tambin se puede usar un join por mezcla. Se puede utilizar un join por asociacin hbrida con la entrada encauzada como la relacin para probar (relacin r). Sin embargo, las tuplas que no estn en la primera particin se enviarn a la salida solamente despus de que la relacin de entrada encauzada se reciba por completo. Un join por asociacin hbrida es til si la entrada no encauzada cabe completamente en memoria, o si al menos la mayora de las entradas caben en memoria. Si ambas entradas estn encauzadas, la eleccin de los algoritmos de join se limita. Si ambas entradas estn ordenadas por el atributo de join y la condicin de join es un equi-join entonces se puede utilizar el mtodo de join por mezcla. Otra tcnica alternativa es el join por encauzamiento que se presenta a continuacin. El algoritmo supone que las tuplas de entrada de ambas relaciones r y s estn 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 Finr y Fins , que sirven como marcas de fin de

99

archivo y que se insertan en la cola despus de que se hayan generado todas las tuplas de r y de s (respectivamente). Para una evaluacin eficaz, se deberan construir los ndices apropiados en las relaciones r y s. Segn se aaden 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 vaca entonces esperar hasta que la cola no este vaca; t = primera entrada de la cola; si t = Finr entonces hechor = verdadero; sino si t = Fins entonces hechos = verdadero; sino si t es de la entrada r entonces r = r " {t}; resultado = resultado " ({t} sino s = s " {t}; resultado = resultado " (r fin si fin si fin si fin mientras
Algoritmo 5-5 - Join encauzado.

s);

{t});

100

5.4.4. Transformacin de expresiones relacionales.

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 implementacin de base de datos tiene su forma de representacin interna de consultas independientes del lenguaje de consultas utilizado. La representacin interna debe cumplir con la caracterstica de ser relacionalmente completo, es por eso que comnmente los motores de BD eligen la representacin del lgebra relacional en forma de rbol sintctico abstracto para su representacin interna. Dada una expresin del lgebra relacional, es trabajo del optimizador alcanzar un plan de evaluacin que calcule el mismo resultado que la expresin dada pero de la manera menos costosa de generar. Para encontrar este plan de evaluacin el optimizador necesita generar planes alternativos que produzcan el mismo resultado que la expresin dada y elegir el ms econmico de ellos. para implementar este paso el optimizador debe generar expresiones que sean equivalente a la expresin dada por medio del uso de las reglas de equivalencia que se explican a continuacin.

101

5.4.4.2. Reglas de equivalencia.

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 expresin en su forma cannica. La nocin de forma cannica es central a muchos brazos de la matemtica y otras disciplinas relacionadas. Esta puede ser definida como sigue: Dado un conjunto de Q objetos (digamos consultas) y una nocin de equivalencias entre objetos (digamos, la nocin de que q1 y q2 son equivalentes si y slo si ellas producen el mismo resultado), un subconjunto C de Q se dice la forma cannica de Q (bajo la definicin de equivalencia expuesta anteriormente) si y slo si cada objeto q en Q es equivalente a slo un objeto c en C. El objeto c es llamado la forma cannica de el objeto q. Todas las propiedades de inters que se aplican al objeto q tambin se aplican a su forma cannica c; por lo tanto es suficiente estudiar slo el pequeo conjunto de formas cannicas C y no el conjunto Q con el fin de probar una variedad de resultados.

las reglas de equivalencia para llevar la expresin relacional a una equivalente son:

102

1. Cascada de proyecciones:

L1 ( L 2 (...( Ln ( E ))...)) = L1 ( E )

2. Cascada de selecciones:

1 2 ( E ) = 1 ( 2 ( E ))

3. Conmutacin de selecciones:

1 ( 2 ( E )) = 2 ( 1 ( E ))

4. Conmutacin de seleccin y proyeccin.

L ( ( E )) = ( L ( E ))

5. Conmutacin del Join.

E1

E2 = E2

E1

103

6. Asociatividad del Join Natural. caso1.

( E1
E2 )

E3 = E1

( E2

E3 )

caso 2. 2 involucra slo atributos de E2 y E3 .

( E1
1

E2 )

2 3

E3 = E1

1 3

( E2

E3 )

7. Distributividad de la seleccin con respecto al join. caso 1. 0 involucra slo atributos de E1 .

0 ( E1

E2 ) = 0 ( E1 )

E2

caso 2. 1 involucra slo atributos de E1 y 2 involucra slo atributos de

E2

1 2 ( E

E2 ) = ( 1 ( E1 ))

( 2 ( E2 ))

8. Distributividad de la proyeccin con respecto al join. Si L1 y L2 son los atributos de E1 y E2 respectivamente.

L1" L 2 ( E1

E2 ) = ( L1 ( E1 ))

( L 2 ( E2 ))

104

9. Conmutatividad de la unin y la interseccin.

E1 " E2 = E2 " E1 E1 ! E2 = E2 ! E1
La diferencia de conjuntos no es conmutativa.

10. Asociatividad de la unin e interseccin.

( E1 " E2 ) " E3 = E1 " ( E2 " E3 ) ( E1 ! E2 ) ! E3 = E1 ! ( E2 ! E3 )

11. Distributividad de la seleccin con respecto a la unin, interseccin y diferencia.

( E1 " E2 ) = ( E1 ) " ( E2 ) ( E1 ! E2 ) = ( E1 ) ! ( E2 ) ( E1 E2 ) = ( E1 ) ( E2 ) = ( E1 ) E2

12. Distributividad de la proyeccin con respecto a la unin.

L ( E1 " E2 ) = ( L ( E2 )) " ( L ( E1 ))

Tabla 5-3 - Reglas de equivalencia para expresiones relacionales.

Ejemplo:

105

Supngase que lo que se desea es notificar a todos los dueos de vehculos del ao, que estn siendo conducidos por los choferes con menos experiencia (supngase un ao o menos); la expresin relacional sera :

Dueo.nombre ( Moviles.ao =2001Choferes.Fecha _ licencia _ desde> Fecha ()1 _ ao (( Dueos

Moviles)

Choferes)

Se puede utilizar la regla 6.1 con el fin de asociar el Join.

Dueo.nombre ( Moviles.ao= 2001Choferes.Fecha _ licencia _ desde> Fecha ()1 _ ao ( Dueos

( Moviles

Choferes))

Aplicando la regla 5 se puede conmutar el Join.

Dueo.nombre ( Moviles.ao=2001Choferes.Fecha _ licencia _ desde> Fecha ()1 _ ao (( Moviles

Choferes)

Dueos)

Luego se aplica la regla 7.1 con el fin de distribuir la seleccin sobre el join.

Dueo.nombre (( Moviles.ao= 2001Choferes.Fecha _ licencia _ desde> Fecha ()1 _ ao ( Moviles

Choferes))

Dueos)

Aplicando la regla 7.2 se obtiene :

Dueo.nombre ((( ao=2001 ( Moviles))

( Fecha _ licencia _ desde> Fecha ()1 _ ao (Choferes)))

Dueos)

106

Las siguientes figuras muestran la expresin inicial y la final en una estructura de rbol sintctico.

107

As, los optimizadores generan de manera sistemtica expresiones equivalentes a la consulta dada. El proceso se entiende como sigue: dada una expresin, se analiza cada subexpresin para saber si se puede aplicar una regla de equivalencia. De ser as se genera una nueva expresin donde la subexpresin que concuerda con una regla de equivalencia se reemplaza por su equivalente. Este proceso contina hasta que no se pueden generar ms expresiones nuevas. Una optimizacin en trminos de espacio se puede lograr como sigue. Si se genera una expresin E1 de una expresin E2 mediante una regla de equivalencia, entonces E1 y E2 son equivalentes en su estructura y por lo tanto sus subexpresiones son idnticas. Las tcnicas de representacin de expresiones que permiten a ambas expresiones apuntar a la subexpresin compartida pueden reducir el espacio de bsqueda significativamente.

5.5. Ordenes de Join.

En los sistemas de base de datos relacionales tradicionales raramente se encuentra una consulta que involucre ms de 5 tablas, de este modo, el clculo de un orden de Join ptimo con el menor costo de evaluacin por medio de una bsqueda exhaustiva es perfectamente posible. Sin embargo, cuando esta consulta involucra 8 o ms tablas el problema no se puede determinar de esta forma. Por lo tanto lo que se espera son algoritmos que calculen la mejor aproximacin a la solucin. Estos algoritmos pueden ser separados en dos clases. 1. Heursticas: Construyen un plan de evaluacin paso a paso de acuerdo a ciertos criterios predefinidos.

108

2. Aleatorios: Realizan una especie de caminata aleatoria a travs 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 relacin 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 operacin Join es conmutativa y asociativa (ver equivalencia de expresiones algebraicas en la seccin 5.4.4.1) el nmero de posibles rboles de proceso se incrementa rpidamente a medida que se incrementa el nmero de relaciones bases que participan en el Join. Existe un subconjunto de este espacio de soluciones, comnmente llamado rboles en profundidad por la izquierda que ha sido de especial inters 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 relacin interna de cada Join es una relacin base. Para un nmero fijo de relaciones base, la especificacin de profundidad por la izquierda no deja ningn 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 disposicin General. La solucin 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 ms 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 Determinsticos. Cada algoritmo en esta clase construye una solucin paso a paso de una forma determinstica, ya sea aplicando heursticas o por medio de una bsqueda 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 slo si, ellas pueden ser transformadas una en la otra por medio de un slo movimiento. Cada uno de estos algoritmos realizan una caminata aleatoria a lo largo de los mrgenes de acuerdo a ciertas reglas, terminando ya sea si no existen ms movimientos a realizar o si se ha excedido un lapso de tiempo predeterminado. La mejor solucin encontrada hasta ese momento es la solucin elegida.

3. Algoritmos Genticos. Estos algoritmos hacen uso de la estrategia aleatoria, muy similar a la evolucin biolgica. La idea bsica es comenzar con una poblacin base y generar descendencia por medio de cruces aleatorios, el ms digno de los miembros de la poblacin (de acuerdo a una funcin de costo) sobrevive a la seleccin y la siguiente generacin estar basada en l. El algoritmo terminar ya sea si no hay mayor

110

perfeccionamiento o despus de un determinado nmero de generaciones. El miembro ms digno de la poblacin actual en el momento de terminar el algoritmo ser la solucin elegida.

4. Algoritmos hbridos. Los algoritmos hbridos combinan las estrategias de los algoritmos determinsticos y de los aleatorios. La idea es que la solucin obtenida por medio de algoritmos determinsticos algoritmos genticos. sirva como punto de partida para los algoritmos aleatorios o como poblacin base para los

5.5.1. Algoritmos Determinsticos.

5.5.1.1. Selectividad mnima.

Las buenas soluciones comnmente se caracteriza porque los resultados intermedios tienen una pequea cardinalidad. La heurstica de selectividad mnima construye un rbol de profundidad por la izquierda paso a paso mientras trata de mantener relaciones intermedias tan pequeas 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 Relacin Ri Rrestantes con el menor factor de selectividad

ser mezclada con el resultado intermedio y ser movida desde Rrestantes a Rusados .

5.5.1.2. Heurstica Top-Down.

El principio de esta tcnica esta basado en la observacin de que los ltimos Join son los ms importantes para la expresin en trminos de costo, simplemente porque los resultados intermedios tienden a ser algo ms largos hacia el fin de la evaluacin. 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 relacin en el orden ser la que tiene el menor costo si se une con el resto, suponiendo un costo h como medida mnima, el costo de cada una de las 6 combinaciones sera:

112

C(OBAPW C(CBAPW C(COAPW C(COBPW C(COBAW C(COBAP

C) = h O) = 35h B) = 5h A) = h P) = h W) = h

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 C(OAPW C(OBPW C(OBAW C(OBAP

O) = 7h B) = 5h A) = h P) = h W) = h

Al escoger A como la siguiente relacin, el tercer paso ser:

C(BPW C(OPW C(OBW C(OBP

El cuarto paso luego de escoger P:

O) = 7h B) = 5h P) = h W) = h

C(BW
C(OW

O) = 7h
B) = 5h

C(OB

W) = h

113

Luego de escoger W como la cuarta relacin en el orden las alternativas restantes son:

C(B

O) = 7h

C(O
As, el orden final de Join es :

B) = 5h

((((O

B)

W)

P)

A)

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 mrgenes que se definen como un conjunto de movimientos. Este tipo de algoritmos realizan una suerte de caminata aleatoria a travs del espacio de soluciones a lo largo de los mrgenes 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 solucin slo 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 ms simple realiza una caminata a travs 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 solucin (en trminos de la funcin de costo elegida) este se almacenar como el nuevo resultado. El algoritmo terminar despus de un predeterminado nmero de movimientos y la mejor solucin encontrada hasta el momento ser la solucin elegida como resultado. En principio, este algoritmo traza una muestra aleatoria desde el conjunto de todas las soluciones posibles y entrega la mejor solucin desde esta muestra. El rendimiento de este algoritmo depende fuertemente del factor de buenas / malas soluciones y del tamao de la muestra elegida. Sin embargo, es obvio que esta estrategia es una perdida de recursos dado que slo cubre una pequea rea en la proximidad del punto de partida y no se hace nunca un intento siquiera de encontrar un mnimo local.

5.5.2.2. Mejora Iterativa.

Un acercamiento ms sofisticado es el algoritmo de mejora iterativa [Swami88]. Luego de seleccionar una punto de partida aleatorio el algoritmo busca un punto de costo mnimo. comenzando en el punto de partida, se elige al azar un vecindario prximo (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 mnimo local si no se han encontrado vecinos con menor costo despus de un cierto nmero de intentos. Este procedimiento se repite hasta que se hayan procesado un nmero predeterminado de puntos de partida o se haya excedido un lmite de tiempo. El menor de los mnimos locales encontrados ser el resultado.

115

5.5.2.3. Simulacin de coccin.

El algoritmo de mejora iterativa sufre de un gran inconveniente: dado que los movimientos son aceptados slo si mejoran el resultado obtenido hasta el momento, es posible que an con un alto nmero de puntos de partida el resultado final sea inaceptable. Este ser el caso cuando el espacio de solucin no muestra un mnimo global, sino que una gran nmero de mnimos locales de alto costo. En este caso el algoritmo puede quedar fcilmente atrapado en uno de estos mnimos locales. El algoritmo de Simulacin de coccin es un refinamiento de la Mejora Iterativa que quita esta restriccin. En el algoritmo de Simulacin de coccin se puede efectuar un movimiento an si los puntos del vecindario son de costos altos. As este algoritmo no queda tan fcilmente atrapado en mnimos locales como el algoritmo de Mejora Iterativa. El nombre de este algoritmo viene del estudio del proceso de coccin de los cristales, en este proceso natural el sistema eventualmente alcanza un estado de mnima energa 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 mnimo local que encuentra, el algoritmo de Simulacin de coccin se salta la barrera de costo que separa este punto del punto mnimo 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 nuevo. con una probabilidad que depender de la temperatura y de la diferencia entre el estado de costo actual y el

116

Figura 5-1 - Comportamiento del Algoritmo de Simulacin de Coccin

En cualquier caso,

el comportamiento exacto del algoritmo est

determinado por parmetros tales como la temperatura inicial, los pasos de reduccin de temperatura y la condicin de fin. La literatura al respecto presenta distintas variantes que no viene al caso estudiarlas ac. Para encontrar referencias se recomienda consultar [Steinbrunn93].

117

5.5.3. Algoritmos Genticos.

Los Algoritmos genticos estn diseados para simular el proceso natural de evolucin. Al igual que en la naturaleza, donde el miembro ms digno de una poblacin es el que tiene la mayor probabilidad de sobrevivir y de heredar sus caractersticas a su descendencia, los algoritmos genticos propagan soluciones para un determinado problema de generacin en generacin, combinndolos para alcanzar mejoras. A continuacin se presenta una breve terminologa, para una compresin ms detallada se recomienda consultar [Steinbrunn93]. Una de las caractersticas ms importantes de los algoritmos genticos es que trabajan sobre un conjunto de soluciones (poblacin). 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 gentico tiene una solucin representada como una cadena de caracteres con una codificacin apropiada. La dignidad de una solucin se medir de acuerdo a una funcin objetivo que debe ser minimizada o maximizada. Generalmente, en un algoritmo gentico bien diseado ya sea el ndice de dignidad promedio como el de la mejor solucin se deben incrementar con cada nueva generacin.

118

5.5.3.1. Algoritmo gentico para la optimizacin de ordenes de Join.

El principio de este algoritmo es el siguiente. Primero, se genera una poblacin aleatoria de cadenas de caracteres, Esta ser la generacin cero de soluciones. Luego, cada generacin se determina como sigue.

Una fraccin de los miembros ms dignos de la poblacin se propaga a la siguiente generacin (Principio de seleccin).

Una fraccin de los miembros ms dignos de la poblacin se combina generando descendencia. (principio de combinacin)

Una fraccin de la poblacin (no necesariamente la ms digna) se altera de forma aleatoria (Principio de Mutacin) Estas fracciones son elegidas de modo que el nmero total de soluciones

permanezca invariante. Este ciclo se itera hasta que la mejor solucin en la poblacin ha alcanzado la calidad deseada, se ha producido un nmero predeterminado de generaciones o hasta que la mejora entre una generacin y otra ha cado por debajo de un cierto umbral predeterminado. Antes de que se pueda aplicar un cierto algoritmo se debe elegir una codificacin apropiada y una funcin objetivo. Para la optimizacin de ordenes de join las soluciones son rboles ya sea de profundidad por la izquierda o de

119

disposicin general. La funcin objetivo es la evaluacin de costo a ser minimizada. Una codificacin 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 Seleccin. El operador de seleccin se utiliza para separar buenas y malas soluciones de la poblacin, la motivacin 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 seleccin. La poblacin de muestra consiste de 4 soluciones, la funcin 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 solucin se le asigna un sector en una ruleta de tamao 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 solucin 4 se ha extinguido debido a falta de adaptacin.

120

Figura 5-2 - Ejemplo del principio de seleccin para el algoritmo gentico para la optimizacin de ordenes de Join

Este esquema se basa en el factor de dignidad de los miembros de la poblacin. Mientras mejor se satisfaga la funcin objetivo ms posibilidades tiene en la ruleta. Principio de Combinacin. El operador de combinacin es un medio para combinar parcialmente las buenas soluciones con el fin de obtener un resultado superior. La realizacin de una combinacin depender fuertemente de la codificacin escogida dado que, el operador de combinacin tiene que tener la certeza de que las caractersticas de una codificacin en particular no se han violado. Para el caso estndar de la

121

codificacin estudiada en los rboles de profundidad por la izquierda se utiliza el operador de combinacin 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 combinacin para el algoritmo gentico para la optimizacin 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 efecta de igual forma. Principio de Mutacin. El operador de mutacin se utiliza para introducir caractersticas que no estn presentes en ningn miembro de la poblacin. La mutacin se lleva a cabo por medio de la alteracin aleatoria de una cadena seleccionada aleatoriamente. Una forma bsica de mutacin es el intercambio (swap) de 2 caracteres aleatorios dentro de una cadena.

122

Debido al carcter de la mutacin como algo poco deseado en un proceso evolutivo, este no debe ser aplicado sin control sobre una generacin dado que puede ser daada severamente. Usualmente se realizan muy pocas mutaciones en una generacin.

123

5.6. Eleccin de los planes de evaluacin.

Un plan de evaluacin define exactamente que algoritmo utilizar para cada operacin y como coordinar la ejecucin de las operaciones. La Figura 5-4 muestra un plan de evaluacin para la expresin analizada en el ejemplo de la seccin 5.4.4.2. Se hace la suposicin respecto a algunos ndices con el fin de lograr encauzamiento.

Figura 5-4 - Un plan de evaluacin de ejemplo

124

Una forma de elegir los planes de evaluacin es simplemente elegir para cada operacin el algoritmo ms econmico para luego elegir cualquier ordenacin. Sin embargo, la eleccin independiente del algoritmo ms econmico no es necesariamente la mejor eleccin. Por ejemplo, en una operacin de Join, bajo ciertas circunstancias puede ser ms costosa con el algoritmo de join por mezcla de lo que podra ser con un algoritmo de Join por asociacin. Sin embargo, la primera alternativa puede producir una salida ordenada que puede ayudar a la evaluacin de una operacin posterior (como una eliminacin de duplicados o la entrada para otro join por mezcla) por lo tanto, para elegir el mejor algoritmo genrico 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 operacin, incluyendo aqu las decisiones de encauzamiento de esta operacin con otra a evaluar. Existen 2 grandes aproximaciones para elegir el mejor plan de evaluacin de una consulta. La primera examina todos los planes y elige el mejor basndose en el costo estimado. La segunda aproximacin utiliza heursticas. La mayora de los optimizadores actuales incorporan elementos de ambas aproximaciones en la eleccin de los planes de ejecucin.

5.6.1. Heursticas.

Aunque sea paradojal, el mayor inconveniente de la optimizacin por costos es precisamente el clculo del costo, para aliviar este clculo muchos

125

optimizadores utilizan heursticas que ayudan a reducir el nmero de elecciones a realizar en la optimizacin por costos. Algunas de estas son utilizadas y aceptadas por la mayora de los optimizadores, a decir :

Realizar las selecciones tan pronto como sea posible. Un optimizador basado slo en heursticas debera 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, considrese la expresin

(r | x | s ) donde la condicin se

refiere solamente a los atributos de s. Supngase adems que r es extremadamente pequeo, 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 seleccin, puesto que al no existir ndices en los atributos de aplicar la seleccin significara recorrer todas las tuplas de s (full scan), siendo que es ms barato realizar el join (por medio de los ndices) y luego rechazar las tuplas que no cumplen la seleccin.

Realizar las proyecciones al principio. Esta heurstica se ocupa comnmente en el caso de que sea necesario generar una relacin temporal, se reduce la cantidad de atributos a seleccionar, lo que implica reducir el tamao de estas relaciones en gran medida.

Una revisin de las reglas de equivalencia del apartado 5.4.4.2 puede llevar a la construccin de un algoritmo heurstico que reordene los componentes del rbol sintctico inicial con el fin de mejorar la ejecucin de la consulta. 1. Deshacer las selecciones conjuntivas en una serie de selecciones simples, basndose en la regla de equivalencia nmero 2 (ver apartado 5.4.4.2).

126

2. Mover las operaciones de seleccin hacia abajo en el rbol de la consulta para una ejecucin 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 seleccin y join producirn las relaciones temporales ms pequeas. 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 relacin 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 subrboles cuyas operaciones se pueden encauzar y ejecutarlas utilizando encauzamiento (ver apartado 5.4.2). En resumen : estas heursticas reordenan la representacin inicial del rbol de una consulta de tal modo que las operaciones que reducen el tamao de los resultados intermedios se apliquen primero; las selecciones anticipadas reducen el tamao de tuplas y las proyecciones reducen el nmero de atributos. Las transformaciones heursticas tambin reestructuran el rbol para que las selecciones y los joins ms restrictivos se realicen antes que otras operaciones similares.

127

La optimizacin heurstica tambin hace corresponder la expresin de la consulta heursticamente transformada con secuencias alternativas de operaciones para producir un conjunto candidato de planes evaluacin. Un plan de evaluacin incluye no slo las operaciones relacionales a realizar, sino tambin los ndices a utilizar, el orden en que se acceden las tuplas y el orden en que se tienen que producir las operaciones.

128

Captulo 6.

El

Optimizador

de

Consultas

de

Sybase

Adaptive Server Enterprise, un ejemplo prctico.

6.1. Introduccin.

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 ms barato que minimice el tiempo total de una consulta. Para alcanzar este objetivo, el optimizador de consultas de ASE buscar caminos de acceso que:

Minimicen el acceso a pginas lgicas Minimicen el acceso a pginas fsicas. Los pasos que el optimizador ocupa para analizar una consulta son :

1. Anlisis sintctico (Parser) de la consulta validando adems las referencias de objetos. 2. Optimizacin de la consulta y generacin del plan de la consulta. 3. Compilacin del plan de la consulta. 4. Ejecucin del plan y devolucin del resultado al usuario. Un estudio ms detallado sobre el paso 2 llevar a una subdivisin de este en:

129

1. Anlisis de la consulta. 2. Seleccin de ndices. 3. Seleccin de los ordenes de Join. 4. Uso de tablas temporales (Worktables). 5. Seleccin del plan.

6.2. Anlisis de la Consulta.

El primer paso que realiza ASE es analizar cada tabla de la consulta con el fin de reconocer los SARG (argumentos de bsqueda), las clusulas OR y las clusulas de JOIN. La identificacin de estas clusulas sirve para que se utilicen en la siguiente etapa para seleccionar ndices.

Clusulas SARG : La existencia de SARG en una consulta habilita al optimizador a limitar el nmero 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 <=. El operador de desigualdad (!= o <>) si bien es cierto es un operador vlido, no es un operador que pueda ser analizado por el optimizador. Cada vez que en una consulta aparezca un operador de desigualdad el optimizador utilizar un table scan para resolver la desigualdad a menos que pueda ser resuelta por medio de un ndice.

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 DUEO WHERE VIGENCIA <> 0 Se puede rescribir como :

SELECT NOMBRE FROM DUEO WHERE VIGENCIA = 1 La cual contiene un SARG valido que el optimizador reconocer y lo considerar para calzarlo con algn 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 <=

FECHA BETWEEN 01-01-2001 AND 12-31-2001 se transforma en :

FECHA >= 01-01-2001 AND FECHA <=12-31-2001

LIKE se transforma en >= AND < NOMBRE LIKE Sm%

131

se transforma en: NOMBRE >= Sm AND NOMBRE <= Sn La clusula LIKE se puede transformar siempre y cuando el primer carcter en la cadena sea una constante, la siguiente clusula no se puede transformar: NOMBRE like %son

Clusulas OR: las clusulas OR son clusulas que estn en la forma normal disyuntiva, comnmente son SARG combinados con sentencias OR en vez de ser combinados con sentencias AND. El formato de una clusula OR es : SARG or SARG [or ] Donde todas las columnas involucradas en el OR pertenecen a la misma tabla. La sentencia IN tambin se trata como una clusula OR: Columna in (constante1, constante2, ...) ----quedar como :

Columna = constante1 or Columna = constante2 or ... Existen 2 formas de tratar las clusulas OR por parte de ASE. La primera y ms sencilla es un table scan, el cual lee cada fila de la tabla y aplica todos los criterios de bsqueda en cada fila. La segunda tcnica ASE le llama OR Strategy que es la aplicacin del algoritmo estudiado de seleccin disyuntiva mediante la unin de identificadores. (Algoritmo A11 seccin 5.3.2). Clusulas de JOIN: una clusula de join es una una clusula de la forma:

132

TABLA1.COLUMNA operador TABLE2.COLUMNA Comnmente 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 ms 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 relacin interna, el optimizador detiene la bsqueda de valores coincidentes en la relacin 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 Relacin externa, se plantea como ejemplo la siguiente consulta extrada de la Base de datos de ejemplo PUBS2 de ASE:

select pub_name from where publishers pub_id not in ( select pub_id from titles

where type = 'business')

133

ser procesada por el optimizador de ASE de la siguiente forma :

select p.pub_id, tmp_field = t.pub_id into from #worktable 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

Una subconsulta correlacionada contiene una referencia a una tabla externa en la clusula de join en la subconsulta, Por ejemplo, la subconsulta siguiente:

select col_a from where table_1 t1 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 from #worktable 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 porcin 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 evala la efectividad del cach, si este ndice se ve bajo, el optimizador determina que el cach de subconsultas es intil y lo reduce en tamao.

6.3. Seleccin de ndices.

Una vez que la fase de anlisis de la consulta se ha completado el prximo paso es hacer calzar las clusulas 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 estadsticas de distribucin de datos del catlogo para estimar el costo de los caminos de acceso, en el caso de que no existan estadsticas Sybase tambin ocupa los nmeros mgicos, estos nmeros son: Operador = BETWEEN, > y < >, <, >=, <= Porcentaje estimado de filas 10% 25% 33%

En algunas versiones de ASE, la utilizacin de un tipo de datos equivocado llevar al optimizador a no utilizar los ndices definidos, en general, cuando los tipos de datos no son equivalentes ASE tratar de hacer una conversin implcita de tipo de datos, si esta no es posible ASE no utilizar los ndices.

136

Si la consulta contiene una clusula de Join ASE buscar los ndices que calcen con los atributos de Join, para este caso utiliza las estadsticas de densidad de ndices las cuales estiman el nmero de ocurrencias de un valor en un ndice. Si esta estadstica no est disponible el optimizador estima el nmero de filas coincidentes con la frmula:

1 / nmero 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 deberan 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 debera 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 clusula de join. A menos que se utilice una clusula OR, ASE utilizar un solo ndice por tabla para satisfacer la consulta, el ndice elegido debe ser el que requiera el menor nmero 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 recuperacin de los datos. Para cualquier caso el clculo de la estimacin de E/S es el mismo que se explic en la seccin 5.3.1, este es, el nmero de paginas de la tabla para el caso

137

de un table scan, valor que se rescata de la pgina OAM [Rankins96] (object allocation map) de la tabla. En el caso de que exista un ndice en cluster el costo se estimar como el nmero de niveles del ndice ms el nmero de pginas a recorrer; este ltimo valor a su vez se determina como el producto entre el nmero estimado de filas a recuperar y el nmero de filas por pgina. Para un ndice que no sea en cluster, el costo se estima como: Nmero de niveles del ndice + El nmero de pgina del nivel de hojas + El nmero de filas estimadas a rescatar (peor caso) Para ndices nicos y para equi-join el costo de E/S e estima como una pgina de datos ms el nmero de niveles de ndices que se deben recorrer para acceder a la pgina de datos. Adicionalmente ASE utiliza la tcnica 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 definicin del ndice. De esta manera el optimizador no accede a las pginas de datos dado que tiene todos lo necesario en las pginas de ndices.

6.4. Seleccin de los ordenes de Join.

138

El optimizador de consultas evala 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 ms 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 ms optimo para un join involucra elegir los mejores ndices para cada tabla y el orden ms eficiente para procesar las tablas en el join.

6.4.1. Determinacin de los ordenes de Join.

Dado que el optimizador de ASE se basa en costos, el orden de las tablas en la clusula FROM no dicta el orden en el cual las tablas deben ser procesadas. Cuando se procesa un Join, el optimizador evala todas las permutaciones razonables y estima el costo total de E/S en trminos de tiempo de E/S. El plan que resulta producto de la estimacin ms baja de los tiempos de E/S ser el plan elegido. Para minimizar el nmero de permutaciones que deben ser examinadas, el optimizador desintegra el join de ms 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 solucin iterativa, que se repite hasta que se determinen los ordenes de Join para todas las tablas. El propsito de este alcance es limitar el nmero de permutaciones que el optimizador tenga que considerar. El algoritmo usado por ASE para procesar los Joins de ms 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 permutacin de menor costo, la primera tabla de esta permutacin se deja como la tabla ms 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 slo 4 tablas. Estas 4 tablas sirven de entrada para la ultima estimacin de costo de Join. Ejemplo: Supngase 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 tendrn : + 6( ) ) 4& & = 15 grupos * ' T1T2T3T5 T1T2T3T6 T1T2T4T5 T1T2T4T6

T1T2T3T4

140

T1T2T5T6 T2T3T4T5

T1T3T4T5 T2T3T4T6

T1T3T4T6 T2T3T5T6

T1T3T5T6 T2T4T5T6

T1T4T5T6 T3T4T5T6

Para cada grupo de 4 encontrar la permutacin con costo ms bajo y tomar la primera tabla de esa permutacin, extraerla de la lista de tablas y dejarla como la tabla ms externa del Join. Asumiendo que la mejor permutacin es: T3T5T4T2, la tabla T3 ser la tablas ms externa. Las tablas que quedan son reagrupadas en todos los posibles grupos de 4, la cantidad de grupos resultantes es: + 5( ) ) 4& & = 5 grupos * ' T1T2T4T5 T1T2T4T6 T1T2T5T6 T1T4T5T6 T2T4T5T6

Si la permutacin de costo ms bajo es T4T2T5T6; ser entonces la tabla T4 la segunda tabla ms externa en la consulta. De aqu en adelante quedan 4 tablas por lo tanto se encuentra la permutacin con menor costo de estas, supngase que esta permutacin es T5T2T1T6, este orden de Join se agrega a las 2 tablas extradas anteriormente quedando el orden de Join de la consulta como : T3 T4 T5 T2 T1 T6 El nmero de permutaciones examinadas con este algoritmo puede ser sustancialmente menor especialmente cuando el nmero de tablas en la consulta excede las 8 tablas.

141

El beneficio principal de este algoritmo es economizar tiempo de CPU en la identificacin del mejor orden de Join. El nmero resultante de combinaciones + n! ( examinadas con este alcance es la suma de ) ) (n 4)! & & para cada iteracin. * ' Para este ejemplo el nmero de permutaciones consideradas debera 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 nmero de tablas se incrementa el ahorro se hace cada vez ms significativo como se muestra en la siguiente tabla: Nmero de Tablas 6 7 8 9 10 16 720 5040 40320 362880 3628800 20922789888000 N! Mtodo Optimizado 504 1344 3024 6048 11088 148512 30% 73.3% 92.5% 98.3% 99.7% 99.999% Ahorro

6.4.2. Estimacin de los costos.

Para cada permutacin estudiada el optimizador de ASE debe estimar el costo de ese orden de Join particular en trminos de E/S total. Con propsitos de comparacin, ASE estima el total de E/S lgicas por tabla y el nmero de E/S

142

fsicas por tabla, luego las suma y lo transforma en un estimado del tiempo total transcurrido. ASE tasa una lectura lgica en 2 ms. (milisegundos) y una lectura fsica en 18 ms. Por lo tanto la razn entre las lecturas lgicas y las fsicas es de 1 a 9. Estos valores son fsicos 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 pgina), 1.000 pginas. 25.000 filas en titleauthor (50 filas por pgina), 500 pginas. Las estadsticas 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 tamao en el cach para mantener ambas tablas en memoria.

143

Ejemplo 1: tabla titles como tabla externa, estudio sin ndices. Para la tabla externa hay un costo de 1.000 pginas 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 pginas de la tabla interna. El nmero 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 permutacin, el primer scan en la tabla titles realiza 1.000 lecturas lgicas y 1.000 lecturas fsicas. Para la tabla titleauthor, como cabe enteramente en el cach slo se necesitan 500 lecturas fsicas y 15.000 lecturas lgicas 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 informacin estadstica, ASE asume que un 33% de las filas deberan calzar con el argumento de bsqueda. As ASE estima que slo se deberan 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 iteracin para esa fila).

144

Por lo tanto el costo relativo de la consulta es: (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 informacin estadstica que indica que slo 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 bsquedas por rango, ASE slo deber recorrer las tuplas que cumplen con la condicin, estas son 5.000 filas / 50 filas por pgina = 100 pginas. Adems, como hay un ndice nico en cluster en la tabla titles slo una fila debe calzar con cada fila iterada de la tabla titleauthor, osea 5.000 filas. A 15 filas por pgina se tienen 5.000 / 15 = 334 pginas de datos a acceder en titles mientras se procesa la consulta. Cada bsqueda simple todava cuesta 3 accesos a disco ms. Con esta informacin ASE estima que la consulta debera costar: 100 pginas en titleauthor + (5.000 filas en titleauthor * 3 pginas por bsqueda en titles) = 15.500 100 lecturas fsicas en titleauthor: 18 * 100 = 1.800 ms. 100 lecturas lgicas en titleauthor: 2 * 100 = 200 ms. 334 lecturas fsicas en titles: 18 * 334 = 6.012 ms. 15000 lecturas lgicas en titles: 2 * 15.000 = 30.000 ms.

145

Total = 38.012 ms. 38 segundos.

6.4.3. Estrategia de Reformateo.

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 frmula de costo resultante es:

nmero de paginas de la tabla externa + (nmero de filas de la tabla externa * nmero de paginas de la tabla interna) Ocasionalmente puede resultar ms 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 slo recuperar las filas que califican para con la condicin de Join. El costo de aplicar la estrategia de reformateo es el costo de las E/S requeridas para crear la tabla temporal ms el costo de crear el ndice en ella. Sybase calcula esta frmula como sigue:

P2 + log2 P2 * P2; donde P2 es el nmero de pginas 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 debera ser el costo de reformateo ms el nmero de pginas de la tabla externa (P1) ms el nmero de filas de la tabla externa (R1)

146

multiplicado por el nmero de scans en la tabla externa. La ecuacin completa que estima el costo de E/S para una consulta utilizando la estrategia de reformateo sera: (P2 + log2 P2 * P2) + P1 + R1 Como ejemplo, supngase que se tiene una tabla externa de 300 filas y 200 pginas y una tabla interna que consiste en 100 pginas, 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 sera 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 vlido pensar que la estrategia de reformateo es ms efectiva que un table scan, sin embargo, no es menos cierto que una buena definicin de ndices es mucho ms 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 clusula de join donde se desea que se incluyan todas las filas.

147

Tal y como se ha explicado en la seccin 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 clusula 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 clusulas ORDER BY, GROUP BY y DISTINCT comnmente determinar la creacin 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 clusula 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 clusula DISTINCT, y como esta clusula 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 creacin de la tabla temporal dado que el ndice nico garantiza la que cada fila es distinta. Para el caso de la clusula ORDER BY, la utilizacin de una tabla depender de los ndices sobre la tabla.

148

Considrese la situacin en la cual existe un ndice en cluster sobre una tabla, la clusula ORDER BY especifica como mnimo 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 exploracin del ndice en cluster o por medio de un table scan. Sin embargo, si existe un ndice que no sea en cluster y que adems fue utilizado para resolver la consulta, se requiere una tabla temporal que ordene los datos extrados por medio del ndice no en cluster. No se necesitar la creacin de una tabla temporal si la clusula 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 adems sea este el ndice que se utiliza para satisfacer un SARG. Ejemplo: select * from table where text like texto% order by text

6.6. Seleccin del plan.

La seleccin del plan de ejecucin de una consulta estar entonces determinada por la solucin que tenga el menor costo estimado para la consulta referenciada, dado que esta eleccin se estima, hay veces en que el usuario puede estar un tanto escptico acerca de si es el plan elegido el ms optimo para la consulta. Se hace necesaria entonces, informacin tcnica especfica acerca del plan de ejecucin 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)

149

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) 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 ejecucin elegido para resolver la consulta. El anlisis de la informacin que entrega esta opcin escapa al alcance de este trabajo, para un estudio ms 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 ejecucin, es posible que el usuario determine que el optimizador no est eligiendo el plan ms ptimo. A continuacin se detallan los problemas ms comunes que llevan al optimizador a elegir un plan de ejecucin pobre en trminos de eficacia. Estadsticas actualizadas. Uno de los problemas ms comunes encontrados en ambientes de produccin es que, ya sea, las estadsticas no estn disponibles para los ndices, o bien, estn desactualizadas. Se recomienda entonces actualizar las estadsticas y re-ejecutar la consulta.

150

Clusulas SARG. Revisar la existencia de clusulas SARG dentro del WHERE. Fijar atencin en operadores de desigualdad, operaciones sobre columnas y expresiones constantes que no puedan ser evaluadas en el momento de la compilacin de la consulta. ndices que cubren consultas. Si lo que se espera es una cobertura de ndice, chequear que todos los campos del ndice estn presentes en la consulta. La falta de uno de ellos lleva a una recuperacin 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 indexacin de tablas o rescribir la consulta de manera que utilice los ndices disponibles.

6.6.2. Mejoras propias del optimizador de ASE.

En cada versin que se lanza al mercado, los motores de base de datos tradicionales tienden a mejorar las caractersticas de optimizacin de consultas, en el caso de ASE, estas mejoras tienen que ver con el manejo de memoria y con las estadsticas del catlogo. Ya en la versin 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 tamao (el tamao de un extent) y no en bloques de 2 Kb. (el tamao de la pgina 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 nmero de paginas secuenciales de datos minimizando as el nmero de accesos a disco. del tipo: Las consultas que se pueden beneficiar con este tipo de estrategia son las consultas

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 caracterstica de esta versin es la habilidad que tiene el optimizador de usar la llamada estrategia de fetch-and-discard para las pginas que se leen de disco. Un cach de ASE se compone de dos cadenas, el MRU(Most Recently Used - ms recientemente usado) y LRU (Least Recently Used - menos recientemente usado), en versiones anteriores a la versin 11 de ASE la estrategia del uso del cach era del tipo FIFO (first in- first out), lo que significaba que toda pgina cargada en el cach deba recorrerlo completamente efectuando el mismo nmero de saltos antes de ser reemplazada. Esto muchas veces daaba el rendimiento, sobre todo cuando se deba leer una tabla grande y las paginas (que seguramente slo 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 pgina al final del LRU, de manera que no empuje fuera del cach a las paginas que deberan permanecer en l. La versin 12 de ASE adems 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 (slo 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 aos, el optimizador de ASE ha sufrido continuas mejoras (al igual que la mayora de los optimizadores para motores comerciales), en esta seccin se ha verificado la correspondencia entre la teora expuesta a lo largo del captulo Captulo 5 y la implementacin comercial de uno de los motores de base de datos ms conocidos en la actualidad. Se demuestra adems que en la mayora de las oportunidades el optimizador toma la decisin correcta, sin embargo, hay ocasiones en las que el optimizador puede tomar una mala decisin debido a una imprecisa o incompleta informacin en las estadsticas del catlogo como tambin en algunas consideraciones de cmo se escribe la consulta.

153

Ahora bien, cuando existen sospechas acerca de la eleccin del plan, ASE (como los dems motores de base de datos comerciales) disponen de herramientas que proporcionan informacin acerca de las decisiones tomadas para la eleccin del plan ms ptimo.

154

Resumen y Conclusiones.
Resumen

El procesamiento de consultas tiene varias etapas a seguir para resolver una consulta SQL, las caractersticas del modelo relacional permiten que cada motor de base de datos elija su propia representacin que, comnmente, resulta ser el lgebra relacional. La optimizacin de consultas es, entonces, una de estas etapas (que por cierto otros modelos de bases de datos no poseen). Existen distintos mtodos para optimizar consultas relacionales, sin embargo el enfoque de optimizacin basada en costos combinado con heursticas que permitan reducir el espacio de bsqueda de la solucin es el mtodo mayormente utilizado por los motores de base de datos relaciones de la actualidad, en todo caso, independiente del mtodo elegido para optimizar la consulta, la salida de este proceso debe ser un plan de ejecucin, el cual comnmente es representado en su forma de rbol relacional. La optimizacin de consultas en base a costos supone la utilizacin de una medida de costo que sea comn a lo largo del proceso, esta medida debe representar el criterio de minimizacin en la utilizacin de recursos del sistema, la medida estndar 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 informacin del catalogo inherente a la consulta. Sin embargo el optimizador no siempre escoge el plan ms optimo, ya que una bsqueda exhaustiva de la estrategia ptima puede consumir demasiado tiempo de proceso. Se dice entonces que el optimizador escoge una estrategia razonablemente eficiente.

155

El catlogo de la base de datos guarda informacin estadstica de cada una de las relaciones como tambin de los ndices de cada una de la relaciones, estas estadsticas permiten estimar los tamaos de los resultados de varias operaciones. Esta informacin 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 eleccin del plan de ejecucin de la consulta. Una mala administracin de la informacin que contiene el catlogo conducir inevitablemente a una desafortunada eleccin del plan de ejecucin. Para ayudar a solucionar este problema existen varios enfoques que conjunta o separadamente pueden asistir al optimizador en su eleccin. Uno de estos consiste en la actualizacin automtica de las estadsticas que algunos motores de base de datos incluyen como opcin. Otro enfoque es la opcin de guardar en el catlogo planes de ejecucin precalculados que adems le ahorran al motor el tiempo de clculo del plan. Obviamente estos planes son vulnerables a ser invalidados si se producen cambios lgicos en el esquema de la base de datos o si hay un cambio en la distribucin de los datos a ser recuperados. Uno de los primeros optimizadores de consultas y el que se conoce como base para la mayora de los optimizadores tradicionales es el optimizador de System R. System R es un optimizador basado en costos pero que utiliza heursticas para desplazar selecciones y proyecciones hacia abajo en el rbol de la consulta, la resolucin 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 estimacin de los caminos de acceso para ndices secundarios supone que se necesita un acceso a disco por cada tupla de la relacin lo que supone el peor caso. Es probable que la estimacin sea precisa

156

con tamaos de buffer pequeos, sin embargo con un buffer de mayor tamao la pgina que contiene la tupla podria estar todava 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 estadsticas del catlogo, la inclusin de la utilizacin de CPU en las frmulas del clculo de costos y los mtodos para determinar ordenes de join. El concepto de factor de seleccin 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 teora expuesta en el captulo Captulo 5 valida las investigaciones hechas a partir de system R, planteando el proceso de optimizacin de consultas como sigue. El primer paso de un optimizador de consultas es encontrar una expresin del lgebra de relaciones que sea equivalente a la expresin dada y cuyo costo estimado de ejecucin sea menor. En el apartado 5.4.4.2 se presenta una lista de equivalencia de expresiones que se pueden utilizar para transformar una expresin en otra equivalente, se usan estas reglas para generar sistemticamente todas las expresiones equivalentes de la consulta y luego elegir la ms barata. Dado que generalmente esta evaluacin se basa en costos, se presentan en el apartado 5.3.1, 5.3.2 y 5.3.3 distintos algoritmos para la seleccin de caminos de acceso a relaciones simples, a joins y consultas complejas, estas medidas estn determinadas por la informacin que se tiene en el catlogo de la base de datos.

157

Para el caso de consultas a relaciones simples se utilizar entonces la evaluacin de cada una de las expresiones equivalentes con su evaluacin de costos para elegir el plan de acceso a la consulta ms barato. Para el caso de Joins es necesario incluir el clculo de ordenes de join, que considerar ordenamientos y encauzamientos en la medida de los posible. Dado que el clculo de estos ordenamientos puede ser costoso mientras ms relaciones estn involucradas en un Join, se presenta en el apartado 5.5 distintas tcnicas para el clculo de estos ordenamientos, estas tcnicas comnmente iterativas introducen distintas heursticas para reducir el espacio de bsqueda de soluciones buscando mejorarlo en cada iteracin. Bajo este alero de teora, se presenta en el captulo Captulo 6 un ejemplo prctico de cmo 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 eleccin de caminos de accesos y tcnicas de recuperacin de datos al motor de procesamiento de consultas. Al independizar de esta tarea al usuario final, se hacen necesarios un conjunto de tcnicas que permitan asegurar al motor que los datos sern rescatados de la manera ms optima posible. Este componente es el optimizador de consultas, el cual se encarga de elegir el plan de evaluacin ms apropiado dada la informacin con la que cuenta de el catalogo y una serie de tcnicas y algoritmos predefinidos para estos efectos.

158

Por muy importante que sea el la etapa de optimizacin en una consulta (y de hecho lo es), existen casos en que la bsqueda del plan ms optimo de ejecucin de una consulta puede tomar mucho tiempo, para solucionar este problema, los optimizadores se apoyan en heursticas, en tcnicas de bsquedas aleatorias y en reglas predefinidas, con el fin de que, no abarcando todo el espacio de bsqueda, se d con una solucin 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 mayora de los optimizadores han elegido el enfoque de optimizacin basada en costos como predeterminada. La utilizacin de el enfoque de optimizacin basada en costos se fundamenta en la necesidad de contar con una medida que sea representativa del criterio de minimizacin en la utilizacin de recursos del sistema. Esta medida puede no ser la misma, dependiendo del tipo de SGBD y de los avances tecnolgicos 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 utilizacin 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 tecnolgicos en este campo. Una de las ventajas que se logra comprendiendo el proceso de optimizacin de consultas es la de entender que es lo que hace realmente un optimizador y con esto evitar la construccin de malas consultas. Sin Embargo, nada de esto cobra mucha importancia si el diseo de la base de datos es pobre, estudios indican que el 65% de los problemas de tunning en bases de datos en ambientes de produccin es debido a un pobre diseo 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.

159

Algunas consideraciones que ayudan al buen diseo de una base de datos son:

Seguir los estndares de normalizacin de base de datos. Tratar de maximizar el uso de ndices en cluster Tratar de reducir el nmero de ndices secundarios (no en cluster) Si existen consultas que involucren ms 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).

160

Bibliografa.
[Bjeletich99] S. Bjeletich, G. Mable, Microsoft SQL Server 7 Al descubierto, Prentice Hall, Madrid 1999, Traduccin de Microsoft SQL Server 7.0 Unleashed ,SAMS 1999. D. Comer, "The Ubiquitous B-tree", ACM Computer Surveys, Volumen 11, Nmero 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, Nmero 1, Marzo 1996, pp. 121-123. K. Kline, L. Gould, A. Zanevsky, Transact-SQL Programming, OReilly, USA 1999. R. L. Kruse, Estructura de datos y diseo de programas, Prentice Hall, Mexico 1988, traduccin 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.

[Comer79]

[Codd71]

[Date98]

[Ioannidis96]

[Kline99]

[Kruse84]

[Lorie78]

161

[McJones97]

Paul McJones, SRC Technical Note 1997 018 The 1995 SQL Reunin: People, Projects, and Politics, Agosto 1997. R. Rankins, J. R. Garbus, D. Salomon, B. W. McEwan, Sybase SQLServer 11 UNLEASHED, SAMS 1996. 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.

[Rankins96]

[Selinger79]

[Silberschatz97] A. Silberschatz, H. F. Korth, S. Sudarshan, Fundamentos de Bases de datos Tercera Edicin, McGraw Hill, Espaa 1998, Traduccin de Database System Concepts, McGraw Hill, USA 1997. [Steinbrunn93] 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 administracin 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.

[Swami88]

[Sybase01]

[Wong76]

162

Apndices. A. Sintaxis de SQL

A.1. Definiciones de datos en SQL Las Sentencias del lenguaje de definicin 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 atencin a los aspectos que son de directo inters para el usuario y no los aspectos que tienen que ver con el nivel interno del sistema (tales detalles son de importancia para el DBA15). Una tabla base se define en los sistemas relacionales como una fila de encabezados de columnas ms cero o ms 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 ms 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 estn ordenadas de izquierda a derecha pero este orden no es parte del modelo relacional. Las Tablas son autnomas e independientes a diferencia de las vistas las cuales no existen en su propio espacio pero si se derivan de una o ms tablas.

A.1.1. Comando CREATE TABLE

El comando CREATE TABLE se usa para especificar una nueva relacin 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 constraints16 sobre el atributo. La sintaxis del comando es :

CREATE TABLE nombre_de_tabla (definicion_de_columna [,definicion_de_columna ] ...)

donde la definicin de columna es de la forma :

nombre_de_columna tipo_de_dato [ NOT NULL ]

Ejemplo :
create table DUENOS ( RUT NOMBRE TELEFONO DIRECCION ); INTEGER CHAR(30) CHAR(10) CHAR(50) not null, not null, ,

Una Constraint es una regla que se debe aplicar a un atributo de una tabla. Las constraints proveen un mecanismo rpido y eficiente para asegurar la integridad de la base de datos sin importar los cambios que requiera el usuario.

16

164

A.1.1.1. Definicin de NOT NULL (no nulo)

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 relacin.
A.1.1.2. Tipos de datos SQL

Los siguientes tipos de datos son los comnmente soportados por el estndar SQL.
Datos Numricos INTEGER SMALLINT DECIMAL(p,q) FLOAT(p) Datos String CHAR(n) VARCHAR(n) GRAPHIC(n) Entero con signo de 31 bits Entero con signo de 15 bits Nmero con signo de p dgitos, q decimales Nmero de punto flotante, p bits de precisin Cadena de texto de largo fijo de n bytes Cadena de texto de largo variante, hasta los n bytes Cadena de texto de largo fijo, n*2 bytes

VARGRAPHIC(n Cadena de texto de largo variante, hasta los n*2 bytes ) Datos de Fecha y Hora DATE TIME TIMESTAMP Fecha (aaaammmdd) Hora (hhmmss) Combinacin de fecha y hora

Tabla A-1 - Tipos de datos de SQL

A.1.2. Comando DROP TABLE

El comando DROP TABLE se usa para eliminar una relacin y su definicin de atributos como tambin borra del catlogo la tupla relacionada a esta. La sintaxis de la Instruccin es :

165

DROP TABLE

nombre_de_tabla;

Ejemplo :
drop table DUENOS;

A.1.3. Comando ALTER TABLE

El comando ALTER TABLE es usado para agregar un atributo a una de las tablas de la base de datos. Adems 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 relacin inmediatamente despus de ejecutada la instruccin, 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 ms. 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 especificacin opcional CLUSTER17 en un comando CREATE INDEX indica si este ndice estar el cluster. Una tabla dada puede tener un slo ndice en cluster en un momento dado.

ORDER:

Toda especificacin 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 organizarn los datos, el valor por defecto para ORDER es ASC.

UNIQUE:

La opcin UNIQUE en una sentencia SQL CREATE INDEX especifica que no se permitirn dos registros en la tabla a indexar que tengan el mismo valor para el campo (o la combinacin 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 razn para borrar ndices es que es costoso mantenerlos cada vez que la relacin 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 tambin la constraint asociada. La sintaxis de la clusula DROP INDEX es:
DROP INDEX nombre_de_indice;

Ejemplo:
drop index DUENO_PK;

La tcnica de clustering involucra el tratar de almacenar en disco lo ms cerca posible los registros que estn relacionados lgicamente, de manera de poder mejorar el rendimiento.

17

167

A.2. Manipulacin de datos en SQL SQL provee cuatro sentencias de manipulacin de datos (DML). Esas son:

SELECT UPDATE DELETE INSERT

A.2.1. Comando SELECT

El comando DML SELECT es la sentencia SQL bsica para la recuperacin de informacin desde una base de datos. (ntese que el comando SELECT de SQL no guarda relacin con el operador de seleccin del lgebra relacional). La sintaxis del comando es la siguiente:

SELECT

[DISTINCT] FROM [ WHERE [ GROUP BY [ HAVING [ ORDER BY

tem(s) tabla(s) condicin ] campo(s) ] condicin ] 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 funcin 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 clusula junto con la funcin especial COUNT(*). La palabra Clave UNIQUE es un sinnimo para DISTINCT y las dos se pueden usar sin distincin. Ejemplo:
select COUNT(DISCTINCT MARCA) FROM MOVIL;
Retorna el nmero de Marcas de autos que tiene la empresa

A.2.1.1. Funciones Agregadas de la clusula 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 funcin COUNT se usa para obtener el nmero de valores en la columna. Opera sobre una coleccin 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 vaco la funcin COUNT retorna el valor cero. Un ejemplo de COUNT es:

SELECT

COUNT (DISTINCT MARCA) FROM MOVIL;

SUM : La funcin SUM se usa para sumar los valores de una columna. La funcin opera sobre una coleccin de valores en una columna de la tabla. Los valores deben ser numricos. Si el resultado del argumento es el conjunto vaco, SUM retorna NULL. Un ejemplo de SUM es:

SELECT

SUM (HORA_HASTA - HORA_DESDE) FROM VIAJE WHERE PATENTE_MOVIL = 'HL-8483';

AVG : La Funcin AVG se usa para promediar todos los valores seleccionados en una columna, opera sobre una coleccin de valores (numricos) en una sola columna de la tabla. La funcin AVG puede ir precedida por la palabra clave DISTINCT lo cual promediar slo los valores nicos. Si el resultado del argumento es el conjunto vaco, AVG retorna NULL.

Ejemplo :
SELECT AVG (HORA_HASTA - HORA_DESDE) FROM VIAJE WHERE PATENTE_MOVIL = 'HL-8483';
MIN (MAX): La funcin MIN (MAX) se usa para obtener el menor (mayor) valor en una columna. Ambas funciones operan sobre una coleccin de valores en una columna. Los valores no necesitan ser numricos. Si el resultado del argumento es el conjunto vaco, ambas retornan NULL.

Ejemplo:

SELECT

MAX (HORA_HASTA - HORA_DESDE)

170

FROM VIAJE;

SELECT

MIN (HORA_HASTA - HORA_DESDE) FROM VIAJE;

COUNT(*):

La funcin COUNT(*) se usa para contar la cardinalidad de una tabla sin eliminacin de valores duplicados. En las funciones anteriores, cualquier valor nulo en el argumento se elimina antes que la funcin se aplique (indiferentemente de si se usa o no la clusula DISTINCT) . COUNT(*) retorna cero si el resultado del argumento es el conjunto vaco.

Ejemplo:

SELECT

COUNT(*) FROM VIAJES WHERE PATENTE_MOVIL = 'HL-8483';

A.2.1.2. Clusula GROUP BY

La clusula GROUP BY en una sentencia SELECT reordena lgicamente la tabla representada por la clusula FROM en grupos, tal que dentro de cada grupo todas las filas tienen el mismo valor para el campo dado en la clusula GROUP BY (esto es conceptual; la tablas no se reordena fsicamente en la base de datos). Cada expresin en la clusula SELECT debe ser reducible a valor simple dentro de un grupo, es decir, que puede ser ya sea el mismo campo evaluado en la Clusula GROUP BY (o talvez una expresin que lo contenga), un literal, o una funcin 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 tambin la clusula ORDER BY. Ejemplo:

SELECT

PATENTE_MOVIL, SUM(HORA_HASTA - HORA_DESDE) FROM VIAJE GROUP BY PATENTE_MOVIL;

A.2.1.3. Clusula HAVING

La clusula HAVING en una sentencia SELECT se usa para eliminar grupos, (tal como se usa WHERE para eliminar filas). Si se especifica, debe existir una clusula GROUP BY tambin. La Expresin en la clusula 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. Clusula ORDER BY

Esta clusula se utiliza en un comando SELECT para producir como resultado una relacin en un orden especfico. En general, la relacin resultado no

172

se garantiza que est en un orden particular. De ah que la clusula ORDER BY se utilice para ordenar el resultado en alguna secuencia particular antes de que los datos sean desplegados. AL igual que la clusula ORDER del comando CREATE INDEX el argumento puede ser ya sea ASC o DESC. ASC es el valor por defecto. Tambin es posible identificar columnas por su nmero de columna en lugar de su nombre, esto es, por la posicin ordinal (de izquierda a derecha) de la columna en cuestin dentro de la tabla resultado. Esta caracterstica 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. Clusula EXIST

La clusula EXISTS en un comando SELECT representa el calificador de existencia. La expresin se avaluara como verdadera, si y slo si, el resultado de evaluar la sentencia SELECT FROM no es vaca, esto es, si y slo si, existe un registro en la tabla dada en FROM desde el nivel ms externo de la consulta. La negacin (NOT EXISTS) es especialmente importante para una cierta clase de consultas bastante ms complejas que el comn. Ejemplo :

173

SELECT

PATENTE FROM MOVIL WHERE EXISTS ( SELECT * FROM VIAJE WHERE MOVIL.PATENTE = VIAJE.PATENTE_MOVIL);

A.2.1.6. Subconsultas.

Una Subconsulta en una clusula SELECT es una expresin de la forma SELECT - FROM - WHERE - GROUP BY - HAVING que se anida dentro de otra expresin. Las Subconsultas se usan comnmente para representar un conjunto de valores que se buscan por medio de una condicin IN condicin. El sistema evala toda la consulta evaluando la Subconsultas anidadas. Ejemplos : * Retorna todos los mviles que tienen ms 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;

174

A.2.2. Comando UPDATE

El comando DML UPDATE se usa para modificar valores de atributos de una o ms tuplas seleccionadas. Al igual que con el comando SELECT la clusula WHERE es la que selecciona la o las tuplas que sern modificadas desde una relacin simple. La clusula adicional SET especifica los atributos que sern 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 condicin sern modificados de acuerdo a sus asignaciones (campo = expresion_escalar) en la clusula SET. El siguiente ejemplo demuestra el uso del comando UPDATE en un Registro.

UPDATE

CHOFER SET DIRECCION = Otra Direccin, TELEFONO = 5555555 WHERE RUT = 12657378

El siguiente ejemplo demuestra el uso del comando UPDATE para un conjunto de registros.

175

UPDATE

CHOFER SET WHERE VIGENCIA = N SYSDATE > FECHA_LICENCIA_HASTA;

A.2.3. Comando DELETE

El comando DML DELETE borra tuplas desde una relacin. Al igual que el comando UPDATE puede incluir la clusula WHERE para seleccionar las tuplas a ser eliminadas. Las tuplas son borradas slo desde una tabla a la vez. Dependiendo del nmero de tuplas seleccionadas por la condicin en la clusula WHERE ser la cantidad (cero, una o ms) de tuplas que sern eliminadas con un slo comando DELETE. Si se omite la clusula WHERE se asume que todas las tuplas de la relacin deben ser borradas, sin embargo la tabla permanece en la base de datos como una tabla vaca. (el comando DROP TABLE se usa para eliminar completamente la tabla, an si esta no est vaca). La sintaxis del comando DELETE es la siguiente :

DELETE FROM [ WHERE table condition ] ;

El siguiente ejemplo borra una sola tupla en la tabla base:

DELETE FROM WHERE MOVIL PATENTE = 'HL-8205' ;

176

El siguiente ejemplo borra todas las tuplas que satisfagan la condicin

DELETE FROM MOVIL WHERE ANO <= 1960;

A.2.4. Comando INSERT

El comando DML INSERT en su forma ms simple se usa para agregar una sola tupla a una relacin. Se debe especificar el nombre de la relacin y una lista de los valores que se agregarn para la tupla. La lista de valores se debe proporcionar en el mismo orden que sus respectivos atributos. Es posible tambin insertar mltiples registros de una sola vez por medio de una subconsulta. La sintaxis es la siguiente:

INSERT

INTO VALUES

TABLE

[ ( campo [, campo ] ... ) ] ;

( literal [, literal ] ... )

INSERT

INTO

TABLE

[ ( campo [, campo ] ... ) ]

subconsulta;

En el primer formato se inserta una fila en la tabla especificada dados los valores para los campos respectivos. En el segundo formato, la subconsulta ser evaluada y se insertar en la tabla una copia de su resultado. Omitir la lista de campos es equivalente a especificar una lista con todos los campos de la tabla (en orden de creacin, de izquierda a derecha).

177

El siguiente es un ejemplo de la insercin de un slo registro.

INSERT INTO DUENO ( RUT, NOMBRE, VIGENCIA ) VALUES ( 12657378, MARIO CISTERNA, S);

El siguiente ejemplo muestra la insercin por medio de una Subconsultas.

INSERT INTO CHOFER (RUT, NOMBRE, TELEFONO, DIRECCION, VIGENCIA) SELECT RUT, NOMBRE, TELEFONO, DIRECCION, VIGENCIA FROM DUENO WHERE VIGENCIA = S

178

B. Indices B+

Los ndices B+ son ndices multinivel, que contienen n punteros P1, P2, Pn y que pueden contener hasta n-1 claves de bsqueda K1, K2, Kn-1. Los valores de las claves de bsqueda 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 cajn de punteros cada uno de los cuales apuntan a registros con clave Ki que se utiliza slo si la clave de bsqueda no forma una clave primaria y el archivo no est ordenado segn la clave de bsqueda. 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 bsqueda de Li es menor que cada valor de Lj. El puntero Pn apunta al siguiente nodo hoja en el orden de la clave de bsqueda, eso permite un mejor desempeo en bsquedas 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 nmero 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 subrbol que contiene los valores de clave de bsqueda 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

179

que todos los nodos tengan %n/2# punteros se impone a todos los nodos internos menos a la raz. Otro requisito de los rboles B+ es que estn equilibrados. Es decir, la longitud de cada camino desde la raz 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 raz hasta algn nodo hoja. Si hay K valores de la clave de bsqueda en e archivo, este camino no ser ms largo que %log[n/2](K)# En la prctica slo se accede a algunos nodos, Generalmente un nodo se construye para tener el mismo tamao que un bloque de disco, el cual ocupa normalmente 4Kb. Con una clave de bsqueda del tamao de 12 bytes y un tamao de puntero a disco de 8 bytes, n est alrededor de 200. Incluso con una estimacin ms conservadora de 32 bytes para el tamao de la clave de bsqueda, n est prximo a 100. Con n = 100, si se tiene 1.000.000 de la clave de bsqueda en la tabla, una bsqueda 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 bsqueda. ndices asociativos. En una organizacin de archivos por asociacin se obtiene la direccin del bloque de disco mediante el clculo de una funcin de asociacin sobre el valor de la clave del registro. Se utiliza el trmino cajn (bucket) para indicar una unidad de almacenamiento que puede guardar uno o ms registros. Formalmente, sea K el conjunto de todos los valores de claves de bsqueda y sea B el conjunto de todas las direcciones de cajn, una funcin de asociacin h es una funcin de K a B. Para realizar una bsqueda con valor Ki en la clave de bsqueda simplemente se calcula h(Ki), y luego se busca en el cajn al que apunta esa direccin, como existe la posibilidad de que dos claves de bsqueda tengan el mismo valor de

180

asociacin, se debe buscar luego en el cajn las tuplas que coincidan con los valores de bsqueda de la clave. La peor funcin de asociacin posible asigna todos los valores de la clave de bsqueda al mismo cajn, una funcin ideal es aquella que distribuye las claves almacenadas uniformemente a traves de los cajones de manera que cada uno de estos tenga el mismo nmero de registros. Un ndice asociativo (hash index) organiza las claves de bsqueda 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 slo estructuras de ndices secundarios. Para ms referencias se recomienda consultar [Silberschatz97] captulo 11 (Indexacin y Asociacin) y [Comer79].

181

C. Mtodos de almacenamiento de Datos.

En la mayor parte de los sistemas informticos 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 adquisicin del medio y por la fiabilidad del medio. La clasificacin ms general y la que se presentar a continuacin es una mezcla entre las medidas de velocidad y la fiabilidad del medio. Almacenamiento Primario.

Cach: La forma de almacenamiento ms rpida y ms 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 elctricos. 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 magnticos para guardar pequeos volmenes de datos.

Almacenamiento secundario (en conexin)

182

Discos magnticos: Principal medio de almacenamiento a largo plazo que resiste los fallos de energa. Generalmente se guarda toda la base de datos en discos magnticos, 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 conexin)

Almacenamiento ptico: CDROM (Compact Disc Read Only Memory) y WORM (Write Once Read Only memory), permiten la grabacin una sola vez pero no el borrado o sobre-escritura.

Almacenamiento en Cinta: Almacenamiento secuencial comnmente utilizado para respaldos de la informacin puesto que es ms lento tanto en lecturas como escrituras.

C.1. Discos Magnticos.

Los discos magnticos proporcionan la parte principal del almacenamiento secundario de los SGBD. La capacidad de almacenamiento de un slo disco vara actualmente desde los 10 Mb hasta los 100 Gb. Una Base de datos comercial grande tpicamente puede necesitar decenas o centenas de discos. Fsicamente, un disco esta compuesto por platos, cada plato es de metal o vidrio cubierto por un material magntico, giran a 60, 90 o 120 Revoluciones por segundo. La superficie se divide lgicamente en pistas y las pistas en sectores.

183

Cada cara del plato tiene una cabeza de lectura escritura, cada una de estas cabezas estn 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 informtico 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 adems una unidad de comprobacin 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 comprobacin 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 informtico o a un controlador por medio de una conexin de alta velocidad, suele utilizarse la Interfaz de conexin para sistemas informticos pequeos (Small Computer-System Interconnect Interface, escasi) sin embargo los sistemas de alto rendimiento suelen disponer de un bus ms rpido 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 bsqueda. Tiempo que le toma al disco desplazar el brazo para que se ubique sobre la pista correcta.

184

Tiempo medio de bsqueda. Media estadstica de los tiempos de bsqueda medido en una sucesin de bsquedas 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 bsqueda + 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)