Pregunta de diseño del modelo de datos: relaciones múltiples, de varios a muchos

[Syndicate_Admin]

Hola a todos, tengo un modelo de datos relacionado con Pipelines, Actividades y Tickets. La tabla de canalizaciones tendrá una lista de canalizaciones por producto. Cada canalización tendrá actividades que se ejecutarán y almacenarán en la tabla Actividades. Si hay algún error en las actividades, se producen tickets y los tickets se almacenan en la tabla de tickets. Queremos calcular

1) Tasa de fracaso de cada producto

2) Tasa de fallos por plataforma y fuera de la plataforma para cada producto

3) # de actividades por tipo de problema

Tasa de fallas = # de canalizaciones fallidas / # de tuberías en Progess.

# de canalizaciones fallidas = recuento de PipelineId con estado anulado

# de canalizaciones InProgress = Recuento de PipelineId con InProgress+ estado anulado

Plataforma de tasa de errores = # de canalizaciones fallidas ( Tipo de problema = Plataforma) / # de canalizaciones en curso

# de actividades por tipo de problema = # de actividades ( por tipo de problema )

Modelo:

Datos de ejemplo:

Según los datos anteriores, la canalización B tiene un tipo de problema de plataforma y no de plataforma (la canalización B tiene ActivityId B5467 y tiene un tipo de problema de mulriple, lo que dio lugar a una relación de varios a varios)

Además, en los datos de actividades, en la canalización B, entre dos actividades, solo 1 actividad tiene problemas de plataforma y otra actividad no tiene problemas.

(ActivityId B5467 tiene varios tipos de problemas)

Medidas:

En la tabla de canalizaciones:

# de canalizaciones = CALCULAR(CONTAR('Oleoductos'[PipelineId]), TODO(Tuberías[PipelineId]))

# de canalizaciones activas = CALCULAR([# de Oleoductos], Tuberías[Estado] EN {"En progreso","Abortado"})

# de canalizaciones fallidas = CALCULAR([# de Oleoductos], Tuberías[Estado] == "Abortado" )

Tasa de fallos = DIVIDIR([# de canalizaciones fallidas], [# de Pipelines Activos])

Tabla de Medidas en Actividades:

# de actividades = CALCULAR(DISTINCTCOUNT('Actividades'[Id. de actividad]))

Medidas en la tabla de tickets

# de errores de canalización de plataforma = CALCULAR(DISTINCTCOUNT('Tickets'[PipelineId]),'Tickets'[IssueType]=="Plataforma")

# de errores de canalización que no son de plataforma = CALCULAR(DISTINCTCOUNT('Entradas'[PipelineId]),'Entradas'[TipoProblema]=="No plataforma")

Tasa de fallos de la plataforma = DIVIDIR([# de errores de canalización de plataforma], [# de Pipelines Activos])

# de errores de canalización que no son de plataforma = CALCULAR(DISTINCTCOUNT('Entradas'[PipelineId]),'Entradas'[TipoProblema]=="No plataforma")

Pregunta

1) ¿Es posible agregar IssueType como columna a la tabla de canalizaciones y actividades y usarlo como dimensión común para las 3 tablas?

Ej: ¿creando una tabla puente?

Nota: Se produce un error en la siguiente relación

2) Otra posible solución es aplanar las 3 tablas en una sola tabla porque la mayoría de los datos estarán dispersos (por ejemplo, considere que hay 2 millones de tuberías, 10 millones de actividades y 10 mil incidentes. Después de combinar 3 mesas, la mayoría de las actividades no tendrán boletos y darán como resultado datos escasos)

Columna esperada - Atenuación común entre 3 tablas (debido a la relación de muchos a muchos, no estoy seguro de si necesitamos crear varias tablas puente)

Por favor, proporcione sus sugerencias

Gracias

Abhiram

[Syndicate_Admin]

Hola @abhiram342 ,

Sobre la base de la información que ha proporcionado, esto suena como un intento de optimizar la forma en que se modelan los datos en relación con los pipelines, las campañas y las órdenes de trabajo para calcular de manera eficiente las tasas de fracaso y las campañas por tipo de problema.

1. La creación de tablas puente es, de hecho, una solución viable cuando se trata de relaciones de varios a varios en el modelo de datos. Puedes seguir los siguientes pasos:
Cree una nueva tabla que contenga los identificadores únicos de la tabla Pipelines/Activities y la tabla Tickets. Esta tabla también debe incluir la columna IssueType.
Establezca una relación entre esta tabla puenteada y las demás tablas del modelo. La tabla puente actuará como un punto de referencia central para unir registros relacionados en función de IssueType.
Puede consultar el siguiente enlace para obtener más detalles:

Relaciones de modelos en Power BI Desktop - Power BI | Microsoft Learn

2. Distribuir las tablas en una sola tabla puede simplificar el modelo de datos y facilitar los cálculos. Sin embargo, este método puede dar lugar a un aumento significativo del tamaño del conjunto de datos. Esto puede afectar al rendimiento de los informes y paneles de Power BI. Tenga en cuenta los siguientes puntos antes de decidirse por esta acción:
El impacto en el rendimiento y si el entorno de Power BI puede controlar eficazmente el aumento del tamaño del conjunto de datos.
La complejidad de mantener y actualizar una sola tabla grande.

En muchos casos, mantener un modelo de datos normalizado con relaciones correctamente definidas puede proporcionar un buen equilibrio entre rendimiento y flexibilidad.

Los dos enfoques que mencionaste tienen sus ventajas y desventajas potenciales. La elección entre crear tablas puenteadas o estirar tablas en una sola tabla depende de los requisitos específicos del proyecto, incluidas las consideraciones de rendimiento y la complejidad del mantenimiento.

Si decides optar por el enfoque de la mesa puenteada, ¿puedes compartir información más detallada sobre los problemas específicos que encontraste al intentar construir la relación? Esta información ayudará a proporcionar recomendaciones más personalizadas.

Saludos

Ada Wang

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]

¡Gracias @v-yifanw-msft por sus sugerencias!

[Syndicate_Admin]

Hola @abhiram342 ,

De nada.

Saludos

Ada Wang

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