La granularidad, y por qué un modelo tiene un solo camino

La idea

La granularidad (grain) de una tabla es lo que significa una fila. En orders una fila es un pedido. En order_items una fila es una línea de un pedido. En 'Date' una fila es un día del calendario. Antes de construir nada, debes poder terminar la frase "una fila de esta tabla es ..." sin ningún "o".

La granularidad parece vocabulario, pero es la regla detrás de casi todas las decisiones de modelado. Un número pertenece a la tabla cuya granularidad describe, y una relación conecta tablas cuyas granularidades encajan: muchas líneas en un pedido, muchos pedidos en un día.

Por qué existe

Un modelo que ignora la granularidad da totales erróneos sin dar ningún error. Power BI suma encantado cualquier columna que le des. Si un valor que pertenece a un pedido está en cada línea de ese pedido, la suma lo cuenta una vez por línea. Los ingresos se inflan, el informe se ve bien y el gerente decide con un número que nadie comprobó.

Declarar la granularidad también te dice en qué tabla va una columna nueva. La tarifa de envío describe el pedido, así que vive en orders. La quantity de una línea describe la línea, así que vive en order_items. Cuando una columna cabe en dos tablas, es que aún no has decidido la granularidad de una de ellas.

Cómo funciona por dentro

Nombra la granularidad y luego relaciona

Hazle la pregunta de la granularidad a cada tabla del modelo y escríbela:

Una relación siempre une una granularidad más gruesa (el lado 1) con una más fina (el lado muchos). Una relación entre dos tablas con la misma granularidad es de uno a uno, lo que normalmente significa que deberían ser una sola tabla. Dos tablas que son "muchos" una de la otra son muchos a muchos, y eso indica que falta una dimensión entre ellas.

Qué comprueba el motor

Cuando creas una relación en Model view (Home → Manage relationships → New), Power BI comprueba que el lado 1 no tenga la clave repetida. Una clave duplicada en el supuesto lado 1 significa que la granularidad no es la que pensabas, y la relación se rechaza o se vuelve de muchos a muchos. Arregla la granularidad (quita duplicados o busca la clave real); no cambies la cardinalidad para que desaparezca el error.

Un solo camino activo

Entre dos tablas cualesquiera, el modelo permite un solo camino activo. Los filtros siguen las relaciones activas y nada más. Si existieran dos caminos, un filtro podría llegar a una tabla por las dos rutas y la respuesta dependería de cuál eligiera el motor.

Por eso una segunda fecha tiene que ser inactiva. Harbor & Pine tiene dos fechas que significan cosas distintas: cuándo se hizo un pedido y cuándo se dio de alta un cliente. Ambas se relacionan con la misma tabla 'Date'. La relación de la fecha del pedido es activa porque las ventas son la historia principal. La relación de la fecha de alta es inactiva, se dibuja punteada, y una medida la activa de forma explícita con USERELATIONSHIP. En el cuadro Edit relationship la casilla se llama Make this relationship active.

El mismo calendario juega dos papeles, lo que se llama una dimensión de rol múltiple (role-playing dimension). Mantienes una sola tabla 'Date', con todas sus columnas, y dejas que distintas relaciones la usen. La alternativa, una copia del calendario por cada fecha, duplica el mantenimiento y divide las segmentaciones.

Marca el calendario

Una regla más va aquí. En una tabla 'Date', usa Table tools → Mark as date table y elige la columna Date. Eso le dice a DAX cuál es la columna del calendario, y desbloquea la inteligencia de tiempo de los próximos capítulos. La tabla debe tener una fila por día, sin huecos, desde la primera fecha de pedido hasta la última.

Las jerarquías también se apoyan en la granularidad

Una jerarquía (hierarchy) es un camino ordenado por columnas de una dimensión, como Year, Quarter, Month, Date. Créala en el panel Data (clic derecho en una columna, Create hierarchy) y un gráfico puede bajar de año a mes con un clic. Solo funciona porque cada nivel encaja en el siguiente: un mes pertenece a un año. Una columna que no encaja, como el día de la semana, no pertenece a esa jerarquía. Además, los nombres de mes se ordenan alfabéticamente salvo que uses Sort by column con el número de mes.

Errores comunes

"El filtrado bidireccional arregla cualquier problema del modelo"

Una relación en Both deja que los filtros suban también del lado muchos al lado uno. Parece una cura cuando una segmentación no llega a una tabla, y a menudo es la causa del siguiente error: más caminos, visuales más lentos, ambigüedad. Antes pregúntate si la segmentación está en la tabla correcta. La estrella normalmente necesita dirección única, de las dimensiones a los hechos.

"Si un total parece razonable, la granularidad es la correcta"

Un valor repetido no rompe nada a la vista. Cada visual sigue dibujando un número; solo que es demasiado alto. Nada lo señala. La comprobación es sumar la columna con su propia granularidad, aquí los $11.94 de orders, y compararla con la misma medida en un visual. Si difieren, se está contando un valor más de una vez.

"Dos relaciones entre las mismas tablas son un error"

Están bien mientras como máximo una sea activa. Que una fecha juegue varios papeles es la razón más común para tener dos. Power BI mismo crea la segunda como inactiva cuando detecta relaciones automáticamente. El error son dos caminos activos, no dos relaciones.