Objetivo
Entender qué cambia al publicar un informe.
Explicación
Desktop diseña; Service publica, comparte y programa refresh según licencias/conectividad. RLS filtra datos por usuario/rol. Una conexión a Snowflake requiere decidir Import o DirectQuery según frescura, rendimiento y capacidad. Power BI profesional empieza antes de elegir un gráfico. Primero se limpia la entrada, se define un modelo semántico coherente y se crean medidas verificables. Cada KPI del informe debe poder reconciliarse con los datos de origen o con una consulta independiente. Para trabajar Power BI Service, refresh, RLS y Snowflake de forma profesional, no te quedes con el ejemplo: identifica la entrada, ejecuta el caso base, provoca al menos un caso incorrecto y compara el resultado con un control independiente. En este laboratorio el criterio de salida es concreto: Decisión documentada con requisitos de frescura y rendimiento; RLS probado como usuario. La verificación principal será: En Desktop usa “View as role”; en Service revisa asignaciones. Si no puedes explicar por qué pasa esa comprobación, vuelve al paso anterior antes de continuar.
Contexto profesional
Power BI profesional empieza antes de elegir un gráfico. Primero se limpia la entrada, se define un modelo semántico coherente y se crean medidas verificables. Cada KPI del informe debe poder reconciliarse con los datos de origen o con una consulta independiente.
Ejemplo real
[Region Access] = Users[email] = USERPRINCIPALNAME()
Archivos o datos de entrada
- powerbi/orders.csv
- powerbi/customers.csv
- powerbi/calendar.csv
Práctica guiada
Define dos roles regionales conceptuales y cómo los probarías.
Laboratorio paso a paso
- Prepara el entorno y localiza los datos/archivos de entrada: powerbi/orders.csv, powerbi/customers.csv, powerbi/calendar.csv. Antes de modificar nada, anota el número de filas, columnas u objetos que esperas usar.
- Reproduce el ejemplo real de la lección y guarda la salida. No avances hasta poder explicar qué hace cada bloque relacionado con «Power BI Service, refresh, RLS y Snowflake».
- Ejecuta la práctica guiada: Define dos roles regionales conceptuales y cómo los probarías. Documenta el comando, consulta o acción exacta y el resultado obtenido.
- Resuelve el reto sin mirar la solución: Compara Import vs DirectQuery para un mart que se actualiza una vez al día. Si falla, registra el mensaje de error y formula una hipótesis antes de cambiar código.
- Compara tu resultado con el criterio esperado: Decisión documentada con requisitos de frescura y rendimiento; RLS probado como usuario. Después ejecuta la comprobación: En Desktop usa “View as role”; en Service revisa asignaciones.
- Provoca deliberadamente un caso problemático relacionado con este error frecuente: RLS mal probada puede exponer datos a usuarios incorrectos.. Comprueba que sabes detectarlo y corregirlo.
Reto sin ayuda
Compara Import vs DirectQuery para un mart que se actualiza una vez al día.
Resultado esperado
Decisión documentada con requisitos de frescura y rendimiento; RLS probado como usuario.
Cómo verificarlo
En Desktop usa “View as role”; en Service revisa asignaciones.
Checklist de validación
- El resultado cumple: Decisión documentada con requisitos de frescura y rendimiento; RLS probado como usuario.
- Has ejecutado esta verificación y puedes explicar el resultado: En Desktop usa “View as role”; en Service revisa asignaciones.
- Has probado al menos un caso límite o dato inválido y el comportamiento es explícito, no silencioso.
- Puedes repetir la práctica desde cero sin copiar la solución y dejar evidencia (consulta, commit, captura o salida de consola).
Pista específica
Si refresh es diario, Import suele simplificar rendimiento.
Solución paso a paso
1) Empieza reproduciendo el caso base con los datos indicados. 2) Aplica esta estrategia específica: No elijas DirectQuery sólo porque parece “más en tiempo real”. 3) Usa como referencia técnica el ejemplo de la lección ([Region Access] = Users[email] = USERPRINCIPALNAME()). 4) Ejecuta la verificación: En Desktop usa “View as role”; en Service revisa asignaciones. 5) Compara con el resultado esperado: Decisión documentada con requisitos de frescura y rendimiento; RLS probado como usuario. 6) Repite el reto cambiando un dato o condición para demostrar que entiendes el comportamiento y no has obtenido el resultado por casualidad. Si aparece el error «RLS mal probada puede exponer datos a usuarios incorrectos.», corrige la causa antes de continuar; no ocultes el fallo ni cambies el resultado esperado para que la prueba pase.
Errores frecuentes
- RLS mal probada puede exponer datos a usuarios incorrectos.
Qué debes recordar
Power BI debe separar preparación, modelo, medidas y presentación.
Preguntas de entrevista
- ¿Cómo validarías esta medida fuera del visual? Aplícalo concretamente a «Power BI Service, refresh, RLS y Snowflake».
- ¿Qué parte resolverías en Power Query/modelo y cuál en DAX? Explica qué evidencia enseñarías al revisor.
Siguiente paso
Aplicarás Power BI en el proyecto de marts analíticos.
Recursos de esta lección
Preparando contenido…
Quiz de la lección
¿Qué función devuelve el usuario en muchos escenarios RLS?