Hoy mientras hacía cubos (¿qué otra cosa?) y utilizaba unos indicadores compuestos avanzados del tipo:
SUM( CASE WHEN (COLOR = ‘RED’ AND TIPO = 3) THEN INVENTARIO_LT ELSE INVENTARIO + EXCEDENTES )
Constataba lo poderosos que son. Sin embargo este tipo de indicadores son muy complicados de mantener en un data warehouse. El problema viene cuando la base de datos ha crecido demasiado y tenemos que crear agregados (por Tienda o Departamento digamos), la herramienta OLAP no puede usar estos agregados debido a que las columnas que se ocupan para el CASE dentro del sum no existen en el agregado.
Para que los agregados funcionaran tendríamos que agregar a cada agregado las columnas Color y Tipo. La herramienta OLAP solamente usaría estos agregados cuando lo elementos del: group by+where+(lo que está dentro del sum), existen en el agregado.
Hay que programar los dashboards para que al abrirlos utilicen todas las variables en el agregado. Tantito que el usuario juegue con el tablero, ya sea filtrando o moviendo una dimensión provocará que no use agregados. A este tipo de agregados que solamente se pueden usar cuando la consulta exactamente tiene las columnas del agregado les llamo agregados exactos.
Entiendase que normalmente no es así, por ejemplo una consulta que solo use un sum(ventas) puede obtener el total de ventas x tienda de un agregado a nivel tienda-departamento-producto.
Respecto a estos indicadores avanzados que usan agregados exactos, tendría que programar para cada variante de la consulta que el usuario haga: un agregado. Me refiero con variante a cualquier filtro de dimensión que el usuario aplique o dimensión que mueva (que normalmente es lo que hacen los usuarios con una herramienta OLAP).
Lo mejor es traducir estos indicadores simples de tal forma que no se tengan que referenciar otras columnas (propiedades) de dimensiones dentro del sum.
Comentarios recientes