Power BI

PBIRS vs Power BI Service

Cuando hablamos de soluciones de Business Intelligence (BI) dentro del ecosistema de Microsoft, la primera opción que viene a la mente es Power BI. Sin embargo, dentro de esta herramienta tan robusta existen dos variantes principales que, a menudo, generan dudas sobre cuál elegir: Power BI Report Server (PBIRS) y el servicio de Power BI en la nube. En este artículo, exploraremos en profundidad las características, ventajas y limitaciones de cada opción, ayudándonos a discernir cuál se adapta mejor a nuestras necesidades organizativas.

¿Qué es Power BI?

Power BI es una suite de herramientas de análisis empresarial (BI) desarrollada por Microsoft que nos permite convertir datos en información útil mediante informes interactivos y visualizaciones impactantes. Dentro de Power BI tenemos integración de manera efectiva con una amplia gama de fuentes de datos, permitiéndonos analizar y compartir insights con facilidad prácticamente sea cual sea su origen. Además de poder combinar en un solo modelo de datos e informes datos de varios orígenes.

Hemos hablado de modelo de datos e informes y es que, Power BI Desktop (la aplicación que se instala en el ordenador y nos permite a los usuarios crear informes complejos y dashboards interactivos) consta de dos partes principales. Por un lado la integración de datos de los informes y su adaptación (lo que tradicionalmente se conoce como ETL) a cargo de Power Query y la propia aplicación para diseñar los informes que además permite cálculos avanzados con DAX. 

Así, a grandes rasgos, con Power BI Desktop, podemos conectar, transformar y modelar datos antes de visualizarlos en gráficos y tablas que ayuden a tomar decisiones informadas. La interfaz es intuitiva y, a pesar de su poder, está diseñada para ser accesible tanto a analistas de datos experimentados como a usuarios menos técnicos. Una vez que los informes están listos, los podemos publicar y compartir a través de Power BI Service (en la nube) o mediante Power BI Report Server (PBIRS), según la infraestructura y las necesidades de la organización.

Entendiendo PBIRS y Power BI en la Nube

Antes de entrar en sus diferencias, es importante entender qué son PBIRS y el servicio de Power BI en la nube. PBIRS es una plataforma local de informes basada en SSRS que nos permite mantener los datos y reportes dentro de nuestra infraestructura local, sin necesidad de depender de servicios externos. Esta opción es especialmente útil para aquellas empresas con estrictos requisitos de seguridad o que operan en sectores altamente regulados. Por otro lado, Power BI en la nube ofrece un servicio completamente gestionado por Microsoft, con actualizaciones frecuentes, escalabilidad casi ilimitada y acceso desde cualquier lugar.

Seguridad y Cumplimiento. Punto para PBIRS

Uno de los principales argumentos a favor de PBIRS es la seguridad. Muchas organizaciones tienen normativas estrictas sobre dónde deben residir los datos, lo que hace que la opción de mantener todo «en casa» sea atractiva. Con PBIRS, el control total sobre los servidores, bases de datos y la red es una realidad. Esto es crucial en sectores como el financiero, sanitario o gubernamental, donde el cumplimiento de normativas es ineludible.

Además, PBIRS permite la integración directa con las políticas de seguridad corporativas existentes, como Active Directory, lo que facilita la implementación de controles de acceso granulares y personalizados. En contraste, Power BI en la nube, aunque seguro y conforme a muchas normativas internacionales, deja el control de la infraestructura en manos de Microsoft, lo que puede no ser ideal para todas las organizaciones.

Flexibilidad y Personalización. Otro punto para PBIRS

PBIRS nos ofrece una mayor flexibilidad en términos de personalización y control de la infraestructura. Podemos ajustar los servidores a las necesidades específicas de nuestros informes y modelos de datos, lo que es fundamental cuando trabajamos con grandes volúmenes de información o requerimos configuraciones especializadas. Además, PBIRS permite utilizar Reporting Services, Power BI y Excel, lo que proporciona una solución integral para la gestión de informes en una única plataforma.

En contraste, Power BI en la nube se enfoca más en la simplicidad y la facilidad de uso. Aunque ofrece un entorno muy completo, su flexibilidad en cuanto a personalización es menor, ya que estamos limitados a las opciones y configuraciones que Microsoft ha diseñado para el servicio. Sin embargo, esta «limitación» viene acompañada de una gestión simplificada y la eliminación de la carga de mantenimiento y actualizaciones de la infraestructura.

Licenciamiento. Punto para el Servicio

Un aspecto clave en la decisión de optar por PBIRS o Power BI en la nube, es el modelo de licenciamiento. En PBIRS, los usuarios pueden consultar informes sin necesidad de adquirir licencias adicionales. Una vez que el servidor está configurado y licenciado, cualquier usuario de la organización con acceso al servidor puede visualizar los informes sin coste adicional. Sin embargo, las opciones de licenciamiento de PBIRS son escasas y caras, muy caras. Realmente no podemos licenciar exclusivamente PBIRS y, si lo queremos usar debemos adquirir una licencia de otro producto que incluya este. Estas licencias de otros productos que incluyen PBIRS son SQL Server Enterprise con Software Assurance o una capacidad Premium de Power BI (mínimo una F64 de instancia reservada y no pago por uso).

Este modelo contrasta con el de Power BI en la nube, donde cada usuario que quiera acceder a los informes debe contar con una licencia, ya sea Power BI Pro o Premium. Aunque este modelo de suscripción tiene sus ventajas en términos de escalabilidad y simplicidad de gestión, puede resultar costoso para organizaciones grandes o aquellas con muchos usuarios ocasionales.

Esta diferencia en el licenciamiento hace que PBIRS sea poco atractivo ya que muchas empresas no pueden permitirse el desembolso de dinero del que estamos hablando. Una licencia de SQL Server Enterprise cuesta unos 14.000€ por cada dos cores del servidor (y que menos que 8 cores para un servidor decente, lo que suman ya más 55.000€ ) más luego la suscripción del Software Assurance y, para el otro modo de licenciamiento, una instancia reservada con capacidad F64 tiene un coste de suscripción de unos 8000€ al mes.

Escalabilidad y Mantenimiento. Otro punto para el servicio

La escalabilidad es otro aspecto donde las diferencias entre PBIRS y Power BI en la nube se hacen evidentes. Power BI en la nube ofrece una escalabilidad casi ilimitada, ya que la infraestructura de Microsoft Azure se encarga de todo. Esto significa que podemos empezar con un pequeño proyecto piloto y escalar sin problemas a nivel empresarial sin necesidad de preocuparnos por la capacidad del servidor o el rendimiento, solo por el coste.

Por otro lado, con PBIRS, la escalabilidad depende completamente de nuestra infraestructura local. Si nuestras necesidades crecen, deberemos estar preparados para invertir en más hardware, espacio y, seguramente, más personal para gestionar y mantener el entorno. Esto puede ser una barrera para organizaciones en rápido crecimiento o que experimentan picos estacionales en la demanda de informes.

El mantenimiento es otro punto clave. Power BI en la nube se actualiza automáticamente, con nuevas características y mejoras implementadas por Microsoft de manera constante. Esto garantiza que siempre tengamos acceso a la última tecnología sin necesidad de realizar cambios manuales en nuestra infraestructura. En cambio, con PBIRS, somos responsables de aplicar las actualizaciones y parches, lo que requiere un equipo dedicado y una planificación cuidadosa para evitar interrupciones en el servicio.

Costes y Retorno de la Inversión. ¿Empate?

