Mejor enfoque de modelado de datos

[Syndicate_Admin]

Hola a todos

Como punto de partida tengo 1 sola tabla plana con varias informaciones sobre los servicios y sus atributos:

Todas las columnas como Tiempo de servicio, Tiempo de soporte , etc. están relacionadas / forman parte del Servicio B (habrá muchas más columnas que forman parte del Servicio B en realidad).

El requisito que debo cumplir es una matriz que:

• Tiene una jerarquía con el Servicio A y el Servicio B (como filas)
• Muestra los diferentes atributos del Servicio B (como valores)
• Agrupa los diferentes atributos con un "Grupo" padre adicional (como Columnas):

Me gustaría lograr el objetivo bajo las siguientes condiciones:

• Uso del mejor enfoque de modelado de datos
• El modelo de datos debe permitir agregar más tablas de hechos (que están relacionadas con el Servicio B)
• Uso de prácticas recomendadas generales
• Las segmentaciones de datos del servicio A y el servicio B deben filtrarse entre sí (que solo se muestren los elementos relacionados)

Parece un requisito fácil, pero he probado diferentes métodos y cada uno de ellos tiene ventajas y desventajas. Además, es difícil para mí decidir si el Servicio B debe manejarse como una tabla de hechos o una tabla de dimensiones, porque no hay "valores" numéricos disponibles.

Si dejo fuera el requisito con respecto a la "Agrupación" por ahora, estas son las opciones que he validado hasta ahora:

Opción 1)

Usar la tabla plana original como una sola tabla en Power BI.

Ventajas:

• Se da la dependencia de las segmentaciones de datos

Desventajas:

• No es la mejor práctica (en absoluto)
• El modelo de datos no es flexible para requisitos adicionales / tablas de hechos adicionales
• https://radacad.com/basics-of-modeling-in-power-bi-what-is-a-dimension-table-and-why-say-no-to-a-sin...

Opción 2)

Definir "Servicio A" y "Servicio B" (incluidos todos los atributos) como tablas de dimensiones. Debido a una relación de muchos a muchos, necesito un puente / tabla de mapeo entre estos dos:

Ventajas:

• Prácticas recomendadas implementadas debido al modelado dimensional y porque no hay una relación de muchos a muchos
• La tabla de dimensiones "Servicio B" se puede utilizar y relacionar con tablas de hechos adicionales

Desventajas:

• Las dependencias de segmentación de datos no se dan "por defecto", sino que se pueden lograr con DAX y filtros: https://www.sqlbi.com/articles/syncing-slicers-in-power-bi/

Opción 3)

Definir "Servicio A" como una tabla de dimensiones y "Servicio B" como una tabla de dimensiones (pero solo con ID, Nombre y Descripción) y poner las otras columnas como Tiempo de servicio en una tabla separada de "Hechos" llamada "Hechos del servicio B". Al igual que en la opción 2, necesito una tabla puente / mapeo.

Ventajas:

• Tabla de hechos adecuada / separada (que se puede despivotar más adelante para lograr el objetivo de agrupar las columnas en la matriz)

Desventajas:

• Tendría una relación bidireccional 1: 1 entre "Servicio B" y "Hechos del Servicio B", lo que no es la mejor práctica. Tales combinaciones son candidatas para fusionarlas / combinarlas en una sola tabla (como en la opción 2). Una relación entre la tabla de hechos y la tabla de asignación tampoco resolverá este problema, debido a la dirección (una tabla de hechos no debe filtrar la dimensión, solo al revés) y las relaciones faltantes terminarán en una coherencia de datos incorrecta.
• Las dependencias de segmentación de datos no se dan "de forma predeterminada" (pero se pueden lograr con DAX y filtros)

Ahora aquí está el gran desafío para mí:

• En mi opinión, la opción 2 parece ser la mejor solución (hasta que intente lograr el objetivo de agrupar las columnas en la matriz, ver más abajo), ¿o me falta algo aquí y hay incluso una mejor solución?
• Al usar la opción 2, ¿cómo puedo resolver ahora el desafío relacionado con la agrupación de columnas? La única forma parece ser despivotar la tabla de "Servicio B", que ya ha sido respondida en mi post anterior aquí de @Greg_Deckler : https://community.powerbi.com/t5/Desktop/Grouping-columns-in-Matrix/m-p/2805995. Pero dado que "Servicio B" es una tabla de dimensión, generaré varias filas para cada clave y terminaré con una relación de muchos a muchos entre "Asignación de servicios" y "Servicio B" y ya no puedo usar "Servicio B" como tabla de dimensiones para otras / tablas de hechos adicionales correctamente con una relación de 1 a muchos:

¿Cuál es la forma correcta de alcanzar todas mis metas?

Gracias de antemano por cualquier sugerencia.

Saludos
Entusiasta de PBI

[Syndicate_Admin]

Hola, @PBI-entusiasta

