OPTIMIZACION DE CONSULTAS

INTRODUCCIN 2

2. EJEMPLO DE LA PROBLEMTICA DE OPTIMIZACIN.

3. DONDE INCIDE LA OPTIMIZACIN?.

4. EL PROCESO DE OPTIMIZACIN. 4.1. 4.2. 4.2.1. 4.3. 4.4. REPRESENTACIN INTERNA DE CONSULTAS. CONVERSIN A FORMA CANNICA. REGLAS DE TRANSFORMACIN. ELECCIN DE PROCEDIMIENTOS DE BAJO NIVEL. GENERACIN Y ELECCIN DE PLANES DE CONSULTA.

4 5 6 6 13 14 14

5. OTRAS CUESTIONES EN OPTIMIZACIN DE CONSULTAS.

6. ALGUNOS OPTIMIZADORES COMERCIALES. 6.1. 6.2. 6.3. 6.3.1. SYSTEM R DB2. INGRES. INGRES ACADMICO.

14 15 17 18 18 21 21 21 25 27

7. DISEO ORIENTADO A LAS PRESTACIONES. 7.1. 7.2. 7.3. INTRODUCCIN. DESNORMALIZACIN. PARTICIONAMIENTO DE RELACIONES.

BIBLIOGRAFIA

Introduccin
La optimizacin de consultas es el proceso por el cual se pretende mejorar los tiempos de respuesta en un sistema de gestin de bases de datos relacional. Hay que tener en cuenta que los lenguajes de consulta relacionales son no procedimentales, es decir, que el usuario solo indica cual es el resultado que desea obtener y no el camino de acceso en la base de datos para llegar a dicho resultado. Esta navegacin automtica permite el desarrollo de sistemas que evalen y mejoren las sentencias de consulta realizadas por los usuarios. Debido a que esta posibilidad de mejora de especificacin de consultas slo es posible en los SGBDR, algunos autores consideran que un sistema de bases de datos slo se puede considerar relacional si tienen optimizador. Hay que tener en cuenta que el proceso de optimizacin tiene que evaluar no solamente cual consulta es algebraicamente ms correcta, sino tambin si dicha consulta no sobrecarga los recursos del sistema. Por tanto la palabra optimizador no sera la ms correcta (aunque es la mas extendida) sino planificador de consultas.

2.

Ejemplo de la problemtica de optimizacin.

Para dar una idea de la necesidad y el potencial de la optimizacin en los SGBDR tomaremos como ejemplo las tablas S y SP de suministradores y pedidos con 100 suministradores y 10000 pedidos y la consulta obtener los nombres de los suministradores que sirven la pieza P2. Consideraremos que solo 50 tuplas de SP corresponden a la pieza P2. Una posible solucin SQL sera:

SELECT DISTINCT S.NOMBRE FROM S, SP WHERE S.S#=SP.S# AND SP.P#=P2; Los pasos a seguir por un sistema sin optimizador seran: 1.Calcular el producto cartesianos de S y SP. Este paso implica 100 lecturas de cada una de las 10000 tuplas de SP, en total 1000000 lecturas de tuplas que, probablemente, no quepan en memoria y por tanto implique 1000000 escrituras de tuplas. 2. Realizar la seleccin segn la condicin especificada en la clusula WHERE, lo que implica la lectura de 1000000 tuplas, dejando el resultado reducido a 50 tuplas, que en este caso cabran en memoria. 3. Realizar la proyeccin sobre S.NOMBRE, dando como resultado un mximo de 50 tuplas. Otro procedimiento para la misma consulta, es decir con el mismo resultado o algebraicamente equivalente sera: 1. Seleccionar en SP las tuplas de la pieza P2. Esto implicara la lectura de 10000 tuplas, pero produce una tabla de slo 50 tuplas, que puede caber en memoria principal.

2. Realizar el JOIN de la tabla anterior con la tabla S mediante S#. Esto implica la lectura de slo 100 tuplas. El resultado contiene 50 tuplas que siguen en memoria principal. 3. Proyeccin sobre S.NOMBRE con un resultado de un mximo de 50 tuplas. Si consideramos rendimiento como en nmero de operaciones de E/S de tuplas, el segundo procedimiento es unas 300 veces mejor que el primero, ya que el primero realiza 3000000 operaciones de E/S frente a 10100 del segundo.

3.