A la hora de evaluar PBIRS frente a Power BI en la nube, los costes son un factor determinante. PBIRS suele requerir una inversión inicial significativa en hardware, licencias y recursos humanos. Además, los costes de mantenimiento y actualización deben considerarse a largo plazo. Sin embargo, para organizaciones que ya disponen de una infraestructura robusta, este coste puede ser amortizado más fácilmente.

Por otro lado, Power BI en la nube sigue un modelo de suscripción, lo que permite empezar con costes más bajos y escalarlos según el uso y las necesidades. Aunque a largo plazo, las suscripciones pueden acumularse, ofrecen la ventaja de no requerir una inversión inicial significativa y permiten a las organizaciones ajustar sus gastos según la evolución de sus requerimientos.

El retorno de la inversión (ROI) en ambos casos depende en gran medida de la naturaleza de la organización y de cómo se utilice la herramienta. PBIRS puede ofrecer un ROI más alto en entornos donde la seguridad y el control son primordiales, mientras que Power BI en la nube podría ofrecer un mejor ROI para organizaciones que valoran la flexibilidad y la capacidad de escalar rápidamente.

Facilidad de Implementación y Adopción. El cloud gana esta batalla

La facilidad de implementación es otra área donde Power BI en la nube sobresale. Al ser un servicio gestionado, la configuración inicial es mínima y la adopción por parte de los usuarios finales suele ser más rápida. Los informes pueden compartirse fácilmente, y el acceso a los mismos está garantizado desde cualquier lugar y dispositivo, lo que fomenta una cultura de datos más abierta y colaborativa.

Por otro lado, PBIRS puede requerir un proceso de implementación más complejo, especialmente si no contamos con una infraestructura avanzada o experiencia en la gestión de servidores de informes. 

¿PBIRS o Power BI en la Nube?

La elección entre PBIRS y Power BI en la nube no es sencilla y depende en gran medida de las necesidades específicas de cada organización. Si la seguridad, el cumplimiento normativo y el control absoluto sobre la infraestructura son prioridades, PBIRS es la opción ideal. Si ya contamos en nuestra organización con una licencia de SQL Server Enterprise con SA ese problema de costes de licenciamiento se diluye y PBIRS pasa a ser una opción muy atractiva. Además, el hecho de que no se necesitan licencias adicionales para que los usuarios visualicen informes puede representar un ahorro significativo, en entornos con un gran número de usuarios.

Sin embargo, si valoramos la escalabilidad, la facilidad de uso y la reducción de la carga de mantenimiento, Power BI en la nube se posiciona como la opción más adecuada. Aunque implica un coste por usuario, la flexibilidad y el acceso global que ofrece son difíciles de igualar.

Conclusión

En resumen, ambas herramientas son complementarias y podríamos combinar un servicio en la nube con uno local. La clave está en evaluar cuidadosamente las necesidades de nuestra organización, los recursos disponibles y los objetivos a largo plazo antes de tomar una decisión. Al hacerlo, garantizamos que estamos invirtiendo en la solución que mejor se alinea con nuestra estrategia de BI.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

No te vayas aun. Hemos creado una página donde estamos recopilando todos estos artículos que dan respuesta a estas preguntas frecuentes de SQL Server. Pásate por aquí a echar un vistazo.

Antes de cerrar este artículo me gustaría agradecer la inestimable ayuda de mi amigo Ricardo Rincón, experto MVP en Power BI que me ha asesorado y ayudado, sobre todo a poner algo de luz en el tema del licenciamiento.

Publicado por Roberto Carrancio en Cloud, Power BI, 2 comentarios

Bus Dimensional

El modelado dimensional es una técnica fundamental en la construcción de sistemas de Business Intelligence (BI), que nos va a permitir analizar nuestros datos de forma eficiente y con un alto grado de flexibilidad. Dentro de este marco, el concepto de «Bus dimensional» se posiciona como un componente clave para garantizar la cohesión y la escalabilidad de nuestros modelos de datos. Este enfoque fue popularizado por Ralph Kimball, uno de los pioneros del modelado dimensional, quien estableció las bases de esta metodología en sus numerosos escritos y libros. En este artículo, exploraremos en profundidad el concepto de Bus dimensional, su aplicación en modelos de BI y por qué es esencial para el éxito de cualquier proyecto de análisis de datos.

El Bus Dimensional en modelos de BI según Kimball

Cuando diseñamos un modelo dimensional, nuestro objetivo principal es organizar los datos de forma que facilite tanto su análisis como su consulta. Ralph Kimball, en su obra «The Data Warehouse Toolkit», introdujo la idea del Bus Dimensional como una estrategia para unificar y estandarizar los modelos de datos en toda la organización. Esta técnica nos va a permitir que las diferentes áreas de negocio interactúen y compartan información de forma coherente, garantizando que los datos se interpreten de forma única y consistente a lo largo de diferentes procesos y departamentos.

El Bus dimensional no es solo una herramienta técnica, sino una estrategia de diseño que busca asegurar que todos los modelos compartan una misma estructura y lenguaje, al menos así lo propuso Kimball. De este modo, las distintas áreas de negocio podrán interactuar y comparar datos de forma coherente y sin ambigüedades. Este enfoque es particularmente útil en organizaciones grandes, donde múltiples equipos de BI trabajan en paralelo y, por tanto, es vital que los modelos de datos sean consistentes y escalables.

Diseño del Bus Dimensional en modelos de BI siguiendo a Kimball

Para entender cómo implementamos un Bus Dimensional, es necesario primero comprender su arquitectura básica según la metodología de Kimball. El Bus Dimensional se fundamenta en dos componentes esenciales que os sonarán seguro: las dimensiones conformadas y los hechos compartidos. Las dimensiones conformadas son aquellas que, por diseño, se utilizan en múltiples áreas de negocio y mantienen la misma estructura y contenido. Por ejemplo, una dimensión de tiempo o de clientes puede ser utilizada en distintos modelos para representar el mismo conjunto de datos, asegurando la coherencia entre informes y análisis.

Kimball destacó que la clave del éxito en la implementación de un Bus Dimensional radica en la consistencia de estas dimensiones conformadas. Este enfoque facilita que los hechos compartidos, que se refieren a los eventos o transacciones relevantes para diferentes áreas de negocio, sean representados de forma uniforme en los modelos. Así, se asegura que al consultar los datos, se puedan comparar y analizar los mismos eventos desde diferentes perspectivas sin perder la integridad de la información.

Implementar un Bus Dimensional en nuestros modelos de BI siguiendo las recomendaciones de Kimball requiere un análisis exhaustivo de las necesidades de negocio, así como una colaboración estrecha entre los distintos equipos de desarrollo. No se trata solo de diseñar un modelo técnico eficiente, sino de asegurar que todos los stakeholders involucrados en el proyecto compartan una visión común de los datos y su estructura.

Beneficios de implementar un Bus Dimensional según Kimball

Implementar un Bus Dimensional, como lo concibió Kimball, nos va a aportar múltiples beneficios que pueden impactar positivamente tanto en la eficiencia operativa como en la calidad del análisis de datos. Uno de los beneficios más destacados es la reducción de la redundancia en el modelado de datos. Al utilizar dimensiones conformadas y hechos compartidos, evitamos la creación de múltiples versiones de las mismas entidades, lo que a su vez disminuye la complejidad del mantenimiento del modelo y mejora la consistencia de los datos.

Otro aspecto crucial, resaltado por Kimball, es la escalabilidad. A medida que la organización crece y se incorporan nuevas áreas de negocio o se amplían las ya existentes, el Bus Dimensional permite que estos cambios se integren de forma armoniosa en el modelo de datos existente. Esto no solo reduce el tiempo y los costes asociados con la ampliación del modelo, sino que también asegura que los datos de las nuevas áreas sean compatibles con los modelos ya existentes.

