Informe similar a "Máquina del tiempo" para la tabla de hechos versionada

[Syndicate_Admin]

Estoy buscando visualizar el estado de ciertos artículos con el tiempo. Cada elemento tiene su estado registrado en una especie de registro de cambios (ejemplo):

ItemId	Actualizado	estado
cuervo	12.04.2021	abrir
cuervo	18.04.2021	cerrado
Boogie	19.04.2021	resuelto
cuervo	20.04.2021	resuelto
cuervo	23.04.2021	cerrado

El objetivo es poder producir un conjunto similar de informes basados en medidas sobre estos datos de ejemplo:

fecha	Recuento total	Conde de "Cerrado"	Recuento de "Resuelto"
18.04.2021	1	1	0
19.04.2021	2	1	1
20.04.2021	2	0	2
21.04.2021	2	0	2
22.04.2021	2	0	2
23.04.2021	2	1	1
24.04.2021	2	1	1
25.04.2021	2	1	1

Tenga en cuenta que incluso si el historial de versiones no tiene datos para 21 y 22.04.2021, el informe resultante contiene filas correspondientes con valores correctos. La medida debe producir resultado por cualquier punto de granularidad dado (ya sea día o hora o cualquier cosa en general); esto significa que para un informe similar a una tabla con granularidad diaria utilizada en el ejemplo, debe haber filas para cada día.

En general, quiero elegir un punto de tiempo y calcular los agregados requeridos (count() por estado en este ejemplo) sobre los datos tal como existían en este momento. Esto parece ser una tarea bastante común, pero desafortunadamente, no pude encontrar ningún ejemplo.

EDITAR: Datos de ejemplo modificados para incluir el escenario cuando el elemento cambia su estado de ida y vuelta.
EDIT2: Recalcó que no debe haber lagunas en el informe (la medida debe calcularse para cada día consecutivo si usamos la granularidad diaria, para cada hora si usamos por hora y así sucesivamente)

[Syndicate_Admin]

No @DmitriiK,

Estos son los pasos que puede seguir:

1. Cree una tabla calculada.

Date = SELECTCOLUMNS('Table',"Date",'Table'[Updated])

2. La relación entre la conexión de dos tablas

3. Cree una columna calculada.

Count of "Closed" =
var _1=CALCULATE(COUNT('Table'[Status]),FILTER(ALL('Table'),'Table'[Status]="Closed"&&'Table'[Updated]=MAX('Date'[Date])))
return
IF(_1=BLANK(),0,_1)

Count of "Resolved" =
var _1=CALCULATE(COUNT('Table'[Status]),FILTER(ALL('Table'),'Table'[Status]="Resolved"&&'Table'[Updated]=MAX('Date'[Date])))
return
IF(_1=BLANK(),0,_1)

Total count = 'Table'[Count of "Closed"]+'Table'[Count of "Resolved"]

resultado:

Si los datos se agrupan por horas, he cambiado la presentación de datos sin cambiar la función Dax:

resultado：
Los datos se agrupan por número de horas

¿Este resultado satisface sus expectativas.

Saludos

Liu Yang

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

[Syndicate_Admin]

Hola Liu!..

No veo cómo la tabla calculada de este tipo cambia nada - es básicamente lo mismo que la tabla de historial de versiones. En el ejemplo actualizado, el resultado sigue contiene lagunas:

El objetivo es obtener el recuento de elementos que tenían un estado específico en un momento específico con la granularidad dada - basado en un registro de "historial de versiones" que no tiene ninguna granularidad específica.

P.S. Por alguna razón no puedo publicar el ejemplo completo aquí; plantea un error sobre el mensaje que contiene caracteres HTML no válidos - que es enfurecedor ya que el mensaje fue totalmente compuesto por el editor incorporado...

[Syndicate_Admin]

No @DmitriiK,

Según su descripción, creo algunos datos:

Estos son los pasos que puede seguir:

1. Cree la medida.

