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

1. Capnulo Procesamiento de consultas Objetivos del captulo: En este captulo aprender: Los objetivos del procesamiento de consultas y optimizacin. Las diferencias entre la optimizacin de consultas esttica y dinmica. Cmo se descompone y se analiza semnticamente una consulta. Cmo crear un rbol de lgebra relacional para representar una consulta. Las reglas de equivalencia para las operaciones de lgebra relacional. Cmo aplicar reglas de transformacin heurstica para mejorar la eficiencia de una consulta. Los tipos de estadsticas de bases de datos requeridas para estimar el coste de las operaciones. Las diferentes estrategias para implementar las operaciones de lgebra relacional. Cmo evaluar el coste y el tamao de las operaciones de lgebra relaciona!. Cmo puede utilizarse el pipelining para mejorar la eficiencia de las consultas. La diferencia entre materializacin y pipelining. Las ventajas de los rboles de profundidad izquierda. Las tcnicas para determinar una estrategia de ejecucin ptima. Cmo gestiona Oracle la optimizacin de consultas. Cuando se lanz por primera vez comercialmente el modelo relacional, una de las principales crticas que se hacan era el pobre rendimiento de las consultas. Desde entonces, se ha dedicado una gran cantidad de esfuerzos de investigacin para desarrollar algoritmos altamente eficientes para el procesamiento de consultas. Hay muchas formas en las que se puede ejecutar una consulta compleja y uno de los objetivos de procesamiento de consultas es determinar cul de esas formas es la menos costosa. En los sistemas de bases de datos en red y jerrquicos de primera generacin, el lenguaje de consulta pro- cedimental de bajo nivel est generalmente incrustado en un lenguaje de programacin de alto nivel tal como COBOL y es responsabilidad del programador seleccionar la estrategia de ejecucin ms apropiada. Por con- traste, con lenguajes declarativos del tipo de SQL, el usuario especifica qu datos se requieren en lugar de cmo hay que extraerlos. Esto libera al usuario de la responsabilidad de determinar, e incluso de conocer, qu es una buena estrategia de ejecucin y hace que el lenguaje sea ms universalmente utilizable. Adicionalmente, asignar al SGBD la responsabilidad de seleccionar la mejor estrategia evita que los usuarios seleccionen estrategias que ya se sabe que son ineficientes y proporciona al SGBD un mayor control sobre las prestaciones del sistema. Existen dos tcnicas principales de optimizacin de consultas, aunque en la prctica se suelen combinar ambas estrategias. La primera tcnica utiliza reglas heursticas que ordenan las operaciones de una consulta. La otra tcnica compara diferentes estrategias basndose en su coste relativo y selecciona aquella que mini-