Además, el Bus Dimensional facilita la creación de informes y análisis comparativos entre diferentes áreas de negocio. Al tener un modelo de datos estandarizado, podemos comparar datos de ventas, finanzas, operaciones, entre otros, sin la necesidad de realizar complejas transformaciones o ajustes manuales. Esto mejora la rapidez y la precisión en la toma de decisiones, ya que todos los stakeholders acceden a la misma información y pueden confiar en la coherencia de los datos, un punto esencial en la metodología de Kimball.

Consideraciones para la Implementación según Kimball

A pesar de sus numerosos beneficios, la implementación de un Bus Dimensional según las directrices de Kimball no está exenta de dificultades que deberemos afrontar. Uno de los principales retos, como ya habrás podido imaginar, es alinear las distintas áreas de negocio y que todos estén de acuerdo en cuanto a la definición de dimensiones conformadas y hechos compartidos. Es común que diferentes departamentos tengan visiones y necesidades particulares sobre cómo deben estructurarse los datos, lo que puede generar conflictos a la hora de definir un modelo común.

Para esto, Kimball enfatiza la importancia del liderazgo en estos casos. Es fundamental contar con un liderazgo fuerte y una clara visión de los objetivos del proyecto. Los equipos de BI deben trabajar de forma colaborativa, estableciendo estándares y prácticas que aseguren la alineación de todas las partes involucradas. Esto puede implicar negociaciones y concesiones, pero al final, el resultado será un modelo de datos más robusto y flexible.

Otro aspecto a considerar, que Kimball también aborda, es la complejidad técnica que puede implicar la implementación de un Bus Dimensional en organizaciones con sistemas heredados (legacy) o con una infraestructura de datos fragmentada. En estos casos, puede ser necesario realizar importantes transformaciones en los sistemas existentes para alinearlos con la nueva arquitectura de datos, lo que puede requerir tiempo y recursos significativos. Sin embargo, los beneficios a largo plazo, en términos de eficiencia y escalabilidad, suelen justificar estos esfuerzos.

Conclusión

En resumen, el Bus Dimensional, tal como lo propuso Ralph Kimball, es una estrategia poderosa para garantizar la cohesión, consistencia y escalabilidad en modelos de BI. Al estandarizar las dimensiones y hechos que se utilizan en diferentes áreas de negocio, facilitamos la comparación y el análisis de datos, reducimos la redundancia y mejoramos la escalabilidad del sistema. Si bien su implementación puede presentar desafíos, especialmente en organizaciones grandes o con infraestructuras complejas, los beneficios a largo plazo en términos de eficiencia operativa y calidad del análisis de datos hacen que el esfuerzo valga la pena.

Adoptar un enfoque de Bus Dimensional no solo mejora la gestión de datos en el presente, sino que prepara a la organización para un futuro en el que la capacidad de analizar y utilizar datos de forma eficaz será cada vez más crucial. En última instancia, seguir las directrices de Kimball en el diseño de modelos de BI nos permite construir sistemas más sólidos, coherentes y preparados para los desafíos del mañana.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

No te vayas aun. Hemos creado una página donde estamos recopilando todos estos artículos que dan respuesta a estas preguntas frecuentes de SQL Server. Pásate por aquí a echar un vistazo. 

 

Publicado por Roberto Carrancio en Power BI, 0 comentarios

SQL vs DAX ¿Quién es más rápido?

El pasado viernes andaba yo absorto en la masterclass de Salvador Ramos en Nasmasdata cuando, de repente, una diapositiva salvaje apareció. Salva nos hablaba de un cálculo de stock acumulado con su fórmula en DAX porque según ponía en SQL era un cálculo imposible. ¿IMPOSIBLE? Eso era un reto para mí, así que, raudo tomé una captura de pantalla y acepté ese reto. No hubo que esperar mucho, hoy sábado, de buena mañana me he sentado delante del ordenador, he creado una tabla con los datos necesarios para la prueba y me he puesto manos a la obra. No sin antes contactar a Salva e informarle de lo que estaba aconteciendo porque sí amigos, Salva sabe de la existencia de este artículo días antes que vosotros, para la próxima que el reto venga de vosotros y estaréis informados antes. 

SQL-vs-DAX_1

Entendiendo el reto en DAX

Lo primero que tenemos que entender es lo que nos propone el reto, la medida DAX que se ve en la imagen es esta:

Por un lado CALCULATE es una función que cambia una expresión en un contexto de filtro modificado. Como parámetros le hemos pasado [Stock Final] que es una medida o una calculada que nos sumariza los movimientos de stock. Para el segundo parámetro hemos pasado la función FILTER con dos parámetros más, el resultado es que filtra la tabla Fecha para incluir solo las filas donde la fecha es menor o igual a la fecha máxima en el contexto actual.

Convirtiendo el DAX a T-SQL

Ahora que ya sabemos lo que tenemos que obtener vamos a ver como debemos hacerlo en SQL Server, a ver si realmente era imposible o no. He de deciros que mi tabla solo tiene dos columnas fecha y stock. Podriamos haber complicado el escenario añadiendo artículos pero para la demo nos vale sin eso, supongamos que tenemos solo uno. Como luego vamos a llevarnos estas tablas a Power BI tal como están en SQL no hay problema, en DAX vamos a jugar en las mismas condiciones.

Para empezar vamos a tener que totalizar por dias para saber cuantos movimientos hemos tenido ese día. Luego tenemos que hacer una suma de los valores desde la primera fecha hasta la fecha actual. Eso lo podremos lograr con una función de ventana. Esta sería la consulta imposible:

Vamos a verla paso a paso. En lo primero que nos tenemos que fijar es en la subconsulta del FROM. Es justo lo que comentábamos antes, la suma de los movimientos de stock agrupados por día. Luego, en la consulta principal, estamos utilizando una función de ventana para calcular el Stock_Acumulado. Esta función de ventana SUM() OVER (ORDER BY Fecha ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) suma los valores de Stock_Final en todas las filas desde el inicio de la tabla (UNBOUNDED PRECEDING) hasta la fila actual (CURRENT ROW), ordenadas por Fecha. Esto da como resultado un total acumulativo de Stock_Final hasta la fecha actual.

SQL-vs-DAX_2

Ya lo tenemos, no era imposible. Sin embargo, a lo que Salva se refería era los inconvenientes de realizar los cálculos en SQL por tiempos. Y realmente este es un pensamiento muy extendido en el sector. DAX es más rápido realizando cálculos que SQL Server. Pero, ¿realmente es cierto? Vamos a verlo.

Comparativas de rendimiento DAX vs SQL

Para que los resultados puedan ser representativos, vamos a hacer las pruebas sobre una tabla con algo más de 1 millón de registros, algo normal en una empresa pequeña. Vamos a analizar dos años de datos de movimientos de stock. Para medir los tiempos de la consulta DAX he sacado la consulta de la tabla y la he llevado a DAX Studio. En SQL vamos a usar las estadísticas de tiempo que podemos sacar con SET STATISTICS TIME ON.

SQL-vs-DAX_3

Como vemos los resultados son demoledores y para nada lo esperado. Analizando 1.010.000 registros repartidos en 1096 fechas distintas SQL Server se ha demorado 85 milisegundos de los cuales 78 ms han sido CPU. En DAX Studio podemos ver que la fórmula DAX para la tabla ha tardado 180 milisegundos, repartidos entre 175 ms del motor de fórmulas (FE) y 5 ms del motor de almacenamiento (SE). 

Complicando el escenario

