Join us for an expert-led overview of the tools and concepts you'll need to pass exam PL-300. The first session starts on June 11th. See you there!
Get registeredPower BI is turning 10! Let’s celebrate together with dataviz contests, interactive sessions, and giveaways. Register now.
Tengo un curioso modelo de datos a partir del cual necesito crear informes de Power BI.
En este modelo hay una tabla de asignaciones que contiene claves externas a otras dos tablas, lo que permite una relación m:m.
Una de esas claves externas es coherente en el sentido de que siempre se relaciona con la tabla Assets y la clave es Asset_UID.
La otra clave se llama Record_UID y se relaciona con una de varias tablas, la tabla relevante está determinada por Entity_UID.
No he visto este tipo de estructura de datos antes, pero no soy un científico de datos, por lo que en realidad puede ser bastante común e incluso tener un nombre. Yo no creé el modelo de datos y no tengo ninguna influencia sobre él, solo estoy tratando de informar sobre él.
Para dar sentido a las cosas, he usado Power Query para crear varias copias de la tabla, cada una filtrada en Enitiy_UID y luego crear las relaciones en Power BI con la tabla correspondiente, dictadas por el Enity_UID.
¿Es esto lo correcto? ¿O hay un enfoque mejor o más simple que podría adoptar?
Ejemplo: Una fila de la tabla podría vincular un activo a otro activo, un tipo de activo, una orden de trabajo o un evento, con tablas separadas para cada uno de ellos.
Solved! Go to Solution.
Hola @v-priyankata , Si bien la respuesta de @lbendlin fue un puntero útil para los esquemas de estrellas, sobre los que necesito leer un poco más, realmente no respondió a mi pregunta. Sin embargo, CoPilot lo hizo; Esto es lo que decía:
Parece que se trata de una asociación polimórfica, que es un patrón de diseño en el que una sola clave externa de una tabla puede hacer referencia a varias otras tablas. Esto no es raro en el modelado de datos, especialmente cuando se trata de relaciones complejas.
El enfoque de usar Power Query para crear varias copias de la tabla, cada una filtrada por Entity_UID, y luego crear relaciones en Power BI es una solución válida. Sin embargo, hay algunos otros enfoques que podría considerar:
Tablas de unión: En lugar de crear varias copias de la tabla, puede crear una tabla de unión que combine todas las tablas relacionadas posibles (por ejemplo, Activos, Tipos de activos, Órdenes de trabajo, Eventos) en una. De esta manera, solo necesita una relación en Power BI. Puede agregar una columna a esta tabla de unión para indicar el tipo de entidad (Activo, Tipo de activo, etc.).
Tabla puente: cree una tabla puente que Record_UID asigne a la tabla y Entity_UID adecuadas. Esta tabla puente se puede usar para crear relaciones en Power BI. Este enfoque puede ayudar a simplificar el modelo y hacerlo más escalable.
Relaciones dinámicas: use DAX para crear relaciones dinámicas basadas en el Entity_UID. Esto puede ser más complejo, pero permite una mayor flexibilidad en sus informes.
Voy a marcar eso como la respuesta, creo.
¿Es M:M unidireccional o bidireccional? ¿Hasta qué punto está familiarizado con el modelo asociativo de Qlik?
Me temo que no estoy familiarizado con el modelo asociativo de Qlik, simplemente lo busqué en Google y parece algo propietario.
En cuanto a las relaciones, la tabla de asignaciones es la que permite una relación m:m entre, por ejemplo, el activo y la orden de trabajo. Una orden de trabajo puede usar cero, uno o muchos activos y un activo puede usarse en cero, una o varias órdenes de trabajo. No estoy seguro de la dirección, pero he descubierto que Power BI no me permitirá hacerlos todos bidireccionales.
Hola @IntaBruce , Solo me comunico ya que no hemos recibido una actualización de su parte con respecto a la última respuesta. ¿Pudo resolver el problema con la respuesta de @lbendlin ?
Si la solución fue útil, márquela como Aceptar respuesta y haga clic en Sí para confirmar.
No dudes en avisarnos si tienes más preguntas, ¡estamos aquí para ayudarte!
¡Gracias por formar parte del foro de la comunidad de Microsoft Fabric!
Hola @v-priyankata , Si bien la respuesta de @lbendlin fue un puntero útil para los esquemas de estrellas, sobre los que necesito leer un poco más, realmente no respondió a mi pregunta. Sin embargo, CoPilot lo hizo; Esto es lo que decía:
Parece que se trata de una asociación polimórfica, que es un patrón de diseño en el que una sola clave externa de una tabla puede hacer referencia a varias otras tablas. Esto no es raro en el modelado de datos, especialmente cuando se trata de relaciones complejas.
El enfoque de usar Power Query para crear varias copias de la tabla, cada una filtrada por Entity_UID, y luego crear relaciones en Power BI es una solución válida. Sin embargo, hay algunos otros enfoques que podría considerar:
Tablas de unión: En lugar de crear varias copias de la tabla, puede crear una tabla de unión que combine todas las tablas relacionadas posibles (por ejemplo, Activos, Tipos de activos, Órdenes de trabajo, Eventos) en una. De esta manera, solo necesita una relación en Power BI. Puede agregar una columna a esta tabla de unión para indicar el tipo de entidad (Activo, Tipo de activo, etc.).
Tabla puente: cree una tabla puente que Record_UID asigne a la tabla y Entity_UID adecuadas. Esta tabla puente se puede usar para crear relaciones en Power BI. Este enfoque puede ayudar a simplificar el modelo y hacerlo más escalable.
Relaciones dinámicas: use DAX para crear relaciones dinámicas basadas en el Entity_UID. Esto puede ser más complejo, pero permite una mayor flexibilidad en sus informes.
Voy a marcar eso como la respuesta, creo.
Las tablas puente son una señal de advertencia de un modelo de datos ineficiente. Son lo opuesto a escalable.
Exactamente, porque entonces sería Qlik....
Power BI quiere relaciones 1:*, en una sola dirección. Más información sobre los esquemas de estrella.
Gracias por el puntero sobre los esquemas de estrellas, que fue útil y lo será en el futuro.