Warning: Cannot modify header information - headers already sent by (output started at /home/content/23/3939523/html/index.php:3) in /home/content/23/3939523/html/wp-includes/feed-rss2.php on line 8
Amby.Net http://amby.net Business Intelligence con SQL Server y más Mon, 02 Apr 2018 07:30:44 +0000 es-ES hourly 1 https://wordpress.org/?v=4.9.5 http://amby.net/wp-content/uploads/2016/03/cropped-logo-32x32.png Amby.Net http://amby.net 32 32 Mi visión del VI Encuentro PUG Madrid http://amby.net/2018/04/02/mi-vision-del-vi-encuentro-pug-madrid/ http://amby.net/2018/04/02/mi-vision-del-vi-encuentro-pug-madrid/#respond Mon, 02 Apr 2018 07:30:44 +0000 http://amby.net/?p=9588 Hoy, voy a hablar de nuevo de un evento, esta vez de comunidad Power BI.

Hace unos días, el pasado 19 de Marzo, se celebró el 6to Encuentro del Grupo de Usuarios de Power BI en España, de forma presencial en las oficinas de Microsoft, Madrid.

Estos encuentros resultan altamente instructivos, la temática que se debate en ellos es muy variada, aunque gira en torno a Power BI. He asistido a todos y estoy encantada, de verdad. Es un marco para todos, los que inician pueden asimilar la experiencia y vivencias de los ya iniciados y entre todos se produce un ritmo de aprendizaje continuo, es una mezcla de trabajo serio, compartido con muy buen humor. El material que se imparte es de calidad.

Me llevé, como siempre, muchos apuntes. Hubo lecciones aprendidas que pude compartir al día siguiente con mis alumnos, sin dilación 🙂

El evento, pudo ser grabado, se transmitió en streaming, con sus altas y bajas; pero el vídeo está bien, enhorabuena !!!

En esta ocasión los temas tratados fueron:

Azure Machine Learning, R, Excel y Power BI – la sesión resultó muy instructiva, tomé apuntes. Yo desconocía, entre otras, que existiese un paquete AzureML, me parece muy interesante, tengo que sacar tiempo para probarlo.

Hololens y PowerBI, queda un largo camino por andar en este sentido; pero ya se comienzan a integrar y conseguimos ver cómo funciona. Vimos unos vídeos que emplean este tipo de tecnologías y auguran un futuro muy interesante en este sentido.

BI de Tiempos con Power BI, esta fue mi sesión, estuvo dedicada a ver cómo se trabaja con columnas tipo fecha en las consultas, en el modelo tabular y en las visualizaciones. El tiempo es oro y se mide con Power BI :), me encantó hacer esta presentación, el tratamiento de fechas da para mucho, aprendí muchísimo preparándola, aprendí, por ejemplo, a crear rangos de tiempos dinámicos a partir del código del maestro Chris Webb, esto lo he podido compartir con mis alumnos.

Uso de conectores, novedades en Tooltip y mucha creatividad con informes Power BI, la presentación fue muy interesante, tomé muchísimos apuntes, sobre el nuevo conector,  data world, tengo pendiente darme de alta y empezar a bucear entre tantos recursos. Además del tema, que fue sobre la felicidad y la presentación fue muy amena, vimos en funcionamiento los Tooltips en páginas de Power BI, como dije, una sesión muy útil e interesante.

Trabajo con mapas ArcGis, muy ilustrativa la sesión, me gustó mucho, también tomé muchos apuntes, se integra muy bien con Power BI También tuve ocasión de compartir con mis alumnos las funcionalidades, que aprendí en el encuentro, a los largo de estos días desde el evento.

He asistido a los seis encuentros presenciales que se han desarrollado, estoy presentando sesión desde el tercero, me preparo con muchísima alegría y lo disfruto siempre, es una suerte poder participar y compartir experiencias en estos encuentros. Hay tiempo para el intercambio durante la pausa, con o sin café 🙂 y al finalizar, por lo general, una quedada para una cerveza, o similar, lo importante es participar y compartir.

¿Cómo se llega a estos eventos?

El grupo de usuarios funciona como un meetup, hay que darse de alta de forma gratuita desde PUGSpain Los miembros reciben la información sobre los eventos, la invitación a participar y los recursos compartidos..

Además, como todos los grupos de usuarios que pertenecen oficialmente a la comunidad PUG, hay que darse de alta

Luego, debemos buscar el PUG correspondiente a España y cualquier otro que se ajuste a nuestros intereses.

Les invito a inscribirse, es gratis, se publican los recursos de los encuentros, se intercambian dudas y soluciones en los foros y como suele ser en el trabajo de comunidad, ganamos todo. Muchísimas gracias a todos los que hacen posible el evento, especialmente a Jesús López Martín, líder de la Comunidad Power BI en España.

]]>
http://amby.net/2018/04/02/mi-vision-del-vi-encuentro-pug-madrid/feed/ 0
Eventos: Estuve en SQLBits http://amby.net/2018/03/12/eventos-estuve-en-sqlbits/ http://amby.net/2018/03/12/eventos-estuve-en-sqlbits/#respond Mon, 12 Mar 2018 08:30:09 +0000 http://amby.net/?p=9543 Interrumpí la serie de Escenarios de Modelado con DAX para hablar de los eventos y la comunidad.

Hace muchos años que trabajo por cuenta propia, por lo que no tengo lo que se dice un equipo de trabajo, mis compañeros de trabajo se encuentran en las empresas con las que colaboro y cómo no, en la Comunidad. ya sea en una comunidad de desarrolladores de Visual FoxPro, de analistas del mundo Business Intelligence y en los últimos años, especialmente la comunidad dedicada al trabajo con Modelos tabulares y Power BI.

El trabajo de un grupo de usuarios se vive intensamente en las redes sociales, Twitter y Linkedin fundamentalmente y se vive de forma presencial en los meetups y grandes eventos.

Hace un par de semanas estuve, por primera vez, en SQLBits. (No lo pude contar antes, porque una conjuntivitis me sacó de circulación) 🙁

Regresé encantada, 🙂 me la pasé muy bien, aprendí muchísimo, intercambié con mucha gente y me enfrenté a un formato de evento totalmente diferente, con miles de asistentes (me asusté un poco al inicio, pensé que nos íbamos a tropezar, de verdad); pero hubo espacio para todos, grandes salones, muchísimas sesiones a la vez, un lujo de participantes, ponentes, voluntarios y patrocinadores. Hubo bastante presencia española, me encantó conocerles e intercambiar cada vez que hubo oportunidad. La organización de 10. Tal y como estaba previsto, hubo muchos conocidos y tuve la oportunidad de conocer a otros asistentes y ponentes maravillosos, es imposible nombrar a tanta gente, muchos y muy buenos, gracias !!!. Se notaba la preocupación por la seguridad de todos (custodios a la entrada y perros policías controlando el perímetro todo el tiempo, sin molestar; pero dejándose ver). La gente fue muy amable y generosa con las explicaciones, ante cualquier duda, preocupación o necesidad.

Asistí a los dos días de Training, jornada completa, a cargo de los maestros Alberto Ferrari y Marco Russo. Me traje de regreso muchísimo material para preparar y luego compartir con mis alumnos. Vaya par de jornadas más ilustrativas, un lujazo, un #HappyDAXing en toda regla. En los recesos pude aprovechar y saludar a otros participantes y profesores que ya conocía: Dejan Sarka, Steph Locke, Mark Wilcock y pude conocer a: Adam Saxton & Patrick LeBlanc y otros muchos.