Vamos a pasar de 1 millón a 15 millones de registros a ver si los resultados son distintos. Todos sabemos que el fuerte de Power BI reside en su motor Vertipaq y su gran capacidad de trabajar con grandes cantidades de datos.

SQL-vs-DAX_4

Ahora sí que vemos la gran diferencia de tiempos de la que todo el mundo habla en DAX y Power BI. Con 15 millones de registros los tiempos en SQL Server se han disparado a 1219 milisegundos de CPU aunque paralelizando la consulta se ha resulto en 186 ms. En DAX tenemos un tiempo total de 193 milisegundos repartidos en 175 ms del motor de fórmulas (FE) y 18 ms del motor de almacenamiento (SE). Aunque los tiempos de DAX son mayores a los de SQL no hay tanta diferencia y teniendo en cuenta el paralelismo de SQL podemos deducir un mayor consumo de recursos si ejecutamos los cálculos en origen.

Mejorando los tiempos de SQL

Ya sabemos el objetivo a batir en DAX 193 ms. Veamos qué podemos hacer en SQL. Para empezar vamos a probar con un índice columnar sobre la tabla, al fin y al cabo los índices columnares son la misma tecnología que el motor vertipaq de Power BI.

SQL-vs-DAX_5

Ahí lo tenemos, ahora sí. Nuestra consulta sobre la tabla con índices columnares ha tardado 155 milisegundos de CPU y solo 56 ms totales al paralelizar. Aun así esto todavía se puede mejorar, ¿recordáis las vistas indexadas? Vamos a probarlo.

SQL-vs-DAX_6

¿Qué os parece el resultado? ¿Os lo esperabais? Con la combinación de índice columnar más vista indexada hemos podido ejecutar la consulta pesada sobre 15 millones de registros en menos de un milisegundo. A mi me ha sorprendido la verdad. No esperaba tanta mejoría.

Es importante destacar que esto es una prueba de concepto en un entorno de laboratorio sin carga de trabajo donde puedo hacer todos los cambios que quiero sobre el SQL sin afectar a ningún otro proceso. Esto es un escenario muy simplificado para la DEMO sin ningún parecido con una base de datos de un ERP de producción. Como siempre digo, primero válida en tus servidores de pruebas y luego, si ves que va bien y no da problemas, piensa en aplicarlo en producción.

Conclusión

SQL sigue más vivo que nunca. Es verdad que DAX es muy potente y seguro que tiene un montón más de optimizaciones de las que yo he sido capaz de aplicar. Os diré que para las pruebas estaba la inteligencia de tiempos desactivada y como dimensión de tiempos estaba usando la plantilla que Salva proporciona gratuitamente en su web que entiendo que es la que usa él. 

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

PD.: Salva, no me importa el resultado de estas pruebas, tu sigues siendo un referente para mi 🙂.

Publicado por Roberto Carrancio en Cloud, Power BI, Rendimiento, SQL Server, 0 comentarios

NULL, un dato especial que debemos saber tratar

Cuando hablamos de datos, uno de los conceptos más interesantes y a menudo malinterpretados es el tratamiento del valor NULL. Nosotros, como DBAs, debemos comprender en profundidad cómo manejar estos valores especiales para asegurar la integridad y eficiencia de nuestras bases de datos. En este artículo, quiero profundizar en cómo SQL Server y las bases de datos SQL de Azure tratan los valores nulos, sus implicaciones y las mejores prácticas para su gestión. Por último compararemos este comportamiento con otros sistemas de gestión de bases de datos (SGBD) como PostgreSQL, MySQL y Oracle.

¿Qué significa NULL?

En el estándar SQL, NULL representa un valor desconocido o no aplicable. A diferencia de otros lenguajes de programación o de fórmulas, NULL no es igual a cero ni a una cadena vacía, en resumen, es simplemente la ausencia de un valor. Esta distinción es crucial, debemos interiorizarla y no olvidarla jamás, hazle un hueco en tu cerebro junto al recuerdo del gol de Iniesta en el minuto 116 de la final del Mundial de Sudáfrica 2010. Y no digo esto porque si, este comportamiento afecta a la forma en que las consultas se construyen y ejecutan. En entornos como SQL Server y Azure SQL, manejar correctamente los valores nulos puede marcar la diferencia entre una base de datos coherente y una llena de inconsistencias.

Tratamiento del valor NULL en SQL Server y Azure SQL

Lo primero que debemos recordar es que NULL no representa ningún valor y como tal no se va a comportar como un valor típico. En SQL Server, cualquier comparación lógica con NULL (por ejemplo, =, <, >, etc.) dará como resultado otro NULL. Esto se debe a que, al ser un valor desconocido, no se puede determinar con certeza si es igual o diferente a otro valor. Tenemos que pensar en que a la lógica de verdadero o falso (sí o no) se le va a sumar una tercera posibilidad, desconocido. Desconocido no es ni verdadero ni falso, ni sí ni no. Por esta razón, debemos utilizar el operador IS NULL o IS NOT NULL para verificar su existencia.

Efectos de NULL en las consultas

Cuando escribimos consultas, el manejo de los nulos es crucial. Vamos a verlo con un ejemplo, supongamos que tenemos una tabla Empleados y queremos encontrar a los que no tienen un jefe asignado. Podriamos pensar que esta consulta va a funcionar:

Sin embargo, esta consulta no devolverá ningún resultado, porque JefeID = NULL siempre es falso. La consulta correcta es:

Funciones de manejo de NULL

Para poder salvar estas limitaciones SQL Server y Azure SQL ofrecen varias funciones para tratar los valores nulos de manera efectiva. Algunas de las más útiles incluyen:

ISNULL(): Esta función reemplaza NULL con un valor especificado. Por ejemplo, para mostrar «N/A» en lugar de NULL en un campo de teléfono, usaríamos:

COALESCE(): Hemos visto que ISNULL() es una función que acepta dos valores y devuelve el primero que no sea NULL. Coalesce es igual, pero acepta múltiples argumentos y devuelve el primero que no sea NULL. Esto es especialmente útil cuando trabajamos con varias columnas que podrían contener valores nulos:

Tratamiento de NULL en funciones agregadas

Las funciones agregadas como SUM(), AVG(), MAX(), y MIN() directamente ignoran los valores nulos en sus cálculos. Esto es importante para evitar resultados inesperados. Por ejemplo, si queremos calcular el salario promedio de nuestros empleados, SQL Server excluirá automáticamente los valores nulos de la columna y podremos hacer esta consulta simple sin miedo a errores o resultados inesperados:

Tratamiento de NULL en Dynamic Data Masking (DDM)

DDM nos permite enmascarar la información sensible de nuestra base de datos y, en ocasiones, la propia ausencia de información es sensible en sí. Sin embargo, y esto es algo mejorable a mi parecer, DDM no nos permite ocultar valores NULL sensibles en nuestras tablas. Es decir, DDM solo enmascara datos conocidos, mostrando un valor NULL real a los usuarios sin privilegios igual que a los que sí tienen permiso de desenmascarar.

Implicaciones de NULL en índices y claves

Al definir índices y claves, debemos tener en cuenta cómo los valores nulos afectan a estas estructuras. Por ejemplo, en SQL Server, un índice único permite múltiples valores nulos, lo cual puede ser útil pero también peligroso si no se entiende y maneja correctamente. Veamos ahora 

Claves Primarias

Las claves primarias (PK) no admiten valores nulos. Esto es lógico, una clave primaria debe identificar de manera única cada fila en una tabla, y un valor nulo, al ser desconocido, no puede cumplir con esta restricción de unicidad. Por lo tanto, al diseñar nuestras tablas, debemos asegurarnos de que las columnas definidas como clave primaria siempre contengan valores no nulos. Realmente, SQL Server hará esto por nosotros y solo nos dejará definir como campos clave de una PK aquellas columnas definidas como NOT NULL, es decir, que no admiten valores nulos. 

