En la siguiente imagen podemos ver un ejemplo de esta situaci\u00f3n, donde tanto los albaranes como las facturas presentan una estructura de datos del tipo descrito:<\/p>\n
<\/p>\n
Esta situaci\u00f3n es distinta a la que surge cuando tenemos una tabla por cada nivel dentro de una jerarqu\u00eda dimensional, como puede ser la jerarqu\u00eda natural que se forma cuando tenemos productos, familias de productos y secciones de productos. Aunque en este caso existen tambi\u00e9n varios niveles de datos, todos ellos corresponden a atributos dimensionales almacenados con distinta granularidad.<\/p>\n En el caso que nos ocupa en este art\u00edculo, que podemos denominar como estructura cabecera\/detalle, ambas tablas forman una jerarqu\u00eda que modela los hechos de un mismo proceso de negocio, aunque su granularidad sea distinta<\/strong>. Podemos decir que este tipo de estructura surge cuando existe alg\u00fan tipo de relaci\u00f3n entre dos tablas de hechos.<\/p>\n Como podemos ver en la imagen anterior, cada uno de los niveles de las tablas de hechos se relaciona directamente con alguna de las dimensiones del modelo, pero no con todas. Por ejemplo, si existe alguna m\u00e9trica en la cabecera<\/strong>, como puede ser un descuento o un coste log\u00edstico, no podr\u00eda segmentarse en funci\u00f3n de los atributos de la dimensi\u00f3n producto, al no estar directamente relacionadas ambas tablas. Este tipo de m\u00e9tricas corresponden con un documento de venta en su conjunto, pero no con cada una de las l\u00edneas que componen el mismo.<\/p>\n Es posible pensar que mediante el uso de filtro cruzado entre ambas tablas de hechos podemos resolver esta situaci\u00f3n:<\/p>\n Tanto si habilitamos la direcci\u00f3n de filtro cruzado en Power BI como si utilizamos un patr\u00f3n en DAX de relaci\u00f3n varios-a-varios, si utilizamos un atributo de producto como segmentador, el modelo ser\u00e1 capaz de propagar el filtro tanto a la tabla que contiene la cabecera de las facturas como a la que contiene los detalles de cada una de ellas. Si creamos una visualizaci\u00f3n obtendremos un resultado que aparentemente computa los importes que nosotros buscamos, es decir, la suma de los importes descontados segmentados por cada uno de los art\u00edculos:<\/p>\n Aunque obtenemos un importe de descuento distinto para cada c\u00f3digo de art\u00edculo, este c\u00e1lculo es err\u00f3neo<\/strong>. Por cada producto, el filtro de contexto mantendr\u00e1 visibles todas las facturas que contienen dicho producto y sumar\u00e1 todos los descuentos aplicados a cada factura en su conjunto. Como podemos observar en la visualizaci\u00f3n anterior, solo al nivel del total general el c\u00e1lculo ser\u00e1 correcto, es decir, cuando no existe ning\u00fan filtro en los atributos de la dimensi\u00f3n Producto. No necesitamos los descuentos a nivel de detalle de cada producto, sino que los necesitamos al nivel de detalle de cada venta individual de producto.<\/strong><\/p>\n Por lo tanto, cambiar el modelo de datos simplemente habilitando la propagaci\u00f3n de los filtros entre ambas tablas de hechos en las dos direcciones no nos proporciona el resultado buscado; que es reproducir un esquema en estrella, con una sola tabla de hechos que contenga toda la informaci\u00f3n relevante del proceso de negocio correspondiente y pueda filtrarse y segmentarte por cada uno de los atributos de cualquier dimensi\u00f3n.<\/p>\n La forma de solucionar esta situaci\u00f3n es calcular el porcentaje de descuento que corresponde a cada una de las facturas, para posteriormente aplicar dicho porcentaje a cada una de las l\u00edneas de cada factura y desnormalizar completamente (aplanar) el resto de columnas de la cabecera en la tabla de detalles.<\/strong><\/p>\n Si no podemos modificar la estructura de las consultas que componen el modelo y tenemos que trabajar directamente con un modelo como el de las im\u00e1genes anteriores, podemos realizar este proceso utilizando el lenguaje DAX.<\/p>\n Tanto para calcular el % que supone el descuento sobre la base imponible de cada factura y posteriormente aplicarlo a cada una de las l\u00edneas de detalle podemos usar el siguiente c\u00f3digo DAX gen\u00e9rico:<\/p>\n SalesHeader[DiscountPct] = Si podemos realizar transformaciones en las consultas de forma que apliquemos una optimizaci\u00f3n estructural de los datos antes de que estos sean cargados al modelo<\/strong>, podemos realizar los mismos pasos que hemos hecho en DAX desde el editor de consultas de Power BI, que en mi opini\u00f3n, es una soluci\u00f3n mucho m\u00e1s elegante.<\/p>\n En primer lugar, obtenemos el descuento en t\u00e9rminos porcentuales respecto al total de la base imponible en la tabla Facturas con una columna calculada:<\/p>\n Una vez obtenido dicho porcentaje, solo tenemos que combinar las dos consultas que registran el proceso de facturaci\u00f3n y expandir la columna de descuento en t\u00e9rminos porcentuales, as\u00ed como otras columnas que queramos trasladar hacia la tabla de l\u00edneas de facturas, que ser\u00e1, en el nuevo modelo, la \u00fanica tabla de hechos que registra el proceso de facturaci\u00f3n de la empresa<\/strong>:<\/p>\n Una vez hemos realizado este proceso, solo tendremos que cargar al modelo la tabla de detalles de factura:<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/bicontrolling.com\/wp-content\/uploads\/2019\/03\/image-2-2.png?ssl=1\")
<\/a><\/p>\nC\u00f3mo modelar correctamente esta situaci\u00f3n<\/h4>\n
<\/a><\/p>\n<\/a><\/p>\n<\/h4>\n
Utilizando DAX<\/h4>\n
\nDIVIDE<\/span> (<\/span>
\n <\/span>SalesHeader[TotalDiscount],
\n <\/span>SUMX<\/span> (<\/span>
\n <\/span>RELATEDTABLE<\/span> (<\/span> SalesDetail )<\/span>,
\n <\/span>SalesDetail[Unit Price] SalesDetail[Quantity]
\n <\/span>)<\/span>
\n)<\/span>
\nSalesDetail[LineDiscount] =
\nRELATED<\/span> (<\/span> SalesHeader[DiscountPct] )<\/span> <\/em> SalesDetail[Unit Price] * SalesDetail[Quantity]<\/p>\n<\/h4>\n
Utilizando M<\/h4>\n
<\/a><\/p>\n<\/a><\/p>\n