El primer día de sesiones, el 23, asistí a:

  • DirectQuery in Power BI and Analysis Services – Marco Russo
  • Best practices for Power BI on implementation and monitoring – Bent Nissen Pedersen
  • PowerBI-Model Designs – Neil Hambly
  • DAX Optimization Examples – Alberto Ferrari
  • Understanding the Power BI data model – Kasper de Jonge
  • Power BI Report Server: A Deep Dive – Patrick LeBlanc

El 24, último día, asistí a:

  • Advanced Techniques for Cleaning Data using SQL Server – Jen Stirrup
  • Its Here! The Newly Remodeled SQL Server Reporting Services  – Tim Mitchell
  • Power BI security deep dive – Kasper de Jonge
  • Data Overview and Manipulation – T-SQL, R, Python – Dejan Sarka

Además, participé en una sesión muy interesante, Lightning Talks, cuyo formato desconocía por completo. En esta sesión participamos 8 ponentes, seleccionados previamente el día anterior, a partir de las propuestas entregadas durante el evento, el tiempo de exposición fue de 5 minutos, un jurado de expertos evaluó las intervenciones, un público muy entusiasta que aplaudió alzando las manos, para no molestar a las otras salas, temas muy variopintos, cierto toque de humor y algo de valor, sólo 5 minutos para introducción-desarrollo y conclusiones 🙂 Yo presenté un par de escenarios de modelado para escoger entre columnas calculadas y medidas, en ambos, ganaron las medidas, además, introducción y conclusiones ¡¡¡ y me sobraron 45 segundos !! Fue genial la oportunidad, de verdad, me la pasé estupendamente y el feedback del jurado fue muy bueno. Nunca supe quien ganó el premio, para mí era lo de menos, está claro que no fui yo, lo dieron al final del evento, por la tarde, yo me tuve que marchar al aeropuerto, justo antes de la última sesión. Estoy muy agradecida por el reto y la oportunidad.

En cuanto a temas, el evento estuvo muy bien servido, me quedaron muchísimas cosas por ver, hubo de todo: Administración Power BI, Manipulación de datos, Modelado, DAX, Visualización, SSRS, R, una maravilla !!! Y mil cosas más que no se ajustan al perfil en el que trabajo.

Este evento organizó actividades para tardes y noches, todo muy divertido, hubo un concurso de conocimientos de temas variados, nada técnico, cerveza y cena incluidas, con equipos de 6 personas mínimo, vaya diversidad en nuestra mesa: venía la gente de Alemania, Suecia, Grecia, Australia, Polonia y España 🙂 no ganamos nada; pero nos la pasamos de bien !!! La noche siguiente hubo una fiesta de disfraces con la magia como tópico, me disfracé de McGonagall y hubo quien lo adivinó, muy chulo, cena, bebida, disfraces, diversión, excelente !!!

Y hasta el clima se portó bien, mucho frío; pero mucho sol, una maravilla, no olvidemos que es Londres !!!

Bonus track 🙂

Tuvimos la oportunidad adicional de participar en una reunión del PUGPower BI User Group de LondresAn evening with #PowerBI Experts, un lujo de encuentro con maestros y expertos, entre otros:  Alberto Ferrari y Marco Russo, Chris Webb, Mark Wilcock, Kasper de Jonge, Adam Saxton & Patrick LeBlanc, y quizás me esté dejando alguno, una maravilla, divertidísimo, la pasamos estupendamente. El formato del encuentro fue muy bueno, primero una charla y luego “barra libre”… no, no de cerveza 🙂 de preguntas a los expertos y de networking. Excelente idea de los compañeros y amigos del London PUG, muchísimas gracias.

Una maravilla de evento, que he contado cada vez que he podido, en Twitter !!

En la próxima entrada, vuelvo a los temas técnicos, siento el retraso; pero entre el evento y la conjuntivitis, todo quedó paralizado. Seguiré la serie Escenarios DAX, justo donde la dejamos. Modelo tabular y relaciones y hablaremos del filtro cruzado.

]]>
http://amby.net/2018/03/12/eventos-estuve-en-sqlbits/feed/ 0
Eventos: Me voy al SQLBits http://amby.net/2018/02/20/eventos-me-voy-al-sqlbits/ http://amby.net/2018/02/20/eventos-me-voy-al-sqlbits/#respond Tue, 20 Feb 2018 08:30:30 +0000 http://amby.net/?p=9485 Esta semana voy a interrumpir la serie de Escenarios de Modelado con DAX para hablar de los eventos y la comunidad.

Hace muchos años que trabajo por cuenta propia, por lo que no tengo lo que se dice un equipo de trabajo, mis compañeros de trabajos se encuentran en las empresas con las que colaboro y cómo no, en la Comunidad. ya sea en una comunidad de desarrolladores de Visual FoxPro, de analistas, del mundo Business Intelligence y en los últimos años, especialmente la comunidad dedicada al trabajo con Modelos tabulares y Power BI.

El trabajo de un grupo de usuarios se vive intensamente en las redes sociales, en Twitter y Linkedin fundamentalmente y se vive de forma presencial en los eventos.

Cada evento al que he tenido la oportunidad de asistir ha sido un privilegio, una experiencia, una fiesta del conocimiento. Los disfruto mucho.

Hay eventos de todos los tipos, en cuanto a contenidos, objetivos y costes. Hay eventos gratuitos, hay eventos de pago asociados a la comunidad por lo que sus precios son reducidos, hay eventos de pago, sin reducción de precio, hay eventos muy caros (al menos para mí). Todo depende de los objetivos, aspiraciones y posibilidades de cada uno.

En España, suelo participar, entre otros, en los meetups de:

  • PASS_ES (Capítulo Professional Asosiation SQL Server en Spain), radicado en España y en casa de todos y cada uno de los que participamos en los eventos online o presenciales, según sea la oportunidad nos reunimos varias veces al año y celebramos una fiesta espectacular, SQL Saturday, suele ser el tercer sábado de septiembre,  vete preparando, la fecha del 22 de septiembre… puede ser, puede ser…
  • PUG Spain (Grupo de usuarios de Power BI), está radicado en Madrid, con varias reuniones al año donde se combinan técnicos, como yo, dedicados a trabajar con estas herramientas con los llamados “clientes o usuarios finales”, los verdaderos genios que saben exprimir todo el jugo de una herramienta tan maravillosa como Power BI. El próximo encuentro ya tiene fecha, para el próximo 19 de Marzo, en un mes !!!

Fuera de España, he asistido a SQLSaturday en Lisboa, Edimburdo, Copenhagen y Oporto (como ponente de dos sesiones). Me gusta muchísimo el formato de este evento. Uno de los grandes atractivos de estos eventos es que las sesiones pre-evento, que se desarrollan los jueves y viernes antes al SQLSaturday suelen tener precios muy reducidos. Las jornadas de los sábados son totalmente gratuitas, el único problema real es decidir entre tantas y tantas sesiones de calidad que no te quieres perder. He podido disfrutar de una jornada de 8 horas con figuras de primerísimo nivel por unos 100.00 € o 120.00 €. Y a veces, además hemos conseguido combinar, de maravilla, el viaje de trabajo con algo de turismo familiar. Todas son ventajas. Desafortunadamente, también he cancelado más de uno y más de dos, por razones personales. Por eso, cada vez que consigo asistir, se convierte para mí en un gran regalo.

He estado más de una vez en TUGA.IT, en Lisboa, me encantan los eventos en Portugal, desde España es muy cómodo viajar, la gente es entrañable y consiguen unos invitados de lujo.

El pasado año estuve dos veces en Londres, en dos eventos de comunidad, UK Power BI Summit y  Power BI World Tour dos eventos excelentes !!! Ya se que me repito, es una suerte, un regalo, una oportunidad para compartir y disfrutar.