En el ejemplo anterior, EmpleadoID no puede contener valores nulos, garantizando así la unicidad y la identificabilidad de cada registro. Gracias a esa restricción podemos definir la columna como clave primaria.

Claves Foráneas

Las claves foráneas (FK), por el contrario, sí pueden admitir valores nulos. Un valor nulo en una clave foránea indica que no hay una relación con la tabla referenciada. Esto puede ser útil para representar situaciones donde una relación no es obligatoria. Por ejemplo, si un empleado no tiene un jefe designado, el campo JefeID puede ser NULL.

En este caso, JefeID puede ser nulo, lo que indica que un empleado no tiene jefe.

Mejores prácticas para manejar NULL

Para mantener la integridad y eficiencia de nuestras bases de datos, debemos seguir algunas mejores prácticas en el uso y control de nulos. Siempre que sea posible, definiremos valores por defecto en nuestras columnas para evitar NULL. Por ejemplo, en lugar de permitir NULL en una columna de estado, podríamos definir «Desconocido» como valor por defecto. Los valores por defecto son aquellos que se van a poner en nuestra base de datos cuando insertamos un registro y no especificamos manualmente otra cosa. Por ejemplo:

No solo los nulos pueden ser un problema, también es posible que un dato técnicamente válido no tenga sentido de negocio. Para estos casos podemos utilizar restricciones CHECK y NOT NULL para asegurarnos de que nuestras columnas contengan siempre valores válidos. Por ejemplo, la siguiente restricción se asegura de que el salario de un empleado siempre sea un número mayor que 0. Como hemos visto antes, esta restricción también invalidará los valores NULL de forma intrínseca.

Por último, debemos documentar claramente cuándo y por qué permitimos nulos en nuestras tablas y asegurarnos de que todos los desarrolladores sigan las mismas buenas prácticas a la hora de crear tablas.

Comparación con otros SGBD

Como este tema es importante vamos a ver el comportamiento de NULL cuando trabajamos con otros de los principales motores de base de datos presentes en el mercado.

  • PostgreSQL maneja los valores nulos de manera similar a SQL Server. Al igual que en SQL Server, las comparaciones directas con NULL siempre devuelven NULL, y se utilizan IS NULL y IS NOT NULL para verificar la existencia de valores NULL. PostgreSQL también soporta funciones como COALESCE() y NULLIF() para manejar NULL. Una diferencia notable es que PostgreSQL permite definir restricciones más avanzadas usando expresiones booleanas, lo que puede ser útil para controles más complejos sobre los valores NULL.
  • MySQL, el manejo de nulos es también bastante similar. Las comparaciones directas con NULL resultan en NULL, y se usan IS NULL y IS NOT NULL para las verificaciones. MySQL proporciona las funciones IFNULL() y COALESCE() para manejar valores NULL. Un aspecto distintivo de MySQL es que, en ciertos modos de SQL, puede comportarse de manera más laxa con los valores nulos en índices únicos, permitiendo múltiples entradas NULL, lo cual es similar a SQL Server.
  • Oracle maneja los nulos de manera muy coherente con el estándar SQL. Las comparaciones con NULL devuelven NULL, y se utilizan IS NULL y IS NOT NULL. Oracle también ofrece funciones como NVL() (que es equivalente a ISNULL() en SQL Server) y COALESCE(). Una característica única de Oracle es su uso de NULLS FIRST y NULLS LAST en las cláusulas ORDER BY, permitiendo un control más granular sobre el orden de los valores NULL en los resultados de las consultas.

Comparación con DAX

Ya hemos hablado de DAX (Data Analysis Expressions) en el blog. DAX es un lenguaje de fórmulas utilizado en Power BI, Analysis Services y Power Pivot para realizar cálculos y consultas de datos. DAX tiene su propia forma de manejar valores nulos, conocida como BLANK. En DAX, el equivalente de NULL es BLANK. El manejo de valores BLANK en DAX difiere de los NULL en SQL en varios aspectos clave

Comparaciones

En DAX, una comparación directa con BLANK no devuelve BLANK. En lugar de eso, BLANK es tratado como 0 (cero) en comparaciones numéricas y como una cadena vacía en comparaciones de texto. Por ejemplo:

Funciones de manejo de BLANK

DAX proporciona varias funciones para manejar valores BLANK, incluyendo BLANK(), ISBLANK(), y COALESCE(). La función COALESCE() en DAX es similar a su homóloga en SQL, devolviendo el primer valor que no sea BLANK.

Impacto en cálculos agregados

Las funciones agregadas en DAX, como SUM(), AVERAGE(), MAX(), y MIN(), manejan los valores BLANK de manera similar a SQL, ignorándolos en los cálculos. Sin embargo, es importante saber que en DAX, un BLANK en una medida puede tener implicaciones diferentes dependiendo del contexto del cálculo. Supongamos que tenemos una tabla de ventas en Power BI y queremos calcular el total de ventas, tratando los valores nulos en la columna Cantidad como ceros:

En este ejemplo, la función SUMX recorre cada fila en la tabla Ventas y utiliza COALESCE para tratar los valores BLANK en la columna Cantidad como 0.

Diferencias clave DAX vs SQL

Como hemos visto el tratamiento de los valores nulos en DAX difiere del de SQL. Podríamos resumir las diferencias así:

  • Manejo en comparaciones: Mientras que en SQL, NULL no se puede comparar directamente y cualquier comparación devuelve NULL, en DAX el valor BLANK se trata como 0 o una cadena vacía, dependiendo del contexto.
  • Funciones específicas: DAX tiene funciones específicas para trabajar con BLANK, y estas funciones son esenciales para manejar datos en contextos de análisis y cálculos complejos.
  • Contexto de cálculo: En DAX, el contexto de cálculo puede afectar cómo se manejan los valores BLANK, especialmente en modelos de datos complejos donde se utilizan múltiples tablas y relaciones.

Conclusión

El manejo de valores nulos es una característica fundamental  cuando trabajamos con datos, ya sea en SQL Server, Azure SQL, otros SGBD como PostgreSQL, MySQL y Oracle o con herramientas de BI como Power BI. Aunque las diferencias en el comportamiento son sutiles, cada SGBD ofrece herramientas y funciones específicas para tratar con valores NULL de manera eficiente. 

Comprender estas diferencias y mejores prácticas es imprescindible para diseñar y gestionar nuestras bases de datos de manera más efectiva, asegurando la integridad y eficiencia de nuestros sistemas. 

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, Power BI, SQL Server, 0 comentarios

Consultar datos con DAX

Voy a empezar por el final este artículo: Tenemos que saber DAX. No digo que seamos expertos en la materia pero sí ser capaces de entender y aconsejar en un momento dado a los usuarios. Y ahora que ya lo he dicho, y antes de ganarme más de un enemigo, os voy a explicar por qué.

Dentro de la estructura empresarial, los DBAs somos una grupo en ocasiones difícil de encajar. Nuestro trabajo se divide entre varios departamentos más asentados históricamente como sistemas, IT o infraestructura y los consumidores de los datos que acostumbraban a ser desarrolladores. Es raro que el DBA tenga relación directa con el usuario final de los datos. En los últimos años, cada vez cobra más fuerza un subgrupo que inicialmente podríamos encajar dentro de desarrollo pero que, por su importancia en las organizaciones, cada vez tiene más peso e independencia, los trabajadores de datos. Estamos hablando de analistas, ingenieros, científicos de datos, etc… Esto nos lleva a tener que entendernos con ellos también, y cuanto mejor sea este entendimiento mejor podremos desarrollar nuestro trabajo. 

