
En la lista siguiente, se proporcionan los requisitos mínimos para ejecutar Power BI Desktop:
Windows 7 y Windows Server 2008 R2 o posterior
.NET 4.5
Internet Explorer 10 o posterior
Memoria (RAM): Al menos 1 GB disponible; se recomienda 1,5 GB o más.
Pantalla: se recomienda al menos 1440 x 900 o 1600 x 900 (16:9). No se recomiendan resoluciones inferiores a 1024x768 o 1280x800, ya que ciertos controles (por ejemplo, para cerrar la pantalla de inicio) solo se muestran en resoluciones superiores a estas.
CPU: se recomienda un procesador x86 de 32 o 64 bits de 1 gigahercio (GHz) o superior.
Fuente: https://docs.microsoft.com/es-mx/power-bi/desktop-get-the-desktop
La manera más común de consumir datos en Power BI es importándolos a nuestro modelo de datos
Importar datos implica crear una copia local de los mismos, la cual permanece estática hasta que actualizamos dicha conexión.
Cuando nuestra información reside en una base de datos, tenemos la opción adicional de conectarnos directamente, sin crear una copia local de los datos. Este método se conoce como Direct Query. Existen algunas implicaciones al utilizar esta opción.
IMPORTAR VS DIRECT QUERY
La tecnología de Power BI se basa en un motor in-memory llamado VertiPaq, los datos que son importados consumen RAM y espacio en disco, ya que son guardados en archivos.
Una vez cargada la información en el cache de Power BI, se mantiene en un estado de compresión, gracias a VertiPaq consume mucho menos espacio que en su estado original.
Una vez publicado el reporte al servicio de Power BI, los datos consumen espacio en disco y RAM en los servidores de la nube.
VENTAJAS DE IMPORTAR DATOS
Podemos emplear todas las funcionalidades de Power BI sin restricciones, incluyendo todas las transformaciones disponibles en Power Query así como todas las funciones DAX para modelado de datos.
Adicionalmente importar datos nos permite combinar múltiples fuentes de datos en el mismo modelo.
Otra ventaja importante es la velocidad de los cálculos. Debido a que VertiPaq almacena datos en memoria, hay muy poca o ninguna latencia al acceder y calcular sobre los mismos.
DIRECT QUERY
Cuando usamos la opción de Direct Query no estamos cargando datos en Power BI. Estos permanecen en la fuente, con excepción de los metadatos (nombres de tablas y columnas, tipos de datos y relaciones).
Con este método, Power BI solo sirve como herramienta para visualizar los datos del origen.
La principal ventaja de este método es que no estamos limitados por el hardware de nuestra máquina de desarrollo. Todos los datos se guardan en la fuente de datos y todos los cálculos se realizan ahí mismo.
IMPLICACIONES DE UTILIZAR DIRECT QUERY
El desempeño de nuestros reportes puede variar considerablemente dependiendo del hardware de la base de datos subyacente.
Solo podemos utilizar una fuente de datos a la vez.
El rango de transformaciones disponibles en el editor de consultas es bastante limitado y en algunas ocasiones nulo.
La experiencia de modelado de datos también tiene sus limitaciones en Direct Query, muchas funciones DAX no están disponibles o se tienen que habilitar manualmente.
DATA SHAPING
Proceso que involucra la extracción de datos, la transformación de datos y su posterior carga en Power BI.
La forma (shaping) de los datos responde a las siguientes preguntas:
¿Que información extraemos?
Cómo se cargan nuestros datos en una o más tablas y qué tablas se importan.
Qué nombres le asignamos a las columnas, tablas y otros objetos.
Que información necesitamos filtrar, transformar etc., antes de cargar.
DATA MODELING
El modelado es el proceso de construir relaciones entre tablas y convertir los requerimientos del negocio en medidas y columnas calculadas usando el lenguaje DAX .
Dichas medidas contienen:
La lógica comercial que transforma datos brutos en un cálculo útil y de valor agregado
El formato requerido para lo que queremos medir (moneda, porcentaje, etc.)
Un buen nombre para la medida que describe con precisión su propósito.
¿POR QUÉ ES TAN IMPORTANTE MODELAR DATOS?
Cuando el modelado no es el correcto
El código DAX para hacer cosas en apariencia "sencillas" tiende a ser bastante complejo.
Las fórmulas son difíciles de concebir e interpretar.
La complejidad se traduce en problemas de desempeño.
Cuando modelamos adecuadamente los datos
El código DAX es simple y elegante y en ocasiones innecesario.
Gran desempeño de medidas y campos calculados.
¿QUÉ ES UN MODELO DE DATOS?
Un modelo de datos o data model es un conjunto de tablas relacionadas. Un modelo con una sola table ya se considera un data model, aunque uno muy básico. Para poder crear una relación entre tablas son necesarias:
Tabla Dependiente (Many Side): La tabla desde donde empieza la relación y que contiene la clave foránea o foreing key.
Tabla Padre (One Side): Es una tabla que contiene una llave primaria o primary key que está relacionada, como mínimo, con una clave foránea de otra tabla (tabla dependiente).
ESQUEMAS EN ESTRELLA
La distinción entre activos y eventos nos lleva a una técnica de modelado de datos llamada esquema en estrella o star schema. En este esquema las entidades o tablas se dividen en:
a) Dimensiones: Una dimensión es un activo que genera información, como un producto, cliente, empleado, etc. Las dimensiones tienen atributos, por ejemplo: un producto tiene color, tipo, categoría, fabricante, precio, costo, etc.
b) Hechos: Un hecho es un evento que involucra alguna dimensión. Por ejemplo, la venta de un producto es un hecho. Los hechos tienen medidas, las cuales son números que se pueden agregar cómo la cantidad vendida, el precio, descuento, costo, etc.
VENTAJAS DE UN ESQUEMA EN ESTRELLA
Muy fácil de entender a primera vista.
Filtramos por dimensiones y agregamos hechos.
No hay ambigüedad.
Un nivel de direccionamiento facilita ver la función de cada tabla.
Muy rápido.
Los motores tabulares modernos están optimizados para utilizar este esquema.
Un modelado claro y conciso.
Los números van en la tabla de hechos.
Los textos van en las dimensiones.
CARDINALIDAD DE RELACIONES
Varios a uno (Many to one): este es el tipo predeterminado más común. Esto significa que la columna en una tabla puede tener más de una instancia de un valor, y la otra tabla relacionada, a menudo conocida como tabla padre, tiene solo una instancia para cada valor en la columna primary key.
Uno a uno (One to one): esto significa que las columnas que relacionan a ambas tablas tienen una sola instancia de un valor particular.
Varios a varios (Many to many): ambas columnas de la relación tienen valores repetidos. Por ejemplo: Ventas e Inventario.
DIRECCIONES DE FILTRO CRUZADO
Única (Single): significa que cuando filtramos la tabla padre (one side) de una relación, los filtros se propagan al many side de manera automática, pero filtrar el many side (tablas dependientes) no filtra automáticamente el one side (tabla padre) de la relación.
Ambas (Both): también conocida como relación bidireccional, se asegura de que ambas tablas se filtren entre sí indistintamente. Sin embargo, esta opción se debe considerar cuidadosamente, ya que tiene consecuencias en el rendimiento. Además, esta configuración puede impedirnos crear relaciones activas en ciertos casos o causar ambigüedad en nuestros modelos.
MEJORES PRÁCTICAS PARA NOMBRAR OBJETOS
Los nombres de tablas dimensionales deben de contener el nombre del activo en singular o plural. Por ejemplo: Los atributos de clientes en una tabla llamada Clientes, Proveedores, Empleados, etc.
En caso de que el nombre del activo contenga varias palabras, se recomienda no usar espacios, por ejemplo: CategoriaProductos, EmpleadosExternos, etc.
Las tablas de hechos deben de nombrarse en plural de acuerdo a las medidas que contenga. Por ejemplo: Ventas, Clientes, Compras, etc.
Evita usar nombres muy largos que sean difíciles de leer, siempre que sea necesario utiliza abreviaturas y elimina las palabras innecesarias.
Evitar nombres extremadamente cortos que no sean claros para usuarios del reporte. Por ejemplo: nombrar una tabla PER (País de Embarque Revendedores) puede ser difícil de interpretar para terceros y difícil de recordar.
Es necesario siempre tener en cuenta a la audiencia de nuestros reportes al nombrar objetos en Power BI.
Cuando creamos relaciones entre tablas se recomienda nombrar dichas columnas de manera especial, anteponiendo la palabra Key al nombre de la columna. Por ejemplo: CustomerKey en la tabla de Clientes es fácilmente identificable como la llave primaria, mientras que CustomerKey en la tabla de Ventas se reconoce como llave foránea.
SINTÁXIS DAX
DAX es utilizado para calcular valores en columnas de una tabla. Se puede agregar, calcular, buscar, filtrar, etc., pero al final todos los cálculos involucran tablas y columnas.
Para referenciar una columna en DAX, primero escribimos el nombre de la tabla en comillas simples, seguido del nombre de la columna en corchetes:
‘Sales’[Quantity]
Podemos omitir las comillas simples siempre y cuando el nombre de la tabla no empiece con un número, no contenga espacios y no sea una palabra reservada para las funciones como SUM o Date, etc. En este caso:
‘Sales’[Quantity] = Sales[Quantity]
LO QUE TIENES QUE SABER ANTES DE EMPEZAR A APRENDER DAX
Lo más importante para entender código DAX es comprender el concepto de CONTEXTOS DE EVALUACIÓN.
La fórmula es la misma el resultado depende del CONTEXTO en que se aplica el cálculo.
Estos conceptos están relativamente ocultos en el lenguaje detrás de una sintaxis "simple", que es bastante intuitiva para cálculos sencillos.
Tan pronto como deseemos escribir fórmulas más complejas, estos conceptos ocultos crean problemas porque un usuario principiante ni siquiera es consciente de que estos existen y mucho menos como interactúan para producir resultados.
DAX tiene estos conceptos ocultos (contexto de fila, contexto de filtro y transición de contextos) que no existen en ningún otro idioma o modelo que hayamos visto antes. Son extremadamente poderosos, pero son muy abstractos y no son "visibles" en el lenguaje.
A veces, una pequeña diferencia en una fórmula produce un resultado completamente diferente. Otras veces, el total de una matriz no coincide con la suma de las celdas que vemos en el informe, y puede ser difícil entender por qué.
Aprender DAX a partir de ejemplos no es productivo. Es mucho mejor pasar algunas horas estudiando la teoría y entender como funcionan e interactúan el contexto de filtro y contexto de filas para "entender" DAX. Estos conceptos son exclusivos de DAX y es difícil inferir su comportamiento simplemente observando el resultado de algunas fórmulas.
La recompensa de aprender DAX es una productividad muy alta una vez que dominemos el lenguaje: algunas líneas de DAX pueden requerir decenas o cientos de líneas de código SQL para el mismo cálculo o lógica de negocios.
COLUMNAS CALCULADAS
Uno de los conceptos más importantes en DAX, es la diferencia entre columnas calculadas y campos calculados o medidas.
Una columna calculada es una columna adicional en un tabla, definida a través de una fórmula DAX. Cualquier referencia a una columna regresa el valor de dicha columna en la fila actual.
Gross Margin Amount = Sales[SalesAmount] - Sales[TotalProductCost]
Las columnas calculadas se computan durante el procesamiento de la base de datos y luego se almacenan en el modelo. Todas las columnas calculadas ocupan espacio en la memoria y cómputo en el procesamiento de las tablas.
Columnas calculadas utilizando el lenguaje DAX
Representan una adición al modelo de datos
Siempre se calculan fila por fila
La expresión Sales[SalesAmount] en en una columna calculada se refiere a:
El valor de la columna SalesAmount
En la tabla Sales
Para la fila actual
Es diferente para cada fila
MEDIDAS
¿Qué pasaría si quisiéramos calcular la utilidad neta como porcentaje de los ingresos en una columna calculada?
Gross Margin% = DIVIDE( Sales[Gross Margin Amount], Sales[SalesAmount] )
La fórmula funciona a nivel fila dentro de la tabla, sin embargo, cuando queremos agregar el valor de un porcentaje, no podemos utilizar columnas calculadas.
Lo que necesitamos es un campo calculado (medida), que compute el valor agregado de la suma del margen bruto dividido entre la suma de las ventas.
Escritas utilizando DAX
No iteran fila por fila
En su lugar, usan tablas y agregadores
No tiene el concepto de «fila actual»
GrossMargin$
es una columna calculada
pero también puede ser una medida
GrossMargin%
es una medida necesariamente
MEDIDAS VS COLUMNAS
Las medidas y columnas calculadas ambas usan expresiones DAX; la diferencia esta en el contexto de evaluación.
Cuando utilizamos la función SUM(Sales[Sales Amount]) en una medida, nos referimos a la suma de todas las ventas dentro del contexto de filtrado. Dicha función dentro de una columna calculada hace referencia al valor de las ventas en la fila actual.
Algunas veces la misma fórmula se puede calcular indistintamente dentro de una medida o columna calculada. En la mayoría de las ocasiones el cómputo a realizar determina la opción a seguir.
Cómo regla general siempre es preferible un campo a una columna calculada.
Utilizamos columnas calculadas cuando:
Necesitemos filtrar en base al valor resultante de dicha columna
Utilizamos medidas para:
Calcular porcentajes
Calcular ratios
Agregaciones y funciones complejas
Espacio de almacenamiento y uso de CPU:
Las columnas consumen memoria en el modelo
Las medidas consumen CPU en el momento de la consulta
INTRODUCCIÓN A CONTEXTOS DE EVALUACIÓN
Los contextos de evaluación son los pilares del lenguaje DAX.
La complejidad del código puede escalar rápidamente.
Conceptos simples, difíciles de aprender.
DAX es sencillo, pero no es fácil.
CONTEXTO DE FILTROS
Al conjunto de filtros aplicados a la base de datos antes de la evaluación de la fórmula se le conoce cómo el contexto de evaluación.
Cualquier fórmula DAX especifica un cálculo, pero DAX evalúa este cálculo en un contexto el cuál define el valor final computado. La fórmula es siempre la misma, pero el valor es diferente ya que DAX lo evalúa contra diferentes subconjuntos de datos.
Los filtros visuales, de página y de nivel de informe; ejes en un visual; slicers; filas y columnas en una Matriz, etc. definen el contexto de evaluación de una función. A esto le llamamos el contexto de filtros o filter context.
Filas fuera del contexto de filtros, no son considerados para el cómputo.
Definido automáticamente por la herramienta.
También se puede crear con funciones específicas DAX.
[Sales Amount] := SUMX ( Sales, Sales[Quantity] * Sales[UnitPrice] )
Esta función se puede leer alternativamente como “la suma de todas las ventas visibles dentro del contexto de filtrado actual”.
El contexto de filtrado como su nombre sugiere filtra una tabla antes de ser calculada.
CONTEXTO DE FILAS
Sales[GrossMargin] = Sales[SalesAmount] – Sales[TotalCost]
Esta expresión es una columna calculada. DAX computa la fórmula para cada una de las filas en la tabla y calcula un valor diferente para cada una, como es de esperarse.
En ningún momento le estamos especificando a DAX que fila usar para cada cálculo, pareciera que esta implícito en la fórmula, pero no. La fila utilizada para cada cálculo no reside en la fórmula, sino en el contexto de filas.
Cada que definimos una columna calculada, DAX itera desde la primera hasta la última fila de la tabla, creando así un contexto de filas en cada iteración.
Un contexto de filas es un contexto que siempre incluye una sola fila y es definido automáticamente cuando creamos una columna calculada o una función de iteración.
Necesario para evaluar el valor de una columna, es el concepto de "fila actual" en DAX.
En DAX siempre hay dos contextos: uno de filtros el cual filtra una tabla y otro de filas el cual itera sobre todas las filas visibles dentro del contexto actual de filtros. El resultado de cualquier expresión DAX depende de ambos.
CONTEXTOS DE EVALUACIÓN
Se llaman contextos de evaluación porque cambian la forma en que una expresión es evaluada, produciendo diferentes resultados para la misma fórmula.
Las funciones de agregación como SUM, MIN,MAX, AVERAGE y COUNTROWS utilizadas en columnas calculadas, utilizan el contexto de filtros únicamente e ignoran el contexto de filas.
¿Qué pasaría si utilizamos la siguiente fórmula en una columna calculada?
TotalSalesAmount = SUM( Sales[SalesAmount] )
a) El valor resultante es diferente para cada fila.
b) El valor resultante es el mismo para cada fila.
Respuesta: Cómo vimos anteriormente, el significado de la fórmula es: “la suma de todas las ventas dentro del contexto de filtrado”. Entonces ¿cual es el contexto de filtros? Es toda la tabla debido a que DAX evalúa la fórmula fuera de cualquier tabla, visualización o cualquier filtro. En una columna calculada no hay ningún tipo de filtros activo. El resultado de la expresión anterior en una columna calculada es el mismo valor para cada fila.
Ahora imaginemos la siguiente fórmula para calcular ventas totales, pero ahora en un campo calculado o medida en vez de una columna calculada.
TotalSalesAmount = Sales[OrderQuantity] * Sales[UnitPrice]
¿Qué esperarías al escribir algo así en una medida?
a) La expresión funciona de manera adecuada.
b) Un error, no se puede escribir esta fórmula.
Respuesta: Cuándo escribimos este código en una columna calculada, DAX automáticamente sabe que filas utilizar debido al contexto de filas. Sin embargo, en este campo calculado no hay iteraciones, es decir no hay un contexto de filas. El resultado de escribir esta expresión en una medida genera un error.
Una columna no tiene un valor por sí misma, tiene un valor diferente para cada fila. La manera correcta de especificar este cálculo en una medida es utilizando alguna función de agregación, cómo:
TotalSales := SUMX ( Sales, Sale[OrderQuantity] * Sales[UnitPrice] )
De esta manera le estamos indicando a DAX que realice una agregación a través de la función SUMX, así ya no depende de un contexto de filas sino de un contexto de filtros para proporcionar el resultado correcto.
SIEMPRE HAY DOS CONTEXTOS
Contexto de filtros
Filtra las tablas
Definido automáticamente por la herramienta o programáticamente a través de funciones DAX.
Contexto de filas
Iterar las filas activas en el contexto de filtro
Definido automáticamente a través de columnas calculadas o programáticamente a través de iteradores DAX.
Ambos son «contextos de evaluación»
CONTEXTO DE FILAS Y RELACIONES
Por motivos de simplificación hasta ahora hemos visto solamente ejemplos de contextos de evaluación en una sola tabla. Ahora veremos como se comportan los mismos entre varias tablas relacionadas, como se propagan a través de relaciones y cuales son las interacciones entre contextos y relaciones.
No hay ningún tipo de interacción entre un contexto de filas y una relación, al menos no de manera automática.
Si quisiéramos crear una columna calculada que contenga la diferencia entre el precio unitario en la tabla de hechos Sale y el precio de lista en la tabla de dimensiones Stock Item. Podríamos tratar de escribir la siguiente fórmula:
Unit Price Var = Sale[Unit Price] -'Stock Item'[Unit Price]
El contexto de filas de la tabla de ventas no se propaga de manera automática a la tabla de inventario de producto y DAX genera un error cuando tratamos de escribir dicha fórmula.
La manera correcta de escribir la columna calculada anterior es a través de la función RELATED:
Unit Price Var = Sale[Unit Price] – RELATED ( 'Stock Item'[Unit Price])
RELATED funciona cuando tenemos un contexto de filas en el many side de una relación. Sin embargo si el contexto de filas esta activo en el one side de la relación, no podemos usar RELATED debido a que hay potencialmente varias filas detectables a través de la relación.
En este caso utilizaríamos la función RELATEDTABLE que nos sirve cuando estamos en el one side de una relación para computar una tabla que contenga todas las filas relacionadas con el valor actual.
Si quisiéramos calcular el número de ventas por cada categoría de producto, podríamos utilizar la siguiente columna calculada en la tabla de Product Category:
Product Category[NumberOfSales] = COUNTROWS ( RELATEDTABLE ( Sales ) )
Tanto RELATED como RELATEDTABLE pueden navegar a través de una cadena de relaciones entre tablas. En este caso el resultado de las ventas por categoría atraviesa una cadena de relaciones one to many, desde Product Category a Product Subcategory, luego a Product para finalmente alcanzar la tabla de Sales.
La única restricción en cuanto a cadenas de relaciones, es que todas las relaciones tienen que ser del mismo tipo (ya sea one-to-many o many-to-one) y que todas vayan en la misma dirección.
CONTEXTO DE FILTROS Y RELACIONES
Los contextos de filtros interactúan con las relaciones de manera automática y se comportan de manera diferente dependiendo de cómo establezcamos las dirección (flechas) de filtrado.
Podemos pensar en las flechas de las relaciones como semáforos que permiten la propagación de filtros. Las flechas siempre se establecen por default en la dirección del one al many side de una relación y en ambos sentidos cuando se establece bidireccionalmente.
Tanto en el contexto de filas como en el de filtros, no es importante el número de pasos que tengamos que atravesar para alcanzar una tabla: siempre que tengamos habilitada una cadena de relaciones la propagación sucede.
La propagación del contexto de filtrado en DAX se hace de manera automática mientras que la propagación del contexto de filas es a través de las funciones RELATED y RELATEDTABLE.
A diferencia de los contextos de filas que no interactúan con las relaciones, los contextos de filtros se comportan de manera diferente.
Por default cuando creamos una relación en Power BI, los filtros se propagan del one al many-side de la relación. Cuando establecemos un una relación bidireccional los filtros se propagan en ambos sentidos de la relación.
AGREGACIONES
Útiles para agregar valores.
SUM
AVERAGE
MIN
MAX
Solo permiten agregar una columna a la vez.
SUM ( Orders[Price] ) (CORRECTO)
SUM ( Orders[Price] * Orders[Quantity] ) (INCORRECTO)
FUNCIONES "X" DE AGREGACIÓN
Iteradores: útiles para agregar fórmulas.
SUMX
AVERAGEX
MINX
MAXX
Un iterador hace exactamente lo que su nombre sugiere. Itera a lo largo de la tabla y realiza un cálculo para cada fila, agregando el resultado para producir un único valor final.
Total Sales := SUMX ( Sale, Sale[Quantity] * Sale[UnitPrice] )
Todos los iteradores se comportan de la siguiente manera:
Crean un contexto de filas para cada fila dentro de la tabla establecida como primer parámetro de la función.
Evalúan el segundo parámetro de la función dentro del contexto de filas creado.
Agregan los valores computados en cada iteración del paso anterior.
Reciben siempre dos parámetros:
Tabla a iterar
Fórmula a evaluar para cada fila de la tabla
SUM O SUMX?
SUM no es más que azúcar sintáctico (syntax sugar) de la función SUMX.
SUM ( Sales[Quantity] )
Se traduce internamente a: SUMX ( Sales, Sales[Quantity] )
PRINCIPALES FUNCIONES TABULARES
Funciones básicas que funcionan en tablas completas:
FILTER
ALL
VALUES
DISTINCT
RELATEDTABLE
Usualmente los resultados de una función se traducen en un valor único, ya sea numérico o texto. A este tipo de funciones les llamamos escalares.
Sin embargo también podemos escribir funciones DAX que resulten en tablas en vez de valores, estás se conocen como funciones tabulares.
No podemos asignar expresiones tabulares directamente a una medida o columna calculada, sin embargo estas funciones sirven como argumentos en otras funciones más complejas que aceptan tablas como input.
Si una expresión tabular resulta en una tabla con una única columna y fila, la conversión a valor escalar es posible y se hace de manera automática.
EXPRESIONES TABULARES
Cada vez que tenemos una función DAX que acepta expresiones tabulares como argumento, podemos escribir el nombre de la tabla como parámetro o bien una función que se traduzca en una tabla.
Sale Rows = COUNTROWS ( Sales )
En este caso la función COUNTROWS cuenta todas las filas de la tabla Sales.
Sale Filtered Rows = COUNTROWS ( FILTER ( Sale, Sale[Unit Price] > 100 ) )
En este caso la función COUNTROWS toma como argumento una función tabular FILTER y cuenta solo aquellas filas donde el precio sea mayor a 100.
FILTER (DAX)
La función FILTER juega un papel básico: Acepta una tabla como argumento y regresa una tabla con la misma cantidad de columnas que la original, pero solamente con las filas que satisfagan los argumentos condicionales evaluados fila por fila.
Es posible anidar las funciones de filtrado, esto debido a que podemos hacer un llamado a cualquier expresión tabular como argumento de filtrado.
El orden de ejecución, es siempre de adentro hacia afuera. Es decir el filtro central de la función es el primero en ser evaluado. En general, anidar filtros en la misma función produce el mismo resultado que una combinación de condiciones lógicas a través de AND.
FILTER ( <table>, AND ( <condition1>, <condition2> ) )
FILTER ( FILTER ( <table>, <condition1> ), <condition2> ) )
ALL (DAX)
El denominador de la siguiente fórmula calcula siempre la misma expresión: la suma total de ventas, pero debido a que la expresión se encuentra dentro de la función CALCULATE, el contexto de evaluación es diferente al original.
ALL ignora cualquier filtro, en este caso computa sobre todas los colores, reemplazando cualquier filtro preexistente en cualquier columna de la tabla de Stock Item, que en este caso proviene de las filas de nuestra visualización.
No podemos especificar una expresión tabular como argumento de ALL. Solamente acepta una tabla o una lista de columnas como tal. Si especificamos una sola columna el resultado es una tabla con todos los valores únicos para dicha columna.
ALL es una útil función que produce una tabla con todas las filas de una tabla o todos los valores únicos de una columna, dependiendo de los parámetros utilizados.
En cualquiera de sus variaciones, ALL ignora cualquier filtro existente para producir sus resultados. Podemos utilizar ALL ya sea como un argumento para una iterador (SUMX o FILTER) o como filtro para CALCULATE.
VALUES (DAX)
VALUES es una función que compila una tabla de una sola columna, la cual contiene todos los valores de la columna actualmente visible en el contexto de filtrado.
Alternativamente podríamos contar el número de clientes usando la sig. expresión:
[NumOfCustomers] := COUNTROWS ( VALUES ( Sales[CustomerKey] ) )
Esta expresión no cuenta el número de cliente en la tabla Customer. En vez de esto, cuenta el número de valores visibles en el contexto de filtros actual para la columna CustomerKey en la tabla de ventas.
Alternativamente podemos utilizar DISTINCTCOUNT que cuenta los valores distintos para una columna, la cual como regla general es preferible a un CONTROWS de VALUES.
ALLSELECTED (DAX)
ALLSELECTED es una función muy útil que nos permite hacer cálculos tomando en cuenta los filtros de página o selecciones de los slicers.
Si quisiéramos escribir una medida que calcule el porcentaje de cada color sobre las ventas totales de los colores seleccionados, podríamos intentar lo siguiente:
El resultado de la función anterior no es satisfactorio debido a que el gran total no muestra el 100%.
Esto se debe a que el denominador de la fórmula toma en cuenta TODOS los colores independientemente de la selección en el slicer.
Es necesario contar con una función que tome en cuenta el contexto original de filtros para calcular el denominador de la fórmula.
ALLSELECTED toma en cuenta únicamente los valores visibles dentro del contexto de filtros original, es decir, el de la visualización.
Podemos invocar ALLSELECTED con diferentes parámetros:
Una sola columna, por ejemplo ALLSELECTED (Stock Item[Color]) lo cuál calcula los colores seleccionados originalmente.
Una tabla, por ejemplo ALLSELECTED (Stock Item), lo cuál computara sobre todas las columnas de la tabla regresando todas aquellas filas seleccionadas originalmente.
INTRODUCCIÓN A CALCULATE
CALCULATE y CALCULATETABLE son las únicas funciones que pueden modificar el contexto de filtros. En realidad CALCULATE crea una nuevo contexto de filtros y evalúa la expresión dentro del mismo.
[Measure] := CALCULATE(<expression>,<filter1>,<filter2>…)
CALCULATE acepta cualquier número de parámetros, él único que es mandatorio es el primero, la expresión a evaluar.
Esta función acepta 2 tipos de argumentos de filtros:
Lista de valores en la forma de una expresión tabular. El filtro puede ser una tabla con una sola columna o con varias columnas.
Expresiones booleanas. Estos filtros trabajan en una columna solamente, ya que el resultado tiene que ser una lista de posibles valores de una sola columna.
FILTAR UNA SOLA COLUMNA
Total Sales Black nos muestra únicamente las ventas para productos negros, aún cuando en las filas de la visualización el contexto de filtrado indica colores diferentes.
La fórmula comienza la evaluación en el contexto de filtros actual donde el único color es por ejemplo Blue, acto seguido, CALCULATE modifica el contexto de filtros (Color = Black) reemplazando el filtro en color Azul por Negro.
La única columna para la cual CALCULATE sobrescribe la selección es Color, cualquier otra columna mantiene sus filtros ya que no se encuentra incluida en la función.
FILTAR MÚLTIPLES COLUMNAS
En el caso que quisiéramos filtrar una condición mas compleja, por ejemplo todas aquellas ventas en donde el precio unitario es dos o más veces el costo:
En esta ocasión el condicional involucra dos columnas: Unit Cost y Unit Price. La sintaxis anterior no esta permitida ya que durante algoritmo de evaluación la función CALCULATE no especifica si la condición debe de reemplazar filtros existentes en Unit Price, Unit Cost, ambas o ninguna.
La forma correcta de invocar CALCULATE cuando tenemos más de una columna sería:
En vez de utilizar una expresión Booleana, utilizamos una expresión tabular pare el argumento de filtrado. No estamos filtrando en base a una sola columna, estamos filtrando la tabla completa de Product.
En este caso CALCULATE evalúa la condición: El resultado de FILTER es una tabla que contiene todas las columnas de Product. Utilizando la tabla como primer parámetro de FILTER estamos reemplazando todas las condiciones preexistentes en todas las columnas de la tabla.
JERARQUÍAS DE EVALUACIÓN
CALCULATE como primer paso evalúa los argumentos de filtrado (línea 4).
FILTER itera sobre la tabla Sale (línea 5). Sin embargo solo puede acceder a los valores de Sale en el contexto actual de filtrado.
CALCULATE crea un nuevo contexto de filtros después de evaluar los argumentos de filtrado. Por lo tanto Sale en la línea 5 se refiere únicamente a los productos visibles dentro del contexto de filtros original.
Los parámetros de filtrado en CALCULATE son evaluados dentro del contexto original de filtros y solamente después de esto se crea el nuevo contexto de filtros para calcular la expresión de la función.
Si quisiéramos un campo calculado que computara el total de productos de alta rentabilidad independientemente del contexto de filtros actual, tenemos que anteponer ALL a la tabla de Product.
En este caso FILTER itera no solamente en los productos de un solo color sino que itera sobre todos los productos.
Esta medida nos muestras las ventas para todos los productos de alta rentabilidad ignorando así cualquier filtro preexistente en Color.
OPERADORES CALCULATE
Nos permiten sobrescribir un contexto de filtros al nivel de columnas individuales
Eliminar filtros existentes previamente (ALL)
Agregar filtros (KEEPFILTERS)
En DAX trabajamos manipulando filtros con los siguientes operadores internos:
INTERSECT (múltiples filtros en CALCULATE)
OVERWRITE (CALCULATE anidados)
REMOVEFILTERS (cuando uttilizamos ALL)
ADDFILTER (usando KEEPFILTERS)
INTRODUCCIÓN A TIME INTELLIGENCE
DAX incluye funciones de Time Intelligence las cuales nos permiten cambiar los filtros de fechas durante su cálculo para así poder analizar y comparar diferente periodos de tiempo incluyendo: días, meses, cuartos, años, etc.
Normalmente cualquier modelo de datos contiene una tabla calendario. En caso contrario es preciso crear una tabla calendario o de fechas de manera que podamos utilizar algunas funciones DAX más avanzadas.
Definir una tabla de fechas o calendario separada de nuestras tablas de hechos representa una mejor práctica en cualquier esquema estrella.
TIPOS DE FUNCIONES TIME INTELLIGENCE
Agregaciones
Totales Acumulativos: Mes, Cuarto, Año a la fecha
DATESYTD, DATESMTD, DATESQTD
Comparativos
vs Dia, Mes, Cuarto, Año pasado o futuro
DATEADD, SAMEPERIODLASTYEAR, PARALLELPERIOD
Medidas semi-aditivas y no aditivas
Saldos de cuentas, inventarios, etc.
LASTNONBLANK, OPENINGBALANCEMONTH, FIRSTDATE, LASTDATE, CLOSINGBALANCEYEAR, etc.
TABLA DE FECHAS
Todas las funciones de Time Intelligence necesitan una tabla de fechas para funcionar adecuadamente:
Puede ser construida en Power Query, DAX (CALENDAR, CALENDARAUTO), SQL, etc.
En ocasiones ya existe dentro de nuestra base de datos relacional, ERP, etc.
Propiedades de la tabla de fechas
Todas las fechas deben estar presentes, sin espacios
Del 1 ° de enero al 31 ° de diciembre para cada año
Debemos de marcar la tabla como de fechas en Power BI
MANDAMIENTOS TIME INTELLIGENCE
Nunca uses la columna de fecha y tiempo de la tabla de hechos en las funciones de time intelligence.
Siempre crea una tabla dimensional de fechas separada del resto.
Asegúrate de que tu tabla de fechas tenga un intervalo de fechas continuo (años completos sin días faltantes).
Asegúrate de marcar la tabla de fechas en Power BI.
Crea una relación entre la(s) tabla(s) de hechos y la tabla de fechas.
Verifica que las relaciones se basen en una columna de tipo fecha y hora (y NO en otra columna artificial).
La columna de fecha y hora en la tabla de fechas debe estar en una granularidad de día (sin fracciones de día).
TOTALES MÓVILES
En ocasiones queremos acumular el total de los últimos X días, meses o años a la fecha actual en el contexto de filtrado.
DATESINPERIOD compila una tabla con todas las fechas comprendidas en un número determinado de períodos, comenzando por una fecha de referencia.
Microsoft Power BI es una gran herramienta para crear dashboards e informes de Business Intelligence e incluye varios gráficos y gráficos de alta calidad. Además de los gráficos incorporados, hay más de 170 gráficos personalizados que puedes descargar de forma gratuita desde el Marketplace.
¿No está segur@ de cómo elegir los medios visuales correctos para tus reportes o dashboards entre todos estos recursos?
Esta referencia tiene como objetivo guiarte en esa decisión.
¿QUÉ ES EL SERVICIO WEB DE POWER BI?
Power BI es una colección de servicios de software, aplicaciones y conectores que funcionan conjuntamente para crear, compartir y consumir información empresarial
El servicio Microsoft Power BI (app.powerbi.com), que a veces se conoce como Power BI en línea, es la parte SaaS (software como servicio) de Power BI
Este servicio basado en la nube nos permite compartir con distintos usuarios los reportes creados en Power BI Desktop, de manera que puedan acceder a los mismos a través de un navegador web o aplicaciones móviles
INFORMES
Un informe en el servicio web de Power BI es una combinación de múltiples elementos visuales (gráficos, textos, valores, etc.) que pueden estar relacionados entre sí y que están contenidos en una o varias páginas
La información visualizada en el informe puede ser seleccionada y filtrada a través de slicers
Un informe en Power BI es completamente interactivo y dinámico para el usuario final
Los informes están diseñados para que los usuarios puedan manipular y filtrar la información de acuerdo a sus necesidades
PANELES
Un panel en Power BI es una vista de alto nivel de algunos de los indicadores clave de desempeño (KPIs) más importantes provenientes de uno o varios informes
Con un panel de visualización, los elementos de múltiples informes y páginas se pueden anclar a un lugar principal donde se pueden ver juntos en un solo vistazo
Los paneles funcionan como puntos centrales de navegación para informes más detallados
El objetivo de un panel no es proporcionar interactividad al usuario sino simplemente presentar una vista rápida de la información más importante para ayudar en la toma de decisiones ejecutivas
CONJUNTOS DE DATOS
Un conjunto de datos es donde residen el modelo, la estructura y los datos en Power BI
Un conjunto de datos puede ser utilizado para crear múltiples informes o puede ser creado en un solo informe
Un informe no puede existir sin un conjunto de datos (en la opción de importar datos)
Un conjunto de datos es el lugar donde se configura la conexión a la(s) fuentes u orígenes de datos
Cada conjunto de datos tiene varias opciones de configuración entre las que destacan: seguridad y actualizaciones
ÁREA DE TRABAJO (WORKSPACE)
Las áreas de trabajo o worskpaces fueron creadas para cubrir las limitaciones o desventajas de compartir objetos individualmente, ya que nos permiten otorgar accesos de edición así como compartir múltiples objetos a la vez
Un área de trabajo es un entorno compartido para un grupo de colaboradores. Un workspace puede contener cientos de informes, paneles y conjuntos de datos
Una misma cuenta de Power BI (usuario) puede tener acceso a múltiples áreas de trabajo, así como varias cuentas pueden tener acceso al mismo workspace
La única manera de añadir contenido a un área de trabajo (por el momento) es publicándolo desde Power BI Desktop
Después de publicar contenido a un workspace, todos los miembros del mismo incluido el autor tendrán acceso a dicho contenido
Se pueden establecer dos niveles de acceso para todos los miembros de un área de trabajo: Edición y Solo Lectura
VENTAJAS
Podemos compartir múltiples objetos en un solo lugar
Se pueden crear múltiples áreas de trabajo de acuerdo a las necesidades organizacionales
Sincronización con grupos de Office 365
Mejor opción para entornos de desarrollo
DESVENTAJAS
No son ideales para compartir contenido con usuarios finales
No hay separación entre entornos de desarrollo y producción
Cambios en el contenido de un área de trabajo se reflejan inmediatamente al usuario final
EN RESUMEN
Las áreas de trabajo o workspaces nos permiten otorgar dos tipos de acceso: Edición y Solo Lectura. Debido a esto, son ideales para crear entornos colaborativos de desarrollo en Power BI. Múltiples desarrolladores pueden acceder al mismo contenido dentro de un área de trabajo.
Las áreas de trabajo no representan la mejor alternativa para compartir contenido con usuarios finales debido a la falta de separación entre entornos de producción y desarrollo, cualquier cambio en un área de trabajo afecta al usuario final de manera inmediata.
APLICACIONES (POWER BI APPS)
Las aplicaciones en Power BI son una mejora a los dos métodos descritos con anterioridad: compartir objetos individualmente y a través de áreas de trabajo
El método de Power BI Apps proporciona un enfoque integral para compartir contenido con usuarios finales
Con las aplicaciones de Power BI, podemos compartir contenido con los usuarios finales, sin la preocupación de cambiar algo en el entorno de desarrollo
Una aplicación se puede compartir con un grupo de personas o con toda la organización
VENTAJAS DE UTILIZAR APLICACIONES PARA COMPARTIR CONTENIDO
Una de las ventajas de utilizar aplicaciones de Power BI es la capacidad de tener dos entornos separados; uno para desarrolladores y otro para usuarios finales
Una aplicación siempre está asociada a un área de trabajo. El área de trabajo es el entorno de desarrollo y la aplicación el del usuario final
Los cambios en un área de trabajo no afectan el entorno de producción hasta que se actualiza manualmente la aplicación
POWER BI APPS Y LA ACTUALIZACIÓN DE DATOS
El proceso de actualización de datos es independiente al entorno de desarrollo o de usuarios finales
Una vez configurada la actualización de datos, los usuarios siempre tendrán acceso a datos actualizados, sin importar si se encuentran en un área de trabajo o en una aplicación
Solo es necesario actualizar las aplicaciones para cambios estructurales (agregar, modificar o eliminar tablas, campos, relaciones, cálculos) y/o cambios en visualizaciones
Compartir contenido individualmente: El método más fácil y rápido de compartir contenido de manera segura, para compartir versiones preliminares o de prueba
Áreas de trabajo: Ideales como entornos de colaboración para grupos de desarrolladores en Power BI
Aplicaciones: La mejor opción para compartir contenidos con usuarios finales, separación entre el entorno de desarrollo y el de producción
Publicar en la web: El único método gratuito para compartir en Power BI, se utiliza solamente para información pública que no sea confidencial
Descubre el poder de Power BI en nuestro emocionante curso diseñado especialmente para Analistas de Negocio. Si estás buscando aprovechar al máximo esta poderosa herramienta de inteligencia empresarial, ¡este curso es perfecto para ti!
En "Power BI para Analistas de Negocio", te sumergirás en el mundo del análisis de datos y la visualización interactiva. Aprenderás a utilizar Power BI de manera efectiva para transformar datos complejos en información valiosa que impulsa la toma de decisiones estratégicas.
Con la guía de nuestros instructores expertos, adquirirás las habilidades necesarias para importar y combinar datos de diversas fuentes, limpiarlos y prepararlos para su análisis. Aprenderás a utilizar Power Query para dar forma a los datos, aplicar transformaciones y crear consultas personalizadas que se ajusten a tus necesidades.
Dominarás el lenguaje DAX (Data Analysis Expressions) y aprenderás a crear medidas y cálculos avanzados para obtener insights significativos. Descubrirás cómo construir modelos de datos sólidos y efectivos que respalden tus análisis y te permitan responder preguntas críticas para tu negocio.
En cuanto a la visualización, explorarás las capacidades de Power BI para crear informes y paneles interactivos. Aprenderás a utilizar diferentes tipos de visualizaciones, aplicar filtros, agregar interactividad y contar historias impactantes a través de tus datos.
Este curso está diseñado para que puedas aprender a tu propio ritmo, desde cualquier dispositivo con acceso a internet. Ya seas un analista de negocio en busca de habilidades adicionales o un estudiante interesado en adentrarte en el mundo del análisis de datos, este curso te brindará las herramientas necesarias para destacarte en tu campo.
No pierdas la oportunidad de convertirte en un experto en Power BI para Analistas de Negocio. ¡Inscríbete en nuestro curso y descubre cómo aprovechar al máximo esta poderosa herramienta en beneficio de tu organización y tu carrera profesional!