Las ventajas que noté respecto a los reporteadores o herramientas de BI “tradicionales” son obviamente la velocidad de generación de reportes, el drill-down y la interfaz “ajaxcificada” principalmente.

Dentro de las cosas que me llamaron la atención fue la reducción importante de espacio de almacenamiento después de convertir los datos al formato binario (QVD). La lentitud de la carga de datos también es notoria, por lo que para Datawarehouses grandes o cambiantes, es importante definir una estrategia incremental o meterse a programar los scripts de su ETL embebido de manera eficiente.

El modelo tan mencionado de “memoria asociativa” puede ser realmente muy superior al modelo relacional en memoria, pero pienso que para algunos escenarios, el modelo relacional en memoria puede ser suficiente para lograr resultados similares. Y siendo consecuentes con la hipótesis de que la memoria tiende a bajar de precio, entonces el hecho de que el modelo relacional ocupe más espacio que su modelo propietario asociativo realmente no importa tanto si se obtiene un desempeño similar.

Observando las demos y algunos de los casos que presentan, noté algunos escenarios donde se puede resolver de manera muy fácil con otra herramienta de analysis o reporteo como SQL Analysis y Reporting Services o similares.

Es importante mencionar, que Qlikview no reemplaza los Datawarehouses, ya que aún se necesita una fuente de datos confiable y consolidada. Es generalmente aceptado que Qlikview es más una herramienta de reporteo, aunque aparece en el cuadrante mágico de Gartner dentro de las herramientas de Business Intelligence.

Tal como lo he mencionado, las decisiones de inversión deben ser guiadas más sobre la premisa de usar la herramienta apropiada para el problema indicado; sin querer resolver cualquier problema con la herramienta de moda solo por el hecho de estarlo.

Por último, lo que más me sorprende de QlikTech, la compañia detrás de Qlikview es su ingenio y capacidad de penetración en un mercado saturado, con el enfoque de marketing adecuado y con mensajes claros y precisos.

En un Data Warehouse, el término dimensión se refiere a un grupo lógico de datos tal como una localidad geográfica u organizacional sobre los datos de la empresa.

Una Dimensión que cambia con el tiempo es una Slowly Changing Dimensions (SCD) es decir una dimensión que contiene datos que cambian lentamente. Por ejemplo, puede ser una dimensión que permite analizar las ventas de una empresa agrupada por vendedores. Todos los reportes regionales funcionan bien, hasta que un vendedor se mueve de una región o país hacia otra. Como mantienes ese cambio en la Dimensión de ventas?

Podrías obtener un promedio de las ventas anuales por vendedor, pero si se utiliza esto como un indicador de desempeño de los vendedores, esto podría dar información incorrecta. Si el vendedor se movió de una región muy productiva a una región con menos clientes, su promedio será superior al resto de los vendedores aún si su desempeño no es realmente mejor. O podrías crear un nuevo registro de vededor y tratarlo como una entidad distinta, pero eso también trae problemas ya que no se tendrían los totales.

Existen algunas metodologías para tratar este problema del tipo 0,1,2,3,4 y  6 que se explican brevemente a continuación.

Tipo 0. Este es un enfoque pasivo, es decir no se hace nada al respecto. Los valores permanecen como estaba la dimensión cuando los registros fueron creados. No es el tipo más usado.

Tipo 1. En este enfoque se sobreescriben los datos viejos con el dato actualizado sin mantener el historial de  donde perteneció. Este enfoque es sencillo, pero tiene la desventaja de que no contiene historia.

Tipo 2.  En este enfoque se inserta un nuevo registro cada vez que existe un cambio en la dimensión. Se agrega un campo de versión u opcionalmente se agregan dos columnas para capturar la fecha de inicio y final de ese valor. Con este método se puede relacionar fácilmente el período de tiempo para el cual es válido cierto dato en la dimensión pero no es muy sencillo de mantener sobretodo si el modelo dimensional cambia a menudo.

Tipo 3. Este método da seguimiento al cambio agregando nuevas columnas. Una columna  mantendría el dato de la región original de un vendedor por ejemplo, y otra la nueva región o actual, así como una columna de fecha efectiva del cambio. Este enfoque solo puede mantener un cambio histórico, a diferencia del Tipo 2 que puede mantener cambios ilimitados en la historia.

