4.5Dataflows y modelos compuestos
Lo esencial en 30 segundos
- El dataflow = Power Query en la nube: consultas centralizadas en el Servicio, reutilizables por varios informes — preparar una vez, consumir en todas partes.
- La conexión activa a un modelo semántico publicado instala un único modelo de verdad: las medidas definidas una vez, consumidas por todos.
- El modelo compuesto combina un modelo central publicado Y tablas locales (p. ej. un presupuesto de Excel): potente, a reservar para necesidades reales — y sujeto a licencias Pro/Premium.
Mini-caso hilado — Zineb piensa la arquitectura de equipo
Zineb, controladora de gestión en una pyme agroalimentaria de Argel, observa que tres informes del equipo rehacen exactamente la misma limpieza del maestro de productos y de la tabla de fechas. En lugar de corregir cada archivo .pbix uno por uno, piensa en arquitectura. Aplica la sección: esa limpieza repetida se convierte en candidata a dataflow (Power Query en el Servicio, preparado una vez); el modelo de ventas, con sus medidas clave, se convierte en el modelo de verdad publicado una vez y consumido por conexión activa; y un informe que deba añadir su presupuesto local usará un modelo compuesto. Escribe la hoja de ruta en tres líneas: dataflows (preparación) → modelo central (medidas) → informes conectados. Anota el hito: estos bloques requieren una licencia Pro — los conceptos se dominan ya.
Caso autónomo de esta sección: vuelve en el curso, el esquema, el guion y el reto 48 h de la sección 4.5.
1. Mutualizar la preparación
Cuando varios informes repiten la misma limpieza de Power Query, es hora de mutualizar: los dataflows trasladan la preparación al Servicio — una consulta central (el maestro de productos limpio, la tabla de fechas) que consumen todos los informes. Preparar una vez, reutilizar en todas partes: cuando la regla cambia, se modifica en un solo lugar. Zineb detecta cada limpieza repetida como una candidata a dataflow.
2. Un único modelo de verdad
La conexión activa a un modelo semántico publicado instala un único modelo de verdad: las medidas clave se definen una vez y las consumen todos los informes conectados. Se acabaron los «ingresos distintos según el informe». Zineb publica por tanto su modelo de ventas una sola vez, y sus informes se conectan a él en lugar de redefinir cada medida.
3. Los modelos compuestos
Cuando un informe debe combinar un modelo central publicado Y datos locales, los modelos compuestos lo permiten: conectarse al modelo de verdad y añadir su tabla de presupuesto de Excel. Es potente pero más complejo, a reservar para necesidades reales. Zineb anota también que estos bloques de equipo corresponden a licencias Pro/Premium — los conceptos se aprenden ya, las herramientas llegarán después.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — La hoja de ruta de equipo
Zineb escribe la arquitectura objetivo en tres líneas:
Dataflows → preparar los maestros una vez (productos, calendario)
Modelo central → medidas clave definidas una sola vez, publicado
Informes → conexión activa al modelo (medidas ya hechas)
+ Compuesto → un informe añade su tabla de presupuesto local.Lectura: cada limpieza repetida es una candidata a dataflow; cada medida compartida, una candidata a modelo central.
Lección: estos bloques estructuran el trabajo en equipo — su interés nace con varios informes/autores.
Vocabulario de la sección
- Dataflow
- Power Query en la nube: consultas centralizadas en el Servicio, reutilizables por varios informes — preparar una vez, consumir en todas partes.
Ejemplo sencillo: Zineb centraliza en él la limpieza del maestro de productos.
Lo que no es: rehacer la misma limpieza en cada .pbix.
Reflejo: limpieza repetida → dataflow.
- Modelo semántico (dataset)
- El modelo publicado (tablas, relaciones, medidas): otros informes pueden conectarse en directo (conexión activa) sin duplicar.
Ejemplo sencillo: Zineb publica su modelo de ventas una sola vez.
Lo que no es: un modelo recreado en cada informe.
Reflejo: publicar una vez → reutilizar en todas partes.
- Conexión activa (Live)
- El informe consume un modelo publicado tal cual: un único modelo de verdad, varios informes conectados.
Ejemplo sencillo: Los informes de Zineb se conectan a él: las medidas llegan ya hechas.
Lo que no es: redefinir las medidas en cada informe.
Reflejo: un modelo de verdad → conexión activa.
- Modelo compuesto
- La mezcla: conexión a un modelo publicado + tablas locales añadidas (DirectQuery sobre modelo semántico) — flexibilidad máxima, complejidad en proporción.
Ejemplo sencillo: Zineb añade su tabla de presupuesto local al modelo central.
Lo que no es: duplicar todo el modelo por una pequeña tabla.
Reflejo: central + local → compuesto (con moderación).
- Un único modelo de verdad
- El principio de arquitectura: las medidas clave definidas UNA vez, consumidas por todos — se acabaron los «ingresos distintos según el informe».
Ejemplo sencillo: Zineb garantiza unos ingresos únicos para todo el equipo.
Lo que no es: cifras divergentes de un informe a otro.
Reflejo: una definición, una sola vez.
En la práctica — En la práctica — Pensar la arquitectura de equipo (ejercicio de diseño)
- Haga inventario: ¿cuántos informes de su equipo rehacen LA MISMA limpieza (maestros, calendario, mapeo)? Cada duplicado es una candidata a dataflow.
- Identifique el posible modelo «de verdad»: ¿qué modelo merece publicarse una vez y ser consumido por todos (conexión activa)?
- Si tiene licencia Pro: pruebe la conexión a un modelo publicado (Obtener datos → Modelos semánticos de Power BI) — las medidas llegan ya hechas.
- Escriba la arquitectura objetivo en 3 líneas: dataflows (preparación) → modelo central (medidas) → informes conectados. Es la hoja de ruta de equipo.
Guion paso a paso — pensar la arquitectura como Zineb (7 min)
1) Enumere las limpiezas repetidas en su equipo (maestro de productos, tabla de fechas, mapeo): cada una es una candidata a dataflow. 2) Elija el modelo «de verdad»: aquel cuyas medidas merecen definirse una sola vez. 3) Si tiene Pro, obtenga los datos → Modelos semánticos de Power BI y conéctese a ese modelo: las medidas llegan ya hechas. 4) Para una necesidad de datos locales, prevea un modelo compuesto (central + tabla de Excel). 5) Escriba la hoja de ruta: dataflows → modelo central → informes conectados.
Estos bloques requieren una licencia Pro/Premium: los conceptos se aprenden ya, el acceso llegará según su organización.
Plantilla copiar y pegar — mi hoja de ruta de equipo
Limpiezas repetidas: ___ → dataflow (preparación una vez)
Modelo de verdad: ___ → publicado, medidas definidas UNA vez
Informes: conexión activa al modelo central (medidas ya hechas)
Necesidad local: ___ → modelo compuesto (+ tabla local, si de verdad hace falta)
Cadena: dataflows → modelo central → informes conectados.
Licencias: Pro/Premium para estos bloques de equipo.Dataflow
Zineb centraliza la limpieza del maestro de productos: un solo dataflow para todos los informes.
Modelo de verdad
Zineb publica su modelo de ventas una vez; los informes se conectan a él por conexión activa.
Compuesto
Zineb añade su tabla de presupuesto local al modelo central, sin duplicarlo.
Fin de los ingresos divergentes
Zineb define las medidas una sola vez: se acabaron los «ingresos distintos según el informe».
✓ Buenas prácticas
- Transformar cada limpieza repetida en un dataflow mutualizado.
- Publicar un modelo de verdad consumido por conexión activa.
- Reservar lo compuesto para necesidades reales (central + local).
✗ Errores frecuentes
- Duplicar la misma limpieza en diez .pbix aislados.
- Multiplicar los modelos de origen («ingresos distintos según el informe»).
- Adoptar lo compuesto sin necesidad (complejidad en proporción).
Puntos clave
- Dataflow = Power Query mutualizado en la nube: preparar una vez, reutilizar en todas partes.
- Conexión activa a un modelo publicado = un único modelo de verdad, informes múltiples.
- Lo compuesto combina modelo central + datos locales: a reservar para necesidades reales.
- Estos bloques estructuran el trabajo en equipo: su interés nace con varios informes/autores.
Reto 48 h — aplícalo mañana
Como Zineb, enumere las limpiezas repetidas de su equipo y designe el modelo de verdad potencial, y luego escriba la arquitectura objetivo en tres líneas: dataflows → modelo central → informes conectados. Anote en una frase lo que la conexión activa le evitará.
- Puedo explicar qué es un dataflow y cuándo se impone.
- Sé qué aporta una conexión activa a un modelo publicado (un único modelo de verdad).
- Entiendo qué es un modelo compuesto y lo reservo para necesidades reales.
Preguntas frecuentes
¿Dataflow o consulta en el .pbix: cómo decidir?
El criterio es la reutilización. Un uso = consulta local en el .pbix; varios usos (varios informes/autores) = dataflow. El beneficio va más allá del tiempo: cuando la regla cambia, se modifica una vez y todos los informes la heredan.
¿Qué licencias hacen falta para todo esto?
Los dataflows y las conexiones activas a modelos publicados requieren una licencia Pro; algunas opciones avanzadas corresponden a Premium/Fabric. Es un tema de organización: los conceptos se dominan ya, gratis.
¿Qué aporta una conexión activa a un modelo semántico publicado?