Y esta semana, por primera vez, me voy al SQLBits, me hace muchísima ilusión, es en Londres, qué maravilla de ciudad. Habrá muchos conocidos y la oportunidad de conocer a otros muchos.

En su formato, hay dos días de Training, jornada completa. Yo me voy a decantar, los dos días, por los maestros Alberto Ferrari y Marco Russo que como siempre es una suerte tenerlos cerca y que te cuenten de primera mano las maravillas del DAX, #HappyDAXing !!! Hay muchas opciones, ¡qué barbaridad de convocatoria! 🙂 12 opciones un día y 14 opciones el siguiente, gente de la talla de Mark Wilcock, Itzik Ben-Gan, Adam Saxton & Patrick LeBlanc, Tim Mitchell, Dejan Sarka, Chris Webb, Steph Locke y otros muchísimos más. No tiene desperdicio.

Luego hay dos días de sesiones, dos días de mucho networking, muchos temas, variedad, en fin.

El primer día de sesiones, el 23, lo pienso dedicar a:

  • DirectQuery in Power BI and Analysis Services – Marco Russo
  • Best practices for Power BI on implementation and monitoring – Bent Nissen Pedersen
  • PowerBI-Model Designs – Neil Hambly
  • DAX Optimization Examples – Alberto Ferrari
  • Understanding the Power BI data model -Kasper de Jonge
  • Power BI Report Server: A Deep Dive – Patrick LeBlanc

Para el 24, ultimo día, tengo pensado asistir a:

  • What Power BI users need to know about R – Nico Jacobs
  • Its Here! The Newly Remodeled SQL Server Reporting Services  – Tim Mitchell
  • Power BI security deep dive – Kasper de Jonge
  • Dimensional Modeling: Beyond the Basics – Jason Horner
  • Data Overview and Manipulation – T-SQL, R, Python – Dejan Sarka
  • 60 Reporting Tips in 60 Minutes – Ike Ellis

Así es que habrá de todo: Administración Power BI, Manipulación de datos, Modelado, DAX, Visualización, SSRS, R, una maravilla !!!

Al regreso, os cuento qué tal fue y desde luego, en Twitter !!

 

 

 

 

]]>
http://amby.net/2018/02/20/eventos-me-voy-al-sqlbits/feed/ 0
DAX: Relaciones y Cálculos II http://amby.net/2018/02/19/dax-relaciones-y-calculos-ii/ http://amby.net/2018/02/19/dax-relaciones-y-calculos-ii/#respond Mon, 19 Feb 2018 08:30:31 +0000 http://amby.net/?p=9472 Este escrito forma parte de la serie: Escenarios de Modelado con DAX

Algunos de los recursos que he consultado sobre Modelado tabular y DAX los podemos encontrar en Modelos tabulares y DAX – Recursos

En la entrada anterior hablamos de las Relaciones en el Modelo tabular, hablé de los roles que cumplen las tablas a cada lado de la relación y dije que conocer estos aspectos es importante para entender cómo trabajar con columnas que se encuentren en tablas diferentes. Y al final, me despedí con un problema, al aplicar según qué filtro, el resultado de las columnas calculadas ya dejaba de ser coherente.

Esta es la imagen.

Un poco de teoría primero, para ponernos en situación. Un modelo tabular está compuesto por tablas y sus relaciones.

Nuestro modelo de ejemplo, está compuesto por cuatro tablas y sus relaciones. Tiene un diseño de modelo en Estrella – Modelo Denormalizado. Todas las tablas de búsquedas o dimensiones, Productos, Fechas y Clientes apuntan directamente a la tabla de hechos, Ventas.

Antes de solucionar el problema que hemos visto, permitirme que cierre los escenarios. Antes, creamos tres casos, vamos a por el último hoy.

Necesidad de funciones de navegación

Caso 4.- Crear columnas a partir de medidas. No hay necesidad de funciones de navegación.

Vamos a agregar una nueva columna a la tabla Producto, con la siguiente expresión DAX:

Importes desde Medida = [Total Importe]

Veamos el resultado, de momento, sin filtros

Todos los resultados son iguales. La diferencia está en las expresiones y en el uso, o no de las funciones de navegación

Dijimos que al trabajar con columnas de tablas distintas es necesario utilizar las funciones de relación o navegación

RELATED() – Sigue la relación M:1 y devuelve el valor de la columna

RELATEDTABLE() – Sigue la relación 1:M y devuelve todas las filas que se relacionan con la fila actual

Sin embargo, si utilizamos directamente una medida, no necesitamos las funciones de navegación.

Lo que ocurre es que las medidas están envueltas en una función CALCULATE que a su vez es una función muy especial que es capaz de dejar “ver más allá”, deja ver a través de las relaciones de las tablas. El no tener que utilizar funciones de navegación, o relación, reduce muchísimo la complejidad de las expresiones DAX.

Entonces, si aunque podamos y debamos hacer el cálculo desde una medida, no os creéis las advertencia que os hago 🙂 y trabajáis con columnas calculadas 🙁 entonces, una recomendación que os puedo dejar es utilizar como origen para las columnas una medida y no la expresión original que tira de las columnas y exige las funciones de navegación..

Problemas con las relaciones entre tablas, las columnas calculadas, y los filtros

Ahora sí, vamos a regresar al punto donde lo dejamos la entrada anterior. Hablemos de la validez del cálculo para analizar desde columnas calculadas. Hablemos de filtros.

Para comprender lo que ha ocurrido, tenemos que volver a hablar de las desventajas de utilizar columnas calculadas vs medidas.

En cualquier caso, debo repetir, hasta la saciedad, que lo mejor es trabajar directamente con medidas, que ambas columnas calculadas en la tabla Producto, son innecesarias.

Error al trabajar con columnas calculadas

En esta tabla, se muestra la medida Total Importe y las dos columnas calculadas: Importes desde Medida e Importes

Caso 1.- Vamos a filtrar por una columna de la propia tabla Productos, en este caso, por Categorías.

Como vemos no hay problemas, filtra correctamente y los valores de todas las columnas coinciden.

Caso 2.- Vamos a filtrar por una columna de cualquier otra tabla:  Fecha.

Ya no hay coincidencia

Lo mismo ocurre si filtramos por una columna de la tabla Clientes. Lo podemos ver en una tabla

O lo podemos ver en una matriz

Conclusión: El análisis desde las columnas sólo es correcto si se filtra por columnas de la misma tabla.

Vamos de nuevo al diagrama de tablas y relaciones

El filtro se propaga desde el lado Uno al lado Muchos de la relación, se propaga desde Clientes a Ventas; pero no sigue su camino hacia la tabla Productos por lo que no se ven afectadas las filas de la tabla Productos, no se aplica el filtro y la suma se mantiene igual. Lo mismo pasa al filtrar por Fecha, se propaga desde Fechas a Ventas y no sigue hasta Productos.

Por su parte, la medida recorre las filas visibles de la tabla Ventas. La visibilidad depende del contexto de filtro, que, en nuestro ejemplo se ve afectado tanto por el filtro que se aplica sobre la tabla Productos, como por los dos que se aplican sobre Clientes y Fechas.

Una vez más, es muy útil, necesario y beneficio trabajar con medidas en Modelos tabulares.

Espero que resulte de utilidad #HappyDAXing !!! 🙂

En la próxima entrada vamos a ver un ejemplo de cómo solucionar escenarios de Filtro cruzado en cálculos DAX en Modelos tabulares con Power BI

]]>
http://amby.net/2018/02/19/dax-relaciones-y-calculos-ii/feed/ 0
DAX: Relaciones y Cálculos I http://amby.net/2018/02/16/dax-relaciones-y-calculos/ http://amby.net/2018/02/16/dax-relaciones-y-calculos/#respond Fri, 16 Feb 2018 08:30:52 +0000 http://amby.net/?p=9459 Este escrito forma parte de la serie: Escenarios de Modelado con DAX

