Los modelos compuestos en PowerBI

Anteriormente en otros artículos dimos una breve introducción acerca de la importancia de los modelos de datos en las soluciones de análisis de datos, en este artículo vamos a hacer un análisis de los modelos compuestos cuando usamos la herramienta PowerBI.

Como vimos anteriormente al iniciar con el desarrollo de una solución de análisis de datos, debemos dedicar el tiempo suficiente para revisar que modelo de datos vamos a implementar en nuestra solución.

Dependiendo del tamaño, disponibilidad de los datos y demás seleccionamos el modelo adecuado, en este caso tenemos ya reportes que están en línea y que ya generan una parte de los datos que necesitamos para este nuevo reporte, los reportes pueden tener fuentes de datos en línea desde conexiones a SharePoint, Conjuntos de datos de PowerBI, Flujos de Datos de PowerBI entre otros. Para este caso específico el nuevo reporte tiene sus propias fuentes de datos pero tomará algunos datos de un reporte ya existente, lo que va generar un modelo compuesto, como lo muestra la siguiente imagen.

Ahora revisamos que está pasando aquí, el nuevo reporte tiene sus propias fuentes de datos, consultas a una base de datos y archivos online, pero también está utilizando datos de un reporte existente a simple vista se puede rescatar que tenemos una ventaja al no tener que transformar nuevamente esos datos, pero hay que tener precaución en el uso de este modelo.

Desventajas de este modelo:

  1. Este modelo hereda cualquier error del conjunto de datos (DataSet)
  2. No se puede implementar una actualización automática con columnas calculadas creadas en el conjunto de datos heredado.
  3. Las medidas existentes en el conjunto de datos no se pueden editar, si necesitas añadir algo a la medida debes crear una nueva.
  4. No se puede tener una frecuencia de actualización diferente para cada reporte que comparta el conjunto de datos.

Pero también se tienen ventajas, algunos ejemplos:

  1. Centralización de los datos, se tiene un único punto para esos datos y si se arregla un error se propaga a todos los reportes dependientes de ese conjunto de datos.
  2. Una única verdad, si en el conjunto de datos se crea un kpi, ese kpi es el mismo para todos los reportes que comparten la fuente de datos.
  3. Se evita la redundancia y la duplicación de fuentes de datos.

Otro aspecto a mencionar es que se puede utilizar un Flujo de Datos para separar la fuente y democratizar su uso sin tener que relacionar los datos a un reporte específico, pero debe valorarse el escenario, ya que si el objetivo es tener gobernanza, se puede utilizar un Datamart o una vista en un Datawarehouse (almacén de datos), que sirva como referencia para cada uno de los reportes que necesitan esos datos.

Conclusión, debemos tener mucho cuidado en analizar las características de nuestra nueva solución de análisis de datos, ya que estas nos dicen que modelos datos vamos a usar y cuales descartar, para evitar en un futuro tener que ajustar.

Recuerda que en datumfore.com, somos expertos en la creación de soluciones de análisis de datos y automatización, agenda una cita y con gusto te ayudamos a liberar el poder de tus datos.