General
Taller de replica del curso de Power BI 2
ESTRELLA
Una tabla de hechos central (fact table).
Varias tablas de dimensiones directamente relacionadas.
Dimensiones desnormalizadas (atributos en una sola tabla).
DimFecha DimCliente DimProducto
\ | /
FactVentas
Relaciones 1:* desde dimensión hacia hechos.
Cardinalidad simple.
Modelo plano y fácil de entender.
Menor cantidad de joins en tiempo de consulta.
Mejor rendimiento en el motor VertiPaq.
DAX más simple.
Menor ambigüedad en relaciones.
Mejor compresión de datos.
Recomendado por Microsoft como buena práctica.
COPOS DE NIEVE
Tabla de hechos central.
Dimensiones normalizadas en múltiples sub-dimensiones.
Jerarquías separadas en varias tablas.
DimCategoria
|
DimProduCto
|
FactVentas
Más relaciones.
Mayor número de tablas.
Dimensiones parcialmente normalizadas.
Reduce redundancia.
Modelo más alineado con bases de datos OLTP (Online Transaction Processing) normalizadas.
Útil cuando dimensiones son muy grandes y complejas
Recomendación
✔ Priorizar modelo estrella
✔ Minimizar relaciones innecesarias
✔ Evitar cadenas largas de dimensiones
Modelo de datos ESTRELLA


Tabla de Hechos
Definición:
Tabla principal que almacena datos transaccionales, métricas, valores numéricos y medidas de negocio.
Características clave:
Tablas de Dimensión
Definición:
Tablas que almacenan descripciones, atributos, categorías o contexto de las entidades del negocio.
Características clave:
Relación entre Hechos y Dimensiones
Una Dimensión se conecta mediante su clave primaria.
Una Tabla de Hechos guarda esa clave como foránea.
La relación suele ser:
Dimensión (1) → (N) Fact
Ejemplo:
DimProducto (1) → FactVentas (N)
DimFecha (1) → FactVentas (N)
DimCliente (1) → FactVentas (N)
Reglas de oro para tu modelo en Power BI
• Crear medidas DAX en la Fact, nunca en las dimensiones
• Importa solo lo necesario (minimiza el modelo)
Un modelo con tablas gigantes y columnas innecesarias hace más lento todo: refresco, cálculos y visualizaciones.
✔ Elimina columnas que no aportan
✔ Reduce filas con filtros en Power Query
✔ Evita columnas de texto largas si no son obligatorias
Regla de oro: “Todo dato que no se usa, estorba.”
• Usa el modelo estrella (Star Schema) siempre que sea posible
El 90% de los problemas de rendimiento se solucionan con un modelo estrella:
✔ Tablas de hechos en el centro
✔ Tablas de dimensión alrededor
✔ Relaciones 1-* unidireccionales
✔ Evita relaciones muchos-a-muchos
Debe dominar:
• No uses columnas calculadas si puedes usar medidas
Errores comunes del nivel 1:
🚫 Crear columnas que usan contexto de fila cuando deberían ser medidas.
🚫 Duplicar cálculos innecesarios.
Regla avanzada:
- Columnas = cálculos estáticos
Ejemplo típico mal hecho:
Como columna = incorrecto
Como medida = correcto ✔
*** Usa DAX CALCULATE como herramienta principal
El salto al nivel 2 ocurre cuando dominas:
*** Usa Variables (VAR) en todas las medidas medianas o complejas
Mejora rendimiento y legibilidad.
Antes (mal): Porcentaje = SUM(A[Valor]) / CALCULATE(SUM(A[Valor]), ALL(A))
Con VAR (bien):
Porcentaje =
VAR Total = CALCULATE(SUM(A[Valor]), ALL(A))
VAR Actual = SUM(A[Valor])
RETURN Actual / Total

La publicación de un dashboard de Power BI en SharePoint es el proceso mediante el cual un reporte desarrollado en Power BI se integra dentro de un sitio de SharePoint para que otros usuarios puedan visualizarlo en línea.
En términos simples:
Consiste en publicar el reporte en el servicio de Power BI (Power BI Service) y luego incrustarlo en una página de SharePoint mediante el web part de Power BI.
Esto permite:
Compartir información con equipos de trabajo.
Centralizar reportes en el portal institucional.
Mantener actualización automática de los datos.
Controlar accesos según permisos definidos en SharePoint.
Es una práctica común en entornos corporativos donde SharePoint funciona como portal interno de gestión y comunicación.
La principal ventaja es que evita la compra de licencias por cada usuario para acceder a los reportes creados en Power BI.