Algunos de los recursos que he consultado sobre Modelado tabular y DAX los podemos encontrar en Modelos tabulares y DAX – Recursos

En la entrada anterior hablamos de las Relaciones en el Modelo tabular, hablé de los roles que cumplen las tablas a cada lado de la relación y dije que conocer estos aspectos es importante para entender cómo trabajar con columnas que se encuentren en tablas diferentes.

Un modelo tabular está compuesto por tablas y sus relaciones.

Nuestro modelo de ejemplo, está compuesto por cuatro tablas y sus relaciones. Tiene un diseño de modelo en Estrella – Modelo Denormalizado. Todas las tablas de búsquedas o dimensiones, Productos, Fechas y Clientes apuntan directamente a la tabla de hechos, Ventas.

Caso 1: Analizar la medida combinando filtros de tablas diferentes: Productos y Clientes

Recordemos la medida: Total Importe = SUMX(Ventas; Ventas[CantidadETL] * Ventas[Precio])

Un primer filtro se propaga desde la tabla Clientes a la tabla Ventas filtrando por cada valor de la columna Nivel Ingresos

Un segundo filtro se propaga desde la tabla Productos a la tabla Ventas filtrando por cada valor de la columna Categoría

Se puede combinar ambos filtros, por ejemplo, en una matriz.

Un tercer filtro se agrega al informe, en forma de Segmentador (Slicer) desde la tabla Fechas

Los tres filtros se combinan y se aplican sobre la tabla Ventas, dejando, en cada caso las filas visibles, según sea la condición de filtro que se aplica. De esta forma podemos operar sin hacer ningún esfuerzo extra con código DAX.

Caso 2: Crear columnas calculadas que combinen columnas de tablas diferentes. Necesidad de funciones de navegación, RELATED()

Recordemos lo comentado en la entrada DAX: Columnas calculadas vs Medidas – I, con relación a la visibilidad entre tablas desde columnas calculadas.

Desde una columna calculada solamente se ven, las medidas creadas en el modelo y las columnas de la propia tabla.

Se nos plantea analizar las ventas teniendo en cuenta la columna Cantidad de la tabla Ventas y la columna PrecioCatálogo de la tabla Productos

He recomendado evitar a toda costa el trabajo con columnas calculadas para definir cálculos, por la cantidad de inconvenientes que tienen. Hoy voy a crear una columna calculada para que comprobemos otro problema que nos puede surgir si no hacemos caso a esta recomendación.

Lo primero que hacemos es intentar realizar el cálculo, Cantidad * PrecioCatálogo y no es posible, IntelliSense no muestra la columna PrecioCatálogo, significa que no está disponible.

Y si pensamos que Intellisense se equivocó, e insistimos, nos aparece el siguiente mensaje de Error

No se puede determinar un valor único para la columna ‘PrecioCatálogo’ en la tabla ‘Productos’. Esto puede suceder cuando una fórmula de medida hace referencia a una columna que contiene muchos valores sin especificar una agregación, como min, max, count o sum, para obtener un resultado único.

Y es porque, aunque las tablas estén debidamente relacionadas, desde una columna calculada no se “ve” la relación y por tanto no se puede “ir más allá”.

Llega el momento de utilizar las funciones de navegación o relación. Estas funciones que son: RELATED Y RELATEDTABLE se encargan de “dejar ver” la relación y permitirnos seguirla e “ir más allá

Si la tabla a la que queremos acceder se encuentra en el lado Uno de la relación, significa que devolverá un único valor. Tiene sentido, cada fila de la tabla Ventas se refiere a la venta de un único producto, cada fila, un producto y ese producto está una única vez en la tabla Productos, por lo que, siguiendo la relación, podemos “traer” el valor de una columna de la tabla que esté relacionada con la actual y que esté al lado Uno de la relación. Resumiendo:

RELATED() – Sigue la relación M:1 y devuelve el valor de la columna

Importes según Catálogo = Ventas[CantidadETL] *
RELATED(Productos[PrecioCatálogo])

Caso 3: Crear columnas que combinen columnas de tablas diferentes. Necesidad de funciones de navegación, RELATEDTABLE()

Si la tabla a la que queremos acceder se encuentra en el lado Muchos de la relación, significa que devolverá un conjunto de filas, que puede ser, un conjunto vacío, de una única fila o de muchas filas, según se haya vendido, o no, el producto. Tiene sentido, cada fila de la tabla Productos se refiere a la venta de un único producto, ya sea ninguna venta, una venta o muchas ventas, por lo que, siguiendo la relación, podemos “traer” el valor de todas las filas de una columna de la tabla que esté relacionada con la actual y que esté al lado Muchos de la relación. Resumiendo:

RELATEDTABLE() – Sigue la relación 1:M y devuelve todas las filas que se relacionan con la fila actual

Importes = SUMX(RELATEDTABLE(Ventas);
Ventas[CantidadETL]*Ventas[Precio])

La siguiente imagen muestra un resumen de los valores obtenidos, los tres casos devuelven el mismo resultado 🙂

Voy a filtrar por Fecha y vamos a notar que ahora los valores obtenidos ya no son iguales 🙁

¿Cómo es posible?¿Cuál es la causa?.. lo vemos en la próxima

Espero que resulte de utilidad #HappyDAXing !!! 🙂

En la próxima entrada vamos a responder estas preguntas. Veremos un ejemplo de errores que ocurren al no trabajar correctamente las relaciones y los cálculos DAX en Modelos tabulares con Power BI

]]>
http://amby.net/2018/02/16/dax-relaciones-y-calculos/feed/ 0
DAX: Introducción a las relaciones del Modelo Tabular http://amby.net/2018/02/13/dax-introduccion-a-las-relaciones-del-modelo-tabular/ http://amby.net/2018/02/13/dax-introduccion-a-las-relaciones-del-modelo-tabular/#respond Tue, 13 Feb 2018 08:30:47 +0000 http://amby.net/?p=9449 Este escrito forma parte de la serie: Escenarios de Modelado con DAX

Algunos de los recursos que he consultado sobre Modelado tabular y DAX los podemos encontrar en Modelos tabulares y DAX – Recursos

Cuando introduje la serie, en la entrada Introducción a DAX, comenté que DAX es el lenguaje de expresiones que permite trabajar con Modelos Tabulares, para enriquecerlo y consultarlo. Un modelo tabular está compuesto por tablas y sus relaciones.

Los modelos pueden ser de distintos tipos:

  • Única tabla – Clásico de Excel, especialmente, antes de MS Office Excel 2013. No se recomienda en lo absoluto, afecta bastante al rendimiento a partir del millón de filas.
  • Copo de nieve – Modelo Normalizado. Existen enlaces entre las tablas de búsquedas o dimensiones que no apuntan directamente a la tabla de hechos

  • Estrella – Modelo Denormalizado. Todas las tablas de búsquedas o dimensiones apuntan directamente a la tabla de hechos

En DAX el modelo estrella es óptimo !!!!!

Veamos aspectos a tener en cuenta para comprender el funcionamiento de las relaciones

  • En la relación, las dos tablas no tienen el mismo rol
    • Lado Uno vs lado Muchos
      • Geografía (lado Uno) vs Clientes (lado Muchos) 1:M (del ejemplo Copo de nieve)
  • Las columnas de unión, claves o llaves
    • En el lado Uno, valores únicos, suele coincidir con la clave de la tabla. No admite repetidos.
  • La relación puede formar una cadena
    • Categoría->Subcategoría->Producto (del ejemplo Copo de nieve)
  • La dirección de la relación, define el filtrado automático
  • No se admiten relaciones sobre múltiples columnas (restricción del motor)
  • Una columna de una tabla puede relacionarse con más de una columna de otra tabla; pero solamente existirá una relación activa en cada momento.

