De la consulta SQL al dashboard de Power BI: el pipeline más simple que realmente funciona

🎯 Situación

Un nuevo analista se unió al equipo de un cliente y hizo una pregunta directa: "¿Cómo llevo datos desde nuestra base de datos a un reporte de Power BI que se actualice automáticamente?"

La mayoría de las respuestas a esa pregunta en línea saltan directamente a conectar Power BI a tablas crudas y escribir transformaciones en Power Query. Eso funciona a pequeña escala. A escala de producción — con múltiples usuarios, actualizaciones programadas y lógica de negocio que debe ser consistente — crea reportes frágiles que se rompen cuando los datos fuente cambian.

Aquí está ese pipeline, paso a paso.

⚠️ El reto: dos enfoques incorrectos

Antes del enfoque correcto, vale la pena nombrar los dos errores comunes — porque ambos se enseñan como práctica estándar en tutoriales introductorios.

Ambos enfoques funcionan para prototipos y reportes personales. Ninguno escala limpiamente a reporting de nivel equipo en producción donde múltiples personas comparten dashboards construidos sobre datos consistentes y gobernados.

🔍 El pipeline de 4 pasos

Paso 1 — Escribir la lógica de negocio en SQL, no en Power Query

Crear una vista SQL en tu base de datos central que maneje todos los joins, filtros, agregaciones y definiciones de métricas. Esta es la única fuente de verdad para ese KPI — la misma vista que discutimos en el artículo sobre definiciones de KPIs.

-- Step 1: Create a clean view in your database
-- This is what Power BI will connect to — not the raw tables

CREATE VIEW vw_monthly_sales AS
SELECT
    DATE_TRUNC('month', o.order_date)   AS month,
    p.category                          AS product_category,
    r.name                              AS region,
    COUNT(DISTINCT o.order_id)          AS order_count,
    SUM(ol.quantity)                    AS units_sold,
    SUM(ol.quantity * ol.unit_price)    AS gross_revenue,
    SUM(ol.quantity * ol.unit_price
        - ol.quantity * p.cost_price)   AS gross_margin
FROM orders o
JOIN order_lines ol  ON o.order_id  = ol.order_id
JOIN products    p   ON ol.product_id = p.product_id
JOIN regions     r   ON o.region_id = r.region_id
WHERE o.status = 'completed'
GROUP BY 1, 2, 3;

Esta vista une cuatro tablas, filtra a pedidos completados y produce un resumen mensual limpio. Cualquier herramienta — Power BI, Excel, Python, Looker — puede consultarla y obtener los mismos números.

Paso 2 — Conectar Power BI a la vista, no a las tablas crudas

En Power BI Desktop: Obtener datos → SQL Server (o tu base de datos) → ingresar servidor y base de datos → elegir la vista (vw_monthly_sales), no las tablas subyacentes. Modo Import o DirectQuery según volumen y necesidades de actualización. Para la mayoría de las PyMEs: modo Import con actualización diaria es la elección correcta.

Paso 3 — Mantener Power Query mínimo

Una vez que la vista está limpia, Power Query debería hacer casi nada: renombrar columnas si es necesario, definir tipos de datos, nada más. Toda la lógica de transformación se queda en SQL. Si te encuentras escribiendo código M complejo en Power Query, esa es una señal de que la vista SQL necesita trabajo.

Paso 4 — Construir el modelo semántico y programar la actualización

En Power BI Service: publicar el reporte → ir a configuración del dataset → configurar actualización programada (diaria a las 6 AM es estándar) → configurar un gateway si tu base de datos es on-premises. Listo. El reporte se actualiza automáticamente cada mañana sin que nadie lo toque.

✓️ Por qué esta arquitectura dura

La razón por la que este patrón funciona a escala es la separación de responsabilidades — cada capa tiene un solo trabajo:

• Base de datos (SQL) — almacena datos crudos, define lógica de negocio mediante vistas, garantiza consistencia para todos los consumidores
• Dataset de Power BI — importa datos limpios y pre-agregados, define el modelo semántico (relaciones, jerarquías, medidas DAX), maneja cálculos orientados al usuario
• Reporte de Power BI — visualiza el modelo semántico, maneja diseño e interactividad, cero lógica de negocio aquí

Cuando el negocio cambia — una nueva región, un KPI redefinido, una nueva categoría de producto — actualizas la vista SQL. Todos los reportes construidos sobre esa vista se actualizan automáticamente en la próxima actualización. No tocas el archivo .pbix.

Cuando alguien pregunta "¿dónde está el cálculo de ingresos?" — la respuesta siempre es la misma: vw_monthly_sales, línea 12. No "en algún lugar de Power Query" o "creo que está en la medida DAX pero quizás también en la consulta M".