Optimizando tablas

[gnzsoloyo]

Te paso un segmento de un apunte de cátedra respecto de la eficiencia de las consultas, que te puede orientar acerca del porqué varía el comportamiento según la forma que la misma se realice:

Br = cantidad de bloques que ocupa R
V(A,r) = cantidad de valores distintos del atributo A en la relación R.
Lr = Longitud de una tupla

SUPUESTO : R tiene una distribución UNIFORME.

SELECT * FROM R WHERE A θ “a”

Donde θ es { = , < , > , >= , <=, <>}

Costos de lectura: (CL)

a) Si Existe Indice agrupado (cluster) en A = ”a” entonces CL = Br / V(A,r)
b) Si existe Indice no agrupado (no cluster) en A = “a” entonces CL = Tr / V(A,r)
c) Si Existe Indice agrupado (cluster) en A ψ ”a” entonces CL = Br / 2 donde ψ es { < , > , <= , >= }
d) Si existe Indice no agrupado (no cluster) en A ψ “a” entonces CL = Tr / 2 donde ψ es { < , > , <= , >= }
e) Si no existe ningún índice entonces CL = Br

Ejemplo:
SELECT Np FROM proveedor WHERE ciudad = "M" ;

Datos:
Tr = 200 tuplas
Fb = 10 tuplas/ bloque
V(ciudad,proveedor) = 10

Si se cuenta con un índice cluster por ciudad, entonces el CL = Br / V(A,r)

Calculo de Br:
Br = Tr / fb = 200 tuplas / 10 tuplas/ bloque = 20 bloques.

El costo de lectura de la selección es de 2 accesos a bloque, o sea que es recomendable crear un índice cluster por ciudad para mejorar la performance.

A) ESTIMACIÓN DEL TAMAÑO DEL OUTPUT
PRODUCTO CARTESIANO
R X S = Tr . Ts

JUNTA NATURAL
R |X| S
Si R ∩ S = ∅ entonces Tr . Ts
Si R ∩ S = { clave de R } entonces <= Ts
Si R ∩ S = { clave de S } entonces <= Tr
Si R ∩ S = { atributo no clave } entonces Tr . Ts / V(A, r ) ó Tr .Ts / V(A,s)

Como verás, no es lo mismo consultar por "= "que por un LIKE, ni tampoco un índice cluster que uno no cluster (recordando que los índices cluster o densos contienen una alta selectividad y representan a los índices primarios, es decir aquellos que guardan la info física de los registros y sólo hay uno por tabla).