---
title: "Modelado de datos en Power BI: consideraciones para un modelo rápido, fiable y gobernado"
description: "Modelo en estrella, grano, claves, historia con SCD, modelos gobernados frente a aplanados, catálogo de KPI y las prácticas de DAX y rendimiento que marcan la diferencia en Power BI."
url: https://bidatia.com/ideas/modelado-power-bi-buenas-practicas
lang: es
date: 2026-05-05
updated: 2026-11-04
author: "Santos Vicente"
keywords: ["modelado power bi", "modelo en estrella", "kimball", "scd tipo 2", "modelo semántico", "dax buenas prácticas", "rendimiento power bi", "tabular editor", "dax studio"]
publisher: Bidatia
---

# Modelado de datos en Power BI: consideraciones para un modelo rápido, fiable y gobernado

> Modelo en estrella, grano, claves, historia con SCD, modelos gobernados frente a aplanados, catálogo de KPI y las prácticas de DAX y rendimiento que marcan la diferencia en Power BI.

## Resumen ejecutivo

- Los problemas de rendimiento y de cifras que no cuadran en Power BI suelen ser problemas de modelo, no de visualización.
- Base: modelo en estrella de Kimball, con hechos que se resumen y dimensiones que filtran, y el grano definido antes que nada.
- Normalizar lo justo, usar claves numéricas y sustitutas, fechas como entero YYYYMMDD y guardar la historia con dimensiones lentamente cambiantes (SCD), sobre todo de tipo 2 con fecha fin infinito.
- Separar un modelo gobernado (capa gold) de entidades aplanadas para consumo masivo, generadas automáticamente a partir de él.
- En el modelo semántico: relaciones uno a varios en una dirección, tabla de medidas, jerarquías, columnas técnicas ocultas, seguridad por filas y dimensión calendario.
- Rendimiento y gobierno: reducir cardinalidad, buenas prácticas de DAX, herramientas (DAX Studio, VertiPaq Analyzer, Tabular Editor con Best Practice Analyzer, Bravo) y un catálogo único de KPI.

La mayoría de los informes de Power BI lentos, difíciles de mantener o con cifras que no cuadran no tienen un problema de visualización: tienen un problema de **modelo**. Un buen modelo hace que las consultas vuelen, que el negocio entienda lo que ve y que cada indicador signifique lo mismo en toda la organización. Estas son las consideraciones que aplicamos en cada proyecto.

## 1. Empieza por el modelo en estrella

El modelado dimensional de Ralph Kimball sigue siendo la referencia para la analítica, y el motor de Power BI está optimizado para él. Tiene dos piezas:

- **Tablas de hechos**: los eventos del negocio (ventas, pedidos, siniestros, horas) con sus **medidas numéricas**, a ser posible aditivas, y las claves a las dimensiones. Responden a «¿cuánto?».
- **Tablas de dimensiones**: el contexto descriptivo con el que se filtra y agrupa (cliente, producto, fecha, territorio). Responden a «¿quién, qué, dónde, cuándo y cómo?».

La regla práctica: **las dimensiones filtran y agrupan; los hechos se resumen.**

**Estrella o copo de nieve.** En la estrella, cada dimensión es una sola tabla desnormalizada; en el copo de nieve, las dimensiones se dividen en varias tablas (por ejemplo, producto → subcategoría → categoría). El copo ahorra algo de espacio, pero multiplica las relaciones y complica el modelo. En Power BI, la opción por defecto es la **estrella**: si tienes un copo en origen, aplánalo en la carga.

## 2. Define el grano antes que nada

El grano es el nivel de detalle de la tabla de hechos: «una fila por línea de pedido», «una fila por póliza y día». Es la primera decisión, y la más cara de cambiar después. Un grano demasiado agregado impide responder preguntas de detalle; uno mezclado (filas de distinto nivel en la misma tabla) produce sumas incorrectas. Cada dimensión debe ser coherente con ese grano.

## 3. Normaliza lo justo