Hablemos del modelo tabular sobre el que estamos trabajando y más concretamente, de las relaciones que existen entre las tablas de nuestro modelo.

La tabla Ventas es la tabla de Hechos, es el centro de nuestro Modelo tabular.

  • Ventas, tiene más filas que ninguna otra, ya que almacena la información de las transacciones. por ejemplo: órdenes, facturación, presupuestos, líneas de contabilidad, contratos, acciones formativas, expedientes, pólizas, servicios realizados (telefonía, por ejemplo), en fin, los hechos, las métricas que estamos analizando y en nuestro caso, las ventas. Almacena columnas que permiten la relación con las tablas Productos, Fechas y Clientes y columnas con las métricas: CantidadETL, Precio y Coste.
  • Ventas, es a la que apuntan todos los filtros.
    • Cuando se calculan las medidas, se trabaja con las filas visibles, en dependencia de los filtros aplicados
    • Se relaciona con todos desde el lado Muchos y los filtros en el modelo tabular se propagan del lado Uno al lado Muchos.
    • Cada Venta se corresponde a un único Cliente y único Producto (M:1)

Las tablas Productos, Fechas y Clientes son tablas de búsquedas o de dimensiones

  • Contienen las columnas que nos van a servir para fragmentar, segmentar o clasificar el resultado de las métricas almacenadas en Ventas
  • Se relacionan con la tabla Ventas desde el lado Uno
  • Crean los filtros necesarios, que se propagarán a Ventas, por la relación Uno a Muchos.
      • Un Producto se puede vender cero, una o Muchas veces (1:M)
      • Un Cliente puede comprar cero, una o Muchas veces (1:M)

Toda esta teoría es necesaria para poder comprender la necesidad y la funcionalidad de las funciones de navegación o relación, así como otros aspectos en los que el diseño del modelo tabular, sus tablas y relaciones influyen directamente en el código DAX que escribamos para enriquecer el modelo y dar respuesta a los requisitos de negocio.

Espero que resulte de utilidad #HappyDAXing !!! 🙂

En la próxima entrada vamos a ver ejemplo de cómo trabajar con las relaciones y los cálculos DAX en Modelos tabulares con Power BI

]]>
http://amby.net/2018/02/13/dax-introduccion-a-las-relaciones-del-modelo-tabular/feed/ 0
DAX: Medidas vs Variables http://amby.net/2018/02/08/dax-medidas-vs-variables/ http://amby.net/2018/02/08/dax-medidas-vs-variables/#respond Thu, 08 Feb 2018 08:30:26 +0000 http://amby.net/?p=9424 Este escrito forma parte de la serie: Escenarios de Modelado con DAX

Algunos de los recursos que he consultado sobre Modelado tabular y DAX los podemos encontrar en Modelos tabulares y DAX – Recursos

Hoy quiero comentar sobre la posibilidad de crear variables para trabajar con expresiones DAX. Es una gran funcionalidad, da legibilidad al código, según el escenario es posible obtener mejor rendimiento al evaluar la expresión, permite evitar medidas innecesarias… todas son ventajas, veamos.

Variables en DAX

Es posible, a partir de la versión DAX 2015, crear variables y emplearlas en el código de una expresión DAX.

Hay que decir que a pesar de su nombre, las variables creadas en expresiones DAX actúan como constantes, ¡¡¿cómo?!! Pues sí, veamos un ejemplo.

Partimos de las mismas medidas que creamos en el caso anterior, donde, de paso sea dicho, solucionamos los problemas que planteaba el trabajo con columnas calculadas.

Total Importe = SUMX(Ventas;Ventas[CantidadETL]*Ventas[Precio])
Total Beneficios = SUMX(Ventas;Ventas[CantidadETL] * (Ventas[Precio] – Ventas[Coste]))
Total % Beneficios = DIVIDE([Total Beneficios];[Total Importe])

Digamos, que en nuestro modelo, lo único que necesitamos plasmar en el informe es Total % de Beneficio, que no utilizaremos las medidas Total Importe ni Total Beneficio.

Veamos las opciones de las que disponemos:

  • Escribir toda la lógica del cálculo en una única expresión DAX.
    • No es una mala idea, aunque según sea el caso, puede llegar a ser compleja la lectura y depuración.
    • Para ello creamos una nueva medida DAX, cuya expresión es:

Total % Beneficio v2 =
DIVIDE(
SUMX(Ventas;Ventas[CantidadETL] * (Ventas[Precio] – Ventas[Coste]));
SUMX(Ventas;Ventas[CantidadETL]*Ventas[Precio])
)

  • Mantener las dos medidas que creamos antes y ocultarlas ya que no van a ser utilizadas en los informes.
    • Solo nos sirven para solucionar el requisito por etapas.
    • En este caso Total Beneficio es el numerador mientras que Total Ventas es el denominador.
    • Para ocultar una medida, o cualquier objeto del modelo tabular que no queremos que sea visible para la herramienta destino, una opción es desde el panel de Campos, en el Power BI Desktop, seleccionar la medida y con el menú contextual, seleccionar Ocultar. Todos los elementos ocultos se encuentran disponibles para cálculoa previos y/o futuros.

  • Trabajar con variables, que es nuestro objetivo hoy 🙂

 

Trabajar con variables en Modelos tabulares

Un breve resumen:

  • Las variables se pueden utilizar dentro de las expresiones DAX
  • Es posible crear y consumir más de una variable en una expresión de cálculo en DAX
  • Como requisitos de sintaxis, van precedidas de la palabra VAR y para ser evaluadas se precisa de la palabra RETURN
  • En el momento en que sean invocadas, se evalúan una única vez y se tratan como constantes
  • Una de las ventajas es que permite ver toda la lógica de negocio de una expresión compleja, que ha sido dividida en partes
  • Permite crear expresiones más legibles
  • Según sea el escenario, posibilitan un mejor rendimiento del modelo

Vamos a utilizar la misma lógica de negocio, expresada antes en medidas, ahora con variables

  • Lo primero, es definir las expresiones para las variables

  • Luego, definir la expresión que evalúa o consume las variables.

Intellisense, acude, una vez más a nuestra ayuda, mostrando las variables disponibles

  • Hasta que obtenemos toda la expresión DAX que necesitamos

  • Esta es la expresión DAX resultante.

Total % Beneficio v3 =
VAR Importes = SUMX(Ventas;Ventas[CantidadETL]*Ventas[Precio])
VAR Beneficios = SUMX(Ventas;Ventas[CantidadETL] * (Ventas[Precio] – Ventas[Coste]))
RETURN
DIVIDE(Importes;Beneficios)

Hemos creado una medida, para obtener Total % Beneficio a partir de la evaluación de dos variables: Importes y Beneficios, que a su vez, se han creado y definido dentro de la propia medida, ambos valores, al ser utilizados para el cálculo final, se tratan como constantes.

Este es el resultado de utilizar las tres opciones en un informe

En esta serie veremos otros ejemplos de las ventajas de trabajar, siempre que sea posible, con Variables, en lugar de con Medidas intermedias que han de ser ocultadas de la vista informes.

Si trabajamos con Power BI Desktop, y utilizamos la funcionalidad Medidas rápidas, veremos que la herramienta hace un uso elevado y eficiente del trabajo con variables para crear complejas expresiones DAX

Espero que resulte de utilidad #HappyDAXing !!! 🙂