2. 576 Sistemas de bases de datos mice el uso de recursos. Puesto que el acceso a disco resulta lento comparado con el acceso a memoria, los accesos a disco tienden a representar el coste ms importante del procesamiento de consultas en un SGBD centralizado, y es en este aspecto en el que nos vamos a concentrar exclusivamente en este captulo a la hora de proporcionar estimaciones de coste. Estructura del captulo En la Seccin 21.1 se proporciona una panormica del procesamiento de consultas y se examinan las fases principales de esta actividad. En la Seccin 21.2 se examina la primera fase del procesamiento de consultas, que es la descomposicin de la consulta, que transforma una consulta de alto nivel en una consulta de lgebra relacional y comprueba que sta sea sintctica y semnticamente correcta. En la Seccin 21.3 exami- namos la tcnica heurstica de optimizacin de consultas, que ordena las operaciones de una consulta utilizando reglas de transformacin que se sabe generan buenas estrategias de ejecucin. En la Seccin 21.4 analizaremos la tcnica de estimacin de costes para la optimizacin de consultas, que se basa en comparar diferentes estrategias basndose en sus costes relativos y seleccionar aquella que minimice el uso de recursos. En la Seccin 21.5 hablaremos del pipelining, que es una tcnica que puede utilizarse para mejorar todava ms el procesamiento de las consultas. El pipelining (o procesamiento en cadena) permite que se realicen diversas operaciones de forma paralela, en lugar de requerir que cada operacin se complete antes de que la siguiente pueda comenzar. Tambin explicaremos cmo puede un procesador de consultas tpico seleccionar una estrategia de ejecucin ptima. En la seccin final, examinaremos brevemente cmo lleva a cabo Oracle la optimizacin de las consultas. En este captulo nos vamos a concentrar en las tcnicas de procesamiento y optimizacin de consultas en un SGBD relacional centralizado, ya que ste es el rea que ha atrado la mayor parte de los esfuerzos de investigacin y es el modelo en el que nos centramos a lo largo de todo el libro. Sin embargo, algunas de las tcnicas tienen aplicacin general en otros tipos de sistemas que dispongan de una interfaz de alto nivel. Posteriormente, en la Seccin 23.7, examinaremos brevemente el procesamiento de consultas en un SGBD distribuido. En la Seccin 28.5 veremos que algunas de las tcnicas examinadas en este captulo pueden requerir un anlisis adicional para un SGBD objeto-relacional, que soporta consultas que contienen tipos definidos por el usuario y funciones definidas por el usuario. El lector debe estar familiarizado con los conceptos tratados en la Seccin 4.1 sobre el lgebra relacional y con los del Apndice e referidos a los tipos de organizacin de archivos. Los ejemplos de este captulo estn extrados del caso de estudio de DreamHome descrito en la Seccin 10.4 Y en el Apndice A. 21.1 Panormica del procesamiento de consultas Procesamiento de consultas Las actividades implicadas en el anlisis sintctico, la validacin, la optimizacin y la ejecucin de una consulta. Los objetivos del procesamiento de consultas son transformar una consulta escrita en un lenguaje de alto nivel, normalmente SQL, en una estrategia de ejecucin correcta y eficiente expresada en un lenguaje de bajo nivel (implementacin de lgebra relacional) y ejecutar la estrategia para extraer los datos requeridos. Optimizacin de consultas La actividad de seleccionar una estrategia de ejecucin eficiente para el procesamiento de una consulta. Un aspecto importante del procesamiento de consultas es la optimizacin de la consulta. Puesto que hay otras transformaciones equivalentes de la misma consulta de alto nivel, el objetivo de la optimizacin de consultas consiste en elegir aquella que minimice el uso de recursos. Generalmente, lo que intentaremos ser reducir el tiempo total de ejecucin de la consulta, que es la suma de los tiempos de ejecucin de todas las operaciones individuales que componen la consulta (Selinger el al., 1979). Sin embargo, el uso de recursos tambin podra medirse segn el tiempo de respuesta de la consulta, en cuyo caso nos concentraremos en maximizar el nme- 3. Captulo 21 Procesamiento de consultas 577 ro de operaciones paralelas (Valduriez y Gardarin, 1984). Puesto que el problema es computacionalmente intratable cuando el nmero de tablas es grande, la estrategia adoptada se reduce generalmente a encontrar una solucin cercana a la ptima (Ibaraki y Kameda, 1984). Ambos mtodos de optimizacin de consultas dependen de las estadsticas de la base de datos para evaluar apropiadamente las diferentes opciones disponibles. La precisin y grado de actualizacin de dichas estadsticas tienen un gran impacto sobre la eficiencia de la estrategia de ejecucin elegida. Las estadsticas recopilan informacin acerca de las relaciones, atributos e ndices. Por ejemplo, el catlogo del sistema puede almacenar estadsticas que proporcionen la cardinalidad de las relaciones, el nmero de valores distintos que tiene cada atributo y el nmero de niveles de un ndice multinivel (vase el Apndice C.5A). Mantener las estadsticas actualizadas puede llegar a ser problemtico. Si el SGBD actualizara las estadsticas cada vez que se inserta, actualiza o borra una tupla, esto tendra un impacto significativo sobre el rendimiento durante los picos de carga de trabajo. Otra alternativa generalmente preferible, consiste en actualizar las estadsticas de forma peridica, por ejemplo todas las noches, o siempre que el sistema est inactivo. Otra solucin adoptada por algunos sistemas consiste en asignar a los usuarios la responsabilidad de indicar cundo hay que actualizar las estadsticas. Hablaremos con ms detalle de las estadsticas de las bases de datos en la Seccin 2104.1. Como ilustracin de los efectos que las diferentes estrategias de procesamiento tienen sobre el uso de recursos, vamos a comenzar con un ejemplo. I Ejemplo 21.1 Comparacin de diferentes estrategias de procesamiento Hallar todos los gerentes que trabajen en una sucursal de Londres. Podemos escribir esta consulta en SQL como: SELECT * FROM Staff s, Branch b WHERE s.branchNo = b.branchNo AND (s.position = 'Manager' AND b.city = 'London'); Tres consultas de lgebra relacional equivalentes a esta instruccin SQL seran: (1) a(position~'Manager') (cit)='London')(Staff.branchNo~Branch.branchNoiStaffX Branch) (2) a(position~'Manager') (citY~'LOndOn,)(Staff~ Staff.branchNo~Branch.branchNoBranch) (3) (aposition~'Manager,(Staff))~ Staff.branchNo~Branch.branchNo(acitY~'LOndon,(Branch)) Para los propsitos de este ejemplo, vamos a suponer que hay 1000 tuplas en Staff, 50 tuplas en Branch, 50 empleados con categora Manager (uno por cada sucursal) y 5 sucursales en Londres. Vamos a comparar estas tres consultas basndonos en el nmero de accesos de disco requeridos. En aras a la sim- plicidad, vamos a suponer que no hay ndices ni claves de relacin en ninguna de las relaciones y que los resultados de cualquier operacin intermedia se almacenan en el disco. El coste de la escritura final se ignorar, ya que es el mismo en los tres casos. Vamos a suponer tambin que se accede a las tuplas de una en una (aunque en la prctica los acceso a disco se basaran en bloques, cada uno de los cuales contendra normalmente varias tuplas) y que la memoria principal es lo suficientemente grande como para procesar relaciones completas para cada una de las operaciones de lgebra relaciona!. La primera consulta calcula el producto cartesiano de Staff y Branch, que requiere (1000 + 50) accesos a disco para leer las relaciones y crea una relacin con (1000 * 50) tuplas. Despus tendremos que leer cada una de estas tuplas de nuevo para comprobar si cumplen el predicado de seleccin, lo que implica otros (1000 * 50) accesos a disco, dndonos un coste total de: (1000 + 50) + 2*(1000 * 50) = 101050 accesos a disco La segunda consulta combina Staff y Branch segn el nmero de sucursal branchNo, lo que de nuevo requiere (1000 + 50) accesos a disco para leer cada una de las relaciones. Sabemos que la combinacin de las dos relaciones tiene 1000 tuplas, una por cada empleado (un empleado slo puede trabajar en 4. 578 Sistemas de bases de datos una sucursal). En consecuencia, la operacin de seleccin requiere 1000 accesos a disco para leer el resultado de la combinacin, lo que nos da un coste total de: 2*1000 + (1000 + 50) = 3050 accesos a disco La ltima de las consultas lee primero cada tupla de 81aff para determinar si se trata de un empleado con categora de Manager, lo que requiere 1000 accesos a disco y produce una relacin con 50 tuplas. La segunda operacin de seleccin lee cada tupla Branch para determinar cules son las sucursales de Londres, lo que requiere 50 accesos a disco y genera una relacin con 5 tuplas. La operacin final es la combinacin de las relaciones 81aff y Branch reducidas, lo que requiere (50 + 5) accesos a disco, dando un coste total de: 1000 + 2*50 + 5+(50 + 5) = 1160 accesos a disco Claramente, la tercera es la mejor de las opciones en este caso, segn un factor de 87:1. Si incremen- tramos el nmero de tuplas de 81aff a 10000 y el nmero de sucursales a 500, la mejora sera segn un factor de aproximadamente 870: 1. Intuitivamente, caba esperar esto desde el principio, ya que el producto cartesiano de las operaciones de combinacin es mucho ms costoso que la operacin de seleccin y la tercera de las operaciones de consulta reduce significativamente el tamao de las relaciones que estn siendo combinadas. Veremos en breve que una de las estrategias fundamentales del procesamiento de consultas es realizar las operaciones unarias, las de seleccin y proyeccin, lo antes posible, reduciendo as el tamao de los operandos para las subsiguientes operaciones binarias. El procesamiento de consultas puede dividirse en cuatro partes principales: descomposicin (compuesta de anlisis sintctico y validacin), optimizacin, generacin de cdigo y ejecucin, como se ilustra en la Figura 21.1. En la Seccin 21.2 vamos a examinar brevemente la primera de las fases, de descomposicin, antes de volver nuestra atencin hacia la segunda fase, la de optimizacin de consultas. Para completar esta panormica, vamos a hablar brevemente de cundo puede llevarse a cabo la optimizacin. Optimizacin dinmica y esttica Existen dos opciones relativas a cundo llevar a cabo las primeras tres fases del procesamiento de una consulta. Una de las opciones consiste en llevar a cabo dinmicamente la descomposicin y la optimizacin cada vez que se ejecuta una consulta. La optimizacin dinmica de consultas tiene la ventaja de que toda la informacin requerida para seleccionar una estrategia ptima estar actualizada. Las desventajas son que la velocidad de la consulta se ver afectada debido a la necesidad de analizar sintcticamente, validar y optimizar la consulta antes de poder ejecutarla. Adems, puede que sea necesario reducir el nmero de estrategias de ejecucin que hay que realizar, con el fin de conseguir que ese coste de procesamiento adicional sea aceptable, lo que a su vez puede tener el efecto de que se seleccione una estrategia significativamente inferior a la ptima. La opcin alternativa consiste en efectuar una optimizacin esttica de consultas, en la que las consultas son analizadas sintcticamente, validadas y optimizadas una sola vez. Esta tcnica es similar a la que se utiliza cuando se ejecuta un compilador de un lenguaje de programacin. Las ventajas de la optimizacin esttica son que se elimina el coste adicional de procesamiento en tiempo de ejecucin y que puede haber ms tiempo disponible para evaluar un mayor nmero de estrategias de ejecucin, incrementndose as las posibi- lidades de encontrar una estrategia mejor. Para las consultas que se ejecutan muchas veces, tomarse un cierto tiempo adicional para encontrar un plan mejor puede proporcionar muchos beneficios. Las desventajas sur- gen del hecho de que la estrategia de ejecucin que se selecciona como ptima en el momento de compilar la consulta puede haber dejado de ser ptima en el momento de ejecutarla. De todos modos, tambin puede emplearse una tcnica hbrida para evitar esta desventaja, tcnica que consiste en reoptimizar la consulta si el sistema detecta que las estadsticas de la base de datos han cambiado significativamente desde la ltima vez que se compil la consulta. Alternativamente, el sistema podra compilar la consulta para la primera ejecucin de cada sesin y luego almacenar en cach el plan ptimo durante el resto de la sesin, de modo que el coste se distribuya entre toda la sesin del SGBD. 5. Captulo 21 Procesamiento de consultas 579 Consulta en un lenguaje de alto nivel (generalmente SQL) Descomposicin de la consulta Expresin de lgebra relacional oCatlogo del sistema Tiempo de compilacin Optimizacin de la consulta Plan de ejecucin Generacin de cdigo Cdigo generado Ejecucin de la consulta Salida de la consulta Figura 21.1. Fases del procesamiento de consultas. 21.2 Descomposicin de consultas La descomposicin de consultas es la primera fase del procesamiento de consultas. Los objetivos de la descomposicin de consultas son transformar una consulta de alto nivel en una consulta de lgebra relacional y comprobar que la consulta sea sintctica y semnticamente correcta. Las etapas tpicas de la descomposicin de consultas son el anlisis, la normalizacin, el anlisis semntico, la simplificacin y la reestructuracin de la consulta. (1) Anlisis En esta etapa, se analiza la consulta lxica y sintcticamente utilizando las tcnicas de los compiladores de los lenguajes de programacin (vase, por ejemplo Aho y Ullman, 1977). Adems, en esta etapa se verifica que las relaciones y atributos especificados en la consulta estn definidos en el catlogo del sistema. Se verifica asimismo que todas las operaciones aplicadas a los objetos de la base de datos sean apropiadas para el tipo de objeto. Por ejemplo, considere la siguiente consulta: SELECT staffNumber FROM Staff WHERE position > 10; Esta consulta sera rechazada por dos motivos (1) En la lista de seleccin, el atributo staffNumber no est definido para la relacin 8taff (debera ser staffNo). (2) En la clusula WHERE, la comparacin '>1O' es incompatible con el tipo de datos position, que es una cadena de caracteres de longitud variable. 6. 580 Sistemas de bases de datos Completada esta etapa, la consulta de alto nivel habr sido trasformada en algn tipo de representacin interna ms adecuada para su procesamiento. La forma interna que se suele elegir es algn tipo de rbol de consulta, que se construye de la forma siguiente: Se crea un nodo hoja para cada relacin base de la consulta. Se crea un nodo no hoja para cada relacin intermedia producida por una operacin de lgebra relaciona!. La raz del rbol representa el resultado de la consulta. La secuencia de operaciones se dirige desde las hojas hacia la raz. La Figura 21.2 muestra un ejemplo de un rbol de consulta para la instruccin SQL del Ejemplo 21.1 que utiliza el lgebra relacional en su representacin interna. Nos referiremos a este tipo de rbol de consulta deno- minndolo rbol de lgebra relacional. (2) Normalizacin La etapa de normalizacin del procesamiento de consulta convierte la consulta en una forma normalizada que pueda manipularse ms fcilmente. El predicado (en SQL, la condicin WHERE), que puede ser arbitraria- mente complejo, puede convertirse a una de dos formas aplicando unas pocas reglas de transformacin (Jarke y Koch, 1984): Forma normal conjuntiva. Una secuencia de conjunciones conectadas mediante el operador / (AND). Cada conjuncin contiene uno o ms trminos conectados mediante el operador v (OR). Por ejemplo: (position = 'Manager' v salary > 20000) / branchNo = '8003' Una seleccin conjuntiva contiene nicamente aquellas tuplas que satisfacen todas las conjunciones. Forma normal disyuntiva. Una secuencia de disyunciones conectadas mediante el operador v (OR). Cada disyuncin contiene uno o ms trminos conectados mediante el operador / (AND). Por ejemplo, podramos reescribir la forma normal conjuntiva anterior como: (position = 'Manager' / branchNo = '8003' ) v (salary > 20000 / branchNo = '8003') Una seleccin disyuntiva contiene todas las tuplas formadas por la unin de todas las tuplas que satisfacen las disyunciones. (3) Anlisis semntica El objetivo del anlisis semntico es rechazar las consultas normalizadas que estn incorrectamente formula- das o que sean contradictorias. Una consulta estar incorrectamente formulada si sus componentes no contri- buyen a la generacin del resultado, lo que puede suceder si faltan algunas especificaciones de combinacin. Una consulta ser contradictoria si su predicado no puede ser satisfecho por ninguna tupla. Por ejemplo, el predicado (position = 'Manager' / position = 'Assistant') para la relacin Staff ser contradictorio, ya que un empleado no puede ser a la vez Manager y Assistant. Sin embargo, el predicado ((position = 'Manager' / !> 20000) podra simplificarse a (salary > 20000) interpretndose la clusula contradictoria como el valor booleano FALSE. Desafortunadamente, la manera de gestionar las clusulas contradictorias no es coherente entre un SGBD y otro. I Ejemplo 21.2 Comprobacin de la correccin semntica Considere la siguiente consulta SQL: SELECT p.propertyNo, p.street FROM Client e, Viewing Y, PropertyForRent p WHERE c.c1ientNo = Y.clientNo AND c.maxRent >= 500 AND c.prefType = 'Flat' AND p.ownerNo = 'C093'; El grafo de conexin de relaciones mostrado en la Figura 21.3(a) no est completamente conectado, lo que implica que la consulta no est correctamente formulada. En este caso, hemos omitido la condicin de combinacin (Y.propertyNo = p.propertyNo) del predicado. (a) 8:8 s :s(b) Figura 21.3. (a) Grafo de conexin de relaciones que muestra que la consulta est incorrectamente formulada; (b) grafo de conexin de atributos normalizado que muestra que la consulta es contradictoria. 8. 582 Sistemas de bases de datos Ahora considere la consulta: SELECT p.propertyNo,p.street FROM Clientc, Viewingv, PropertyForRentp WHERE c.maxRent > 500 ANOc.clientNo= v.c1ientNoANO v.propertyNo= p.propertyNoANOc.prefType= 'Flat'ANOc.maxRent < 200; El grafo de conexin de atributos normalizado para esta consulta se muestra en la Figura 21.3(b), donde podemos ver que tiene un ciclo entre los nodos c.maxRent y O con una suma de evaluacin negativa, lo que indica que la consulta es contradictoria. Claramente, no podemos tener un cliente con un alquiler mximo que sea a la vez mayor de 500 euros e inferior a 200 euros. Slo existen algoritmos para determinar la correccin para el subconjunto de consultas que no contengan disyunciones y negaciones. Para estas consultas, podemos aplicar las siguientes comprobaciones: (1) Construimos un grajo de conexin de relaciones (Wong y Youssefi, 1976). Si el grafo no est conectado, la consulta estar incorrectamente formulada. Para construir un grafo de conexin de relaciones, creamos un nodo por cada relacin y otro nodo para el resultado. Despus dibujamos aristas entre dos nodos para representar una combinacin y aristas entre los nodos que representen el origen de las operaciones de proyeccin. (2) Construimos un grajo de conexin de atributos normalizado (Rosenlcrantz y Hunt, 1980). Si el grafo tiene un ciclo para el que la suma de evaluacin sea negativa, la consulta sera contradictoria. Para construir un grafo de conexin de atributos normalizado, creamos un nodo por cada referencia a un atributo o para la constante O. Despus creamos una arista dirigida entre los nodo s que representen una combinacin y una arista dirigida entre un nodo de atributo y un nodo de constante O que represente una operacin de seleccin. A continuacin, ponderamos las aristas a ~ b con el valor c, si representa la condicin de desigualdad (a ::; b + c), y ponderamos las aristas O ~ a con el valor -c si representa la condicin de desigualdad (a :::::c). (4) Simplificacin Los objetivos de la etapa de simplificacin son detectar las cualificaciones redundantes, eliminar las subex- presiones comunes y transformar la consulta en otra consulta que sea semnticamente equivalente pero que se pueda calcular de forma ms fcil y eficiente. Normalmente, las restricciones de acceso, las definiciones de vista y las restricciones de integridad se toman en consideracin en esta etapa, pudiendo algunas de esas restricciones y definiciones introducir redundancia. Si el usuario no dispone de los derechos de acceso apropiados a todos los componentes de la consulta, ser necesario rechazar sta. Suponiendo que el usuario tenga los privilegios de acceso apropiados, una optimizacin inicial consiste en aplicar las muy conocidas reglas de idempotencia de lgebra booleana, como son: pl(p)==p P 1 false ==false p 1 true ==p p 1 (~p) ==false pl(pvq)==p pv(P)==p p v false ==p p v true ==true p v (~p) ==true pv(plq)==p Por ejemplo, considere la siguiente definicin de vista y la siguiente consulta realizada sobre la vista: CREATE VIEW Staff3AS SELECT staffNo,fName, IName,salary, branchNo FROM Staff WHERE branchNo = 'B003'; SELECT * FROM Staff3 WHERE (branchNo = 'B003'ANO salary > 20000); 9. Captulo 21 Procesamiento de consultas 583 Como hemos explicado en la Seccin 6.4.3, durante la resolucin de la vista esta consulta se transforma- r en: SELECT staffNo, fName, IName, salary, branchNo FROM Staff WHERE (branchNo = 'B003'ANO salary > 20000) ANO branchNo = 'B003'; y la condicin WHERE se reduce a (branchNo = 'B003' AND salary > 20000). Tambin pueden aplicarse las restricciones de integridad para ayudar a simplificar las consultas. Por ejemplo, considere la siguiente restriccin de integridad, que garantiza que slo los empleados con categora de Manager tengan un salario superior a 20.000 euros: CREATE ASSERTION OnlyManagerSalaryHigh CHECK ((position 'Manager' AND salary < 20000) OR (position = 'Manager' AND salary > 20000)); Y considere el efecto sobre la consulta: SELECT * FROM Staff WHERE (position = 'Manager' AND salary < 15000); El predicado de la clusula WHERE, que busca gerentes cuyo salario sea inferior a 15.000 euros, estar ahora en contradiccin con la restriccin de integridad, por lo que no puede haber ninguna tupla que satisfa- ga este predicado. (5) Reestructuracin de la consulta En la etapa final de la descomposicin de una consulta, la consulta se reestructura para obtener una implementacin ms eficiente. Hablaremos ms en detalle de la reestructuracin en la seccin siguiente. 21.3 Mtodo heurstico de optimizacin de consultas En esta seccin, vamos a examinar el mtodo heurstico de optimizacin de consultas, que utiliza reglas de transformacin para convertir una expresin de lgebra relacional en otra forma equivalente que se sepa que es ms eficiente. Por ejemplo, en el Ejemplo 21.1 hemos observado que era ms eficiente realizar la operacin de seleccin sobre una relacin antes de utilizar dicha relacin en una combinacin, en lugar de efectuar primero la combinacin y luego la seleccin. Veremos en la Seccin 21.3.1 que existe una regla de transformacin que permite cambiar el orden de las operaciones de combinacin y seleccin de modo que la seleccin pueda realizarse primero. Habiendo explicado cules son las transformaciones vlidas, en la Seccin 21.3.2 presentaremos un conjunto de reglas heursticas que se sabe que producen estrategias de ejecucin 'buenas' (aunque no necesariamente ptimas). 21.3.1 Reglas de transformacin para las operaciones de lgebra relacional Aplicando reglas de transformacin, el optimizador puede transformar una expresin de lgebra relacional en otra expresin equivalente que se sabe que es ms eficiente. Utilizaremos estas reglas para reestructurar el rbol de lgebra relacional (cannico) generado durante la descomposicin de la consulta. El lector puede encontrar demostraciones de estas reglas en Aho el al. (1979). Al enumerar estas reglas, utilizaremos tres relaciones R, S Y T, estando R definida sobre los atributos A = {Al, Al, ... , An} Y S definida sobre B = {BI,Bl, ... , Bn}; p, q y r denotan predicados y L, LI, Ll, M, M, Ml Y N denotan conjuntos de atributos.~ (1) Las operaciones conjuntivas de seleccin pueden transformarse en una cascada de operaciones individuales de seleccin (y viceversa). 10. 584 Sistemas de bases de datos Esta transformacin se denomina en ocasiones cascada de selecciones. Por ejemplo: U branchNo='B003'ASalarY>15000(Staff) = UbranchNo='B003'(Usalary>15000(Staff)) (2) Conmutatividad de las operaciones de seleccin. up(uq(R)) = uq(up(R)) Por ejemplo: U branchNo='B003'Usalary>15000(Staff)) = U salary>15000(ubranchNo='B003,(Staff)) (3) En una secuencia de operaciones de proyeccin, slo se requiere la ltima proyeccin de la secuencia. ITLITM' .. ITN(R) = ITL(R) Por ejemplo: ITrNameITbranchNo,IName(Staff) = ITrName(Staff) (4) Conmutatividad de la seleccin y la proyeccin. Si el predicado p implica slo los atributos de la lista de proyeccin, entonces las operaciones de seleccin y de proyeccin son conmutativas: nAf,.Am (up(R)) = Up(TlAf, .,Am (R)) donde p E {Af, A2' ... , Am) Por ejemplo: ITfName,IName(UlName='Beech,(Staff)) = UIName='Beech,(ITfName,IName(Staff)) (5) Conmutatividad de la combinacin Theta (y del producto cartesiano). R [>= p.rent AND c.prefType= p.type AND p.ownerNo= 'C093'; Para los propsitos de este ejemplo, vamos a asumir que hay menos inmuebles propiedad del propie- tario C093 que inquilinos en perspectiva que hayan especificado como tipo preferido de inmueble el de apartamento (flat). Convirtiendo la instruccin SQL en lgebra relacional, tendremos: IIp,propertyNo, p,street( (J" c.prefTyp'Flat' 1 c.c1ientNo=v.c1ientNo 1 v.propertyNo=p.propertyNo 1 c.maxRent>=p.rent A c.prefType=p.type 1 p,ownerNO='C093'( (e xv) x p)) Podemos representar esta consulta mediante el rbol de lgebra relacional cannico que se muestra en la Figura 21.4(a). A continuacin utilizamos las siguientes reglas de transformacin para mejorar la eficiencia de la estrategia de ejecucin: (1) (a) Regla 1, dividir la conjuncin de operaciones de seleccin en operaciones de seleccin individuales. (b) Regla 2 y Regla 6, reordenar las operaciones de seleccin y luego conmutar las selecciones y los productos cartesianos. El resultado de estas dos primeras etapas se muestra en la Figura 21.4(b). (2) Teniendo en cuenta lo explicado en la Seccin 4.1.3, podemos reescribir una seleccin con un predicado de equicombinacin y una operacin de producto cartesiano como una operacin de equicombinacin, es decir: aRa=Sb(R X S) = R ~Ra=Sb S Aplicamos esta transformacin en todos los lugares apropiados. El resultado de este paso se muestra en la Figura 21.4(c). (3) Regla 11, reordenacin de las equicombinaciones de modo que la seleccin ms restrictiva sobre (p.ownerNo = 'C093') se realice en primer lugar, como se muestra en la Figura 21.4(d). (4) Reglas 4 y 7, mediante las que movemos las proyecciones hacia abajo ms all de las equicombinaciones y creamos nuevas operaciones de proyeccin segn sea necesario. El resultado de aplicar estas reglas se muestra en la Figura 21.4( e). l. 13. Captulo 21 Procesamiento de consultas 587 rr p.propertyNo, p.street x P TI p.propertyNo, p.street 1 i pv e I c.pretType='Flat' IIp.propertyNo, p.street i itx1 v.propertyNo=p.propertyNo 1t>=p.rent" c.pretType=p.type 0c.prefType='Flar V !e 0c.c1ientNo=v.clientNo 0p.OwnerNO='C093' t0C,maxRent>=p.rent 1 c.prefType=p.type t v.propertyNo=p.prOpertyNo t x /"- 1 x P rve Dc.prefType='Flaf / c.ctientNo=v.clientNo 1 v.propertyNo=p.propertyNo 1 c.maxRent>=p.rent 1 c.prefTypeop.type tP.ownerNOO'C093' x 1 (a) (b) (e) rr p.propertyNo, p.street 0c.maxRent>=p.rent 1 c.prefType=p.type CXlv.propertyNo=p.propertyNo 0c.prefType='Flat' i evic.maxRent>=p.rent ITp.propertyNo, p.street ! ! P (f) 0p.ownerNo='C093' 1 p.type='Flat' itx1c.clientNo=v.clientNo 1t>""p.rent 1 c.prefTypeo;;;p.type I !p (e) p.ownerNo='C093' i~c.clientNo=v.clientNo 1CXlv.propertyNo=p.propertyNo TI c.clientNo, c.maxRent, c.preffype IIp.propertyNo, p.street, TIv.propertyNo, p.rent, p.type v.clientNo eit:x:lc.c1ientNo=v.clientNo 1 p 1 ! (d) 0p.ownerNo='C093' V Figura 21.4. rbol de lgebra relacional para el Ejemplo 21.3: (a) rbol cannico de lgebra relacional; (b) rbol de lgebra relacional formado al llevar las selecciones hacia abajo; (c) rbol de lgebra relacional formado al cambiar las selecciones/productos cartesianos por equicombinaciones; (d) rbol de lgebra relacional que se forma aplicando la regla de asociatividad de las equicombinaciones; (e) rbol de lgebra relacional que se forma llevando las proyecciones hacia abajo; (f) rbol final reducido de lgebra relacional que se forma sustiuyendo c.prefType = 'Flat' en la seleccin sobre p,type y llevando hacia" abajo del rbol la seleccin resultante. 14. 588 Sistemas de bases de datos Una optimizacin adicional en este ejemplo concreto consiste en observar que la operacin de seleccin (c.preIType=p.type)puede reducirse a (p.type='Flat'), ya que sabemos que (c.preIType='Flat') de la primera clusula del predicado. Utilizando esta sustitucin, movemos esta seleccin hacia abajo en el rbol, lo que da como resultado el rbol final reducido de lgebra relacional que se muestra en la Figura 21.4(f). ~ 21.3.2 Estrategias de procesamiento heurstica Muchos SGBD utilizan reglas heursticas para determinar las estrategias de procesamiento de las consultas. En esta seccin vamos a examinar algunas reglas heursticas convenientes que pueden aplicarse para procesar las consultas. (1) Realizar las operaciones de seleccin lo antes posible. La seleccin reduce la cardinalidad de la relacin y el subsiguiente procesamiento de dicha relacin. Por tanto, debemos utilizar la regla 1para conectar en cascada las operaciones de seleccin y las reglas 2, 4, 6 y 9 referidas a las conmutatividad de la seleccin con las operaciones unarias y binarias, con el fin de mover las operaciones de seleccin lo ms abajo posible en el rbol. Mantenga juntos los predicados de seleccin relativos a una misma relacin. (2) Combinar el producto cartesiano con una operacin de seleccin subsiguiente cuyo predicado represente una condicin de combinacin, para formar una operacin de combinacin. Ya hemos observado que podemos reescribir una seleccin con un predicado de combinacin Theta y una operacin de producto cartesiano como una operacin de combinacin Theta: (3) Utilizar la asociatividad de las operaciones binarias para reordenar los nodos hoja de modo que los nodos hoja con las operaciones de seleccin ms restrictivas se ejecuten primero. De nuevo, la regla prctica consiste en realizar el mximo posible de reducciones antes de llevar a cabo las operaciones binarias. As, si tenemos dos operaciones de combinacin consecutivas que realizar: debemos emplear las reglas 11 y 12 relativas a la asociatividad de la combinacin Theta (y de la unin e interseccin) para reordenar las operaciones de modo que las relaciones que nos de la combinacin ms pequea se calculen primero, lo que significa que la segunda combinacin tambin estar basada en un primer operando ms pequeo. (4) Realizar las operaciones de proyeccin lo antes posible. De nuevo, las operaciones de proyeccin reducen la cardinalidad de las relaciones y, por tanto, el subsiguiente procesamiento de las mismas. Por tanto, debemos emplear la regla 3 para conectar en cascada las operaciones de proyeccin y las reglas 4, 7 Y la referidas a la conmutatividad de la proyeccin y las operaciones binarias con el fin de mover las operaciones de proyeccin lo ms abajo posible en el rbol. Hay que mantener juntos los atributos de proyeccin correspondientes a una misma relacin. (5) Calcular una nica vez las expresiones comunes. Si una expresin comn aparece ms de una vez en el rbol y el resultado que produce no es excesi- vamente grande, hay que almacenar el resultado despus de haberlo calculado la primera vez y luego reutilizarlo cada vez que se requiera. Esto slo representar una ventaja si el tamao del resultado correspondiente a la expresin comn es lo suficientemente pequeo como para almacenarlo en memoria principal o como para poder acceder a l en el almacenamiento secundario con un coste inferior al de recalcular el resultado. Esto puede ser especialmente til cuando se efectan consultas sobre las vistas, puesto que puede utilizarse la misma expresin para calcular la vista cada vez. 15. Captulo 21 Procesamiento de consultas 589 En la Seccin 23.7 mostraremos cmo pueden aplicarse estas reglas heursticas a las consultas distribuidas. En la Seccin 28.5 se mostrar que algunas de estas reglas heursticas pueden requerir un anlisis adicional para los SGBD objeto-relacionales, que soportan consultas que contienen tipos definidos por el usuario y funciones definidas por el usuario. 21.4 Estimacin de costes para las operaciones de lgebra relacional Un SGBD puede tener muchas formas distintas de implementar las operaciones de lgebra relacional. El objetivo de la optimizacin de consultas consiste en seleccionar la ms eficiente. Para ello, utilice frmulas que estiman los costes para una serie de opciones y seleccione aquella que tenga el coste menor. En esta seccin vamos a examinar las diferentes opciones disponibles para implementar las principales operaciones de lgebra relacional. Para cada una de ellas, proporcionaremos una panormica de la implementacin y daremos un coste estimado. Puesto que el coste dominante en el procesamiento de consultas es usualmente el de los accesos a disco, que son lentos comparados con los accesos a memoria, nos concentraremos exclusivamente en el coste de los accesos a disco dentro de las estimaciones proporcionadas. Cada estimacin representa el nmero requerido de accesos a bloques de disco, excluyendo el coste de escribir la relacin que se genera como resultado de la consulta. Muchas de las estimaciones de coste estn basadas en la cardinalidad de la relacin. Por tanto, puesto que necesitamos poder estimar la cardinalidad de las relaciones intermedias, tambin mostraremos algunas estimaciones tpicas que pueden deducirse para dichas cardinalidades. Comencemos esta seccin examinando los tipos de estadsticas que el SGBD almacena en el catlogo del sistema para servir de ayuda durante la estimacin de costes. 21.4.1 Estadsticas de la base de datos El xito en la estimacin del tamao y el coste de las operaciones de lgebra relacional intermedias depende de la cantidad y grado de actualizacin de la informacin estadstica guardada por el SGBD. Normalmente, esperamos que el SGBD sea capaz de mantener las siguientes informaciones en su catlogo del sistema: Para cada relacin base R nTuples(R): el nmero de tuplas (registros) en una relacin R (es decir, su cardinalidad). bFactor(R): el factor de bloqueo de R (es decir, el nmero de tuplas de R que caben en un bloque). nBlocks(R): el nmero de bloques requeridos para almacenar R. Si las tuplas de R se almacenan fsicamente juntas, se cumplir que: nBlocks(R) = [nTuples(R)/bFactor(R)] Utilizamos [x] para indicar que el resultado del clculo se redondea al entero ms bajo que sea igualo supenor ax. Para cada atributo A de la relacin base R nDistinctA(R): el nmero de valores distintos que aparecen para el atributo A en la relacin R. minA(R),maxA(R):los valores mnimo y mximo posibles para el atributo A en la relacin R. SCA(R):la cardinalidad de seleccin del atributo A en la relacin R. Se trata del nmero medio de tuplas que satisfacen una condicin de igualdad para el atributo A. Si asumimos que los valores de A estn uniformemente distribuidos en R y que existe al menos un valor que satisface la condicin, entonces: tI SCA (R) = [nTuples(R) / DistinctA (R)] si A es un atributo clave de R en caso contrario Tambin podemos estimar la cardinalidad de seleccin para otras condiciones: 16. 590 Sistemas de bases de datos [nTuples(R) * ((maxA(R) - c) /(maxA (R) - minA(R))] para la desigualdad (A > c) [nTuples(R) * ((c - maxA (R)) /(maxA (R) - minA(R))] para la desigualdad (A < c) SCA(R) = i[(nTUPleS(R) / nDistinctA (R)) * n] SC A(R) *SCs (R) SCA(R) +SCs (R) -SCA (R) * SCs (R) para A perteneciente a {cl, c2' ., cn} para (A B) para (A v B) Para cada ndice multinivel 1 sobre el conjunto de atributos A nLevelsA(I): el nmero de niveles de I. nLfBlocksA(I): el nmero de bloques hoja de I. Mantener estas estadsticas actualizadas puede ser problemtico. Si el SGBD actualiza las estadsticas cada vez que se inserta, actualiza o borra una tupla, esto tendr un impacto significativo sobre las prestaciones en los momentos de mayor carga de trabajo. Una alternativa generalmente preferible consiste en que el SGBD actualice las estadsticas de forma peridica, por ejemplo durante la noche o cada vez que el sistema est inactivo. Otro enfoque adoptado por algunos sistemas es hacer a los usuarios responsables de indicar que las estadsticas deben ser actualizadas. 21.4.2 Operacin de seleccin (S = O"p(R Como hemos dicho en la Seccin 4.1.1, la operacin de seleccin en el lgebra relacional funciona sobre una nica relacin R, y define una relacin S que contiene nicamente aquellas tuplas de R que satisfacen el predicado especificado. El predicado puede ser simple, implicando la comparacin de un atributo de R con un valor constante o con otro valor de atributo, y tambin puede ser compuesto, implicando ms de una condicin, combinndose las distintas condiciones mediante las conectivas lgicas (AND), v (OR) Y ~ (NOT). Existen diversas implementaciones distintas para la operacin de seleccin, dependiendo de la estructura del archivo en que est almacenada la relacin y de si los atributos implicados en el predicado han sido indexados o se les ha aplicado una funcin hash. Las principales estrategias que vamos a considerar son: bsqueda lineal (archivo desordenado, sin ndice); bsqueda binaria (archivo ordenado, sin ndice); igualdad de la clave hash; condicin de igualdad de la clave principal; condicin de desigualdad de la clave principal; condicin de igualdad en un ndice (secundario) de clstering; condicin de igualdad en un ndice (secundario) no de clstering; condicin de desigualdad en un ndice secundario de tipo B+-tree. Los costes de cada una de estas estrategias se resumen en la Tabla 21.1. Estimacin de la cardinalidad de la operacin de seleccin Antes de considerar estas opciones, vamos a presentar primero estimaciones para el nmero esperado de tuplas y el nmero esperado de valores distintos de un atributo en la relacin resultado S obtenida al efectuar la operacin de seleccin sobre R. Generalmente, es bastante difcil proporcionar estimaciones precisas; sin embargo, si aceptamos las suposiciones tradicionales de simplificacin que suponen que los valores de los atributos estn uniformemente distribuidos dentro de su dominio y que los atributos son independientes, podemos usar las siguientes estimaciones: nTuples(S) = SCA(R) el predicado p es de la forma (A e x) 17. Estrategias Captulo 21 Procesamiento de consultas 591 Tabla 21.1. Resumen del coste estimado de E/S para las estrategias correspondientes a una operacin de seleccin. Coste Bsqueda lineal (archivo desordenado, [nBlocks(R)/2], para una condicin de igualdad sobre un atributo clave sin ndice) nBlocks(R), en caso contrario Bsqueda binaria (archivo ordenado, [loginBlocks(R], para una condicin de igualdad sobre un atributo ordenado sin ndice) [loginBlocks(R] + [SCA(R)/bFactor(R)] - 1, en caso contrario Igualdad de la clave hash Condicin de igualdad de la clave principal Condicin de desigualdad de la clave principal Condicin de igualdad en un ndice (secundario) de clstering Condicin de igualdad en un ndice (secundario) no de clstering Condicin de desigualdad en un ndice secundario de tipo B+-tree 1, suponiendo que no se produzca desbordamiento nLevelsA(I) + 1 nLevelsA(I) + [nBlocks(R)/2] nLevelsA(I) + [SCA(R)/bFactor(R)] nLevelsA(I) + [nLfBlocksA(I)/2 nTuples(R)/2] Para cualquier atributo B *- A de s: {nTUPleS(S) nDistinctB (S) = [(nTuples(S) +nDistinctB (R)/3] nDistinctB (R) si nTuples(S) < nDistinctB (R)/2 si nDistinctB (R)/2 :S: nTuples(s) :S: 2*nDistinctB (R) si nTuples(S) > 2*nDistinctB (R) Podemos calcular estimaciones ms precisas si relajamos la suposicin de la distribucin uniforme de los valores, pero esto requiere el uso de informacin estadstica ms detallada, como, por ejemplo, histogramas y pasos de distribucin (Piatetsky-Shapiro y Connell, 1984). Hablaremos brevemente de cmo utiliza Oracle los histogramas en la Seccin 21.6.2. (1) Bsqueda lineal (archivo desordenado, sin ndice) Con esta tcnica, puede se necesario analizar cada tupla de cada bloque para determinar si satisface el predicado, como se ilustra en el algoritmo resumidos que se ilustra en la Figura 21.5. Esto se denomina algunas veces exploracin completa de tabla. En el caso de una condicin de igualdad sobre un atributo clave, si supo- nemos que las tuplas estn uniformemente distribuidas por el archivo slo har falta, por trmino medio explorar la mitad de los bloques para encontrar una tupla especfica, por lo que la estimacin de costes ser: [nBlocks(R)/2] Para cualquier otra condicin, puede que sea necesario explorar el archivo completo, por lo que la estimacin ms general de coste ser: nBlocks(R) (2) Bsqueda binaria (archivo ordenado, sin ndice) Si el predicado tiene la forma (A = x) y el archivo est ordenado segn el atributo A, que es tambin el atribu- to clave de la relacin R, entonces la estimacin de coste para la bsqueda ser: 18. 592 Sistemas de bases de datos // // Bsqueda lineal // El predicado predicate es la clave de bsqueda. // El archivo no est ordenado. Los bloques estn numerados secuencialmente a partir de 1. // Devuelve una tabla de resultados que contiene las tuplas de R que satisfacen el predicado. // for i = 1 to nBlocks(R) { block = read_bJock(R, i); for j = 1 to nTuples(block) { if (block.tuple [j] satisfies predicate) then add tuple to result; // recorrer en bucle cada bloque // recorrer en bucle cada tupla del bloque i Figura 21.5. Algoritmo para bsqueda lineal. [log2(nBlocks(R))] El algoritmo para este tipo de bsqueda est esbozado en la Figura 21.6. Con carcter ms general, la estimacin de coste ser: [log2(nBlocks(R))] + [SCA(R)/bFactor(R)] - 1 El primer trmino representa el coste de encontrar la primera tupla utilizando un mtodo de bsqueda binaria. Esperamos que existan SCA(R)tuplas que satisfagan el predicado, las cuales ocuparn [SCA(R)/bFactor(R)] bloques, de los cuales uno ya ha sido extrado al localizar la primera tupla. (3) Igualdad de la clave hash Si el atributo A es la clave hash, aplicamos el algoritmo hash para calcular la direccin correspondiente a la tupla. Si no hay ningn desbordamiento, el coste esperado ser 1. Si hay desbordamiento, puede que sean necesarios accesos adicionales, dependiendo de la cantidad de desbordamiento y del medio para gestionarlo. (4) Condicin de igualdad de la clave principal Si el predicado implica una condicin de igualdad para la clave principal (A = x), podemos utilizar el ndice principal para extraer la nica tupla que satisface esta condicin. En este caso, necesitaremos leer un bloque ms que el nmero de accesos de ndice, equivalente al nmero de niveles del ndice, por lo que el coste estimado ser: nLevelsA(I) + 1 (5) Condicin de desigualdad de la clave principal Si el predicado implica una condicin de desigualdad para la clave principal A (A < x, A x, A >= x), podemos primero utilizar el ndice para localizar la tupla que satisface el predicado A = x. Suponiendo que el ndice est ordenado, podr accederse a las tuplas requeridas leyendo todas las tuplas situadas antes o despus de esta tupla que hemos localizado. Suponiendo una distribucin uniforme, cabra esperar que la mitad de las tuplas satisfagan la desigualdad, por lo que el coste estimado ser: nLevelsA(I) = [nBlocks(R)/2] (6) Condicin de igualdad en un ndice (secundario) de clstering Si el predicado implica una condicin de igualdad para el atributo A, que no es la clave principal pero proporciona un ndice secundario de clstering, podemos utilizar el ndice para extraer las tuplas requeridas. El coste estimado ser: 19. Captulo 21 Procesamiento de consultas 593 // // Bsqueda binaria // El predicado predicate es la clave de bsqueda. // El archivo est ordenado segn valores ascendentes de la clave de ordenacin, A. // El archivo ocupa nBlocks bloques, numerados secuencialmente a partir de l. // Devuelve una variable booleana (found) que indica si se ha encontrado un registro que // se ajuste al predicado y una tabla de resultados en caso afirmativo. // next = 1; last = nBlocks; found = FALSE;keep_searching = TRUE; while (last >= 1 and (not found) and (keep_searching { i = (next + last)/2; // la mitad del espacio de bsqueda block = read_block(R, i) ; if (predicate < orderinll-key_fie1d(firsCrecord(block) then // el registro se encuentra en la mitad inferior del rea de bsqueda last=i-l; else if (predicate > orderinll-key_fie1d(last_record(block) then // el registro se encuentra en la mitad superior del rea de bsqueda next= i + 1; e1seif (check_block_for_predicate(block, predicate, result then // el registro requerido se encuentra en el bloque found = TRUE; e1se keep_searching = FALSE; // el registro no est ah Figura 21.6. Algoritmo de bsqueda binaria en un archivo ordenado. nLevelsA(I) + [SCA(R)/bFactor(R)] El segundo trmino es una estimacin del nmero de bloques que se requerir para almacenar el nmero de tuplas que satisfacen la condicin de igualdad, que hemos estimado como SCA(R). (7) Condicin de igualdad en un ndice (secundario) no de clstering Si el predicado implica una condicin de igualdad para el atributo A, que no es la clave principal pero proporciona un ndice secundario no de clstering, podemos utilizar el ndice para extraer las tuplas requeridas. En este caso, tenemos que asumir que las tuplas se encuentran en diferentes bloques (el ndice no tiene estructura de clster en este caso), por lo que el coste estimado ser: (8) Condicin de desigualdad en un ndice secundario de tipo B+-tree Si el predicado implica una condicin de desigualdad para el atributo A (A < x, A x, A >= x), que proporciona un ndice secundario de tipo B+-tree, entonces a partir de los nodos hoja del rbol podemos explorar las claves desde el valor ms pequeo hasta x (para condiciones < o o >=). Suponiendo una distribucin uniforme cabra esperar que haya que acceder a la mitad de los bloques de nodos hoja y a la mitad de las tuplas (a travs del ndice). El coste estimado ser entonces: nLevelsA(I) + [nLfBlocksA(I)/2 + nTuples(R)/2] El algoritmo para explorar un ndice B+-tree en busca de una nica tupla se muestra en la Figura 21.7. 20. ~' 594 Sistemas de bases de datos // // Bsqueda B+-tree // La estructura B+-tree est representada como una lista enlazada en la que cada nodo no hoja est estructurado como: // un mximo de n elementos, cada uno compuesto por: // un valor clave (key) y un puntero (P) a un nodo hijo (posiblemente NULL). // Las claves estn ordenadas: keYl < keY2 < keY3 < ... < keYn_l // Los nodos hoja apuntan a las direcciones de los registros reales. // El predicado predicate es la clave de bsqueda. // Devuelve un valor booleano (jound) que indica si el registro ha sido encontrado y // la direccin (return_address) del registro, en caso afirmativo. // nade = gecrooCnodeO; while (node is not a leaf node) { i = 1; // localizar la clave que sea inferior al predicado while (not (i > n al' predicate < node[i].key)) { i= i+ 1; node = gecnexcnode(node[i] .pYinode[i].p apunta a un subrbol que puede contener un predicado. } // Se ha encontrado un nodo hoja, as que hay que comprobar si existe un registro con este predicado. i= 1; found = FALSE; while (not (found 01' i > n)) { if (predicate = node[i].key) then { found = TRUE; retufl1_address = node[i] .p; ese i= i+ 1; Figura 21.7. Algoritmo para explorar un rbol B+-tree en busca de una nica tupla que se corresponda con un determinado valor. (9) Predicados compuestos Hasta ahora, hemos limitado nuestro anlisis a predicados simples que slo implican un atributo. Sin embargo, en muchas-s-itQaciones el predicado puede ser compuesto, consistiendo en varias condiciones relativas a ms de un atributo. Ya hemos observado en la Seccin 21.2 que podemos expresar un predicado compuesto de dos formas: mediante la forma normal conjuntiva y mediante la forma normal disyuntiva: Una seleccin conjuntiva contendr nicamente aquellas tuplas que satisfagan todas las conjunciones . Una seleccin disyuntiva contendr aquellas tuplas formadas por la unin de todas las tuplas que satisfagan todas las disyunciones. Seleccin conjuntiva sin disyuncin Si el predicado compuesto no contiene ningn trmino de disyuncin, podemos considerar las siguientes tc- lllcas: (1) Si uno de los atributos en una conjuncin tiene un ndice o est ordenado, podemos utilizar una de las estrategias de seleccin 2-8 explicadas anteriormente para extraer las tuplas que satisfagan dicha con- 21. Captulo 21 Procesamiento de consultas 595 dicin. Despus podemos comprobar si cada tupla extrada satisface las condiciones restantes del predicado. (2) Si la seleccin implica una condicin de igualdad sobre dos o ms atributos y existe un ndice compuesto (o clave hash) sobre los atributos combinados, podemos explorar el ndice directamente, como se ha explicado anteriormente. El tipo de ndice determinar cul de los algoritmos anteriores hay que utilizar. (3) Si hay ndices secundarios definidos sobre uno o ms atributos y, de nuevo, estos atributos estn implicados nicamente en condiciones de igualdad dentro del predicado, entonces si los ndices utilizan punteros de registro (un puntero de registro identifica unvocamente cada tupla y proporciona la direccin de la tupla al disco), en lugar de punteros de bloque, podemos explorar cada ndice para encontrar las tuplas que satisfagan una condicin individual. Formando a continuacin la interseccin de todos los punteros extrados, tenemos el conjunto de punteros que satisfacen las condiciones. Si no hay disponibles ndices para todos los atributos, podemos comprobar si las tuplas extradas cumplen las condiciones restantes. Selecciones con disyuncin Si uno de los trminos de la condicin de seleccin contiene un v (OR) y el trmino requiere una bsqueda lineal porque no existe ningn ndice u ordenacin adecuado, toda la operacin de seleccin requerir una bsqueda lineal. Slo si existe un ndice u ordenacin para cada trmino de la seleccin podremos optimizar la consulta extrayendo las tuplas que satisfagan cada condicin y aplicando la operacin de unin, como se explica ms abajo en la Seccin 21.4.5, operacin que tambin permitir eliminar los duplicados. De nuevo, pueden utilizarse punteros de registros, si es que existen. Si no puede utilizarse ningn atributo para extraer de manera eficiente las tuplas, empleamos el mtodo de la bsqueda lineal y comprobamos todas las condiciones simultneamente para cada tupla. A continuacin vamos a ver un ejemplo para ilustrar el uso de la estimacin con la operacin de seleccin. I Ejemplo 21.4 Estimacin de coste para una operacin de seleccin Para los propsitos de este ejemplo, vamos a hacer las siguientes suposiciones acerca de la relacin Staff: Existe un ndice hash sin desbordamiento sobre el atributo de clave principal staffNo. Existe un ndice de clstering sobre el atributo de clave externa branchNo. Existe un ndice B+-tree sobre el atributo salary. La relacin Stafftiene las siguientes estadsticas almacenadas en el catlogo del sistema: nTuples(Staff) = 3000 taff) = 30~nBlocks(Staff) = 100= 500~SCbranchNo(Staff)=6= 10~SCposition(Staff)= 300= 500~SCsalary(Staff) =6= 10.000maxsalary(Staff)= 50.000=2 alary(l) =2nLffilockssa'ary(I)= 50 El coste estimado de una bsqueda lnea sobre el atributo clave staffNoes 50 bloques y el coste de una bsqueda lineal sobre un atributo no clave es de 100 bloques. A continuacin, consideramos las siguientes operaciones de seleccin y utilizamos las estrategias anteriores para mejorar estos dos costes: SI: astaffNO='SG5,(Staff) S2: aPosition='Manager,(Staff) 22. 596 Sistemas de bases de datos S3: abranchNo='B003,(Staff) S4: asalary>2oooo(Staff) S5: (J"position='Manager' A branchNo='B003,(Staff) SI: S2: S3: S4: S5: Esta operacin de seleccin contiene una condicin de igualdad sobre la clave principal. Por tanto, como el atributo staffNoest almacenado con un mtodo hash, podemos utilizar la estrategia 3 definida anteriormente para estimar el coste, que ser de 1 bloque. La cardinalidad estimada de la relacin resultante ser SCstaffNo(Staff)= 1. El atributo del predicado es un atributo no clave y no indexado, por lo que no podemos mejorar el mtodo de la bsqueda lineal, lo que nos da un coste estimado de 100 bloques. La cardinalidad estimada de la relacin resultante ser SCposition(Staff)= 300. El atributo del predicado es una clave externa con un ndice de clstering, por lo que podemos utilizar la Estrategia 6 para estimar el coste, que ser 2 + [6/30] = 3 bloques. La cardinalidad estimada de la relacin resultante es SCbranchNO(Staff)= 6. Este predicado implica una bsqueda de rango sobre el atributo salary, que tiene un ndice B+-tree, por lo que podemos utilizar la Estrategia 7 y estimar el coste como: 2 + [50/2] + [3000/2] = 1527 bloques. Sin embargo, esto es significativamente peor que la estrategia en bsqueda lineal, por lo que en este caso utilizaramos el mtodo de bsqueda lineal directamente. La cardinalidad estimada de la relacin resultante ser SCsalariStaff)= [3000*(50000-20000)/(50000-10000)] = 2250. En el ltimo ejemplo, tenemos un predicado compuesto, pero la segunda condicin puede imple- mentarse utilizando el ndice de clstering sobre branchNo (el caso S3 anterior), que sabemos que tiene un coste estimado de 3 bloques. Mientras extraemos cada tupla utilizando el ndice de clstering, podemos comprobar si satisface la primera condicin (position= 'Manager'). Sabemos que la cardinalidad estimada de la segunda condicin es SCbranchNO(Staff)= 6. Si denominamos a esta relacin intermedia T, podemos estimar el nmero de valores distintos de position en T, nDistinctposition(T),como: [(6 + 10)/3] = 6. Aplicando ahora la segunda condicin, la cardinalidad estimada de la relacin resultante ser SCposition(T)= 6/6 = 1, que sera correcta si hubiera un nico gerente por cada sucursal. 21.4.3 Operacin de combinacin (T = (R t> 20000 AND position" 'Manager'; Este predicado adicional puede ser muy til si el nico ndice para la relacin Staff es un ndice B+-tree sobre el atributo salary. Por otro lado, este predicado adicional complicara la consulta si no existiera dicho ndice. Para tener informacin adicional sobre la optimizacin semntica de consultas, el lector interesado puede consultar King (1981); Malley y Zdonik (1986); Chakravarthy et al. (1990); Siegel et al. (1992). 21.5.7 Tcnicas alternativas de optimizacin de consultas La optimizacin de consultas es un campo en el que se han llevado a cabo numerosas investigaciones, habin- dose propuesto diversas alternativas al algoritmo de programacin dinmica de System R. Por ejemplo, la tcnica de templado simulado realiza una bsqueda en un grafo cuyos nodos estn constituidos por estrategias de ejecucin alternativas (esta tcnica modela el proceso de templado mediante el que se pueden recrecer cris- tales, calentando primero el fluido que los contiene y luego dejndolo enfriarse lentamente). Cada nodo tiene un coste asociado y el objetivo del algoritmo es localizar un nodo con un coste global mnimo. Un movimien- to de un nodo a otro se considerar cuesta abajo (cuesta arriba) si el coste del nodo de origen es superior (inferior) al coste del nodo de destino. Un nodo ser un mnimo local si para todas las rutas que dan comienzo en ese nodo cualquier movimiento cuesta abajo viene siempre precedido de un movimiento cuesta arriba. Un nodo ser un mnimo global si tiene el menor coste de entre todos los nodos. El algoritmo realiza un paseo aleatorio continuo aceptando siempre los movimientos cuesta abajo y aceptando los movimientos cuesta arriba con un cierto valor de probabilidad, para tratar de no quedarse con un mnimo local de alto coste. La probabilidad de aceptar un movimiento cuesta arriba decrece con el tiempo y llega al final a ser cero, en cuyo momento se detiene la bsqueda y se devuelve como estrategia ptima de ejecucin el nodo visitado que tenga el menor coste. El lector interesado puede consultar Kirkpatrick et al. (1983) y Ioannidis y Wong (1987). El algoritmo de mejora iterativa realiza una serie de optimizaciones locales, comenzando cada una de ellas en un nodo aleatorio y aceptando repetidamente movimientos cuesta abajo hasta que se alcanza un mnimo local. El lector interesado puede consultar Swami y Gupta (1988) y Swami (1989). El algoritmo de optimizacin en dos fases es un hbrido del templado simulado y de la mejora iterativa. En la primera fase, se utiliza la mejora iterativa para realizar determinadas optimizaciones locales que dan como resultado algn mnimo local. Este mnimo local se utiliza como entrada para la segunda fase, que est basada en el templado simulado con una baja probabilidad de partida para los desplazamientos cuesta arriba. El lector interesado puede consultar Ioannidis y Kang (1990). Los algoritmo s genticos, que simulan un fenmeno biolgico, tambin se han aplicado a la optimizacin de consultas. Los algoritmos comienzan con una poblacin inicial, compuesta por un conjunto aleatorio de estrategias, cada una de ellas con su propio coste. A partir de esta poblacin inicial, se combinan pares de estrategias extradas de esa poblacin para generar descendientes que heredan las caractersticas de ambos padres, aunque esos descendientes pueden sufrir pequeas modificaciones de forma aleatoria (mutacin). Para la siguiente generacin, el algoritmo retiene los padres/hijos de mnimo coste. El algoritmo termina cuando toda la poblacin est compuesta por copias de la misma estrategia (ptima). El lector interesado puede consultar Bennett et al. (1991). El algoritmo heurstico A* se ha utilizado en inteligencia artificial para resolver problemas de bsqueda complejos y tambin se ha empleado en la optimizacin de consultas (Yoo y Lafortune, 1989). A diferencia del algoritmo de programacin dinmica anteriormente explicado, el algoritmo A* expande una estrategia de ejecucin cada vez, basndose en su proximidad a la estrategia ptima. Se ha demostrado que A * genera una estrategia completa mucho antes que la programacin dinmica y es capaz de realizar la poda del rbol de bsqueda de manera mucho ms agresiva. 21.5.8 Optimizacin distribuida de consultas En los Captulos 22 y 23 hablaremos de los SGBD distribuidos (SGBDD), que estn compuestos por una coleccin lgicamente interrelacionada de bases de datos distribuidas fsicamente en una red informtica y 39. Captulo 21 Procesamiento de consultas 613 cada una de ellas bajo control de un SGBD local. En un SGBDD, una relacin puede dividirse en una serie de fragmentos distribuidos entre una serie de sistemas; esos fragmentos pueden ser replicados. En la Seccin 23.6 veremos el tema de la optimizacin de consultas en un SGBDD. La optimizacin de consultas distribuidas es ms compleja debido a la distribucin de los datos entre los diferentes sitios de la red. En el entorno distribuido, adems de los costes de procesamiento local (es decir, costes de procesador y de E/S), es necesario tomar en consideracin la velocidad de la red subyacente a la hora de comparar diferentes estrategias. En particular, analizaremos una extensin del algoritmo de programacin dinmica de System R que hemos expuesto anteriormente, as como el algoritmo de optimizacin de consultas de otro proyecto de investigacin sobre sistemas SGBDD muy conocido, denominado SDD-l. 21.6 Optimizacin de consultas en Oracle Para completar este captulo, vamos a examinar los mecanismos de optimizacin de consultas utilizados en Oracle9i (Oracle Corporation, 2004b). Restringiremos nuestro anlisis en esta seccin a las tcnicas de optimizacin basadas en tipos de datos primitivos. Posteriormente, en la Seccin 28.5, veremos cmo proporciona Oracle un mecanismo de optimizacin ampliable para gestionar los tipos definidos por el usuario. En esta seccin emplearemos la terminologa Oracle, refirindonos a las relaciones mediante el trmino tabla y estando las tablas compuestas de columnas yfilas. En la Seccin 8.2 el lector puede encontrar una introduccin a Oracle. 21.6.1 Optimizacin basada en reglas y basada en costes Oracle soporta las tcnicas de optimizacin de consultas que hemos expuesto en este captulo: optimizacin basada en reglas y optimizacin basada en costes. El optimizador basado en reglas El optimizador basado en reglas de Oracle tiene 15 reglas, ordenadas segn su eficiencia, como se muestra en la Tabla 21.4. El optimizador puede seleccionar la utilizacin de una ruta de acceso concreta a una tabla slo si la instruccin contiene un predicado u otro tipo de estructura que haga que esa ruta de acceso est disponible. El optimizador basado en reglas asigna una puntuacin a cada estrategia de ejecucin utilizando estas clasificaciones y luego selecciona la estrategia de ejecucin con la mejor puntuacin (es decir, la ms baja). Cuando dos estrategias tienen la misma puntuacin, Oracle resuelve el empate tomando una decisin que depende del orden en que aparezcan las tablas dentro de la instruccin SQL, lo que no parece que sea una forma particularmente buena de tomar la decisin final. Por ejemplo, considere la siguiente consulta sobre la tabla PropertyForRent y suponga que tenemos un ndice sobre la clave principal, propertyNo, otro ndice sobre la columna rooms y otro ms sobre la columna city: SELECT propertyNo FROM PropertyForRent WHERE rooms > 7 AND city = 'London'; En este caso, el optimizador basado en reglas considerar las siguientes rutas de acceso: Una ruta de acceso mono-columna utilizando el ndice sobre la columna city de la condicin WHERE (city = 'London'). Esta ruta de acceso tiene rango 9. Una exploracin de rango no limitado utilizando el ndice sobre la columna rooms de la condicin WHERE (rooms > 7). Esta ruta de acceso tiene rango 11. Una exploracin completa de tabla, que est disponible para todas las instrucciones SQL. Esta ruta de acceso tiene rango 15. Aunque hay un ndice para la columna propertyNo, esta columna no aparece en la clusula WHERE y el optimizador basado en reglas, como consecuencia, no la toma en consideracin. Basndose en estas rutas, el optimizador basado en reglas decidir utilizar el ndice referido a la columna city. En la actualidad, la optimizacin basada en reglas est desaconsejada por Oracle. 40. 614 Sistemas de bases de datos Tabla 21.4. Clasificaciones de la optimizacin basada en reglas. Rango 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Ruta de acceso Una sola fila basndose en ROWID (identificador de fila) Una sola fila basndose en combinacin con clster Una sola fila basndose en clave hash de clster con clave unvoca o principal Una sola fila basndose en clave unvoca o principal Combinacin clster Clave hash con clster Clave indexada con clster Clave compuesta ndices mono-columna Bsqueda de rango limitado sobre columnas indexadas Bsqueda de rango no limitado sobre columnas indexadas Combinacin mediante ordenacin-mezcla MAX o MIN de columnas indexadas ORDER BY sobre columnas indexadas Exploracin completa de tabla El optimizador basado en costes Para mejorar la optimizacin de las consultas, Oracle introduce el optimizador basado en costes en la versin Oracle 7; dicho optimizador selecciona la estrategia de ejecucin que requiera el mnimo uso de recursos necesario para procesar todas las filas a las que accede la consulta (evitando la anomala de los empates que antes hemos mencionado). El usuario puede seleccionar si el uso mnimo de recursos debe definirse basndose en la tasa de procesamiento (minimizacin de la cantidad de recursos necesaria para procesar todas las filas a las que accede la consulta) o basndose en el tiempo de respuesta (minimizar la cantidad de recursos necesaria para procesar la primera fila a la que accede la consulta), configurando para ello el parmetro de inicia- lizacin OPTIMIZER _MODE. El optimizador basado en costes tambin toma en consideracin las sugerencias que el usuario pueda proporcionar, como explicaremos a continuacin. Estadsticas El optimizador basado en costes depende para su funcionamiento de las estadsticas disponibles para todas las tablas, clsteres e ndices a los que accede la consulta. Sin embargo, Oracle no recopila estadsticas automticamente, sino que deja en manos del usuario la responsabilidad de generar dichas estadsticas y mantener- las actualizadas. Puede utilizarse el paquete PL/SQL DBMS _STATS para generar y gestionar las estadsticas de las tablas, columnas, ndices, particiones y los dems objetos de esquema de la base de datos. Siempre que sea posible, Oracle utiliza un mtodo de procesamiento paralelo para recopilar las estadsticas, aunque las estadsticas de ndice se recopilan en serie. Por ejemplo, podemos recopilar estadsticas para el esquema 'Manager' utilizando la siguiente instruccin SQL: EXECUTE DBMS _STATS.GATHER_SCHEMA _STATS('Manager', DBMS_STATS. AUTO_SAMPLE_SIZE); El ltimo parmetro le dice a Oracle que debe determinar por s mismo el mejor tamao muestral para la obtencin de unas buenas estadsticas. Hay una serie de opciones que pueden especificarse a la hora de recopilar estadsticas. Por ejemplo, podemos especificar si las estadsticas deben calcularse para la estructura de datos completa o slo para una mues- 41. Captulo 21 Procesamiento de consultas 615 tra de los datos. En este ltimo caso, se puede tambin especificar si el muestreo debe estar basado en filas o en bloques: El muestreo basado en filas lee las filas ignorando su ubicacin fisica en el disco. Como escenario de caso peor, el muestreo de filas podra seleccionar una nica fila de cada bloque, requiriendo una exploracin completa de la tabla o ndice. El muestreo de bloques lee una muestra aleatoria de bloques y genera las estadsticas utilizando todas las filas contenidas en esos bloques. Generalmente, el muestreo utiliza menos recursos que si se calcula el valor exacto para la estructura completa. Por ejemplo, s se analiza un 10% o menos de una tabla de tamao muy grande podemos obtener los mismos porcentajes relativos de espacios no utilizados. Tambin se puede hacer que Oracle recopile estadsticas al crear o reconstruir ndices, especificando la opcin COMPUTE STATlSTlCS en los comandos CREATE INDEX o ALTER INDEX. Las estadsticas se almacenan en el diccionario de datos de Oracle y pueden ser inspeccionadas mediante las vistas que se mues- tran en la Tabla 21.5. Cada vista puede estar precedida por tres prefijos: ALL_ incluye todos los objetos de la base de datos a los que el usuario tiene acceso, incluyendo los objetos de otros esquemas a los que se haya concedido acceso al usuario. DBA_ incluye todos los objetos de la base de datos. USER_ incluye slo los objetos del esquema del usuario. Sugerencias Como hemos mencionado anteriormente, el optimizador basado en costes tambin toma en consideracin las sugerencias que el usuario pueda proporcionar. Una sugerencia se especifica como un comentario formatea- do de manera especial dentro de una instruccin SQL. Hay una serie de sugerencias que pueden emplearse para forzar al optimizador a tomar diferentes decisiones, como por ejemplo forzarle a utilizar: Tabla 21.5. Vistas del diccionario de datos de Oracle. Vista ALLJABLES TAB_HISTOGRAMS TAB COLUMNS TAB_COL_STATlSTlCS TAB]ARTITTONS CLUSTERS INDEXES IND_COLUMNS CONS COLUMNS CONSTRAINTS LOBS SEQUENCES SYNONYMS TRIGGERS VIEWS Descripcin Informacin sobre los objetos y tablas relacionales a los que el usuario tiene acceso. Estadsticas sobre el uso de histogramas. Informacin sobre las columnas de las tablas/vistas. Estadsticas utilizadas por el optimizador basado en costes. Informacin sobre las particiones de una tabla particionada. Informacin sobre los clsteres. Informacin sobre los ndices. Informacin sobre las columnas de cada ndice. Informacin sobre las columnas de cada restriccin. Informacin sobre las restricciones de las tablas. Informacin sobre las columnas con tipo de datos LOB (large object, objeto de gran tamao). Informacin sobre los objetos de secuencia. Informacin sobre los sinnimos. Informacin sobre los disparadores de las tablas. Informacin sobre las vistas. 42. 616 Sistemas de bases de datos el optimizador basado en reglas; una ruta de acceso concreta; un orden de combinacin concreto; una operacin de combinacin concreta, como por ejemplo una combinacin mediante ordenacin- mezcla. Por ejemplo, podemos forzar la utilizacin de un ndice concreto utilizando la siguiente sugerencia: SELECT /*+ INDEX(sexlndex) *j fName, IName, position FROMStaff WHERE sex = 'M'; Si hay tantos empleados de sexo masculino como femenino, la consulta devolver aproximadamente la mitad de las filas de la tabla Staff y es probable que una exploracin de tabla completa sea ms eficiente que una exploracin de ndice. Sin embargo, si supiramos que hay un nmero significativamente mayor de muje- res que de hombres, la consulta devolvera un pequeo porcentaje de las filas de la tabla Staff y es probable que la exploracin mediante ndice fuera ms eficiente. Si el optimizador basado en costes asume que hay una distribucin equitativa de valores en la columna sex, es probable que seleccione una exploracin completa de tabla. En este caso, la sugerencia le dice al optimizador que debe utilizar el ndice disponible sobre la columna sexo Planes de ejecucin almacenados Hay muchas veces en las que se ha encontrado un plan ptimo y es innecesario o poco conveniente que el optimizador genere un nuevo plan de ejecucin cada vez que se vuelva a ejecutar la instruccin SQL. En este caso, es posible crear un esbozo almacenado utilizando la instruccin CREATE OUTLINE, que almacenar los atributos utilizados por el optimizador para generar el plan de ejecucin. A partir de ese momento, el optimizador emplear los atributos almacenados para crear el plan de ejecucin en lugar de generar un nuevo plan cada vez. 21.6.2 Histogramas En las secciones anteriores, hemos hecho la suposicin de que los valores de datos dentro de las columnas de una tabla estaban uniformemente distribuidos. Un histograma de valores junto con sus frecuencias relativas proporciona al optimizador unas estimaciones de selectividad mejores en presencia de una distribucin no uniforme. Por ejemplo, la Figura 21.15(a) ilustra una distribucin uniforme estimada para la columna rooms de la tabla PropertyForRent mientras que la Figura 21.15(b) muestra la distribucin no uniforme real. La primera distribucin puede no almacenarse de forma bastante compacta mediante un valor inferior (1) y un valor superior (10) y un recuento total de todas las frecuencias (en este caso, 100). Para un predicado simple tal como rooms > 9, si nos basamos en una distribucin uniforme podemos estimar fcilmente el nmero de tuplas del resultado, que ser (1/10)*100 = 10 tuplas. Sin embargo, esta estimacin es bastante imprecisa (como podemos ver en la Figura 21.15(b), slo hay en realidad una tupla). Un histograma es una estructura de datos que puede utilizarse para mejorar dicha estimacin. La Figura 21.16 muestra dos tipos de histograma: un histograma con anchuras equilibradas, que divide los datos en un nmero fijo de rangos de igual anchura (denominados ranuras) y cada uno de los cuales contiene un recuento del nmero de valores que caen dentro de dicha ranura); un histograma de altura equilibrada, que sita aproximadamente el mismo nmero de valores en cada ranura de modo que los puntos terminales de cada una de ellas se determinan segn el nmero de valores contenidos en la ranura. Por ejemplo, suponga que tenemos cinco ranuras. La Figura 21.16(a) ilustra el histograma de anchuras equilibradas para la columna rooms. Todas las ranuras tienen igual anchura, comprendiendo dos valores 43. Captulo 21 Procesamiento de consultas 617 6 14 20 20 20 8 4 4 3 10 10 10 10 10 10 10 10 10 10 2 3 4 5 6 7 8 9 10 (a) 2 3 4 5 6 7 8 9 10 (b) Figura 21.15. Histograma de valores de la columna rooms en la tabla PropertyForRent: (a) distribucin uniforme; (b) distribucin no uniforme. (1-2,3-4, etc.), y dentro de cada ranura se asume que la distribucin es uniforme. Esta informacin se puede almacenar de forma bastante compacta escribiendo el valor inferior y superior de cada ranura y el recuento del nmero de valores contenidos en la ranura. Si consideramos de nuevo el predicado rooms > 9, el histograma de anchuras equilibradas nos permitira estimar el nmero de tuplas que satisfacen este predicado, calcu- lndolo como un elemento de rango multiplicado por el nmero de elementos de rango, es decir 2*1 = 2, lo cual es mejor que la estimacin basada en la distribucin uniforme. El histograma de alturas equilibradas se ilustra en la Figura 21.16(b). En este caso, la altura de cada columna es 20 (100/5). De nuevo, los datos pueden almacenarse de forma bastante compacta escribiendo los valores inferior y superior de cada ranura, as como la altura de todas las ranuras. Si consideramos el predicado rooms > 9, podemos estimar mediante el histograma de alturas equilibradas el nmero de tuplas que satisfacen este predicado utilizando la frmula: (1/5)*20 = 4, que en este caso no es tan buena como la estimacin proporcionada por el histograma de anchuras equilibradas. Oracle utiliza histogramas de alturas equilibradas. Otra variante del histograma de alturas equilibradas utiliza una altura uniforme dentro de una ranura pero posiblemente alturas ligeramente distintas entre unas ranuras y otras. Puesto que los histogramas son objetos persistentes, existe un coste asociado al almacenamiento y man- tenimiento de los mismos. Algunos sistemas, como SQL de Microsoft, crean y mantienen los histogramas 20 20 20 20 20 20 14 10 4 1 2 3 4 5 6 7 8 9 10 LJLJLJLJLJCount 20 40 28 8 4 (a) 1 2 3 4 LJ 5 6 7 8 l (b) 9 10 1 Figura 21.16. Histograma de valores de la columna rooms en la tabla PropertyForRent: (a) anchuras equilibradas; (b) alturas equilibradas. 44. 618 Sistemas de bases de datos automticamente sin necesidad de que el usuario introduzca ningn dato. Por el contrario, en Orac1e es responsabilidad del usuario crear y mantener los histogramas para las columnas apropiadas, utilizando de nuevo el paquete PL/SQL DBMS_STATS. Las columnas apropiadas son, normalmente, aquellas columnas que se utilicen dentro de la clusula WHERE de las instrucciones SQL y que tienen una distribucin no uniforme, como la columna rooms en el ejemplo anterior. 21.6.3 Visualizacin del plan de ejecucin Oracle permite visualizar el plan de ejecucin que el optimizador va a elegir utilizando el comando EXPLAIN PLAN. Este comando puede ser enormemente til si la eficiencia de una consulta no es la esperada. La salida de EXPLAIN PLAN se escribe en una tabla de la base de datos (la tabla predeterminada es PLAN_ TABLE). Las columnas principales de esta tabla son: STATEMENT _ID, el valor de un parmetro opcional STATEMENT _ID especificado en la instruccin EXPLAIN PLAN. OPERATION, el nombre de la operacin interna realizada. La primera fila sera la propia instruccin SQL: SELECT, INSERT, UPDATE o DELE TE. OPTIONS, el nombre de otra operacin interna realizada. OBJECT_NAME, el nombre de la tabla del ndice. ID, un nmero asignado a cada paso del plan de ejecucin. PARENT_ID, el identificador del siguiente paso que opera sobre la salida del paso ID. POSITION, el orden de procesamiento para aquellos pasos que tienen el mismo valor de PARENT _ID. COST, una estimacin de coste para la operacin (null para las instrucciones que utilicen el optimizador basado en reglas). CARDINALlTY, una estimacin del nmero de filas a las que accede la operacin. En la Figura 21.17 se muestra un plan de ejemplo. Cada lnea de este plan representa un nico paso en el plan de ejecucin. Se ha utilizado el sangrado de las lneas para mostrar el orden de las operaciones (observe que el valor ID de columna es insuficiente por s mismo para mostrar la ordenacin). SQL> EXPLAIN PLAN 2 SET STATEMENT_IO = 'PB' 3 FOR SELECT b.branchNo, b.city, propertyNo 4 FROM Branch b, PropertyForRent p 5 WHERE b.branchNo = p.branchNo 6 OROER BY b.city; Explained. SQL> SELECT 1011''IIPARENT_IOII' 'IILPAO(' ',2*(LEVEL - 1)1I10PERATIONII' '1I0PTIONSII 2 ' 'IIOBJECT_NAME "Query Plan" 3 FROM Plan_Table 4 START WITH ID = O ANO STATEMENT_IO = 'PB' 5 CONNECT BY PRIOR ID = PARENT_IO ANO STATEMENT_ID = 'PB'; Query Plan O SELECT STATEMENT 1 O SORT OROER BY 2 1 NESTEO LOOPS 3 2 TABLE ACCESS FULL PROPERTYFORRENT 4 2 TABLE ACCESS BY INOEX ROWIO BRANCH 5 4 INOEX UNIQUE SCAN SYS_C007455 6 rows selected. Figura 21.7. Salida de la utilidad Explain Plan. 45. Captulo 21 Procesamiento de consultas 619 Resumen del captulo Los objetivos del procesamiento de consultas son transformar una consulta escrita en un lenguaje de alto nivel, normalmente SQL, en una estrategia de ejecucin correcta y eficiente expresada en un lenguaje de bajo nivel, como, por ejemplo, el lgebra relacional, y ejecutar dicha estrategia para extraer los datos soli- citados. Puesto que hay muchas transformaciones equivalentes para una misma consulta de alto nivel, el SGBD tiene que elegir aquella que minimice el uso de recursos. Este es el objetivo de la optimizacin de consultas. Puesto que el problema es intratable desde el punto de vista computacional cuando hay un gran nmero de relaciones, la estrategia adoptada se reduce generalmente a determinar una solucin cercada a la ptima. Hay dos tcnicas principales de optimizacin de consultas, aunque las dos estrategias se suelen combinar en la prctica. La primera tcnica utiliza reglas heursticas que ordenan las operaciones de la consulta. La otra tcnica compara las diferentes estrategias basndose en sus costes relativos y selecciona aquella que minimiza el uso de recursos. El procesamiento de consultas puede dividirse en cuatro fases principales: descomposicin (compuesta de anlisis sintctico y validacin), optimizacin, generacin de cdigo y ejecucin. Las primeras tres fases pueden realizarse en tiempo de compilacin y en tiempo de ejecucin. La descomposicin de consultas transforma una consulta de alto nivel en una consulta de lgebra relacional y comprueba que dicha consulta sea sintctica y semnticamente correcta. Las etapas tpicas de la descomposicin de consultas son el anlisis, la normalizacin, el anlisis semntico, la simplificacin y la reestructuracin de la consulta. Puede utilizarse un rbol de lgebra relacional para proporcionar una representacin interna de la consulta transformada. La optimizacin de consultas puede aplicar reglas de transformacin para convertir una expresin de lgebra relacional en una expresin equivalente que se sepa que es ms eficiente. Entre las reglas de transformacin se incluyen la conexin en cascada de operaciones de seleccin, la conmutatividad de las operaciones unarias, la conmutatividad de la combinacin Theta (y del producto cartesiano), la conmutatividad de las operaciones unarias y de la combinacin Theta (y del producto cartesiano) y la asociatividad de la combinacin Theta (y del producto cartesiano). Entre las reglas heursticas se incluyen la realizacin de las operaciones de seleccin y proyeccin lo antes posible; la combinacin de un producto cartesiano con una seleccin subsiguiente cuyo predicado represente una condicin de combinacin en una operacin de combinacin; la utilizacin de la asociatividad de las operaciones binarias para reordenar los nodos hoja de modo que aquellos que tengan las selecciones ms restrictivas se ejecuten primero, etc. La estimacin de coste depende de la informacin estadstica recopilada del catlogo del sistema. Entre las estadsticas tpicas se incluye la cardinalidad de cada relacin base, el nmero de bloques requeridos para almacenar una relacin, el nmero de valores distintos para cada atributo, la cardinalidad de seleccin de cada atributo y el nmero de niveles en cada ndice multinivel. Las principales estrategias para implementar la operacin de seleccin son: bsqueda lineal (archivo no ordenado y no indexado), bsqueda binaria (archivo ordenado y no indexado), igualdad de clave hash, condicin de igualdad de clave principal, condicin de desigualdad de clave principal, condicin de igualdad de ndice (secundario) de clstering, condicin de igualdad de ndice (secundario) no de clstering y condicin de desigualdad en un ndice secundario de tipo B+-tree. Las principales estrategias para implementar la operacin de combinacin son: combinacin mediante bucle anidado por bloques, combinacin mediante bucle anidado indexado, combinacin mediante ordenacin-mezcla y combinacin hash. Con la tcnica de materializacin la salida de una operacin se almacena en una relacin temporal para su procesamiento por parte de la siguiente operacin. Otra tcnica alternativa consiste en procesar en cadena los resultados de una operacin, pasndolos a la operacin siguiente sin crear una relacin tempo- 46. 620 Sistemas de bases de datos ral donde se almacenen los resultados intermedios; esta tcnica de pipelining nos permite ahorramos el coste de crear relaciones temporales y de volver a leer los resultados. A un rbol de lgebra relacional donde la relacin del rbol derecho sea siempre una relacin base se le denomina rbol de profundidad izquierda. Los rboles de profundidad izquierda tienen las ventajas de reducir el espacio de bsqueda de la estrategia ptima y de permitir que el optimizador de consulta se base en tcnicas de procesamiento dinmico. Su principal desventaja es que, al reducir el espacio de bsqueda, no se toman en cuenta muchas estrategias de ejecucin alternativas, algunas de las cuales podran tener un coste menor que la determinada mediante un rbol lineal. Un aspecto fundamental para la eficiencia de la optimizacin de consultas es el espacio de bsqueda de las posibles estrategias de ejecucin y el algoritmo de enumeracin utilizado para buscar en este espacio una estrategia ptima. Para una consulta determinada, este espacio de bsqueda puede ser muy grande; como resultado, los optimizadores de consultas restringen dicho espacio mediante una serie de tcnicas. Por ejemplo, las operaciones unarias pueden procesarse sobre la marcha; los productos cartesianos nunca se forman a menos que la propia consulta lo especifique; el operando interno de cada combinacin es una relacin base, etc. El algoritmo de programacin dinmica se basa en la suposicin de que el modelo de coste satisface el principio de optimalidad. Para obtener la estrategia ptima para una consulta compuesta por n combinaciones, slo necesitamos considerar las estrategias ptimas para (n - 1) combinaciones y ampliar dichas estrategias con una combinacin adicional. Se crean clases de equivalencias basadas en las ordenaciones interesantes y se retiene la estrategia de menor coste dentro de cada clase de equivalencia para ponerla en consideracin en el siguiente paso, hasta construir toda la consulta, momento en que se selecciona la estrategia que tenga el menor coste global. Cuestiones de repaso 21.1. Cules son los objetivos del procesamiento de consultas? 21.2. En qu sentido difiere el procesamiento de consultas en los sistemas relacionales del procesamiento de lenguajes de consultas de bajo nivel para sistemas de red y jerrquicos? 21.3. Cules son las fases tpicas del procesamiento de consultas? 21.4. Cules son las etapas tpicas de la descomposicin de consultas? 21.5. Cul es la diferencia entre las formas normales conjuntiva y disyuntiva? 21.6. Como comprobara la correccin semntica de una consulta? 21.7. Indique las reglas de transformacin que pueden aplicarse a: (a) Operaciones de seleccin (b) Operaciones de proyeccin (c) Operaciones de combinacin Theta. 21.8. Indique las reglas heursticas que deberan aplicarse para mejorar el procesamiento de una consulta. 21.9. Qu tipos de estadsticas debe almacenar un SGBD para poder calcular estimaciones del coste de las operaciones de lgebra relacional? 21.10. En qu circunstancias tendr que utilizar el sistema una bsqueda lineal a la hora de implementar una operacin de seleccin? 21.11. Cules son las estrategias principales para implementar la operacin de combinacin? 21.12. Cules son las diferencias entre materializacin y pipelining? 21.13. Explique la diferencia entre rboles de lgebra relacionallineales y no lineales. Proporcione ejemplos para ilustrar su respuesta. 21.14. Cules son las ventajas y desventajas de los rboles de profundidad izquierda? 47. Captulo 21 Procesamiento de consultas 621 21.15. Describa cmo funciona el algoritmo de programacin dinmica del optimizador de consultas de System R. Ejercicios 21.16. Calcule el coste de las tres estrategias citadas en el Ejemplo 21.1 si la relacin 8taff tiene 10000 tuplas, si Branch tiene 500 tuplas, si hay 500 empleados con categora de Manager (uno por cada sucursal) y si hay 10 sucursales en Londres. 21.17. Utilizando el esquema Hotel dado al principio de los ejercicios del Captulo 3, determine si las siguientes consultas son semnticamente correctas: (a) SELECT rtype, r.price FROM Room r, Hotel h WHERE r.hotel_number = h.hotel_number AND h.hotel_name = 'Grosvenor Hotel' AND r.type > 100; (b) SELECT g.guestNo, g.name FROM Hotel h, Booking b, Guest 9 WHERE h.hotelNo = b.hotelNo AND h.hotelName = 'Grosvenor Hotel'; (c) SELECT r.roomNo, h.hotelNo FROM Hotel h, Booking b, Room r WHERE h.hotelNo = b.hotelNo AND h.hotelNo = 'H21' AND b.roomNo = r.roomNo AND type = 'S' AND bhotelNo = 'H22'; 21.18. Utilizando de nuevo el esquema Hotel, dibuje un rbol de lgebra relacional para cada una de las siguientes consultas y utilice las reglas heursticas dadas en la Seccin 21.3.2 para transformar las consultas en una forma ms eficiente. Explique cada paso y enuncie las reglas de transformacin usadas en el proceso. (a) SELECT r.roomNo, r.type, r.price FROM Room r, Booking b, Hotel h WHERE rroomNo = b.roomNo AND b.hotelNo = h.hotelNo AND h.hotelName = 'Grosvenor Hotel' AND r.price > 100; (b) SELECT g.guestNo, g.guestName FROM Room r, Hotel h, Booking b, Guest 9 WHERE h.hotelNo = b.hotelNo AND g.guestNo = b.guestNo AND h.hotelNo = r.hotelNo AND h.hotelName = 'Grosvenor Hotel' AND dateFrom >= '1-Jan-04' AND dateTo 200000; Por s~mplicidad, suponga que cada tupla de cada relacin tiene 100 caracteres de longitud, suponga tambin que hay 10 clientes con un precio mximo superior a 200.000 euros, que hay 100000 visitas a inmueb1es en Aberdeen y que el tiempo de procesamiento es despreciable comparado con el tiempo de comunicacin. Vamos a suponer tambin que el sistema de comunicaciones tiene una velocidad de transmisin de datos igual a 10000 caracteres por segundo y un retardo de acceso de un segundo para enviar un mensaje de un nodo a otro. Rothnie identifica seis posibles estrategias para esta consulta, como se resume en la Tabla 22.4. Utilizando el algoritmo para clculo del tiempo de comunicacin que hemos enunciado en la Seccin 22.2, p

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

Education

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