De acuerdo con su descripción, desea obtener esta tabla . ¿Rught?

Para sus necesidades, su Servicio A pertenece a una tabla final, y el resto pertenece a la tabla de hechos. No recomiendo que uses relaciones de muchos a muchos para mantener tus relaciones entre tablas.

Utilizo la siguiente relación de tabla:

Creo la tabla 'Servicio A' en el Editor de Power Query:

let
    Source = Table.Distinct(Table.SelectColumns(#"Fact Table" ,{ "Key A","Service A","Service A Description" }))
in
    Source

Y necesitamos despivotar la tabla de hechos:

let
    Source = Table.FromRows(Json.Document(Binary.Decompress(Binary.FromText("rZHPCsIwDMZfZfQ8IUmzWr2tTyB4HDv476qgB6dPbxPr5sApQj8oX1Lo72ubpjGIaEqzrgHEN6pYIFnZDs/tqyoW4JYAxawgiP6hr+NaHc6X07FAbdtyMoIrlyIoeicSoldiHzBu3/hyKHzjz/0i8eUpN9FwY/SjB7zaMPDtL76rOPHF76L/foj7HyKilCC+VWUewkREtiFYaxNffKfKOQRmTnzxvSrjENoH", BinaryEncoding.Base64), Compression.Deflate)), let _t = ((type nullable text) meta [Serialized.Text = true]) in type table [#"Key A" = _t, #"Service A" = _t, #"Service A Description" = _t, #"Key B" = _t, #"Service B" = _t, #"Service B Description" = _t, #"Service Time" = _t, #"Support Time" = _t, Classification = _t, Responsible = _t, Criticality = _t]),
    #"Changed Type" = Table.TransformColumnTypes(Source,{{"Key A", Int64.Type}, {"Service A", type text}, {"Service A Description", type text}, {"Key B", Int64.Type}, {"Service B", type text}, {"Service B Description", type text}, {"Service Time", type text}, {"Support Time", type text}, {"Classification", type text}, {"Responsible", type text}, {"Criticality", type text}}),
    #"Unpivoted Columns" = Table.UnpivotOtherColumns(#"Changed Type", {"Key A", "Service A", "Service A Description", "Key B", "Service B", "Service B Description"}, "Attribute", "Value")
in
    #"Unpivoted Columns"

Luego aplicamos los datos a Power Bi Desktop, estos son los pasos en Power Bi Desktop que puede consultar:

(1) Necesitamos hacer clic en "Nueva columna" para crear una columna calculada en 'Tabla de hechos':

Group = IF([Attribute] in {"Service Time","Support Time"} , "Group A" , IF([Attribute] in {"Classification","Responsible"} , "Group B" , "Group C"))

(2) Luego necesitamos agregar una hirearchy en esta tabla:

Podemos hacer clic en los tres puntos a la derecha de la 'Tabla de hechos' [Grupo] y hacer clic en 'Crear contratación' y luego agregar el [Atributo] a esta contratación.

(3) Entonces podemos crear una medida:

Measure = IF( HASONEVALUE('Fact Table'[Service B]) , MAX('Fact Table'[Value]))

(4) Luego ponemos el campo que necesitamos en el visual de Matrix y luego podemos obtener esto:

Gracias por su tiempo y uso compartido, y gracias por su apoyo y comprensión de PowerBI.

Saludos

Aniya Zhang

Si esta publicación ayuda, considere Aceptarlo como la solución para ayudar a los otros miembros a encontrarlo más rápidamente.

[Syndicate_Admin]

En ella @v-yueyunzh-msft

Muchas gracias por tomarse el tiempo para analizar y responder a mi pregunta. Su solución utiliza un despivote, que estaba tratando de evitar. Pero cuando "defino" esta tabla no pivotada como una tabla de hechos, supongo que el requisito adicional (tablas de hechos adicionales relacionadas con la tabla de dimensiones "Servicio A") será posible de esa manera.

Muchas gracias de nuevo y saludos,
Entusiasta de PBI

[Syndicate_Admin]

Con los requisitos especiales de agrupación, su única opción es crear medidas dedicadas para cada una de las "columnas" de su matriz. Esto incluirá más trabajo de desarrollo y mantenimiento.

La solución ideal sería abandonar/modificar sus requisitos y utilizar la funcionalidad estándar de la matriz visual. "No luches contra la API".

Proporcione datos de muestra desinfectados que cubran completamente su problema.
Muestre el resultado esperado en función de los datos de muestra que proporcionó.

[Syndicate_Admin]

@lbendlin

Estoy de acuerdo, los requisitos de agrupación son la razón por la que no podré tener el modelo de datos más limpio al final. Desafortunadamente, estos requisitos son imprescindibles según nuestro cliente.

Pero creo que con la solución de @v-yueyunzh-msft estoy listo para irme, ¡gracias por su respuesta!

Saludos

Entusiasta de PBI