En la próxima entrada vamos a ver cómo trabajar con las relaciones y los cálculos DAX en Modelos tabulares con Power BI

]]>
http://amby.net/2018/02/08/dax-medidas-vs-variables/feed/ 0
DAX: Columnas calculadas vs Medidas – II http://amby.net/2018/02/05/dax-columnas-calculadas-vs-medidas-ii/ http://amby.net/2018/02/05/dax-columnas-calculadas-vs-medidas-ii/#respond Mon, 05 Feb 2018 08:30:34 +0000 http://amby.net/?p=9364 Este escrito forma parte de la serie: Escenarios de Modelado con DAX

Algunos de los recursos que he consultado sobre Modelado tabular y DAX los podemos encontrar en Modelos tabulares y DAX – Recursos

Muchísima gente que llega al mundo del DAX con Power BI viene de la mano de Excel y las Tablas dinámicas. Eso está muy bien, hay mucha experiencia que es posible reutilizar para trabajar con el modelo tabular y DAX y particularmente con Power BI.

Lo que sucede es que ahora, al trabajar con Modelos tabulares, llega el momento de pensar de una forma un tanto diferente. Especialmente a la hora de decidir entre Columnas calculadas y Medidas.

Aspectos que tienen en común las columnas calculadas y las medidas:

  • Misma sintaxis para escribir expresiones DAX
  • Misma Barra de fórmulas con mismo Intellisense y conjunto de funciones a su disposición
  • Mismo objetivo, enriquecer el Modelo tabular que ha sido cargado al procesar las consultas.

En días anteriores vimos cómo crear Columnas calculadas en Modelos tabulares con DAX y hablamos de algunos inconvenientes. Mejor repito este fragmento, es muy importante.

Implicación de crear columnas calculadas para Modelos Tabulares

Voy a resumir algunos de los aspectos a tener en cuenta cuando se crea una columna calculada:

  • Se evalúa la expresión para cada una de las filas de la tabla
  • Durante la evaluación se crea algo que conoceremos luego como Contexto de fila, que permite al motor conocer el valor exacto de cada columna involucrada en la expresión a evaluar
  • Se almacena el resultado correspondiente en cada una de las filas de la tabla
  • No se aplica ninguna acción de filtrado en este momento, no existe lo que luego conoceremos como Contexto de Filtro
  • En el proceso de escritura de la expresión DAX, encontramos que, sin utilizar funciones de relaciones o navegación, no es posible ver columnas fuera de la tabla actual.
  • En materia de procesamiento de Modelo Tabular, las columnas calculadas se procesan una vez procesadas todas las tablas que vienen de las consultas o de expresiones DAX que devuelven tablas al modelo. Durante el procesado de las nuevas columnas calculadas no es posible aplicar los algoritmos de optimización que resultan muy eficientes en la primera fase.
  • Para colmo de males:
    • El resultado puede ser incorrecto, tal y como hemos visto hoy. No es posible utilizar columnas calculadas para todo. En caso de ratios o porcientos de contribución al padre, no es posible.
    • Y en otros casos, puede parecer que está bien; pero luego el resultado es incorrecto si se aplican filtros que no afectan a la tabla en cuestión.

Para dar a solución a todos estos escenarios, podemos y debemos trabajar con Medidas, creadas con expresiones DAX para enriquecer los Modelos tabulares, que es nuestro objetivo.

Antes, creamos tres columnas calculadas, que realizaron los siguientes cálculos:

Importe Ventas = Ventas[CantidadETL] * Ventas[Precio]
Beneficios = Ventas[CantidadETL] * (Ventas[Precio] – Ventas[Coste])
% Beneficios = DIVIDE(Ventas[Beneficios];Ventas[Importe Ventas];0)

Recuerdo la imagen que obtuvimos como resultado

Hoy vamos a crear las medidas que cumplan con los requisitos de negocio y que eviten todos los inconvenientes de las columnas calculadas.

Hay que tener en cuenta que:

  • Como la medida no pertenece a ninguna tabla en concreto, no puede acceder, por sí misma a las filas de las columnas de ninguna de las tablas.
  • No existe, de forma natural, el contexto de fila, como en las columnas calculadas.
  • La buena noticia es que DAX dispone de funciones, que son iteradores, que recorren una tabla o expresión DAX que devuelva tabla y se pase a la función como primer parámetro, y fila a fila de esa tabla evalúa la expresión que se pase como segundo parámetro.

Como siempre, veamos la teoría a través de ejemplos.

Para calcular Importe Ventas con una medida DAX, lo que en realidad necesitamos es recorrer la tabla Ventas y poder calcular, fila a fila la expresión Ventas[CantidadETL] * Ventas[Precio]. Luego, hay que sumar estos valores para obtener el resultado agregado.

Medidas en Modelos tabulares

Una de las opciones es seleccionar la tabla _Cálculos, el contenedor para medidas que creamos en la entrada anterior, DAX: Crear contenedor para medidas DAX en Modelos tabulares con Power BI,  y en los tres puntos que aparecen a la derecha desplegar las opciones y seleccionar Nueva Medida. Para que se note la diferencia en el informe, las tres medidas que voy a crear van a empezar con la palabra Total.

En la barra de fórmulas, escribimos el nombre y vemos que, al intentar sumar la expresión, no podemos. La función SUM sólo permite trabajar con una columna.

Afortunadamente, disponemos de SUMX, ese es el iterador del que hablaba yo antes, recibe dos parámetros, Ventas, que es la tabla a recorrer y la expresión a evaluar es: Ventas[CantidadETL] * Ventas[Precio].

Iteradores en DAX

Los iteradores en DAX, son muy variados en cuanto a su utilidad. Estas funciones especiales tienen una gran importancia y potencia dentro de las expresiones DAX para manejo de modelos tabulares.

  • Hay iteradores de agregación, entre ellos: SUMX, AVERAGEX, MINX, MAXX
  • La función FILTER es un iterador, que recorre la tabla, evalúa la condición y devuelve los registros que la cumplan. De esta función hablaremos más adelante.
  • Otra función muy importante, ADDCOLUMNS es también un iterador, crea una tabla nueva con todas las filas y columnas de la tabla que recorre,  y agrega nuevas columnas, que se llenan a partir de la evaluación de expresiones pasadas como parámetros
  • No pierdas de vista los iteradores en DAX, hay más 🙂

Regresamos a las medidas. De igual forma que antes creamos la medidas para Total Beneficios, con el mismo iterador SUMX y la expresión que corresponde.

Por último, definimos la medida para el Total % Beneficios. En este caso, lo más interesante es que podemos reutilizar las medidas que hemos creado anteriormente, lo que resulta muy cómodo, limpio y efectivo.

        

Resumiendo, las expresiones de las tres medidas creadas son:

Total Importe = SUMX(Ventas;Ventas[CantidadETL]*Ventas[Precio])
Total Beneficios = SUMX(Ventas;Ventas[CantidadETL] * (Ventas[Precio] – Ventas[Coste]))
Total % Beneficios = DIVIDE([Total Beneficios];[Total Importe])

Vamos a comparar entonces, el resultado que se obtiene al trabajar con las medidas

Voy a resumir algunos de los aspectos a tener en cuenta cuando se crea una medida:

  • Se evalúa la expresión para cada una de las filas visibles de la tabla. La visibilidad de las filas, depende del Contexto de filtro existente. Regresaremos a este punto.
  • El iterador garantiza que se cree algo que conoceremos luego como Contexto de fila, que permite al motor conocer el valor exacto de cada una de las filas de cada columna involucrada en la expresión a evaluar
  • No se almacena el resultado, se almacena la expresión DAX como parte del Modelo de datos tabular
  • Las medidas ven y son vistas por todo el modelo, están envueltas por la función CALCULATE, lo que facilita mucho las expresiones que  las utilizan. Sobre este aspecto, que hoy queda sin explicar, regresaré en esta serie. De momento, quedémonos con la diferencia en el comportamiento de las columnas, que si no utilizan funciones de relaciones o navegación, no es posible ven columnas fuera de la tabla actual.
  • Las medidas no se procesan cuando se crean ni cuando se actualizan los datos. las medidas se evalúan y devuelven su resultado, sólo en caso de ser utilizadas directamente en el informe o desde otra medida que esté siendo utilizada en el informe
  • Las medidas son la vía adecuada para casos de ratios o porcientos de contribución al padre, etc.