La normalización (primera, segunda y tercera forma normal) evita duplicidades e inconsistencias, y es imprescindible en los sistemas transaccionales y en la capa donde se cura el dato. Para la explotación, el criterio cambia:

- **Datos atómicos siempre**: nada de campos con listas («600111222, 600333444») ni direcciones en un único texto.
- **Separa entidades** cuando sus atributos no dependen de la clave del hecho (el nombre del producto no pertenece a la línea de pedido).
- **No separes por separar**: una jerarquía como país → región → ciudad va en una sola dimensión, salvo que cada nivel tenga muchos atributos propios.

## 4. Cuida las claves y los tipos de dato

- **Claves numéricas** mejor que de texto: ocupan menos, se comprimen mejor y relacionan más rápido.
- **Claves sustitutas** en las dimensiones, para no depender de los códigos del sistema de origen, que pueden cambiar.
- **Ojo con los autonuméricos generados en la base de datos**: si la tabla se recrea o se carga en otro entorno, la misma fila puede recibir otra clave y romper validaciones y migraciones. Mejor claves deterministas generadas en el proceso de carga.
- **Fechas como clave entera `YYYYMMDD`** para relacionar con el calendario, y conviene comprobar la precisión (¿tiene hora?, ¿zona horaria?) y homogeneizar a UTC en integraciones internacionales.
- **El tipo correcto para cada dato**: una fecha guardada como texto obliga a conversiones y estropea el rendimiento; un código postal es texto, no número.

## 5. Decide cómo guardar la historia (SCD)

Los sistemas operacionales sobrescriben: si un cliente cambia de dirección, la anterior desaparece. Para analizar la evolución, auditar o reconstruir el contexto de una decisión, Kimball define las **dimensiones lentamente cambiantes (SCD)**:

| Tipo | Qué hace | Cuándo usarlo |
|---|---|---|
| 0 | Mantiene el valor original | Atributos inmutables |
| 1 | Sobrescribe | Correcciones o atributos cuya historia no interesa |
| 2 | Nueva fila por cada cambio, con fecha de inicio y fin | Historia completa; el más habitual en almacenes de datos |
| 3 | Columna con el valor anterior | Solo un cambio y pocos campos |
| 4 | Tabla de vigentes y tabla de histórico | Dimensiones muy grandes en las que casi siempre se consulta lo vigente |
| 6 y 7 | Variantes estrictas del tipo 2 con versión y clave física propia | Varios cambios el mismo día, reprocesos o auditoría estricta |

Dos consejos prácticos para el **tipo 2**: usa una **fecha fin «infinito»** (31/12/9999) en lugar de nulos, que complican los filtros, y añade un **indicador de registro vigente** en vez de depender de un número de versión que obliga a calcular máximos en cada consulta. Y documenta en el catálogo qué atributos guardan historia y cuáles no.

## 6. Modelo gobernado y modelo aplanado

No hay un único modelo perfecto, sino dos capas con funciones distintas:

| | Modelo gobernado (capa *gold*) | Modelo aplanado (capa de servicio) |
|---|---|---|
| Para qué | Auditoría, núcleo corporativo, curación del dato | Cuadros de mando de uso masivo, inmediatez, menos coste de cómputo |
| Cómo | Estrella con entidades bien definidas, reglas de calidad y semántica | Tablas desnormalizadas derivadas del gobernado, con menos relaciones |
| Riesgo | Más relaciones y peor rendimiento con mucho volumen | Duplicidad y posible desalineación |

La recomendación: **definir el modelo gobernado como fuente única y generar automáticamente las entidades aplanadas a partir de él**, documentadas y versionadas. Así se gana rendimiento sin perder una única versión de la verdad.

## 7. Del modelo en estrella al modelo semántico

Sobre las tablas, el modelo semántico de Power BI necesita:

1. **Relaciones** de uno a varios, de la dimensión al hecho, con **filtro en una sola dirección**. Evita las relaciones de varios a varios y la dirección bidireccional salvo casos justificados.
2. **Medidas** explícitas, en una **tabla de medidas** organizada en carpetas: una medida base por cálculo y medidas derivadas para inteligencia de tiempo, acumulados o ratios.
3. **Jerarquías** de navegación (año → trimestre → mes; país → región → ciudad).
4. **Columnas técnicas ocultas**: claves, campos de control y atributos que no aportan al análisis.
5. **Roles de seguridad a nivel de fila (RLS)** asignados a grupos, no a personas.
6. **Una dimensión calendario estándar** marcada como tabla de fechas, y la opción automática de fecha y hora desactivada.

**Columnas calculadas o medidas.** Una columna calculada se materializa fila a fila y sirve para filtrar, segmentar o categorizar; una medida se calcula en el contexto de cada visual y es la opción para agregaciones, ratios e indicadores. Siempre que se pueda, las columnas calculadas se hacen **en la carga (ETL)**, no en el modelo.

## 8. Rendimiento: lo que más se nota

- Elimina las columnas que no se usan y **reduce la cardinalidad**: identificadores GUID, textos libres y fechas con hora completa son lo que más pesa.
- **Dimensiones estrechas y hechos con las claves y medidas justas.**
- En DAX, usa **variables**, `DIVIDE` en lugar de `/`, `COUNTROWS` en lugar de `COUNT` y `SELECTEDVALUE` en lugar de `VALUES` cuando esperas un valor único.
- En los informes, menos visuales por página y segmentadores jerárquicos solo cuando aportan.

**Herramientas para medir en lugar de adivinar:**

| Herramienta | Para qué |
|---|---|
| Analizador de rendimiento de Power BI Desktop | Ver qué visual o medida ralentiza una página y extraer su consulta DAX |
| DAX Studio | Ejecutar y perfilar consultas DAX y encontrar cuellos de botella |
| VertiPaq Analyzer | Ver el tamaño y la cardinalidad de cada tabla y columna |
| Tabular Editor | Edición masiva, scripts y el **Best Practice Analyzer** con las reglas de buenas prácticas de Microsoft |
| Bravo | Formatear DAX, analizar el modelo y generar calendarios |

## 9. Un catálogo único de indicadores

El modelo técnico no basta si cada área calcula «sus» ventas. Un catálogo corporativo de KPI se apoya en unos principios sencillos:

- **Unicidad**: cada indicador existe una sola vez, con un identificador.
- **Fuente de la verdad**: sistema y dataset oficiales de cada uno.
- **Definición cerrada**: fórmula, filtros, periodo, grano y desgloses permitidos.
- **Responsables**: quién define el dato y quién responde del resultado.
- **Versionado y periodicidad**: cambios controlados y calendario de publicación.
- **Pocos y buenos**: entre 15 y 25 indicadores corporativos; el resto, por área.

Cada indicador solo existe si tiene su ficha completa y ha pasado una validación técnica, metodológica y de negocio. Lo contamos en detalle en [gestión de metadatos](/ideas/gestion-de-metadatos-catalogo-de-datos) y [calidad del dato](/ideas/calidad-del-dato-dimensiones-metricas).

## 10. Estándares que ahorran tiempo

- **Nomenclatura**: `Dim_` para dimensiones, `Fact_` para hechos y nombres de medidas con sentido de negocio, sin duplicados ni siglas crípticas.
- **Plantillas**: un tema `.json` corporativo y una plantilla `.pbit` con páginas base, navegación y tooltips reutilizables. Aceleran el desarrollo, unifican la experiencia de usuario y facilitan la incorporación de nuevas personas al equipo.
- **Documentar y versionar** el modelo como cualquier otro código.

## 11. Elige bien la tecnología que hay debajo

El modelo lógico es el mismo, pero cada plataforma pide matices:

| Plataforma | Qué tener en cuenta |
|---|---|
| Bases de datos relacionales (SQL Server, Oracle, PostgreSQL) | Índices, particionado, planes de ejecución y ventanas de carga, porque lectura y escritura compiten |
| Almacenes en la nube (Fabric, Snowflake, BigQuery, Redshift) | El coste lo marca el cómputo: desnormalizar con criterio y distribuir los datos para evitar lecturas masivas |
| Motores tabulares (Power BI, Analysis Services) | Compresión por columnas: la cardinalidad y el número de columnas pesan más que el número de filas |
| Big data y datos semiestructurados | Normalizar JSON en tiempo real puede frenar la ingesta; se aplana después, en la capa de explotación |