Tipo 4. Este método mantiene una tabla histórica para todos los cambios y una tabla con el valor actual de la dimensión.

Tipo 6 / Híbrido. Este método es una combinación de los Tipos 1,2 y 3 (1 + 2 + 3 = 6. El enfoque es usar una Dimensión TIpo 1 (escribiendo el dato actual), pero agregar un par adicional de columnas con las fechas de validez (TIpo 2).

Otras alternativas son usar un número de versión para cada nuevo renglón tal como el método de Tipo 2.

Los registros deben tener la llave de la tabla de Dimensión como una llave foránea (aunque no es un join a una única columna) en combinación con un filtro de fecha.  Para permitir historial de Tipo 2, las transacciones también podrían tener columnas para referenciar al número de versión aunque tomando las consideraciones de desempeño del Tipo 2.

No es necesario tener una bandera del dato actual en la dimensión o una llave para cada registro pero puede simplificar las consultas y la administración respectivamente.

Note que los Hechos debería tener solamente una fecha para representar la fecha en que ocurrió. Si se tienen múltiples fechas considerar dividir las transacciones de manera más granular.

No pretendo dejar resueltas todas las dudas sobre el manejo de estas dimensiones; sino solamente despertar el interés por aplicarlas y entenderlas.

De manera introductoria les diré, que los tiempos como resultado de usar vistas materializadas en un proyecto donde teníamos reportes con consultas (queries) que duraban hasta más de 1 minuto, se redujeron a segundos.

En un Sistema de base de datos relacional (RDBMS) una vista es una tabla virtual que representa el resultado de un Query.  Siempre que se consulta o se actualiza una vista normal, el RDBMS convierte estas operaciones en queries o actualizaciones de las tablas usadas para definir la vista.

Una vista materializada utiliza una enfoque diferente, ya que el resultado de la consulta se almacena en una tabla cache real, que será actualizada de forma periódica a partir de las tablas originales. Esto proporciona un acceso mucho más eficiente, a costa de un incremento en el tamaño de la base de datos y a una posible falta de sincronía, es decir, que los datos de la vista pueden estar potencialmente desfasados con respecto a los datos reales.

Esto es una solución muy utilizada en entornos de Datawarehousing donde el acceso frecuente a las tablas fuente resulta demasiado lento.

Además, dado que la vista se almacena como una tabla real, se puede hacer con ella lo mismo que con cualquier otra tabla, siendo especialmente importante la capacidad de crear indices en cualquier columna, lo cual puede aumentar significativamente la velocidad de las consultas.

En una vista normal, lo más común es que sólo se permita utilizar índices sobre aquellas columnas que ya tienen definido un índice en la tabla original; a veces ni siquiera se ofrece esa posibilidad.

Una sentencia típica de SQL para definir una Vista materializada:

CREATE MATERIALIZED VIEW nombre_vista
[TABLESPACE nombre_ts]
[PARALELL (DEGREE n)]
[BUILD {INMEDIATE|DEFERRED}]
[REFRESH {FAST|COMPLETE|FORCE|NEVER}|{ON COMMIT|ON DEMAND|[START WITH fecha_inicio] NEXT intervalo}]
[{ENABLE|DISABLE} QUERY REWRITE]
AS SELECT … FROM … WHERE …

Con la sentencia BUILD se establece la forma de carga de datos en la vista. Con la opción INMEDIATE (opción por defecto) se cargarán los datos justo después de crear la vista, mientras que con la opción DEFERRED se definirá la vista cuando se ejecute la sentencia SQL sin cargar ningún dato, que se cargarán cuando se realize el primer refresh de la vista.

Con la palabra REFRESH definimos el método y la frecuencia de actualización de los datos.

La palabra QUERY REWRITE establece si queremos que el optimizador de nuestra base de datos pueda reescribir las consultas. El optimizador, sabiendo que ya existe una determinada vista materializada, puede modificar internamente nuestra consulta sobre una determinada tabla, de tal forma que se mejore el rendimiento de la consulta devolviendo los mismos datos que la consulta original.

En el proyecto en cuestión, la base  de datos es DB2, aunque diversos gestores de base de datos cuentan con esta funcionalidad. De hecho el RDBMS que lo introdujo fue Oracle.