Diseño de grupos jerárquicos: mejores prácticas

[Syndicate_Admin]

Hola, chicos

¿Cómo se modelan los grupos jerárquicos?

Mi modelo se ve así:

Esta configuración me permite dividir por cualquier nivel, como Org a Departamento a Equipo, utilizando un puente jerárquico.

Sin embargo, me preocupa que la introducción de dos tablas de bridge y dimensiones de juego de rol pueda romper una estructura de esquema de estrella limpia o afectar el rendimiento.

¿Has implementado algo similar?

¿Es esta la manera correcta de controlar las jerarquías recursivas o irregulares en Power BI?

¿Mantendrías ambos puentes o lo simplificarías de alguna manera?

¿Alguna práctica recomendada para mantener el rendimiento y la claridad, especialmente con las direcciones de filtro, el tamaño del puente o los patrones DAX?

¡Gracias por tus ideas!

Mejor
Jacek

[Syndicate_Admin]

Hola jaryszek,

1. Materializamos una dimensión de grupo aplanada (DimGroup_Flat) con Level0.. Columnas LevelN para permitir un análisis rápido basado en columnas.
2. Mantenemos un GroupHierarchyBridge separado para capturar múltiples definiciones de jerarquía y pares padre-hijo arbitrarios.
3. Mantenemos un Bridge_ResourceGrouping para asignar recursos a grupos.
4. Todas las relaciones son de una sola dirección. Las selecciones de grupo se aplican a Fact_Costs usando DAX explícito con TREATAS para evitar caminos de filtro ambiguos o circulares y cálculos de caminos en tiempo de ejecución.
5. La medida TotalCost_HierarchyAll resuelve la jerarquía leyendo directamente los valores de las tablas puente y filtra los hechos mapeando claves de recursos en la tabla de hechos mediante TREATAS.
6. La medida no se basa en activar la relación ParentGroupSK ->DimGroup_Flat. En su lugar, deriva claves de grupo hijo a partir del puente y utiliza el puente de recursos para identificar recursos, luego aplica TREATAS para mapear a los hechos. Las relaciones inactivas pueden permanecer en el modelo, pero la medida las omite usando DAX (VALORES / IN / TREATAS) basados en conjuntos.

Si tiene más dudas, por favor contacte con la comunidad de Microsoft Fabric.

Gracias.

[Syndicate_Admin]

Gracias.

[Syndicate_Admin]

Hola jaryszek,

Gracias por tu paciencia y disculpas por la respuesta tardía.

Por favor, busca el archivo PBIX actualizado adjunto, puede ayudar a resolver el problema.

Si esta solución propuesta no resuelve su problema, le pedimos amablemente que contacte con nuestro socio de soluciones certificado en Power BI a través del enlace: Power BI Partners | Microsoft Power Platform. Estos profesionales pueden ofrecer asistencia técnica en profundidad y soluciones adaptadas a tus necesidades específicas.

Siempre eres bienvenido a seguir interactuando con la comunidad Microsoft Fabric también. Si necesitas más ayuda en el futuro, por favor contacta a través del Foro de la Comunidad Microsoft Fabric.

Gracias.

[Syndicate_Admin]

Hola, lo siento, pero Micirosft Partners es un servicio de pago y de muy baja calidad. No lo recomiendo.

Gracias por tu solución.
¿Podrías explicar cómo funciona esto?

¿Has añadido algunas relaciones inactivas?

Mejor
Jacek

[Syndicate_Admin]

Hola jaryszek,

Separé los objetos para evitar relaciones ambiguas, dependencias circulares y comportamientos bidireccionales no deseados de filtros. Esto mantiene el modelo limpio, mejora el control del filtro y evita problemas de rendimiento causados por múltiples rutas de relación.

Si tiene más dudas, no dude en contactar con la Comunidad Microsoft Fabric.

Gracias.

[Syndicate_Admin]

Hola

gracias. ¿Podrías compartir un archivo actualizado, por favor?

Mejor
Jacek

[Syndicate_Admin]

Hola jaryszek,

Gracias por la actualización.

Según mi comprensión del escenario, he adjuntado un archivo PBIX de muestra que puede ayudar a resolver el problema.

Si tiene más preguntas, no dude en ponerse en contacto con la comunidad de Microsoft Fabric.

Gracias.

[Syndicate_Admin]

Hola

Veo que dividió las relaciones y las tablas del esquema en estrella:

¿por qué?

Mejor
Jacek

[Syndicate_Admin]

¿Nadie?

[Syndicate_Admin]

Hola jaryszek,

Gracias por el seguimiento.

