¡Buenos días a todos de nuevo! Otra semana más que nos encuentra en nuestro cálido y entretenido rinconcito de #BestInMicro!
Esta semana volvemos con una nueva historia vivida en carne propia, de estas que te dan respaldo a la experiencia como consultor, de aquellas que se aprende cuando uno las vive.
En mi caso fue una situación que sabía cómo resolverla (no recuerdo si es porque me haya pasado alguna vez o si lo aprendí leyendo de los manuales), pero es una situación que no es común ver y me pareció oportuno contárselos. Esta semana les voy a contar cómo podemos controlar qué tablas dominarán en las consultas a la hora de crear los informes en MicroStrategy.
A ver, vamos desde el principio. Como ya repetimos varias veces, MicroStrategy es básicamente una herramienta que permite generar y ejecutar consultas sin necesidad de entender SQL. Es decir, arrastramos un par de atributos, algunas métricas y algún filtro… y voilá, tenemos nuestros datos. Podemos ir al botoncito que nos muestra la consulta SQL que se generó… pero todo es automático.
Lógicamente, MicroStrategy no se inventa de qué tablas viene la información, todo esta previamente definido en la capa semántica que tanto caracteriza a la herramienta, y por lo que sabemos que la mayoría de los objetos tendrá una tabla asociada. Por ejemplo, un atributo tendrá un ID asociado a una tabla principal (de hechos) y otra tabla de dimensiones que tendrá la descripción de dicho atributo (una tabla de lookup)
En un modelo simple, tenemos un modelo Snowflake… básicamente una tabla de hechos y sus múltiples dimensiones asociadas. Pero cuando entramos en modelos un poco más grande, veremos que hay varias tablas de hechos involucradas en nuestro modelo…
Y aquí es donde se complica el asunto. Pongamos un ejemplo simple: si tenemos una tabla de hechos que registra compras y otra de ventas, en ambas tendremos la columna “ID_PRODUCTO”. Pero si queremos hacer una consulta que nos liste los productos que vendemos, MicroStrategy debería generar la consulta sobre la tabla de ventas… pero ¿cómo hacemos para que nos traiga SOLO los de esta tabla, y no nos traiga todos los productos que tenemos en el catálogo? ¿O los de la tabla de compras?
Lo sé, quizás es un ejemplo bastante genérico, pero creo que se capta la idea. Entonces, acá viene la pregunta:
En el caso de los atributos, la pregunta es sencilla: la tabla que esté definida como tabla de lookup. Fácil, ¿no?
Pero… Si en el reporte solo quiero mostrar el ID, ¿Me irá siempre a la tabla de lookup? ¿Y si agregamos un indicador? ¿Y si encima es un ID heterogéneo? ¿Quién me cuenta donde iría en este caso?…
Pues no hay una respuesta fija. Al menos no genérica, pero hoy les explicaré dos formas de definir una respuesta a esta pregunta.
Todas tablas tienen información, y cuanta más información tenga, y menos indexada este, costará más tiempo el obtener la información de dicha tabla. Es por esto que cada tabla tiene un “peso” determinado.
Si vamos a las propiedades de una tabla en MicroStrategy, veremos que hay un campo que indica el peso de dicha tabla. Esto afecta a la hora de hacer una consulta. MicroStrategy intentará definir la query utilizando las tablas más “livianas”. Esto puede incluso llevar a que el Query engine de MicroStrategy prefiera hacer varias joins anidadas, saltando por distintas tablas antes que hacer una consulta a una tabla agregada única. En esta nota se explica un poco qué factores afectan el peso de cada tabla.
Hay que tener cuidado con modificar este valor. Al actualizar el esquema (o reiniciar el IS, lógicamente), estos valores se recalculan. Excepto que se seleccione la casillita debajo del peso, pero hay que hacerlo comprendiendo que con esto se lleva a un mantenimiento manual de la tabla y puede tener un impacto negativo en la performance general.
Pero ya nos conocemos, y acá nos gusta hacer las cosas escalables y un poco más sencillas. Es por eso que, en lugar de jugar con los pesos de las tablas, nos enfocaremos en los indicadores que gestionan las tablas. Así que pasamos al siguiente punto:
Como aquí ya sabemos, lo que realmente afecta una query es la fact table. ¿Y qué objetos leen principalmente de esta? ¡Claro que sí, los indicadores! Es por esto que podemos generar un impacto desde el editor de métricas.
¿Han notado que si se paran sobre la formula, aparece una opción llamada “Parameters”? Aquí podemos definir ciertas propiedades que impactarán en la query.
Dentro de estas opciones, hay una llamada “FactID”. En esta podemos definir qué fact nos interesa que priorice la fórmula o la consulta. Recordemos que una fact representa una columna en una tabla. Es decir, podemos indicar que preferimos que intente hacer el cálculo basándose en una columna de una tabla particular en nuestro modelo.
Esto lo veremos mucho más claro en el video, donde podemos ver un ejemplo con distintos indicadores y como es la diferencia entre ellos, como cambia la query y el resultado.
¿Qué me cuentan ustedes? ¿Conocen alguna otra forma? Seguramente alguna propiedad VLDB tiene algo que contar por aquí…
En fin, espero que haya quedado claro. Como siempre, ¡les dejo varios links de donde pueden ampliar información, y cualquier duda tienen aquí debajo para preguntarme! Espero que les haya sido de utilidad, ¡y hasta la próxima!
Certificación Microstrategy: Trabajando con atributos (certificacionmicrostrategy.blogspot.com)
How are the fact tables determined using the logical table size for SQL generation in MicroStrategy
KB8983: What is the “Attribute weights” setting in MicroStrategy Developer 9.xKB41812: What do each of the Count parameters control in MicroStrategy Metric Editor
KB41812: What do each of the Count parameters control in MicroStrategy Metric Editor
Project Design Guide – Logical Tables Chapter
* Tu información será utilizada exclusivamente para contactarte en relación al Business Data Master. No hacemos spam ni compartimos datos con terceros.
