Aprendiendo QlikView - Tercera Parte - Algo de Modelamiento

En una de las entradas anteriores a está hable acerca del modelo de datos de qlikview y que no era tan importante el tema del modelo como tal en cada una de las aplicaciones. PALABRAS DE NEWBIE, tengo que retractarme ahora de tan engorrosa entrada porque definitivamente tener un modelo organizado en Qlikview te permite sacar ventajas a la herramienta.

Topología Recomendada

Sin lugar a dudas la recomendación es lograr tener un modelo de estrella en el que se puda tener absolutamente la eficiencia de trabajar con la estructura predilecta del mundo del datawarehouse.

El escenario es el mejor porque con esta topología se logra manejar la data por eventos y se tiene un manejo de múltiples escenarios, adicional se pueden compartir las dimensiones o atributos de la información representada por eventos.

Cuando tenemos en qlikview mas de dos tablas de hechos en una misma aplicación, hay que tener en cuenta algo muy importante "No se deben relacionar las tablas de hechos como en el BI Tradicional, se debe hacer por medio de tener las medidas en una sola tabla de hechos en los casos complejos hacer LINK TABLES". Esto significa que debemos ver una de las alternativas a tomar para poder tener en el modelo las medidas que la aplicación requiere.

- CONCATANATE (MERGE): Lo que se hace es que se concatenan dos tablas de la forma en una sola forzandolas a convivir en una sola tabla.

evento:

load a, b, c from table1.txt;

concatenate load a, b from table2.xls;

Con esto tenemos las dos tablas en la misma evento y cuando los datos provienen de la tabla2 entonces el campo c se encuentra en nulo

- LINK TABLE: El modelo debe tener una tabla donde me haga referencia a cada una de las dimensiones que debe usar la fact table y por este medio se deben llevar las relaciones entre los datos de una aplicación qlikview.

Para mas información buscar en la comunidad QlikView acerca de las link tables http://community.qlikview.com/