En esta serie veremos otros ejemplos de las ventajas de trabajar, siempre que sea posible, con Medidas, en lugar de con Columnas Calculadas.

Espero que resulte de utilidad #HappyDAXing !!! 🙂

En la próxima entrada vamos a ver cómo Utilizar variables en medidas DAX en Modelos tabulares con Power BI

]]>
http://amby.net/2018/02/05/dax-columnas-calculadas-vs-medidas-ii/feed/ 0
DAX: Crear contenedor para medidas DAX en Modelos tabulares con Power BI http://amby.net/2018/02/01/dax-crear-contenedor-para-medidas-dax-en-modelos-tabulares-con-power-bi/ http://amby.net/2018/02/01/dax-crear-contenedor-para-medidas-dax-en-modelos-tabulares-con-power-bi/#respond Thu, 01 Feb 2018 08:30:31 +0000 http://amby.net/?p=9362 Este escrito forma parte de la serie: Escenarios de Modelado con DAX

Algunos de los recursos que he consultado sobre Modelado tabular y DAX los podemos encontrar en Modelos tabulares y DAX – Recursos

En la entrada anterior, DAX: Columnas calculadas vs Medidas – I, hablamos del trabajo con columnas calculadas y algunos de sus inconvenientes. En la entrada siguiente hablaremos sobre medidas en Modelos Tabulares, y así tendremos los elementos que nos permitan poder decidir entre Columnas calculadas y Medidas.

Me gustaría dedicar esta entrada a un aspecto, nada obligatorio, y que no tiene nada que ver con la optimización del modelo tabular; pero que lo considero muy práctico. Hoy, vamos a crear una tabla vacía que nos sirva como contenedor para las medidas que vamos a crear.

La idea es la siguiente:

  • Como vimos antes, en las entradas, Introducción a DAX,  y  DAX: Columnas calculadas vs Medidas – I, las columnas pertenecen a la tabla en la que se han creado, con un nombre que puede coincidir con nombres de otras tablas, que en las expresiones DAX siempre se escribe entre corchetes y, siguiendo las buenas prácticas, su nombre debe ir precedido del nombre de la tabla a la que pertenece.
  • Las medidas, por su parte, pertenecen al modelo, tienen nombre único en el modelo que no puede coincidir con el nombre de ninguna de las columnas de ninguna de las tablas y, siguiendo las buenas prácticas, su nombre no debe ir precedido del nombre de tabla alguna, porque no pertenecen a ninguna tabla.

Entonces, visualmente necesitamos “ubicar” las medidas debajo de alguna tabla, insisto, es únicamente de forma visual, para poderlas utilizar en un informe. Las medidas no van a pertenecer a la tabla en la que se creen ni a la tabla a las que se les pueda asignar en el futuro.

En la entrada DAX: medidas Implícitas vs Explícitas, creamos una medida, Cantidad y la asignamos a la tabla Ventas, aunque no pertenezca a la tabla, la dejamos allí.

Tiene mucho sentido crear un contenedor, o varios, para agrupar las medidas que vamos a necesitar en el modelo, según sea su temática.

  • A la hora de diseñar los informes es muchísimo más cómodo ir a buscar en un único sitio, en lugar de registrar las distintas tablas.
  • Como sólo se trata de un tema visual, práctico, e incluso, estético, es posible modificarlo al gusto del usuario final, devolviendo algunas medidas a la tabla donde originalmente se crearon, como es el caso de la medida Cantidad y la tabla Ventas.
  • Se puede redefinir este diseño tantas veces como lo requieran los requisitos, porque no va a afectar en nada, en ninguna de las expresiones que se realicen en la propia medida y en las nuevas medidas que se hagan a partir de una medida base como es en nuestro caso, Cantidad.

Continuamos con el ejemplo que estamos trabajando.

Para crear un contenedor, lo único que necesitamos es crear una tabla, sin asignar contenido a filas y columnas. Para ello, necesitamos crear una nueva consulta desde el menú Inicio, grupo Datos Externos, opción Especificar Datos. Aparece una ventana con opciones para crear una tabla y definir tanto la estructura como el contenido de la misma.

En nuestro caso, sólo necesitamos cambiar el nombre de la tabla, por ejemplo, a _Cálculos, la idea del guión bajo aquí es sólo porque esta tabla se ubique la primera en el panel Campos en Power BI Desktop.

Como resultado de esta acción, obtendremos una consulta que no será necesario editar, por lo que desde las opciones que aparecen debajo, escogemos Cargar.

En la siguiente imagen vemos la nueva tabla extra _Cálculos, que si la expandimos, vemos que tiene una columna, Columna1.

Podemos comprobar en la vista Datos y vemos que sólo existe Columna1 y que no hay contenidos.

Si tenemos curiosidad, podemos ver la consulta correspondiente desde el Editor de consultas. Para ello, vamos al menú Inicio, grupo Datos Externos, opción Editar Consultas y la podemos ver. En estos momentos no podemos eliminar la columna Columna1, porque es la única estructura que sostiene la tabla.

Ya tenemos el contenedor. Ahora vamos a pasar la medida Cantidad, que creamos antes y alojamos en la tabla Ventas, a esta tabla-contenedor para medidas. Para ello, seleccionamos el campo Cantidad de la tabla Ventas, no marcamos la casilla, sino que hacemos clic sobre el nombre para que quede rodeado en color amarillo continuo.

Vamos al menú, ficha Modelado, grupo Propiedades opción Tabla Inicial

Desplegamos las opciones, donde está actualmente Ventas, seleccionamos _Cálculos.

   Y ya está la medida en la tabla que queremos   

Sólo nos queda eliminar la columna Columna1, que es antiestética y no nos sirve para nada, y ahora sí, una vez que ya tenemos una primera medida, podemos eliminar la columna, que es incluso mejor que ocultarla.

Nos pide opción de confirmación

Y ya está eliminada la columna sobrante

Llegados a este punto, ya estamos listos para trabajar con Medidas creadas con expresiones DAX y que permitan enriquecer el modelo.

En primer lugar, vamos a crear las medidas correspondientes al caso anterior, con las que dejaremos solucionados los problemas que se presentan al trabajar con Columnas calculadas con DAX. Luego, iremos viendo el resto de escenarios.

Espero que resulte de utilidad #HappyDAXing !!! 🙂

En la próxima entrada vamos a ver cómo Crear medidas con DAX en Modelos tabulares con Power BI

]]>
http://amby.net/2018/02/01/dax-crear-contenedor-para-medidas-dax-en-modelos-tabulares-con-power-bi/feed/ 0
DAX: Columnas calculadas vs Medidas – I http://amby.net/2018/01/19/dax-columnas-calculadas-vs-medidas/ http://amby.net/2018/01/19/dax-columnas-calculadas-vs-medidas/#respond Fri, 19 Jan 2018 08:30:27 +0000 http://amby.net/?p=9328 Este escrito forma parte de la serie: Escenarios de Modelado con DAX

Algunos de los recursos que he consultado sobre Modelado tabular y DAX los podemos encontrar en Modelos tabulares y DAX – Recursos

