Tablas de hechos
Lo que ocurre y se puede contar o sumar: ventas, matrículas, entregas, notas.
Crecen sin parar y suelen tener muchas filas. Una fila, un suceso.
El reflejo de quien viene de Excel es dejarlo todo en una tabla: al lado de cada venta, el nombre del cliente, su ciudad, su teléfono, la categoría del producto... Funciona, pero trae dos problemas.
El primero es que repites el mismo dato cientos de veces. El segundo, peor: si un cliente cambia de ciudad, tienes que corregirlo en todas las filas donde aparece, y basta con que se escape una para que el informe muestre dos ciudades para el mismo cliente.
Un modelo bien hecho separa lo que pasa de lo que es:
Lo que ocurre y se puede contar o sumar: ventas, matrículas, entregas, notas.
Crecen sin parar y suelen tener muchas filas. Una fila, un suceso.
Lo que describe a los protagonistas: clientes, productos, estudiantes, fechas.
Son cortas y estables. Una fila, una cosa que existe: un cliente aparece una sola vez, aunque te haya comprado cien veces.
La prueba para saber cuál es cuál: ¿esta fila se repetiría? Si el mismo cliente puede aparecer muchas veces, esa tabla es de hechos. Si cada fila es única e irrepetible, es un catálogo.
Vas a Vista de modelo (el icono de la izquierda con forma de tablas conectadas) y arrastras el campo común de una tabla al de la otra. Por ejemplo, el código de cliente de la tabla de ventas hasta el código de cliente de la tabla de clientes.
A partir de ahí, cuando filtres por ciudad en el informe, Power BI sabe qué ventas corresponden a esa ciudad, aunque la ciudad no esté en la tabla de ventas.
Tiene que ser el mismo valor escrito igual. Si en una tabla el
código es 001 y en la otra 1, no van a casar - y
ese es el momento de volver a Power Query a arreglarlo.
Power BI dibuja una línea entre las dos tablas. Esa línea es la relación.
Un 1 y un *: significa que un cliente (1) tiene muchas ventas (*). Es la relación normal y la que quieres ver.
Indica en qué dirección se propaga el filtro: del catálogo hacia los hechos. Por eso filtrar por ciudad filtra las ventas, y no al revés.
⚠️ Si ves una relación de muchos a muchos, párate. Casi siempre significa que la tabla que creías catálogo tiene valores repetidos - por ejemplo, el mismo cliente dos veces porque uno vino con un espacio al final. El informe seguirá funcionando, pero las cifras se inflarán sin avisar. Se arregla en los datos, no en la relación.
Cambia el nombre de las tablas, nunca la estructura. Sirve igual para un negocio, para un inventario o para el seguimiento de un grupo de personas:
Hechos: ventas. Catálogos: clientes, productos, calendario.
Permite responder «¿cuánto le vendimos a este cliente por categoría?» sin que la categoría esté en la tabla de ventas.
Hechos: transacciones. Catálogos: zonas, metas, calendario.
Las metas viven en su propia tabla: si estuvieran repetidas en cada transacción, cambiar una meta obligaría a tocar miles de filas.
Hechos: notas y asistencias. Catálogos: estudiantes, asignaturas, periodos.
Un estudiante aparece una sola vez en su catálogo, y sus veinte notas en la tabla de hechos.
Hay un catálogo que casi siempre falta y que conviene tener: una tabla con una fila por día, con columnas de año, mes, trimestre y día de la semana.
Sin ella puedes agrupar por la fecha exacta, pero no comparar meses ni ver la evolución por trimestre con comodidad. Con ella, esas preguntas se responden arrastrando un campo.
Tienes una tabla de ventas y otra de clientes. ¿Cuál es la de hechos?
Al relacionar dos tablas, Power BI marca la relación como de muchos a muchos. ¿Qué haces?
Siguiente: Las primeras visualizaciones
Continuar ← Limpiar los datos con Power Query