Donde incide la optimizacin?.

Los procesos de optimizacin tienen que tener en cuenta el funcionamiento global de la Base de Datos y por tanto, una posible optimizacin de una consulta tendr que contar con la sobrecarga que pueda producir al sistema y no solo con la eficiencia de dicha consulta en particular. Para ello los mtodos de optimizacin debern incidir en los siguientes puntos: El coste de comunicacin de acceso a almacenamiento secundario. El coste de almacenamiento. El coste de computacin. Estos elementos variarn segn la arquitectura de la base de datos (centralizada frente a distribuida), la capacidad de memoria principal, las caractersticas del procesador o procesadores y la configuracin del sistema. Para ello el optimizador contar con las siguientes caractersticas: Informacin estadstica tal como cardinalidad de tablas y de dominios. Independencia de las estrategias de acceso con respecto de la organizacin fsica de la base de datos. Potencia de clculo en la toma de decisiones frente a la optimizacin manual. Disponibilidad del optimizador para todos los usuarios del sistema. El optimizador interviene no solo en los procesos de consulta, sino tambin en las actualizaciones y borrados.

4.

El proceso de optimizacin.

Las etapas principales el proceso de optimizacin sern las siguientes: 1. 2. 3. 4. Representacin interna de consultas. Conversin a forma cannica. Eleccin de procedimientos de bajo nivel. Generacin y eleccin de planes de consulta.

4.1.

Representacin interna de consultas.

