La Data Web

De las cosas más importantes en un modelo tabular, ya sea dentro de power bi o analysis services, están las relaciones entre tablas. Ciertamente son la clave para que un modelado escale puesto que una buena comprensión de ellas ayudará a la construcción de medidas y gráficos necesarios que estén en los requerimientos sin necesidad de armar monstruos de dax o ciclos ambiguos de relaciones.

De cierto modo suena a "sencillo" puesto que no tiene mucho para comprobar pero resulta clave entender el uno y el muchos que varios lo ignoran siempre y cuando este relacionado y terminan generando relaciones por todos lados que incluso componen la "prohibida" muchos a muchos. Llamaremos cardinalidad a este concepto de uno a uno, uno a muchos o muchos a muchos.

Tomando de referencia la siguiente imagen vamos a ver dos potentes funciones de DAX que nos ayudarían a involucrar en nuestra tabla actual contenido de una tabla relacionada.

Cuando comenzamos con Power Bi una de las cosas más atractivas que nos atrapa es el código DAX. Sentimos un entorno familiar con sintaxis semejante a excel, pero no por eso vamos a decir que el lenguaje es parecido, que nos permite construir cálculos y medidas matemáticas que resuelven nuestras lógicas de negocio.

Ciertamente nos da fuerza sentirlo conocido para comenzar de golpe con todas las reglas sin importar la dificultad llegando así a una traba. El freno o bloqueo inicial son las funciones de agregación "X". Cuando vamos a constuir nuestra medida nos encontramos no solo con COUNT, AVERAGE, MAX o SUM sino también con COUNTX, AVERAGEX, MAXX, SUMX y nos deja pensando sin conocer bien como deberíamos utilizar dichas funciones.
En este artículo vamos a ver como responden dichas funciones enfocandonos en SUM y SUMX para conocer el concepto que las diferencia. Esto no solo serviría para SUM sino también para las otras agregaciones pero para facilitar la descripción e interpretación usaremos una de ellas como guía.

Existe una característica maravilloso en Power Bi llamada RLS. Con el correr del tiempo me he encontrado con múltiples casos que no han encontrado la utilidad o comprendido tanto el uso como su implementación. Ciertamente su concepto puede ser confuso para un usuario no técnico que solo pensará en "Seguridad es bueno".

Seguridad a niveles de filas significa nada más y nada menos que restringir el acceso a los datos a determinados usuarios. Me detengo en "a los datos" un momento porque esto no significa que no pueden entrar a ver los informes de Power Bi. Lo que RLS restringe son datos puntuales en si y no informes, paneles o areas dentro de Power Bi. Una cosa es el acceso a la información y otra a un dato puntual. RLS va a conseguir que dos usuarios con perfiles/roles diferentes estén viendo el mismo informe y cada quien vea distintos datos porque fueron asignados con un rol que tiene una regla de filtros hacia el conjunto de datos. Eso es seguridad a niveles de filas. Filtrar filas de un conjunto de datos bajo una regla definida que será parte de un rol que asignaremos a un usuario.

Para implementar desde cero esta maravillosa característica vamos a seguir el siguiente proceso.

El mismo titulo me ha dicho muchas veces que ésta es una idea terrible y aun así decidí escribirlo. La realidad es que muchas veces nuestros clientes o usuarios finales tienen estas ideas fatales que rompen un poco el "sentido" del uso de la herramienta queriendo realizar sus fines de otro modo.

Resulta ser que tiene mucha atracción la idea que un informe de power bi que ven diariamente exporte los datos automáticamente a una dirección para que ellos no tengan que estar entrando a exportarlos. Quieren ir a un lugar y que ya tenga el csv listo para explotar/trabajar con toda la limpieza de los datos.

Naturalmente, bajo las condiciones normales de Power Bi, esto no es posible. Aún así se puede obtener el resultado jugando un poco con las capacidades de ejecución de código Python y R dentro de nuestro editor de consultas. Entonces vamos a nutrirnos de esta capacidad para realizar el objetivo de tener los datos limpios exportados automáticamente.

NOTA: Cabe aclarar que no es recomendable con grandes volúmenes de información.

¡Hola! Mi nombre es Matías Deheza, Managing Director en Pi Data Strategy & Consulting. No esta demás comentar que comparto el gusto por el estudio de los datos y el cómo generar valor agregado a partir de estos de hace ya 5 años. Es así como me he nutrido, principalmente, de experiencias que buscaré compartir con todos. 

Me especializo en Azure y Arquitecturas de datos Cloud, de las cuales voy a compartir o contar algunas consideraciones técnicas interesantes a la hora de trabajar en estas arquitecturas. ¡Comencemos nomas!

Uno de los grandes atributos de Data Factory es su capacidad para orquestar múltiples componentes de Azure en un flujo de datos integral. Cuando empezamos a trabajar con datos, y particularmente con Analysis Services, se vuelve necesario que data Factory ejecute el procesamiento de este bajo ciertos parámetros. El procesamiento de Analysis Services será una actividad dentro de nuestro Pipeline y probablemente luego de esta sigan otras, por ende, es necesario que Data Factory reciba un aviso cuando el procesamiento haya finalizado.

Este post pretende mostrarles como disparar ese procesamiento y posteriormente como Data Factory espera por esa respuesta.

Como paso inicial es recomendable que hagan esto https://docs.microsoft.com/es-es/azure/analysis-services/analysis-services-refresh-azure-automation#authentication. Desde el punto "Authentication" hasta el punto "Diseño de un runbook de automation" inclusive.