Según mi entendimiento, la jerarquía se puede representar materializando las columnas de nivel (Level0_Name → Level1_Name → Level2_Name) dentro de Dim_Group_Flat y creando una jerarquía de modelo a partir de ellas. Este enfoque proporciona una capacidad de desglose equivalente, un rendimiento mejorado y un esquema de estrella limpio.

Encuentre el archivo PBIX de muestra adjunto para su referencia.

Esperamos que la información proporcionada ayude a resolver el problema. Si tiene más preguntas, no dude en ponerse en contacto con la comunidad de Microsoft Fabric.

Gracias.

[Syndicate_Admin]

Gracias, pero no resolverá tener múltiples grupos jerárquicos.
Solo funciona para la pertenencia a "recursos de grupo ↔".

Y si tiene varios grupos jerárquicos y pueden ser padres de varios grupos secundarios de jerarquías, ¿cómo puede modelarlo?


Mejor
Jacek

[Syndicate_Admin]

Gracias, @Praful_Potphode, por tu respuesta.

Hola jaryszek,

Agradecemos su consulta en el foro de la comunidad de Microsoft Fabric.

Según mi entendimiento, a continuación encontrará un enfoque seguro para la producción que podría ayudar a resolver el problema:

1. Materialice la jerarquía durante ETL mediante la creación de un único DimGroup que contenga claves o nombres antecesores precalculados y un indicador de profundidad (por ejemplo, Level0_SK, Level1_SK, Level2_SK). Esto permite un filtrado rápido basado en columnas y en profundidad, en lugar de depender de operaciones basadas en cadenas o rutas de acceso en el momento de la consulta.
2. Conserve las tablas de puente solo para asignaciones genuinas de varios a varios (por ejemplo, Grupo de recursos ↔ con intervalos de tiempo). Si una tabla de puente existe únicamente para detectar el linaje principal, reemplácela por la dimensión aplanada ETL.
3. Si los cambios en ETL no son factibles, calcule la ascendencia una vez en el momento de la actualización mediante la creación de columnas calculadas durante la actualización del modelo (no medidas) para almacenar las claves suplentes y la profundidad de los antecesores. Use esas columnas para objetos visuales o medidas para evitar realizar cálculos de jerarquía DAX por representación.
4. Cuando deba asignar valores de dimensión a hechos, use patrones DAX de destino para el filtrado (por ejemplo, TREATAS, USERELATIONSHIP) en lugar de confiar en cadenas de relaciones bidireccionales o complejas.
5. Valide el rendimiento con DAX Studio o Performance Analyzer utilizando datos similares a la producción y limite las filas de la tabla de puente solo a asignaciones activas o actuales.

Además, consulte los enlaces que se proporcionan a continuación:
Descripción del esquema en estrella y la importancia de Power BI - Power BI | Aprendizaje de Microso...
Modelar relaciones en Power BI Desktop - Power BI | Aprendizaje de Microsoft
Guía de relaciones de varios a varios - Power BI | Aprendizaje de Microsoft

Esperamos que esta información ayude a resolver el problema. Si tiene más preguntas, no dude en ponerse en contacto con la comunidad de Microsoft Fabric.

Gracias.

[Syndicate_Admin]

Gracias

Entonces, ¿cómo cambiaría mi modelo propuesto?

Veo que está tratando de convencerme de que use el enfoque DAX y una tabla DimGroup.
¿Cómo pondrías los grupos jerárquicos allí?

Actualicé mi modelo. Pero no puedo mostrar estos grupos jerárquicos como los que tenía usando el modelo de Kimball:

¿Cómo hacer esto usando mi nuevo modelo de jerarquía?

Mi ejemplo:
https://drive.google.com/file/d/1hbButNYgmA6FbUR5LzYgSCAOhhtpI2-Y/view?usp=sharing

Mejor
Jacek

[Syndicate_Admin]

Hola @jaryszek

• Si es posible, intente crear una sola tabla de grupo dim con todas las combinaciones posibles presentes en la tabla de hecho.cree un tipo de rol con 2 valores, es decir, hijo y padre.
• Crear jerarquía personalizada para niveles de grupo DIm
• Intenta mantener la dirección del filtro cruzado única
• Minimice el recuento de filas de la tabla de puente. Agregue previamente y cree una columna de profundidad para contar la profundidad de los niveles.
• use funciones PATH para filtrar.

Por favor, felicita o márcalo como solución una vez confirmado.

Gracias y saludos,

Polvo

[Syndicate_Admin]

Gracias

aquí me centré en el modelado de jerarquía OLAP, no en el modelado padre-hijo al estilo OLTP, lo que está proponiendo. Con este tipo de consultas DAX en tiempo de ejecución, puedo tener problemas con jerarquías irregulares y un rendimiento más lento que no quiero tener.

Mejor
Jacek