En esta etapa se pretende conseguir una representacin de la consulta independiente del lenguaje de acceso utilizado. La representacin interna deber cumplir las siguientes caractersticas: Ser relacionalmente completo. Suministrar un punto de partida solido para las siguientes fases. Proporcionar un grado de libertad suficiente para realizar las posibles optimizaciones. Los sistemas de representacin mas extendidos son: lgebra relacional, clculo relacional (orientado a tuplas o a dominios) y el rbol sintctico abstracto o rbol de consulta. resultado Proyectar (SNOMBRE) Seleccin (SP.P#=P2) Join (S,SP)

Ejemplo de rbol de consulta para la consulta obtener los nombres de los proveedores que suministran la pieza P2. En el desarrollo de este tema utilizaremos el lgebra relacional como sistema de representacin interna, teniendo en cuenta slo los operadores bsicos del lgebra relacional. Con estas condiciones, la operacin de JOIN se expresar como un producto cartesiano y a continuacin una seleccin. La consulta anterior se expresar entonces de la forma:

SNOMBRE (P#=P2 (S.S#=SP.S# (S X SP)))

4.2.

Conversin a forma cannica.

En esta fase se realizan unas optimizaciones previas que tienen un resultado positivo seguro. Estas optimizaciones se basan en que la mayora de los lenguajes de consulta de sistemas relacionales permiten expresar una misma consulta de varias formas distintas. Se trata, por tanto, de encontrar una expresin equivalente de una consulta dada en la que se mejore de alguna manera el rendimiento. Esta expresin equivalente ser la FORMA CANONICA de dicha consulta.

4.2.1. Reglas de transformacin. El paso del resultado de la primera fase a la forma cannica correspondiente se realiza mediante un conjunto de reglas de transformacin bien definidas que son las siguientes: 1. Cascada de proyecciones: Si {A1,...,An} {B1,...,Bm}, entonces:

A1...An(B1...Bm (R)) = A1...An (R)

2. Cascada de selecciones:

c1(c2(R)) = c1 and c2 (R)

3. Conmutacin de selecciones: Como se cumple que c1 and c2 = c2 and c1, entonces:

c1(c2(R)) = c2(c1(R))
4. Conmutacin de seleccin y proyeccin: Si c involucra atributos slo de A1,...,An, entonces:

A1...An(c (R)) = c(A1...An (R))

5. Conmutacin general de seleccin y proyeccin: Si c involucra a los atributos B1,...,Bm que no estn entre los A1,...,An, entonces:

A1...An(c (R)) = A1...An(c(A1...AnB1...Bm (R)))

6. Conmutacin de seleccin y producto cartesiano (I): Si todos los atributos que aparecen en c son atributos de R1, entonces:

c(R1 X R2) = (c(R1)) X R2

7. Conmutacin de seleccin y producto cartesiano (II): Si c es de la forma c1 and c2, donde c1 involucra slo atributos de R1 y c2 involucra slo de R2, entonces:

c1 and c2 (R1 X R2) = ( c1 (R1)) X ( c2 (R2))

8. Conmutacin de seleccin y producto cartesiano (III): Si c es de la forma c1 and c2, donde c1 involucra slo atributos de R1 y c2 involucra atributos de c1 y c2, entonces:

c1 and c2 (R1 X R2) = c2(c1(R1) X R2)

9. Conmutacin de seleccin y unin: Una seleccin sobre una unin equivale a dos selecciones y una unin.

c (R1 R2) = c (R1) c(R2)

10. Conmutacin de seleccin y diferencia: Una seleccin sobre una diferencia equivale a dos selecciones y una diferencia.

c (R1 - R2) = c (R1) - c(R2)

11. Conmutacin de proyeccin y producto cartesiano: Sea {A1,...,An} un conjunto de atributos de los que los k primeros son de R1 y los restantes de R2, entonces:

A1...An (R1 X R2) = A1...Ak (R1) X Ak+1...An (R2)

7

12. Conmutacin de proyeccin y unin: Una proyeccin de una unin equivale a una unin de dos proyecciones.

A1...An (R1 R2) = A1...An (R1) A1...An (R2)

Estas transformaciones van dirigidas a conseguir que las tablas se vean reducidas en su tamao antes de la realizacin de JOIN de manera que se realicen menos operaciones de lectura/escritura de tuplas y buscando mantener los resultados parciales en memoria, sin que se tengan que volcar la informacin a disco. Las estrategias generales de optimizacin sern las siguientes: 1. Realizar las selecciones tan pronto como sea posible. 2. Combinar ciertas selecciones con un producto cartesiano anterior, para realizar una asociacin o un JOIN. 3. Combinar secuencias de operaciones unarias, como selecciones y proyecciones. 4. Detectar subconsultas con resultados equivalentes que puedan reutilizarse a lo largo de una misma consulta. 5. Mediante cascada de selecciones, sustituir una seleccin compuesta en varias simples. 6. Mediante sus propiedades, desplazar cada seleccin simple lo ms abajo posible del rbol. 7. Mediante sus propiedades, desplazar las proyecciones lo ms abajo posible del rbol. 8. Usar las propiedades de proyeccin y seleccin para combinar cascadas de proyecciones y selecciones en una seleccin sencilla, una proyeccin sencilla o una seleccin seguida de una proyeccin. Con esta estrategia se persigue hacer todas las proyecciones y a continuacin todas las selecciones que afecten a una misma relacin en vez de alternar dichas operaciones. 9.Dividir los nodos interiores del rbol resultante en grupos de la siguiente manera: Todo nodo interior que presenta una operacin binaria estar en un grupo junto con sus antecesores correspondientes a una operacin unaria. El grupo

incluir tambin toda cadena de descendientes correspondientes a operaciones unarias y que terminan en una hoja del rbol; excepto en el caso en el que la operacin binaria sea un producto cartesiano no seguido de una seleccin para formar un JOIN. 10.Evaluar cada grupo en cualquier orden, siempre que se respete la jerarqua del rbol. EJEMPLO: Sea la Base de Datos con las siguientes relaciones: P (P#,DESC,FAB) P: Pieza C (C#,NOM,DIR,CIUDAD) C: Cliente PE (P#,C#,CANT) PE: Pedido Se plantea la consulta siguiente: Obtener la descripcin de las piezas servidas en una cantidad superior a 100 unidades a los clientes de Madrid Esta consulta se expresar en lgebra relacional como:

DESC (CANT>100 and CIUDAD=MADRID (P * C * PE))

Para realizar la optimizacin expresaremos el JOIN como producto cartesiano y seleccin, quedando una expresin de la forma:

DESC (CANT>100 and CIUDAD=MADRID (P.P#=PE.P# and C.C#=PE.C# (P X C X PE)))

El rbol correspondiente sera: resultado

DESC CANT>100 and CIUDAD=MADRID P.P#=PE.P# and C.C#=PE.C#

X X P

PE

El primer paso consiste en separar las selecciones compuestas en selecciones simples, por lo tanto CANT>100 and CIUDAD=MADRID se descompone en CANT>100 y CIUDAD=MADRID. La seleccin correspondiente al JOIN: P.P#=PE.P# and C.C#=PE.C# se descompone en P.P#=PE.P# y C.C#=PE.C#. De esta forma se podrn desplazar lo ms abajo posible en el rbol. La seleccin correspondiente a CANT>100 puede desplazarse hasta PEDIDO aplicando la propiedad 6. La seleccin correspondiente a CIUDAD=MADRID puede desplazarse hasta CLIENTE aplicando la propiedad 6. Las selecciones correspondientes al JOIN pueden desplazarse de la siguiente forma: la correspondiente a C.C#=PE.C# se conmuta con el producto cartesiano inmediatamente inferior. La seleccin correspondiente a P.P#=PE.P# no puede conmutarse por hacer referencia a atributos de diferentes relaciones. El rbol quedara entonces de la forma: resultado

DESC P.P#=PE.P#
X

C.C#=PE.P#
X

CANT>100
PE

CIUDAD=MADRID
C

10

A continuacin, por la propiedad 5, podemos sustituir

DESC y P.P#=PE.P# por DESC P.P#=PE.P# DESC,P.P#,PE.P#

La propiedad 11 permite conmutar DESC,P.P#,PE.P# con el producto cartesiano inmediatamente inferior de la siguiente forma:

DESC,P.P# sobre P y PE.P# sobre el resultado de C.C#=PE.C#.

El rbol quedara entonces de la forma:

resultado

DESC P.P#=PE.P#
X

PE.P# C.C#=PE.P#
X

DESC,P.P#
P

CANT>100
PE

CIUDAD=MADRID
C

11

De forma anloga a la anterior y por la propiedad 5, podemos sustituir

PE.P# y C.C#=PE.C# por PE.P# C.C#=PE.C# PE.P#,C.C#,PE.C#

La propiedad 11 permite conmutar PE.P#,C.C#,PE.C# con el producto cartesiano inmediatamente inferior de la siguiente forma:

PE.C#,PE.P# sobre el resultado de CANT>100 y C.C# sobre el resultado de CIUDAD=MADRID.

El rbol optimizado quedara de la forma:

resultado

DESC P.P#=PE.P#
X

PE.P# C.C#=PE.P#
X

DESC,P.P#
P

PE.P#,PE.C#

C.C#

12

CANT>100
PE

CIUDAD=MADRID
C

4.3.

Eleccin de procedimientos de bajo nivel.

En esta etapa el optimizador debe decidir cmo evaluar la consulta previamente transformada, basndose en elementos tales como: Existencia de ndices u otras rutas de acceso. Distribucin de los valores de los datos almacenados. Agrupamiento fsico de los registros. El optimizador considerar la consulta como un conjunto de expresiones de bajo nivel (join, seleccin, etc.) con ciertas interdependencias entre ellas. Ejemplo: Para la eliminacin de valores repetidos, una proyeccin requerir que los valores estn en un cierto orden, cosa que deber cumplir como resultado la consulta inmediatamente anterior. El optimizador tendr una serie de procedimientos predefinidos para realizar cada una de esta operaciones de bajo nivel segn la situacin de los datos. Ejemplo: Para una operacin de join, un optimizador podr tener los siguientes procedimientos disponibles: Un procedimiento para el caso en que la condicin sea a travs de una clave candidata. Un procedimiento para el caso en que el campo de restriccin (en alfa unin) est indexado. Un procedimiento para el caso en que el campo de restriccin no est indexado pero s agrupados los datos fsicamente. Cada uno de los procedimientos tendr asociado una medida de coste. Basndose en la informacin contenida en el catlogo del sistema el optimizador elegir uno o mas procesos candidatos para pasar a continuacin a la generacin y eleccin del plan de consulta ms apropiado.

13

4.4.

Generacin y eleccin de planes de consulta.

La generacin de los distintos planes de consulta se realiza mediante la combinacin de los procedimientos de bajo nivel candidatos, uno por cada consulta. Hay que tener en cuenta que los planes de consulta generados pueden tener un nmero considerable, por lo que puede no ser conveniente generarlos todos. Si el nmero de planes generados es muy elevado, el proceso de seleccin puede ser retrasado. La eficiencia de un optimizador depender, por tanto, de la eficacia de la tcnica heurstica empleada para la generacin de planes de consulta. La estimacin de costos de un plan depender de: El n de operaciones de E/S de disco requeridas. Utilizacin de CPU. El problema est en que una consulta suele implicar la generacin de resultados intermedios. Esto hace que la estimacin de las operaciones de E/S depender del tamao de las tablas con estos resultados, lo cual depende mucho de los valores reales de los datos.

5.

Otras cuestiones en optimizacin de consultas.

Dentro del panorama general de las tcnicas de optimizacin, hay que tener en cuenta casos particulares como: Optimizacin en mquinas multiprocesador (la generacin de planes de consulta para su ejecucin en paralelo). Optimizacin en BD distribuidas (otra forma de resolver la cosas). Optimizacin en BD deductivas y sistemas expertos de gestin.

6.

Algunos optimizadores comerciales.

Como aplicacin de los conceptos anteriores veremos los casos de algunos productos comerciales como SYSTEM R, DB2 e INGRES.

14

6.1.

SYSTEM R

Estudiaremos SYSTEM R como precusor del optimizador de DB2. SYSTEM R optimiza consultas SQL con la siguiente aproximacin: 1. Eleccin del orden de ejecucin de cada uno de los bloques SQL. 2. Eleccin de las operaciones menos costosas para cada bloque SQL. (Esto hace que se reduzca el n de planes generados a evaluar) Para cada bloque SELECT-FROM-WHERE se consideran dos casos: 1. Si el bloque implica nicamente una seleccin y/o proyeccin en una sola tabla, el optimizador emplea la siguiente informacin del catlogo del sistema: Nmero de tuplas de la tabla. Nmero de pginas ocupadas por la tabla. % de la Base de Datos correspondiente a la tabla. Nmero de valores distintos de cada ndice. Nmero de pginas ocupadas por cada ndice.

Hay que tener en cuenta que estos datos, por cuestiones de utilizacin de la Base de Datos, slo se actualizan por mandato expreso del DBA mediante UPDATE STATISTICS. (El n de valores distintos por columna slo se puede utilizar si se encuentra indexada). 2. Si un bloque realiza el JOIN de dos o ms tablas con selecciones y/o proyecciones individuales sobra cada una de las tablas, el optimizador sigue los siguientes pasos: a).Trata cada tabla como en el caso 1. b).Decide en que secuencia se realizar el JOIN. El paso a) se realiza para elegir en cada caso un procedimiento de bajo nivel que d como resultado una tabla con las caractersticas idneas para el JOIN con la siguiente tabla. Cuando se da el caso de un conjunto de tablas sobre las que se va a realizar un JOIN, por ejemplo, una expresin del tipo: A JOIN B JOIN C JOIN D

El optimizador realizar las operaciones de forma estrictamente anidada, por ejemplo de la forma:
15

((D JOIN C) JOIN A) JOIN B Y nunca de la forma: (A JOIN B) JOIN (C JOIN D) Esto permite reducir el n de distintos planes de consulta generados. Los dos mtodos utilizados para realizar un JOIN binario (A JOIN B) son el de Ciclo

Algoritmo de Ciclo Anidado:

para cada tupla de A hacer obtener tupla-A; recorrer la tabla B buscando tuplas-B que concuerden con esa tupla-A; para cada tupla-B hacer obtener tupla-B; construir tupla-AB; terminar; terminar;

Este algoritmo solo es ptimo en algunos casos, por ejemplo cuando la tabla B es pequea y la A es grande, de manera que el recorrido reiterado de la tabla B no consuma muchos recursos, frente a la ordenacin preliminar de la tabla A. Algoritmo de Clasificacin/Fusin: Para que este algoritmo sea aplicable de forma eficiente tanto A como B tienen que estar ordenadas (fsicamente o por ndice) por el atributo comn del join. De esta manera, se puede sincronizar el recorrido de ambas tablas y por tanto realizar un solo recorrido de cada una. Adems la sincronizacin de los recorridos nos permitir en algunos casos no tener que recorrer ambas tablas en su totalidad. Sean R y S dos relaciones de cardinalidad m y n respectivamente y ordenadas segn el atributo A, el algoritmo de clasificacin/ fusin para M:N sera:
comienzo r:=1 s:=1

16

mientras r < m y s < n hacer v:=R[r].A j:=s mientras S[j].A < v hacer j:=j+1 terminar s:=j mientras S[j].A = v hacer i:=r mientras R[i].A = v hacer Aadir R[i] * S[j] al resultado i:=i+1 terminar j:=j+1 terminar s:=j i:=r mientras R[i].A = v hacer i:=i+1 terminar r:=i terminar fin.

La ventaja principal de esta aproximacin es que para una consulta del tipo (A JOIN B) JOIN C, cuando se consigue una tupla de A JOIN B, se pasa a formar las tuplas correspondientes con C. De esta manera puede no ser necesario realizar completamente el join de A y B. 6.2. DB2.

El optimizador de DB2 es un sistema evolucionado de SYSTEM R, en el que las principales diferencias se encuentran en: Informacin estadstica sobre columnas aunque no estn indexadas. Transformacin de subconsultas en joins. (esto plantea el problema adicional de los valores duplicados) ejemplo: SELECT nombre FROM empleados WHERE n# IN (SELECT n# FROM bajas); se transforma en: SELECT nombre FROM empleados,bajas where empleados.n#=bajas.n#;

17

6.3.

INGRES.

Dividiremos el estudio del optimizador INGRES en dos aproximaciones: INGRES acadmico e INGRES comercial.

6.3.1. INGRES acadmico. La estrategia bsica de optimizacin es la descomposicin de consultas. Esta estrategia se basa en la separacin de una consulta en la que aparecen varias variables de tupla en una secuencia de consultas ms pequeas con una o dos variables. Esta descomposicin se realiza mediante dos mtodos: separacin y sustitucin de tuplas. Separacin: proceso de eliminar un componente de la consulta que slo tenga en comn una variable con el resto de la consulta, llevar este proceso hasta el punto en que no se pueden reducir mas una consulta se denomina reduccin. Sustitucin: proceso de sustituir, de tupla en tupla, una de las variables de consulta. Este proceso corresponde al algoritmo de ciclos anidados. Como ejemplo, estudiaremos la descomposicin y sustitucin de la siguiente consulta expresada en QUEL: Obtener los nombres de los proveedores de Londres que suministren alguna pieza roja con peso menor de 25 kilos y en cantidad superior a 200 unidades
C0: RETRIEVE (S.SNOMBRE) WHERE S.CIUDAD = LONDRES AND S.S# = SP.S# AND SP.CANT > 200 AND SP.P# =P.P# AND P.COLOR = ROJO AND P.PESO < 25

Los diferentes pasos de descomposicin son los siguientes: Se realiza una descomposicin en la tabla temporal P con los cdigos de pieza correspondientes al color ROJO y peso menor de 25 kilos. La variable comn que se separa es P.

18

1.

S1: RETRIEVE INTO P (P.P#) WHERE P.COLOR = ROJO AND P.PESO < 25 C1: RETRIEVE (S.SNOMBRE) WHERE S.CIUDAD = LONDRES AND S.S#=SP.S# AND SP.CANT > 200 AND SP.P# = P.P#

2.

S2: RETRIEVE INTO SP (SP.S#, SP.P#) WHERE SP.CANT > 200 C2: RETRIEVE (S.SNOMBRE) WHERE S.CIUDAD = LONDRES AND S.S# = SP.S# AND SP.P# = P.P#

3.

S3: RETRIEVE INTO S (S.S#, S.SNOMBRE) WHERE S.CIUDAD = LONDRES C3: RETRIEVE (S.SNOMBRE) WHERE S.S# = SP.S# AND SP.P# = P.P#

4.

S4: RETRIEVE INTO SP (SP.S#) WHERE SP.P# = P.P# C4: RETRIEVE (S.SNOMBRE) WHERE S.S# = SP.S#

El rbol de descomposicin asociado a la consulta C0 es el siguiente:

resultado global Q4 S D3 SP P D1 P D4 SP D2 SP

En la consulta C4 se puede realizar la sustitucin en los siguientes trminos: El conjunto de proveedores correspondientes a SP.P# corresponde a los valores (por ejemplo) (S1,S2,S4) por lo que la consulta C4 sera equivalente a:

19

RETRIEVE (S.SNOMBRE) WHERE S.S# = S1

OR S.S#=S2
OR S.S#=S4

La descripcin detallada de los algoritmos correspondientes a esta estrategia de optimizacin aparece en Decomposition. A strategy for Query Processing de Eugene Wong y Karel Youssefi. Universidad de California, Berkeley. En este articulo se definen los algoritmos recursivos, divididos en cuatro funciones principales: reduccin, secuenciado de subconsultas, sustitucin de tuplas y seleccin de variables. La utilidad de estas tcnicas de optimizacin viene corroborada por mediciones experimentales de las cuales se extraen las siguientes conclusiones: 1. La descomposicin es el mejor paso inicial. 2. Si es preciso realizar primero una sustitucin, la mejor opcin es sustituir una variable que participe en un JOIN. 3. Si se realiza la sustitucin de una variable en una consulta de dos variables, es muy rentable indexar la otra relacin por el atributo de JOIN. 6.3.2. INGRES comercial. Las diferencias principales entre INGRES acadmico y comercial son las siguientes: 1. El optimizador acadmico utiliza planificacin por pasos. El siguiente paso en el plan de optimizacin se decide en base a los resultados del paso anterior. El optimizador comercial prepara un plan de optimizacin completo basndose en el tamao de los resultados intermedios. 2. El optimizador acadmico utiliza la tcnica de sustitucin de tuplas. El comercial utiliza adems la tcnica de clasificacin/fusin. 3. El optimizador acadmico utiliza informacin estadstica de el nmero de tuplas de las tablas y el nmero de pginas ocupadas por estas. El comercial utiliza adems datos estadsticos como los valores mximos, mnimos y medios para cada atributo y distribuciones de los valores de un atributo. 4. El optimizador acadmico reduce el espacio de bsqueda de un plan de optimizacin mediante la optimizacin por pasos. El comercial realiza una bsqueda mas exhaustiva que se detiene cuando el tiempo invertido en dicha bsqueda supera el mejor tiempo estimado hasta el momento.

20

5. El optimizador comercial adems tiene en cuenta todas las combinaciones de ndices posibles, todas las secuencias de JOIN posibles y todos los mtodos de JOIN disponibles.

7.
7.1.

Diseo orientado a las prestaciones.

Introduccin.

En este apartado estudiaremos las tcnicas de desnormalizacin y particionamiento de relaciones usadas en el diseo de un esquema orientado a a las prestaciones. Estas tcnicas introducen deliberadamente redundancia e inconsistencias potenciales, y por tanto, son tcnicas que se deben utilizar como ltimo recurso cuando los tiempos de respuesta son inaceptables. Estudiaremos las tcnicas de datos duplicados, derivados, vectores de datos y la utilizacin de claves subrogadas. La desnormalizacin esta orientada a la mejora de los tiempos de respuesta en consultas, pero tiene efectos indeseados en las operacines de actualizacin y borrado, ya que aaden procesos extra para el mantenimiento de los datos redundantes. Las consideraciones que tendremos en cuenta para aplicar estas tcnicas son: 7.2. La tasa de actualizaciones con respecto a recuperaciones. Las veces que se accede conjuntamente a los atributos. El tamao de los atributos. El tipo de proceso (Batch/On Line) La prioridad de los procesos. El tamao de las tablas. Desnormalizacin.

La desnormalizacin consta de un conjunto de tcnicas que pueden ser aplicadas al diseo para mejorar el rendimiento de las consultas. Todas las tcnicas de desnormalizacin crean alguna forma de redundancia de datos.

21

Toda desnormalizacin ser funcionalmente dependiente del proceso de consulta que se quiere mejorar, y por tanto, disminuir la independencia entre procesos y datos. Si la consulta cambia, entonces el diseo del esquema tendr que ser revisado y eventualmente cambiado. Por estas razones, la desnormalizacin no se debe aplicar sin un detallado estudio previo.

Hay cuatro tcnicas en la desnormalizacin: Datos duplicados: cuando atributos individuales se introducen de forma redundante para reducir el nmero de tuplas que deben ser revisadas en una consulta. Ejemplo: Teniendo un esquema de BD en el que aparecen dos tablas correspondientes a los datos de unos clientes y sus correspondientes pedidos, queremos mejorar los tiempos de respuesta de una consulta de pedidos con los correspondientes nobres de los clientes.

PEDIDO N pedido fecha N cliente

CLIENTE N cliente nombre direccin

Tablas normalizadas. El acceso a disco para recuperar el nombre del cliente puede ser eliminado mediante la insercin del atributo nombre en la tabla PEDIDO.

PEDIDO N pedido fecha N cliente nombre

CLIENTE N cliente nombre direccin

22

 Datos derivados: Cuando se introducen atributos para valores calculados, para reducir el nmero de tuplas accedidas al realizar un determinado clculo. Ejemplo: Teniendo un esquema de BD en el que aparecen dos tablas correspondientes a los datos de productos, clientes y sus correspondientes pedidos, queremos mejorar los tiempos de respuesta de una consulta de facturacin de clientes.

PRODUCTO Nproducto descripcin precio

PEDIDO Npedido fecha Ncliente cantidad

CLIENTE Ncliente nombre direccin

Tablas normalizadas. El acceso a disco para recuperar los totales de cliente puede ser eliminado mediante la insercin del atributo T_Productos y Facturacin en la tabla CLIENTE.

PRODUCTO Nproducto descripcin precio

PEDIDO Npedido fecha Ncliente cantidad

CLIENTE Ncliente nombre direccin Tot_productos Facturacin

23

 Claves subrogadas: Cuando se introducen claves artificiales en el diseo, para sustituir la clave original en el caso de que sta sea grande o ineficiente.

Ejemplo: Teniendo el esquema correspondiente a una base de datos de publicaciones con una jerarqua 1:N para todas las relaciones, la clave para la tabla ELEMENTO viene dada por la herencia de las distintas claves de la jerarqua. La recuperacin de una tupla determinada de ELEMENTO estar dificultada por el tamao de la clave de esta tabla.
PUBLICACION NPub. EDITORIAL NPub. NEdit. SECCION NPub. NEdit. NSecc. PAGINA Npub. NEdit. NSecc. NPag. ELEMENTO Npub. Nedit. NSecc. NPag. NElem.

Vector de datos: cuando un atributo multivaluado se implementa con un slo atributo o conjunto de atributos en el esquema. Ejemplo: Teniendo un esquema de BD en el que aparecen dos tablas correspondientes a socios y las cantidades pagadas mensualmente a lo largo de un ao por estos, queremos obtener la informacin de cada uno de ellos con las cantidades correspondientes.

24

PAGOS mes Nsocio Dir

SOCIOS Nsocio nombre Dir.

Tablas normalizadas.
SOCIOS Nsocio nombre Enero Febrero Marzo Abril Mayo Junio Julio Agosto Septiembre Octubre Noviembre Diciembre

Tabla desnormalizada mediante vector de datos. 7.3. Particionamiento de relaciones.

El particionamiento horizontal de relaciones persigue la reduccin de las relaciones sobre las que se realizan las consultas. El particionamiento horizontal se basa en las operaciones de seleccin y unin dando como resultado relaciones unin compatible relativas a una relacin inicial. La estrategia de acceso en los SGBDR en estos casos se basa en tcnicas de SQL dinmico.

25

La tcnica de particionamiento horizontal divide una relacin de la siguiente forma: relacin inicial
a1 v11 v21 ... vn1 a2 v12 v22 ... vn2 a3 v13 v23 ... vn3 ... am ... ... ... ... v1m v2m ... vnm

a1 v11 v21 ... vj1

a2 v12 v22 ... vj2

a3 v13 v23 ... vj3

... am ... ... ... ... v1m v2m ... vjm

a1 vk1 vl1 ... vn1

a2 vk2 vl2 ... vn2

a3 vk3 vl3 ... vn3

... am ... ... ... ... vkm vlm ... vnm

relaciones resultantes.

26

BIBLIOGRAFIA
C.J. Date. Introduccin a los sistemas de Bases de Datos. Volumen 1, quinta edicin. Ed. Addison-Wesley Iberoamericana, 1993. Adoracin de Miguel, Mario Piattini. Concepcin y diseo de Bases de Datos Ed. ra-ma, 1993. John Kirkwood. High Perfomance Relatinal Databases Design. Ed. Ellis Horwood, 1993. A. V. Aho, Y. Sagiv y J. D. Ullman. Efficient Optimization of a Class of Relational Expressions. Ed. ACM TODS, Vol. 4, N 4, December 1979, Pages 435-454. Eugene Wong y Kerel Youssefi. Decomposition, a strategy for Query Processing Ed. ACM TODS, Vol1, N 3, September 1976, Pages 233-241. Angel Garca Moreno Tesis doctoral Optimizacin de accesos a Bases de Datos Relacionales: un enfoque desde el punto de vista algebraico. Biblioteca de la Facultad de Informtica de la UPM. Madrid, septiembre 1987.

27