Acest subiect explică diferenţa dintre funcţiile pentru seria cronologică şi funcţiile de filtrare şi explică cum se implementează funcţiile de filtrare. Aceste informaţii se aplică atât la dashboardul registrelor de lucru, cât şi la cel clasic.
Funcţii pentru seria cronologică vs. funcţii de filtrare
Funcţiile pentru seria cronologică Ago
şi Todate
oferă o modalitate simplă de a crea metrici pentru a calcula year-ago, year-to-date,
etc. Această metodă funcţionează bine pentru rapoartele utilizatorului de business, însă aceste funcţii generează interogări complexe, care au un cost semnificativ în raport cu performanţa. De asemenea, de fiecare dată când una dintre aceste funcţii este utilizată într-un raport, este generată o subinterogare suplimentară utilizând şi mai multe resurse din baza de date.
În dashboardurile clasice, în loc de utilizarea funcţiilor pentru seria cronologică, puteţi obţine, de obicei, acelaşi rezultat utilizând metrici de bază cu funcţia Filter
pentru a filtra perioada adecvată. Această metodă ar putea fi prea complexă pentru rapoartele utilizatorilor de business, dar funcţionează bine în dashboardurile predefinite de echipa IT. Utilizând această metodă, codul SQL fizic generat este mult mai simplu şi mai eficient şi nu necesită o subinterogare suplimentară. Aceasta înseamnă că interogarea SQL rulează mai rapid şi utilizează mai puţine resurse din baza de date, reducând utilizarea generală a procesorului bazei de date şi apelurile de intrare-ieşire.
Următoarea figură prezintă un exemplu de interogare fizică generată atunci când utilizaţi atât metrica de bază, cât şi metrica Ago
pentru lună în acelaşi raport. Sunt generate două interogări.
Următoarea figură prezintă codul SQL generat pentru o interogare individuală atunci când utilizaţi în schimb o funcţie Filter
.
Implementarea funcţiilor de filtrare într-un dashboard cu prompturi
În majoritatea implementărilor, dashboardul include deja un prompt, astfel că utilizatorii pot selecta luna pe care o caută. Primul pas este să identificaţi perioadele de timp pe care trebuie să le filtraţi în funcţie de selecţia unui utilizator.
În acest exemplu, dimensiunea calendarului include coloana Julian Period Number
, deoarece simplifică calculele. Este fezabil şi fără Julian Period Number
, dar ar necesita formule mult mai complexe pentru a calcula perioada de timp selectată.
Month
pentru a adăuga variabila pentru prezentare (MonthSelected
).
Julian Period Number
corespunzător şi introduceţi-l în altă variabilă (PeriodNumberSelected
). Acest al doilea prompt nu este afişat utilizatorului final, ci este ascuns în dashboard, iar valoarea este calculată automat pe baza variabilei MonthSelected
.
Julian Period
.
Month
şi utilizaţi funcţiile de filtrare a formulelor coloanei în funcţie de Julian Period Number
, după necesităţi. Iată câteva exemple:
Current Month: Filter("Revenue Metrics"."Revenue" using "Time"."Julian Month Number"=@{PeriodNumberSelected}{80800})
Month Ago: Filter("Revenue Metrics"."Revenue" using "Time"."Julian Month Number"=@{PeriodNumberSelected}{80800}-1)
Year Ago: Filter("Revenue Metrics"."Revenue" using "Time"."Julian Month Number"=@{PeriodNumberSelected}{80800}-12)
Year to date: Filter("Revenue Metrics"."Revenue" using "Time"."Julian Month Number"<=@{PeriodNumberSelected}{80800} and “Time”.”Year”=@{YearSelected}{2019})
Implementarea funcţiilor de filtrare într-un registru de lucru cu parametri
Puteţi aplica acelaşi principiu într-un registru de lucru. Variabile prompturilor şi prezentării sunt înlocuite de un filtru pentru dashboard şi parametri.
Creaţi trei parametri: MonthSelected, PeriodNumberSelected şi YearSelected. Numai parametrul MonthSelected este afişat în canvas într-un filtru de dashboard.
Valorile posibile pentru parametrul MonthSelected sunt definite pe baza unei interogări SQL logice care selectează toate lunile.
Pentru parametrii PeriodNumberSelected şi YearSelected, valorile posibile nu sunt populate.
.jpg
Numai valoarea iniţială este populată, cu o interogare logică filtrată pe baza valorii MonthSelected.
.jpg