Veamos cómo trabaja esta gente: primero de todo conectan sus herramientas de ETLs a los orígenes de datos para extraer información que alimente sus modelos. Una vez hecho eso, tratan esa información para extraer las métricas de negocio que importan a los usuarios finales de estos reportes. Igual que sabemos como funciona un servidor y una red para entendernos con los compañeros de infraestructura, igual que sabemos SQL para entendernos con los compañeros consumidores de los datos, tenemos que saber cómo funciona una herramienta de ETLs, por ejemplo SSIS, y cómo tratar los datos en herramientas de BI (por ejemplo DAX en Power BI).

¿Qué es DAX?

Lo primero que tenemos que aclarar es que DAX no es un lenguaje de programación. Al contrario de lo que mucha gente puede llegar a pensar, DAX es un lenguaje de fórmulas. Similar a excel si lo queréis ver así. Es más. si sabemos algo de excel vamos a tener mucho ganado a la hora de empezar con DAX. Eso no quiere decir que sea lo mismo que Excel, DAX es mucho más potente (para llevarlo a nuestro terreno es como comparar Access y SQL). Por ejemplo, una de las características de DAX más potentes es el contexto de filtro para realizar cálculos dinámicos basados en los datos filtrados.

Herramientas para Usar DAX

Antes de meternos con los detalles técnicos de DAX y aprender a usarlo, es importante conocer las herramientas que podemos utilizar para escribir y ejecutar expresiones DAX (que no código, ya hemos dicho que DAX no es un lenguaje de programación).

Power BI Desktop

Power BI Desktop es la herramienta más popular para trabajar con DAX. Permite a los usuarios crear informes interactivos y visualizaciones a partir de varios orígenes de datos. Desde hace poco, incluye un editor de DAX integrado que facilita la creación y prueba de fórmulas DAX.

DAX Studio

DAX Studio es una herramienta gratuita y de código abierto diseñada para ejecutar y analizar consultas. Se puede integrar con Power BI como herramienta externa y es ideal para depurar y optimizar las fórmulas DAX. DAX Studio nos va a permitir conectarnos directamente a modelos de datos en Power BI, Analysis Services y Power Pivot.

SQL Server Management Studio (SSMS)

Nuestro querido SSMS es principalmente una herramienta para trabajar con bases de datos SQL Server pero, también puede conectarse a instancias de Analysis Services para ejecutar consultas DAX. Esto es útil para los usuarios de bases de datos que desean integrar DAX en sus flujos de trabajo aunque su uso es residual ya que Analysis Services está siendo sustituido por otras herramientas de modelado tabular.

Excel con Power Pivot

Excel, junto con el complemento Power Pivot, va a permitir a los usuarios crear modelos de datos complejos y utilizar DAX para realizar cálculos avanzados. Esto es especialmente útil para los usuarios de Excel que están familiarizados con las fórmulas y desean aprovechar las capacidades avanzadas de DAX aunque nunca va a llegar a la potencia de una herramienta de BI como Power BI.

Trabajar con DAX

Ahora si, después de esta introducción tan larga vamos a ver como empezar a trabajar con DAX. Dada la temática principal del blog voy a suponer que los que leéis estas líneas estáis familiarizados con el lenguaje SQL por lo que vamos a ir viendo cómo hacer operaciones en DAX en comparación a SQL. 

Lectura simple de datos

Empecemos con lo más básico, lo primero que aprendemos cuando empezamos con SQL es a leer datos de una tabla así que con DAX no podía ser de otra manera. Para leer datos de una tabla vamos a usar la función EVALUATE que sería como select * from en SQL.

DAX-1

Ahora bien, normalmente no vamos a necesitar todos las columnas de una tabla, y menos cuando estamos hablando de un entorno analítico. Igual que en SQL declaramos las columnas que queremos seleccionar vamos a ver como hacerlo en DAX.

DAX-2

También vamos a poder poner un alias a las columnas si queremos otro nombre para mostrar. Veamos cómo:

DAX-3

Ya hemos visto cómo filtrar solo las columnas que necesitamos, ahora vamos a ver otro de los casos más comunes. Filtrar las filas en base a una condición. Normalmente en SQL usamos la cláusula WHERE, en DAX vamos a usar la función FILTER.

DAX-4

Operaciones de agregación

Otra de las cosas básicas más comunes son las agregaciones de datos para sumar o calcular mínimos, máximos, promedios y conteos. Veamos cómo lo hacemos

DAX-5

Funciones avanzadas de filtrado y contexto en DAX

Como hemos comentado al inicio, una de las ventajas del uso de DAX es que nos permite “jugar” con el contexto de los filtros. Así, vamos a ser capaces de realizar funciones con un contexto distinto a lo filtrado en nuestro informe. Gracias al uso de la función CALCULATE vamos a poder realizar nuestros cálculos en un contexto de filtros definido en la propia fórmula y sin tener en cuenta el resto de filtros del informe (excepto RLS pero eso ya es otra cosa)

DAX-6

También, podemos combinar CALCULATE con las funciones ALL o REMOVEFILTERS para que en estos cálculos no intervengan filtros, muy útil cuando queremos usar estos valores totales o promedios en un informe sin que sufran variación por los filtros.

DAX-7

Conclusión

El uso de DAX para leer y filtrar datos nos permite realizar análisis extremadamente detallados y personalizados en Power BI y otras herramientas de Microsoft. Desde funciones básicas de agregación hasta técnicas avanzadas de filtrado y manipulación del contexto de filtro, DAX es una herramienta indispensable para cualquier trabajador de datos.

Hoy solo hemos visto lo más básico, esto es solo la punta del iceberg, a medida que nos familiarizamos con estas funciones y conceptos, podemos desbloquear todo el potencial de nuestros datos, obteniendo métricas valiosas que de otro modo pasarían desapercibidos. Fijaos si este tema es extenso que existen multitud de libros completos solo de DAX como este de José Manuel Pomares que es una auténtica maravilla.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Power BI, 0 comentarios

Plegado de consultas en Power BI

Si ya has trabajado alguna vez con Power BI, sobre todo si te has interesado por su rendimiento, te sonará el concepto plegado de consultas (query folding en inglés). Este concepto es clave en el rendimiento de power BI y sin embargo a mucha gente se le escapa o no lo comprende muy bien. Hoy, voy a intentar arrojar algo de luz sobre este tema de manera sencilla y para todos los públicos aunque, ya os adelanto que el tema da para mucho y si os interesa al final del artículo os dejo alguna recomendación extra para continuar aprendiendo. 

¿Qué es el plegado de consultas?

Empecemos por el principio, el plegado de consultas, o “Query Folding”, es un proceso por el cual el motor de Power Query (mashup engine) intenta llevar a cabo la mayor cantidad de transformaciones de datos posible en los sistemas de origen origen, en lugar de hacerlo después de que los datos se hayan cargado en la memoria. Esto puede resultar en una mejora significativa del rendimiento de Power BI, especialmente cuando se trabaja con grandes volúmenes de datos.

¿Qué es Power Query?

¡Quieto Roberto! A más de uno le acaba de volar la cabeza con el párrafo anterior. He introducido el concepto Power Query sin explicaros lo que es, perdonadme. Power Query es una característica de Power BI que cumple las funciones de ETL (extraer, transformar y cargar datos). Gracias al motor mashup engine es capaz de extraer datos de varios orígenes, transformar lo que sea necesario y por último cargarlos en un destino. Principalmente vamos a poder encontrar esta función en Power BI, en los flujos de datos de Power BI (dataflows) y en Microsoft Excel 2016 o superiores. Adicionalmente vamos a poder usar Power Query en Excel 2010 y 2013 si descargamos e instalamos manualmente el componente.