Count of "Closed" =
var _1=CALCULATE(COUNT('Table'[Status]),FILTER(ALL('Table'),'Table'[Status]="Closed"&&'Table'[Updated]=MAX('Table'[Updated])))
return
IF(_1=BLANK(),0,_1)

Count of "Resolve" =
var _1=CALCULATE(COUNT('Table'[Status]),FILTER('Table','Table'[Status]="Resolved"&&'Table'[Updated]=MAX('Table'[Updated])))
return
IF(_1=BLANK(),0,_1)

Total count =
'Table'[Count of "Closed"]+'Table'[Count of "Resolve"]

2. Resultado.

Saludos

Liu Yang

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

[Syndicate_Admin]

Hola.

Desafortunadamente, esto no funcionará con una tabla de versiones. Una tabla de versiones es una tabla en la que solo se registran los cambios en el estado del elemento: si el elemento no tiene cambios de estado durante un determinado período de tiempo, no hay filas correspondientes.

En los datos de origen de ejemplo contiene filas redundantes: hay una fila para cada elemento y todos los días, incluso si el estado no cambió. Por ejemplo, la 2ª fila aquí es redundante y no estaría presente en una tabla de versiones:

Esto podría ser una solución si Power BI permitió combinar una tabla CALENDARAUTO() con una tabla de versiones, pero no es así, la tabla de fechas ni siquiera aparece en la lista de tablas para la operación de combinación.

Por otra parte, ¿qué pasa si necesitamos granularidad antes de la hora en lugar de por día? ¿Por minuto?

[Syndicate_Admin]

¿Alguna idea aquí?

[Syndicate_Admin]

Hola Ashish. Gracias por el archivo de ejemplo. Traté de entender la lógica de las medidas, sin embargo, parece que hay varios problemas con la solución propuesta:

1. Los datos originales pueden abarcar varios años hasta que DATESYTD no se aplique aquí. Traté de cambiarlo a DATESBETWEEN y el resultado fue inmediatamente incorrecto.

2. El elemento podría cambiar su estado de un lado a otro. Podría estar en el mismo estado más de una vez en un período dado. Si modifica los datos de origen para incluir este caso, los resultados vuelven a ser incorrectos (por ejemplo, valores negativos)

[Syndicate_Admin · Accepted solution]

hola

Puede descargar mi archivo PBI desde aquí.

Espero que esto ayude.

[Syndicate_Admin]

Hola Ashish.

Esto solo funcionaría si la tabla de historial de versiones contiene exactamente una fila por período de fecha que necesita en el informe. En el ejemplo, hay exactamente una fila por día por elemento.

Este no es el caso de los conjuntos de datos reales donde el cambio de estado del elemento no se registra diariamente (por hora, etc.), sino que solo se registra cuando cambia el estado del elemento.

[Syndicate_Admin]

hola

Eso es exactamente lo que hace mi solución. Por favor, estudie los pasos de transformación en el Editor de consultas con mucho cuidado. He transformado sus datos para que aparezcan como una fila por fecha.

[Syndicate_Admin]

Bueno, marcé esto como solución, ya que parecía ser la única, pero me equivoqué. Esta solución solo se aplica cuando cierta suposición sobre los datos de changelog es válida. Por ejemplo, obtendría un error de conversión de tipos si alguna de las fechas del registro de cambios es diferente de 0:00:00 de una fecha determinada (por ejemplo, contiene parte de tiempo):

Además, el resultado sería incorrecto si changelog contiene más de un registro para un período de día determinado , debido a la forma en que la transformación analiza los datos.

Esto es muy importante que no se puedan hacer suposiciones con respecto a los datos de origen (changelog). Contiene el historial de versiones en formato de timestamp-item-new status, pero eso es todo. No se garantiza que tenga un solo registro por día, o por hora, o por minuto.

[Syndicate_Admin]

hola

Puede descargar mi archivo PBI desde aquí.

Espero que esto ayude.