La mayoría de los sistemas de Data Warehouse relacionales (ROLAP) se diseñan sobre modelos en estrella, que a nivel físico consisten en tablas centrales de hechos, que agrupan los atributos e indicadores de negocio que se han de mostrar en los informes y análisis, cada una de ellas enlazada con tablas de dimensiones que contienen los datos que van a servir para agrupar o mostrar esos indicadores bajo diferentes puntos de vista.
Las tablas de dimensiones no suelen contener datos históricos, y normalmente su tamaño es insignificante comparado con el tamaño de las tablas de hechos. Las tablas de dimensiones están unidas a la tabla de hechos por una relación 'de 1 a muchos', y la tabla de hechos suele tener definida al menos una clave foránea para cada relación con una dimensión.
En este contexto, con características tan especiales y bien definidas, que el optimizador de la base de datos 'sepa' que va a realizar una query sobre este tipo de estructura puede ser de gran ayuda, ya que las variables que se tienen en cuenta para preparar los planes de acceso en un modelo relacional normalizado no siempre dan como resultado el mejor plan si se aplican sobre un modelo en estrella.
Para ello, las bases de datos de las versiones Enterprise de Oracle disponen de una técnica de optimización llamada 'Star Transformation', que consiste en que el mismo optimizador realiza una transformación previa de la query, sabiendo que este tipo de transformación suele dar los mejores tiempos de acceso sobre esquemas diseñados en estrella. De todas maneras, el resultado del plan de acceso se almacena, y se compara después con el mejor resultado del plan que genera el optimizador sin aplicar la transformación, por si a pesar de todo la opción clásica es la más eficiente.
Optimización Star Query Transformation para modelos en estrella
Es importante saber que esta optimización sólo funciona si el parámetro de inicialización de la base de datos STAR_TRANSFORMATION_ENABLED tiene valor TRUE; por defecto está a FALSE, por lo que es probable que si antes no se ha tenido en cuenta, sólo con cambiar el valor de este parámetro se pueda obtener una importante mejora en el rendimiento de muchas queries de un Data Warehouse.
Otro requerimiento importante para que la optimización sea efectiva es que ha de existir un índice de tipo Bitmap sobre cada una de las claves foráneas que relacionan las tablas de hechos con las de dimensiones, cosa que por otro lado ya forma parte de las buenas prácticas recomendadas por Oracle para el diseño físico de modelos en estrella.
Existe alguna restricción más, que se puede consultar en el capítulo Schema Modeling Techniques de la Oracle Database Data Warehousing Guide.
Para finalizar, y para ilustrar la técnica que aplica el optimizador extraigo de esta misma documentación el ejemplo que se proporciona, con la consulta que recibiría el optimizador para un esquema en estrella, con una tabla de hechos 'Sales', y tres tablas de dimensiones 'Times', 'Customers' y 'Channels':
SELECT ch.channel_class, c.cust_city, t.calendar_quarter_desc,
SUM(s.amount_sold) sales_amount
FROM sales s, times t, customers c, channels ch
WHERE s.time_id = t.time_id
AND s.cust_id = c.cust_id
AND s.channel_id = ch.channel_id
AND c.cust_state_province = 'CA'
AND ch.channel_desc in ('Internet','Catalog')
AND t.calendar_quarter_desc IN ('1999-Q1','1999-Q2')
GROUP BY ch.channel_class, c.cust_city, t.calendar_quarter_desc;
Si el optimizador tiene activado el parámetro STAR_TRANSFORMATION_ENABLED, en un primer paso calculará el coste de identificar primero el subconjunto de datos que se necesitan de la tabla de hechos utilizando una query como esta (de aquí viene la denominación Query Transformation):
SELECT ... FROM sales
WHERE time_id IN
(SELECT time_id FROM times
WHERE calendar_quarter_desc IN('1999-Q1','1999-Q2'))
AND cust_id IN
(SELECT cust_id FROM customers WHERE cust_state_province='CA')
AND channel_id IN
(SELECT channel_id FROM channels WHERE channel_desc IN('Internet','Catalog'));Esta query será muy eficiente porque localiza a través de los índices bitmap, sin acceder realmente a la tabla, todos los registros implicados.
El segundo paso es calcular el mejor método para enlazar los datos que se necesitan de este subconjunto (la tabla de hechos inicial reducida) y las tablas de dimensiones.
Y ya está, el resultado será que para muchas consultas el coste total que devuelva el plan al realizar estos dos pasos será inferior al coste calculado buscando el mejor plan de acceso directamente sobre la query original.