Muchísima gente que llega al mundo del DAX con Power BI viene de la mano de Excel y las Tablas dinámicas. Eso está muy bien, hay mucha experiencia que es posible reutilizar para trabajar con el modelo tabular y DAX y particularmente con Power BI.

Lo que sucede es que ahora, al trabajar con Modelos tabulares, llega el momento de pensar de una forma un tanto diferente. Especialmente a la hora de decidir entre Columnas calculadas y Medidas.

Aspectos que tienen en común las columnas calculadas y las medidas:

  • Misma sintaxis para escribir expresiones DAX
  • Misma Barra de fórmulas con mismo Intellisense y conjunto de funciones a su disposición
  • Mismo objetivo, enriquecer el Modelo tabular que ha sido cargado al procesar las consultas.

Vayamos a nuestro ejemplo. En la tabla Ventas, tenemos las columnas Cantidad, Precio y Coste, a partir de las cuales queremos obtener el Importe Ventas, Beneficio y el % de Beneficio.

Desde ya pido que no nos centremos en la exactitud de las fórmulas, es apenas utilizar lo que tenemos y avanzar con los ejemplos.

Columnas Calculadas en Modelos tabulares

Si venimos del mundo Excel, nuestra tendencia será crear columnas calculadas para garantizar estos cálculos.

Como en el caso anterior, cuando escribimos nuestra primera medida con DAX, hay varias opciones de menú para crear columnas calculadas y además, como en el caso de las medidas, aparece la barra de fórmulas y la sintaxis DAX para escribir medidas y columnas calculadas es la misma, la sintaxis es la misma, lo que es diferente es lo que el motor espera evaluar en una medida y en una columna calculada. Lo iremos viendo.

Para crear columnas calculadas mi recomendación es situarse en la ficha Datos, en este caso, mostrando la tabla Ventas, y seleccionar Nueva Columna

Desde la barra de fórmulas estamos listos para escribir la expresión que va a ser evaluada por cada una de las filas de la nueva columna calculada, para la que como vemos en la imagen ya se ha reservado un sitio en la tabla.

Es posible crear tantas columnas calculadas como se desee; pero cuidado… muchísimo cuidado con las columnas calculadas… poder, se puede trabajar con ellas; pero pueden ser muy dañinas para el Modelo tabular. Las columnas calculadas no están recomendadas. Voy a insistir una y otra vez y veremos ejemplos que lo demuestran, uno de los casos, hoy mismo.

En la Barra de fórmulas, vamos a contar con la inestimable ayuda de IntelliSense, igual que en el caso de las medidas. Escribir la expresión Importe Ventas = Cantidad * Precio, es tan sencillo como seleccionar las columnas con el Intellisense.

En la medida que vamos tecleando Intellisense es más útil

Al crear las columnas, y es válido también para las medidas, podemos y debemos asignar el formato adecuado. Esta asignación a nivel de modelo de datos permite que ya aparezca con formato cuando se utilice en los gráficos, tarjetas y otras visualizaciones de Power BI. No olvidéis dar formato a nivel de modelo a cada columna y medida que vayáis a utilizar.

De esta forma, definimos la expresión DAX para Importe Ventas.

Definimos la expresión DAX para Beneficios.

Y por último, definimos la expresión DAX para % Beneficio.

En este caso, voy a hacer un paréntesis aclarando algunos aspectos relacionados con esta expresión

  • El nombre de la columna, % Beneficio, es correcto. En el modelo tabular las columnas siempre, siempre van entre corchetes, por lo que admiten todo tipo de espacios y caracteres que se quiera definir
  • Para trabajar con cálculos que implican división nos enfrentamos al dilema de la división por cero, tendríamos que utilizar una función que comprobara antes de hacer la división. Las funciones de control de errores en DAX son lentas, no favorecen el óptimo rendimiento del motor. Hay que evitarlas a toda costa. Para ello, siempre hay que definir bien el tipo de datos y en este caso, utilizar la función DIVIDE(), que ya está optimizada y se encarga de comprobar que no ocurra la División por cero.

  • Por otra parte, al tratarse de un % hay que indicar también el formato adecuado

En la tabla Ventas, podemos ver las tres columnas que han sido calculadas. Si nos detemenos fila a fila, vemos que el resultado es correcto, las expresiones se han evaluado de forma adecuada, todo parece ir bien.

Una vez creadas las columnas, el siguiente paso es utilizarlas en una visualización, en nuestro caso será una sencilla tabla. Vamos a analizar el resultado de estas tres expresiones según sea la categoría de los productos vendidos.

Empezamos por las dos primeras columnas calculadas: Importe Ventas y Beneficios.

Mostramos luego, la columna calculada % de Beneficios.

Los valores devueltos por las columnas Importe Ventas y Beneficios tienen buen aspecto, parecen razonablemente bien, de hecho son correctos. Pero la columna % de Beneficios devuelve valores completamente irreales e incorrectos. No tenemos ningún mensaje de error; pero no cabe duda de la incoherencia de los datos.

¿Te haces una idea de lo que ha ocurrido? Pues lo que ha ocurrido es que la columna calculada, a efectos de uso en un informe, se comporta como una columna nativa y al añadirla al informe crea una medida implícita, agregando los valores, sumándolos, como mismo vismos al analizar Medidas implícitas vs Explícitas. Está sumando los Porcientos de Beneficios obtenidos fila a fila en lugar de devolver el Porciento que representan los Beneficios sobre las Ventas.

Podríamos intentar mostrar el Porciento de contribución al padre, reutilizando la columna Beneficios y la funcionalidad Mostrar como porciento del total general, de Power BI Desktop, que es por cierto, la misma que en Excel.

El valor devuelto es correcto; pero no es lo que necesitamos. Al menos, es correcto.

Implicación de crear columnas calculadas para Modelos Tabulares

Voy a resumir algunos de los aspectos a tener en cuenta cuando se crea una columna calculada:

  • Se evalúa la expresión para cada una de las filas de la tabla
  • Durante la evaluación se crea algo que conoceremos luego como Contexto de fila, que permite al motor conocer el valor exacto de cada columna involucrada en la expresión a evaluar
  • Se almacena el resultado correspondiente en cada una de las filas de la tabla
  • No se aplica ninguna acción de filtrado en este momento, no existe lo que luego conoceremos como Contexto de Filtro
  • En el proceso de escritura de la expresión DAX, encontramos que, sin utilizar funciones de relaciones o navegación, no es posible ver columnas fuera de la tabla actual.
  • En materia de procesamiento de Modelo Tabular, las columnas calculadas se procesan una vez procesadas todas las tablas que vienen de las consultas o de expresiones DAX que devuelven tablas al modelo. Durante el procesado de las nuevas columnas calculadas no es posible aplicar los algoritmos de optimización que resultan muy eficientes en la primera fase.
  • Para colmo de males:
    • El resultado puede ser incorrecto, tal y como hemos visto hoy. No es posible utilizar columnas calculadas para todo. En caso de ratios o porcientos de contribución al padre, no es posible.
    • Y en otros casos, puede parecer que está bien; pero luego el resultado es incorrecto si se aplican filtros que no afectan a la tabla en cuestión.

Para dar a solución a todos estos escenarios, podemos y debemos trabajar con Medidas, creadas con expresiones DAX para enriquecer los Modelos tabulares, que es nuestro objetivo.

En esta serie veremos otros ejemplos de las ventajas de trabajar, siempre que sea posible, con Medidas, en lugar de con Columnas Calculadas.

Espero que resulte de utilidad #HappyDAXing !!! 🙂

En la próxima entrada vamos a ver cómo Crear contenedor para medidas DAX en Modelos tabulares con Power BI

]]>
http://amby.net/2018/01/19/dax-columnas-calculadas-vs-medidas/feed/ 0