Construir un modelo de datos sólido es el paso fundamental para obtener reportes precisos y confiables en Power BI. Entender cómo se conectan las tablas de hechos con las dimensiones, qué tipos de relaciones existen y cómo corregir conexiones erróneas marca la diferencia entre un proyecto profesional y uno con resultados inconsistentes.
¿Cómo se estructura el modelo de datos del proyecto integrador?
El proyecto parte de un archivo de Excel llamado Ventas Avanzado [0:08] que contiene múltiples tablas organizadas bajo un diseño relacional. Las tablas se dividen en dos grandes grupos:
- Tablas de dimensiones: contienen datos descriptivos que permiten segmentar la información. Entre ellas están la dim calendario, dim cliente, dim vehículo, dim sede, dim canal y dim vendedor.
- Tablas de hechos (fac): almacenan las transacciones históricas. La principal es fac ventas, que registra cada operación de venta de vehículos, y la tabla fac presupuestos, que contiene los datos presupuestarios.
Cada dimensión aporta campos descriptivos como marca, modelo, tipo de vehículo, año de fabricación, nombre del cliente o identificador de sede [1:01]. La idea es que la tabla de hechos concentre el volumen transaccional y las dimensiones enriquezcan esa información con contexto.
¿Cómo se cargan las tablas desde Excel a Power BI Desktop?
Desde Power BI Desktop se utiliza la opción Importar datos de Excel [1:17]. Al abrir el archivo, se seleccionan únicamente las tablas con formato de tabla de Excel, reconocibles por su ícono distintivo y su primera fila en color azul [1:34]. Las hojas completas no se cargan porque podrían incluir campos en blanco, lo cual no es una buena práctica.
Una vez seleccionadas todas las tablas necesarias, se hace clic en Cargar y el modelo queda disponible en el panel de datos del lado derecho de la interfaz [1:52].
¿Qué es el esquema estrella y por qué es importante?
El esquema estrella [3:17] es un patrón de modelado donde una tabla de hechos central se conecta con múltiples dimensiones a su alrededor. En este proyecto, la fac ventas ocupa el centro y las dimensiones la rodean, proporcionando campos de corte como cliente, sede, canal, vendedor, vehículo y calendario.
Este esquema es el escenario ideal en Power BI porque:
- Facilita la lectura del modelo.
- Optimiza el rendimiento de las consultas.
- Garantiza que las relaciones sean claras y de uno a muchos, donde cada dimensión tiene una llave primaria única y la tabla de hechos contiene la llave foránea correspondiente [3:05].
¿Cómo se validan y corrigen las relaciones en el modelo?
Al cargar las tablas, Power BI genera relaciones automáticas. Para revisarlas se accede a la pestaña Vista Modelo [2:05] y al administrador de relaciones [2:17]. Allí se puede verificar qué campos conectan cada par de tablas.
En el proyecto se detectó un error: la tabla Foto Vehículo se había conectado con fac ventas usando el campo ID, pero en fac ventas ese campo representa el código de la transacción, mientras que en Foto Vehículo representa el código del modelo de vehículo [2:33]. Son conceptos distintos. La corrección consistió en eliminar esa relación errónea y crear una nueva entre Foto Vehículo y dim vehículo, donde ambos campos ID representan el código del vehículo [3:27].
¿Qué tipos de cardinalidad existen en Power BI?
La cardinalidad define cómo se relacionan los registros entre dos tablas [3:37]. Los tres tipos son:
- Uno a uno: cada registro de una tabla corresponde exactamente a uno en la otra. Funciona como una extensión de la tabla original. Es el caso de dim vehículo y Foto Vehículo.
- Uno a muchos: un registro en la dimensión se relaciona con múltiples registros en la tabla de hechos. Es el escenario que siempre se debe buscar.
- Muchos a muchos: múltiples registros en ambas tablas se cruzan entre sí. Es el escenario que siempre se debe evitar porque puede generar resultados errados.
Comprender estas diferencias permite construir modelos confiables donde cada medida y cada filtro se comporten de manera predecible. Si alguna relación no encaja en el patrón de uno a muchos, vale la pena revisar si los datos necesitan transformación antes de conectarse.
¿Has tenido problemas con relaciones de muchos a muchos en tus proyectos? Comparte tu experiencia y cómo lo resolviste.
