Un espacio para compartir ideas, tutoriales, automatizaciones y experiencias reales de trabajo con plataformas de datos y analítica. Artículos y notas sobre datos, Power BI, Fabric, Azure y automatización.
Con la obtención de detalles en Power BI Desktop, puede crear una página en el informe que se centra en una entidad específica, como un proveedor, un cliente o un fabricante. Los usuarios pueden hacer clic con el botón derecho en un punto de datos de otras páginas de informe. A continuación, pueden ofrecer la obtención de detalles en la página seleccionada para obtener información que se filtra para ese contexto.
Similar a pensar en drilldown (explorar en profundidad); ese click derecho sobre barras, tortas, etc que nos permitiría explorar niveles dentro del mismo gráfico; los
drillthrough
también funcionan con ese comportamiento. La diferencia está en que nos permite construir algo muy personalizado para detallar mejor una entidad o un concepto que queremos revelar o enfocar para el usuario final.
Haciendo un breve repaso de la serie, básicamente hemos visto las librerías básicas para interactuar con Azure utilizando PowerShell. Vimos ejemplos de éstas interacciones y la forma de automatizar 100% nuestros scripts para que no requieran interacción alguna con el usuario.
En esta última parte de la serie, vamos a abordar un tema que quedó pendiente en la anterior: no exponer nuestras credenciales a simple vista en el Script. Imagínense lo poco seguro que sería tener la contraseña a simple vista en nuestro script, algo como $password = "martin123" probablemente nos llevaría (con suerte) a un reto en una inspección de auditoria. Incluso si somos cuidadosos con el script, nos restringe la posibilidad de compartirlo para mostrar la lógica, o subirlo a un repositorio público de github para compartir conocimiento. Por esta razón, el broche de oro de esta serie tendrá foco en formas comunes de evitar exponer nuestras credenciales. Para esto veremos 2 formas, cada una con sus ventajas y desventajas.
Una particularidad de esta entrada en el blog, es que finalmente me mude definitivamente a Linux. Por lo que verán que las rutas a los archivos no comienzan con C:/como en windows, pero a los fines prácticos es lo mismo. También mencionaré que para esta oportunidad estaré usando el módulo Az para comunicarme con Azure, en lugar de AzureRM como venia haciéndolo en entregas anteriores (ya expliqué sus diferencias, y como llevar los comandos de uno a otro de forma simple).
Ciertamente a pesar de que Power Bi es un simple "Lector de Datos" por así llamarlo, es decir que no puede tener una ingesta de datos, tiene un característica muy interesante que nos permitiría simular o engañar al usuario para obtener ese comportamiento. Estoy hablando de un lugar donde seleccionar valores de un determinado rango para simular diversos escenarios de medidas, interactuar con la variable como una segmentación y visualizar y cuantificar diferentes valores clave de los informes.
La característica son los parámetros, mejor llamado en ingles "What if parameters". Vamos a ver como aplicarlo.
Power Bi viene por defecto, valga la redundancia, con un defecto de modelado llamado "Auto date/time". Ésta es una opción de Power Bi Desktop o de un archivo en particular que se encuentra bajo la opción Data Load con título Time Intelligence.
¿Por qué no es un buena opción?
Pues para responder ésto primero veamos de que se trata. Para ello voy a mostrar un imagen de un modelo clásico y sencillo de Adventure Works conectado con DAX Studio. Veamos que tablas tenemos cargadas en el modelo.
Como pueden ver tenemos las tablas clásicas del modelo junto con unas adicionales de nombre "LocalDataTable_XXX". Éstas son Tablas Fecha que fueron creadas automáticamente por Power Bi por tener activada la opción mencionada. Auto date/time va a generar una nueva tabla en nuestro modelo por cada columna de tipo fecha que tengamos en el modelo. Cada una de éstas columnas se relacionará a una "LocalDataTable_XXX" para tener desagregados como Año/Trimestre/Mes/Día como así también para ejecutar cálculos de time intelligence.
Recién ahora podemos responder porqué es tan malo tenerlo cargado. La realidad es que depende el caso, si simplemente tenemos un Power Bi de una tabla para responder sencillos escenarios no habría problemas. El problema surge cuando tenemos varios requerimientos que responder que involucran un modelado. Una de las primeras reglas de modelado consiste en tener una tabla fecha que nos permita relatar hechos en el tiempo o inteligencia de fechas. Siempre que éste sea el caso crearíamos nuestra propia dimensión fecha. Por lo tanto, si tenemos un modelo con muchas dimensiones que tienen fechas como fecha de nacimiento, fecha de vencimiento de producto, entre otras. Las mismas van a generar tablas automáticas por todo el modelo haciéndolo cada vez más pesado en tamaño y en performance.
Espero que el consejo les sea útil para reducir el tamaño de esos archivos enormes y mejorar sus modelados.
Newsletter
Recibí nuevos artículos en tu correo
Suscribite para enterarte de nuevas publicaciones, tutoriales y novedades sobre nuestros artículos y herramientas.
