Os dejo el video de mi participación en el Power BI Quizz de los grandes Ricardo Rincón y Raquel Alvear. Un autentico placer haber podido aportar mi granito de arena a esta iniciativa.
Página 2 de 4
Video de mi participación en Power Platform Madrid, con una sesión sobre la creación y el uso de una dimensión horaria que nos permita analizar nuestros hechos a granularidades inferiores al día.
Ya están disponibles las grabaciones del Global Power Platform Bootcamp de Madrid. Os comparto el video de mi sesión donde estuvimos analizando las diferentes opciones que tenemos para integrar previsiones y presupuestos en un modelo de datos de Power BI.
Vimos cómo crear relaciones virtuales con DAX, cómo inspeccionar el contexto de filtro para mostrar u ocultar medidas según el nivel de granularidad de los datos subyacentes con el objetivo de evitar mostrar el presupuesto en contextos de filtro para los que no se encuentra disponible, así como las distintas opciones de las que disponemos para implementar algoritmos que nos permitan asignar o distribuir nuestras previsiones a granularidades mayores a las detalladas en el presupuesto.
Una de las características clave del lenguaje M es su cualidad de ser case sensitive, o sensible a mayúsculas y minúsculas. Esto significa que las palabras clave del lenguaje, las variables, los nombres de las funciones y cualquier otro identificador deben escribirse siempre teniendo en cuenta esta peculiaridad.
Power Query incluye una serie de comparadores integrados en el lenguaje que pueden usarse para determinar la forma en la que realizamos una comparación. Estos son los siguientes:
Comparer.Ordinal: se usa para realizar una comparación ordinal exacta.Comparer.OrdinalIgnoreCase: se usa para realizar una comparación ordinal exacta que no distingue mayúsculas de minúsculas.Comparer.FromCulture: se usa para realizar una comparación compatible con referencias culturales.
Introducción
En una entrada anterior vimos cómo, en escenarios donde tanto los atributos relacionados con la fecha como los relacionados con la hora son relevantes para el análisis que queremos realizar, podíamos crear una dimensión horaria en M que nos sirviera para filtrar y segmentar nuestras medidas en función de atributos temporales menores al día.
La idea principal consiste en crear una lista con todas las horas que va a incluir nuestra consulta, que en función de la granularidad temporal que deseemos, tendrá un número de elementos distinto. Por ejemplo, si queremos que la consulta tenga un nivel de detalle de segundos, utilizaríamos la función List.Times de la siguiente forma:
let
Origen = List.Times(
#time(0,0,0),
24*60*60,
#duration(0,0,0,1)
)
in
Origen
Introducción
Cuando se construye un modelo de datos en Power BI, suele ser común la necesidad de ampliar una tabla procedente de un origen de datos con columnas adicionales, cuyo contenido se derive de los datos existentes en dicha tabla. En estos casos en los que los valores de las nuevas columnas van a ser pre-calculados y materializados de forma estática en el modelo y la lógica de negocio a implementar deriva del resto de columnas, es casi siempre preferible utilizar Power Query para definirlas, principalmente porque obtendremos un mayor nivel de compresión que usando columnas calculadas en DAX, y una columna con mejor compresión ocupará menos en memoria y normalmente nos proporcionará mejores niveles de rendimiento.
Un caso común, corresponde a la creación de columnas que nos ayuden a clasificar valores numéricos de manera que podamos discretizar esa variable y entender de forma clara la distribución de estos valores en nuestro modelo. Esta situación surge en multitud de escenarios, por ejemplo, cuando necesitamos clasificar facturas en función de la fecha de vencimiento, productos por precio de venta, empresas por cifra de negocios o empleados por grupos de edad. En este artículo vamos a ver distintas opciones para crear estas columnas con Power Query.
Introducción
El diagrama de Pareto, también conocido como curva cerrada o distribución A-B-C, es un gráfico combinado de columnas y líneas en el que los valores individuales se representan en orden descendente por columnas, y el total acumulado se representa a través de la línea. El nombre del gráfico proviene del principio de Pareto, llamado así en honor a Vilfredo Pareto, un destacado economista italiano. Dicho principio describe el fenómeno estadístico por el cual en cualquier población que contribuye a un efecto común, es una proporción pequeña la que contribuye a la mayor parte del efecto.
Este gráfico permite asignar un orden de prioridades, al mostrar gráficamente el principio de Pareto y posibilitar distinguir los factores más importantes entre un conjunto, generalmente amplio, de ellos. Es una de las herramientas más utilizadas en el control de calidad, donde a menudo se utiliza para identificar las fuentes más comunes de defectos, la tipología de defecto que más se produce o los motivos más frecuentes de las quejas de los clientes.
Introducción
En numerosas ocasiones, la primera pregunta que nos hace un usuario de un informe en Power BI es ¿están los datos actualizados? En un Panel del Servicio podemos configurar en cualquiera de las visualizaciones ancladas en el mismo, la capacidad de mostrar la hora de última actualización de los datos subyacentes. Pero, ¿qué opciones tenemos si queremos que el usuario tenga disponible directamente en el informe dicha hora de última actualización como una visualización más?
Fecha de modificación del origen de datos
En primer lugar, es importante distinguir entre la fecha de actualización del informe de Power BI y la fecha de actualización de los orígenes de datos utilizados en dicho informe.
Como vimos en una entrada anterior, cuando diseñamos un modelo de datos analítico, el enfoque principal debe situarse en lograr un diseño que favorezca la simplicidad en la exploración y agregación de los datos, a la vez que en obtener un rendimiento óptimo en la realización de consultas.
Las estructuras altamente normalizadas, con dimensiones organizadas en esquemas de copo de nieve que principalmente nos encontraremos en los sistemas de procesamiento de transacciones, no serán adecuadas para satisfacer las necesidades analíticas de la empresa teniendo la comprensibilidad del modelo por parte de los usuarios y la velocidad de consulta como objetivos principales. El hecho de disponer de más de una tabla por cada dimensión de la tabla de hechos de un proceso de negocio implica tener que realizar código más complejo para realizar una consulta que a su vez se ejecutará en un tiempo mayor, debido en parte al mayor número de relaciones.
La función Table.Pivot() del lenguaje M nos ofrece la capacidad de obtener como resultado una tabla que contiene un valor agregado para cada valor único de una columna. Cuando usamos esta función, Power Query agrupa cada valor mediante la agregación que seleccionemos y rota (pivota) los datos de la columna de atributo para convertirlos en encabezados de columna.
Desafortunadamente, Table.Pivot() sólo puede pivotar sobre una columna a la vez, por lo que si necesitamos realizar esta operación sobre más de una columna tenemos que llevar a cabo un sencillo proceso. Imaginemos que disponemos de la siguiente tabla:
