Un informe resulta difícil de mantener cuando cada nueva pregunta obliga a añadir uniones y fórmulas que solo entiende quien lo construyó. Un modelo en estrella ayuda a separar los eventos que se analizan de los atributos que permiten describirlos y agruparlos.
La decisión más importante llega antes de dibujar relaciones: qué representa una fila de la tabla de hechos. Si esa definición cambia a mitad del diseño, las sumas y comparaciones pueden dejar de tener un significado consistente.
Parte de una pregunta concreta
Imagina un análisis ficticio de pedidos por producto, cliente y periodo. El equipo quiere conocer unidades pedidas e importes por línea, conservando la posibilidad de agrupar por familias de producto.
Una fila por pedido completo no permite responder directamente a preguntas por producto cuando un pedido contiene varios. Una fila por línea sí ofrece ese nivel de detalle, siempre que el importe registrado corresponda a la línea y no a toda la cabecera.
Esta decisión fija el grano del modelo. Conviene escribirla como una frase y comprobarla con registros reales antes de cargar datos.
Distingue eventos y contexto
La tabla de hechos recoge el evento medible a ese grano: por ejemplo, una línea de pedido con sus claves y medidas. Las dimensiones contienen atributos utilizados para filtrar o agrupar: producto, cliente o calendario.
La guía de Microsoft sobre modelos en estrella explica esta separación y su relevancia para el filtrado, la agrupación y la agregación en Power BI. El diseño concreto debe responder a las preguntas y al historial que necesita conservar cada organización.
Una representación ilustrativa podría ser:
| Tabla | Qué representa una fila | Ejemplos de información |
|---|---|---|
| Hechos de líneas de pedido | Una línea identificada dentro de un pedido | Unidades e importe de la línea |
| Dimensión de producto | Una versión del producto según la política de historial | Código, nombre y familia |
| Dimensión de cliente | Un cliente o una versión histórica, según el diseño | Segmento y atributos de agrupación |
| Dimensión de fecha | Un día del calendario de análisis | Mes, trimestre y periodo operativo |
Las tablas son un ejemplo conceptual. No implican que todas las empresas necesiten exactamente esas dimensiones o esa política de versiones.
Comprueba las medidas antes de agregarlas
Las unidades de líneas distintas pueden sumarse si expresan una magnitud comparable. Un porcentaje de descuento no se suma del mismo modo. El importe de cabecera tampoco debe repetirse como medida aditiva en cada línea.
Supongamos un pedido con dos líneas de 300 € y 700 €. La suma de importes de línea produce 1.000 €. Si ambas filas contienen además el total del pedido y se agrega esa columna, el resultado sería 2.000 €. La relación entre tablas puede estar técnicamente permitida y la medida seguir siendo incorrecta.
Decide dónde se calculan descuentos globales, gastos y ajustes. Si se reparten entre líneas, documenta el criterio y cómo se reconcilia el total. Si no se pueden repartir de forma útil, quizá necesiten otra vista o un grano distinto.
Diseña las relaciones con cardinalidad comprobable
Verifica que la clave del lado que actúa como dimensión identifica realmente una fila. Un código aparentemente único puede repetirse por país, sistema de origen o versión histórica.
Cuando una unión multiplica registros, investiga la causa antes de aplicar una eliminación genérica de duplicados. Podrías estar ocultando versiones legítimas o perdiendo información que el análisis necesita.
Incluye también una política para referencias que todavía no existen en la dimensión. Una clave desconocida debe poder detectarse y tratarse; descartar la línea sin explicación altera los resultados.
Decide qué hacer cuando cambian los atributos
Si un cliente cambia de segmento, hay al menos dos preguntas diferentes: cómo se agrupan sus pedidos según el segmento actual y cuál era su segmento cuando se realizó cada pedido.
La primera puede resolverse con atributos actuales. La segunda requiere conservar una relación temporal adecuada. No elijas una estrategia de historial solo por costumbre: pregunta qué comparaciones necesita el negocio y qué cambios importan.
Es posible ofrecer ambas perspectivas, pero deben distinguirse en el modelo y en las etiquetas del informe para evitar interpretaciones contradictorias.
Una prueba de aceptación con pocos registros
Prepara un conjunto que puedas calcular manualmente. Incluye un pedido con varias líneas, dos productos de la misma familia, una devolución o corrección y un cliente cuyo atributo de agrupación cambie.
Comprueba el total general y los desgloses por cada dimensión. Repite la prueba combinando filtros. Cuando los totales no coincidan, determina si la causa está en el grano, la relación, la definición de la medida o la selección de registros.
Añade una conciliación con el origen al nivel que corresponda. No basta con que los gráficos sean coherentes entre sí si ambos utilizan una extracción incompleta.
Mantén el modelo junto a sus decisiones
El resultado del diseño debería incluir la definición de cada tabla, el grano, las relaciones, las medidas importantes y las reglas de historial. Registra también qué usos no admite el modelo para que una nueva necesidad no se resuelva acumulando excepciones.
Un modelo en estrella no elimina la necesidad de pruebas ni convierte automáticamente cualquier informe en rápido. Aporta una estructura comprensible sobre la que se pueden medir resultados y localizar problemas.
Para un proyecto de Business Intelligence, lleva a la primera conversación las preguntas que hoy cuestan responder y un ejemplo del detalle disponible. Puedes revisar ese punto de partida con Nexeus Big Data antes de decidir la distribución de tablas.