## 12. Arquitecturas: dónde encaja el modelo

El modelo de Power BI es la última pieza de una cadena: sistemas operacionales, capa de integración (antes ODS, hoy capas *bronze* y *silver*), almacén o *lakehouse* con la capa gobernada (*gold*) y, por último, el modelo semántico. Enfoques como **Data Mesh** (descentralizar la responsabilidad por dominios) o **Data Fabric** (una capa unificada de gobierno sobre entornos distribuidos) cambian quién es dueño de cada producto de datos, pero no las reglas del modelado dimensional: hechos, dimensiones, grano y semántica común siguen siendo la base.

## Errores frecuentes

- **Importar las tablas tal cual están en el sistema de origen** y relacionarlas en Power BI como un modelo transaccional.
- **Una tabla de hechos con todo**: medidas de procesos distintos y granos mezclados en la misma tabla.
- **Relaciones bidireccionales «para que funcione»**, que crean ambigüedades y ralentizan.
- **Calcular en DAX lo que debería venir calculado** de la carga.
- **Usar la jerarquía automática de fechas** en lugar de una dimensión calendario.
- **Duplicar la misma medida** con nombres distintos en informes distintos.

## Lista de comprobación antes de publicar un modelo

- [ ] El grano de cada tabla de hechos está documentado.
- [ ] Las dimensiones están desnormalizadas y tienen clave sustituta.
- [ ] Hay una dimensión calendario marcada como tabla de fechas y la fecha automática está desactivada.
- [ ] No hay relaciones de varios a varios ni bidireccionales sin justificar.
- [ ] Las columnas técnicas están ocultas y las que no se usan, eliminadas.
- [ ] Las medidas están en una tabla de medidas, con carpetas y formato.
- [ ] Los nombres siguen la nomenclatura acordada.
- [ ] La seguridad por filas está definida y asignada a grupos.
- [ ] El Best Practice Analyzer no muestra incumplimientos relevantes.
- [ ] Los indicadores corresponden a fichas del catálogo de KPI.
- [ ] El modelo está documentado y versionado.

En Bidatia diseñamos y optimizamos modelos semánticos en Power BI y Microsoft Fabric, desde el modelo gobernado hasta el cuadro de mando, y formamos a los equipos para mantenerlos.

## Preguntas frecuentes

### ¿Por qué se recomienda el modelo en estrella en Power BI?
Porque el motor de Power BI está optimizado para él: menos relaciones, filtros más sencillos y consultas más rápidas. Además es más fácil de entender para el negocio que un modelo normalizado o en copo de nieve.

### ¿Qué es el grano de una tabla de hechos?
El nivel de detalle de cada fila, por ejemplo «una fila por línea de pedido». Hay que definirlo antes de diseñar la tabla, porque condiciona qué preguntas se pueden responder y si las sumas son correctas.

### ¿Qué es una dimensión lentamente cambiante de tipo 2?
Una dimensión que guarda una fila nueva cada vez que cambia un atributo, con fecha de inicio y de fin, de forma que se puede saber qué valor tenía en cualquier fecha. Es la técnica más habitual para conservar la historia en un almacén de datos.

### ¿Columna calculada o medida?
Columna calculada para valores que se usan para filtrar, segmentar o categorizar, preferiblemente calculada en la carga. Medida para cálculos que dependen del contexto del informe, como totales, ratios o comparativas con el año anterior.

### ¿Qué herramientas sirven para optimizar un modelo de Power BI?
El analizador de rendimiento de Power BI Desktop, DAX Studio, VertiPaq Analyzer, Tabular Editor con el Best Practice Analyzer y Bravo. Permiten medir dónde está el problema en lugar de adivinarlo.