¿Cómo funciona el plegado de consultas?

Cuando creamos una consulta con lenguaje M en Power Query, estamos definiendo una serie de pasos para obtener y transformar nuestros datos. Estos pasos pueden incluir filtrado, agrupación, unión de tablas, entre otros. Idealmente, queremos que estos pasos se realicen en el origen de los datos. Esto es lo que se conoce como plegado de consultas y se podrá llevar a cabo en la mayoría de los casos si los orígenes admiten lenguaje SQL y, siempre y cuando, la instrucción M se traduzca en una sola select con funciones que existan en el lenguaje SQL.

El siguiente diagrama de la documentación oficial de microsoft explica el proceso paso a paso:

Diagrama-plegado-consultas
  1. Power Query recibe el script en código M desde el editor avanzado.
  2. El mecanismo de plegado de consultas envía una consulta de metadatos al origen de datos para evaluar sus características.
  3. El mecanismo de plegado de consultas determina qué información extraer del origen de datos y qué conjunto de transformaciones deben producirse dentro del motor de Power Query. 
  4. Power Query consulta el origen de datos mediante una consulta nativa.
  5. El origen de datos devuelve los datos al motor de Power Query.
  6. Una vez que los datos están en Power Query, el motor de transformación de Power Query (también conocido como motor de mashup) realizará las transformaciones que no se pudieron plegar ni descargar en el origen de datos.
  7. Carga en el modelo de Power BI (o en excel) de los datos extraídos y transformados.

¿Por qué es importante?

El plegado de consultas es especialmente útil cuando trabajamos con grandes conjuntos de datos. Al realizar las transformaciones en el origen de los datos, reducimos la cantidad de datos que necesitamos cargar en la memoria, lo que puede resultar en un rendimiento significativamente mejorado. Si por ejemplo solo necesitamos unas pocas filas y columnas de la tabla de origen, gracias al plegado de consultas no vamos a tener que traer todos los datos para luego filtrarlos. Igualmente si, podemos realizar las uniones entre tablas, agregaciones y ordenados en el origen (que está optimizado para ello) es trabajo que le quitamos a nuestro Power BI.

Tiene otras ventajas, como que Power BI optimizará en gran medida las cargas incrementales de los datos cuando las consultas son 100% plegables ya que si no habría que leer todo el origen y cargarlo en memoria para que el mashup engine cribe las filas nuevas de las ya existentes.

¿Cómo saber si se está realizando el plegado de consultas?

Power Query Dataflows proporciona indicadores visuales que nos permiten saber si se está realizando el plegado de consultas. Estos indicadores se encuentran en la ventana de Power Query y nos muestran qué pasos se están plegando a través de iconos. Esto está muy bien resumido en la documentación oficial así que os dejo directamente el extracto.

Plegado-de-consultas

En Power BI Desktop no va a ser tan sencillo verlo como mirar los iconos al lado de los pasos de la transformación, sin embargo, eso no significa que no podamos verlo. Simplemente con hacer clic derecho sobre el paso y verificar si nos está ofreciendo ver la consulta nativa podremos saber si se mantiene o no el plegado de consultas.

Andrés en nuestro grupo de Telegram añade: «Otra de las formas de saber si el plegado se mantiene, es con la función Value.Metadata (tabla). Devuelve información sobre si existe o no el plegado. Del mismo modo, podemos usar una instrucción para mantener el plegado, es con la función Value.NativeQuery() y con el parámetro EnableFolding=true. Esto nos permitirá enviar una consulta directa a SQL Server, mantener el plegado y poder seguir realizando pasos que mantengan el plegado. El problema es que cuando escribes directamente la consulta desde el conector a SQL Server, la consulta ya no seguirá plegando de ahí en adelante. Por suerte, la función Value.NativeQuery(…), si nos permite esto.«

Niveles de plegado de consulta

Como hemos visto a lo largo de este artículo, existen ciertas operaciones de transformación de datos incompatibles con el plegado de consultas. A esto se le llama romper el plegado de consultas y deberemos evitarlo en la medida de lo posible. Aun así, esto no quiere decir que la consulta ya no se vaya a plegar por tener un paso incompatible, la optimización del motor de Power Query sabrá plegar todos los pasos posibles y solo efectuar en el motor de transformaciones lo estrictamente necesario. En este sentido, nos vamos a encontrar con tres niveles de plegado de consultas:

  • Plegado de consultas completo: Todas las transformaciones de consulta se delegan en el origen de datos. El motor de Power Query realiza un procesamiento mínimo y muy eficiente.
  • Plegado parcial de consultas: Una parte de las transformaciones de la consulta, y no todas, se pueden delegar en el origen de datos. En este caso, una parte de las transformaciones las realiza el origen de datos y el resto se producen en el motor de transformaciones de Power Query.
  • Sin plegado de consultas: La consulta no se puede plegar. Normalmente contiene transformaciones que no se pueden traducir al lenguaje de consulta nativo del origen de datos, ya sea porque las transformaciones no son compatibles o porque el conector no admite el plegado de consultas. En este caso, Power Query obtiene los datos sin procesar del origen de datos y utiliza el motor de Power Query para lograr los datos deseados mediante el procesamiento de las transformaciones necesarias a nivel del motor de Power Query.

Conclusión

El plegado de consultas es un concepto complejo pero crucial para el rendimiento en Power BI. Si trabajas a menudo con Power Query dedica tiempo a entender en profundidad esta funcionalidad y así mejorar considerablemente tus resultados. Por mi parte no me queda más que, como os había prometido al inicio, recomendaros el libro “Power BI Dataflows” de Francisco Mullor para convertiros en unos verdaderos maestros de la herramienta. Si solo os interesa este tema que hemos tratado hoy o si queréis usarlo como aproximación al libro, Fran ha publicado el capítulo dedicado al plegado de consultas de manera que está accesible de manera gratuita aquí. También podéis pasar por la academia virtual de Alex Ayala donde encontraréis cursos de Power BI de gran calidad.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Power BI, Rendimiento, 0 comentarios

Uso de vistas y más buenas prácticas en Power BI

Iniciamos esta semana como terminamos la pasada, con otro artículo sobre análisis de datos e inteligencia de negocio. En concreto vamos a seguir hablando de buenas prácticas en Power BI. Si en nuestro último artículo hablábamos de la importancia de usar un modelo de estrella en Power BI hoy vamos a repasar el resto de buenas prácticas también muy importantes en esto del modelado de datos.

Antes de seguir quiero hacer un inciso (“Disclaimer cero” que diría el gran motero Isaac Feliú) todas las recomendaciones descritas en este artículo aplicadas a Power BI también son válidas para modelos tabulares como Power Pivot, Analisys Services y otros. Aun así, esto no quiere decir que tengamos que tomarnos estas buenas prácticas como los diez mandamientos escritos en piedra e inamovibles, son unas recomendaciones y no todas van a ser aplicables al 100% para todos los modelos. 

Uso de vistas en Power BI

Las vistas son consultas almacenadas en la base de datos que generan un conjunto de resultados al ser invocadas. Podríamos decir que son tablas virtualizadas que se basan en el resultado de una consulta SQL y “no almacenan los datos” así entre unas comillas muy grandes. Cuando hablamos de modelado de datos, las vistas juegan un papel crucial. En Power BI, las vistas pueden ser una herramienta poderosa para simplificar y optimizar nuestros modelos de datos. Vamos ahora a ver estas ventajas:

Abstracción del modelo

Gracias al uso de vistas, cuando importamos datos desde entornos de bases de datos relacionales como SQL Server o Azure SQL vamos a poder abstraer nuestro modelo de datos del modelo original de las aplicaciones transaccionales. Esto que puede no parecer importante realmente es clave, ya que los modelos de datos suelen ser entidades vivas cambiantes con cada actualización de las aplicaciones. Gracias al uso de vistas, vamos a poder salvar este inconveniente, y en caso de cambios en el nombre de una columna, por ejemplo, vamos a poder corregirlo en un solo sitio sin tener que cambiarlo en todos los informes.

Simplificación del modelo de datos de Power BI

Las vistas pueden ayudar a simplificar nuestros modelos de datos en Power BI. Al encapsular la lógica de las consultas en una vista, podemos reducir la complejidad de nuestro modelo de datos y hacerlo más fácil de entender y mantener. En otras palabras, podremos aprovechar estas vistas para simplificar lo más posible el modelo de datos, eliminando de las consultas de la vista todas aquellas columnas que no necesitamos en el modelo analítico.

Mejora el rendimiento de Power BI

Las vistas también pueden contribuir a mejorar el rendimiento de nuestros informes de Power BI. Al utilizar vistas, podemos minimizar la cantidad de datos que necesitamos cargar en Power BI, lo que puede resultar en informes más rápidos y eficientes. También, gracias al uso de vistas indexadas, que ya vimos hace meses en este blog, podemos mejorar el rendimiento de manera sustancial, hasta pasando de horas de procesamiento de la consulta a segundos en los casos más extremos.

Seguridad de los Datos

Las vistas nos permiten implementar una capa adicional de seguridad en nuestros datos. Podemos utilizar vistas para restringir el acceso a ciertos datos, asegurando que sólo los usuarios autorizados puedan ver la información sensible. 

Banner-Telegram

Buenas prácticas en el uso de vistas

Ya hemos visto que el uso de vistas para alimentar nuestro modelo es una buena práctica en sí misma pero esto no queda ahí, existen unas buenas prácticas para la buena práctica de crear vistas. Gracias a estas “meta buenas prácticas” vamos a poder sacar todo el partido de las ventajas del uso de vistas que ya os he comentado. Vais a ver cómo, a medida que las vayamos viendo vamos a poder enlazarlo claramente con todo lo ya mencionado arriba.

Uso de esquemas

Crear un esquema dedicado a las vistas que se van a utilizar para alimentar el modelo de Power BI no solo sirve para mantener la organización, también nos va a ayudar a poder centralizar los permisos. Podemos incluso crear varios esquemas si tenemos varios grupos de informes o reportes en Power BI para tener más control sobre su seguridad y organización. A la hora de importar las tablas al modelo de Power BI no hay ningún problema en eliminar el nombre del esquema y dejar solo el de la vista.

Crear vistas por tabla de Power BI

Otra de las mejores recomendaciones que podemos encontrar sobre este aspecto es la creación de vistas independientes por cada tabla del modelo de Power BI y no por cada tabla del modelo relacional original. De esta manera podemos aprovechar la potencia de SQL Server o el SGBD relacional que usemos y sus índices para las uniones entre tablas y que se presenten a Power BI como una tabla plana.

Limitar el número de columnas

Otra de las ventajas del uso de vistas era optimizar el rendimiento reduciendo la lectura de datos que no van a ser explotados por el modelo de Power BI, esto lo lograremos declarando los campos necesarios en el select de la vista en lugar de un carácter *. De esta manera además podremos ver de una manera fácil en SQL Server que datos se están explotando en Power BI y los DBAs tendremos más fácil localizar las actuaciones del modelo relacional que pueden afectar al modelo analítico.

Otras buenas prácticas para Power BI

No solo de modelos en estrella y vistas vive un buen modelador de datos, existen además ciertas recomendaciones que también tendremos que tener en cuenta al diseñar nuestro modelo en Power BI. Vamos a repasar las más significativas:

Utiliza nombres significativos

Esto es de primero de modelador de datos, no solo para modelos analíticos, sin embargo, es común encontrarnos con situaciones en las que no se aplica, ya sea por desconocimiento, indiferencia o una mezcla de las dos (el típico ni lo sé ni me importa). Un nombre descriptivo a la hora de definir las columnas de las vistas que van a alimentar nuestro modelo en Power BI nos ayudará luego a crear los reportes con menos trabajo. Por supuesto evita repetir los mismos nombres para distintas columnas a no ser que sea en distintas tablas y esas columnas sean las claves por las que vas a relacionar las tablas. En ese caso un nombre común te ayudará a localizar las relaciones. Piensa que al usar vistas has perdido la capacidad de consultar las relaciones establecidas en las tablas de la base de datos por medio de claves foráneas. 

Separa fechas y horas

En los sistemas de bases de datos relacionales es común el uso de tipos de datos que incluyen la fecha y la hora, incluso con presiones de microsegundos o más, por ejemplo en SQL Server el tipo de datos datetime2 tiene una precisión de 7 dígitos (hasta 100 nanosegundos). Esta precisión puede que sea clave para una aplicación pero, os aseguro, que al gerente que está visualizando un informe como mucho le importan los segundos, el resto de precisión suele ser despreciable. Cuando trasladamos estos datos a Power BI seguramente no necesitamos esa precisión, valora separar estos campos en un campo date y otro time y ajustar la precisión a los valores que vayan a necesitar los consumidores de tus reportes.

Mantén los modelos de Power BI sencillos

El título lo dice todo, no hay mucho más que añadir. Aunque Power BI puede manejar modelos de datos complejos, es mejor mantener los modelos lo más sencillos posible. Un modelo simple es más fácil de entender, mantener y optimizar.

Utiliza columnas calculadas y medidas de manera eficiente

Las columnas calculadas y las medidas son dos características poderosas de Power BI. Debemos utilizarlas de manera efectiva para mejorar el rendimiento y la funcionalidad de nuestros informes y valorar cuándo nos va a dar mejor rendimiento un cálculo en el motor de base de datos implementado en la propia vista y cuándo será mejor delegar ese trabajo en Power BI.

Marca las tablas de fecha de Power BI

En los inicios de Power BI, las tablas de dimensiones de fechas eran una tabla más, como todas las demás solo que almacenaban fechas. Sin embargo, desde la actualización de 2018 de Power BI, existe una marca para catalogar las tablas que contienen datos de fecha y hora como tablas de fechas. Esto optimizará el rendimiento y mejorará la experiencia de los usuarios.

Optimiza el Rendimiento

Para terminar, no es que sea una buena práctica como tal pero sí es importante remarcar que debemos revisar continuamente el rendimiento. Nuestro modelo va a crecer con el tiempo y puede que algunas soluciones que en un principio parecían aceptables ahora no lo sean. También podemos encontrarnos con casos como el anterior en el que una actualización de Power BI nos habilita una nueva funcionalidad para optimizar nuestro modelo. El rendimiento es un aspecto crítico del modelado de datos. Debemos tener en cuenta factores como el tamaño de los datos, la complejidad de las consultas y la capacidad de la máquina al diseñar y mantener nuestros modelos.

Conclusión

El modelado de datos es una ciencia y un arte a partes iguales. Conocer las buenas prácticas, y aplicarlas siempre que sea posible, nos ayudará a diseñar reportes optimizados que mejoren la experiencia de los usuarios finales. Espero que gracias a estos artículos estés más cerca de ese objetivo. Y ya sabes, si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Power BI, Rendimiento, 0 comentarios