DAX heti számítások – A LuckyTemplates időintelligencia-problémák

A mai oktatóanyagban néhány technikát és tippet adok a DAX heti részletessége által okozott gyakori problémák kezelésére az időintelligencia számításokban. Az oktatóanyag teljes videóját a blog alján tekintheti meg.

Nemrég készítettem egy oktatóprogramot az előző heti értékek megszerzéséről a LuckyTemplatesben. Azóta számos kérdésem van az időintelligenciával kapcsolatban, és különösen a DAX heti értékeivel kapcsolatban. Ez nem meglepő, mert a hetek valóban a legrosszabbul viselkedett szemcsésség az időintelligencia szférában.

Hónapok esetén mindig 12 hónapja van egy évben. A negyedek esetében mindig négy negyed van. A hetek azért különböznek egymástól, mert egy hétben hét nap, egy évben 52 hét van – ez 364 nap. Szóval, az a plusz nap ott van. Szökőévekben két extra napod van.

Tehát ez néhány év múlva az ISO hét számának számozási séma alapján néha 52 hetet, néha 53 hetet eredményez. Az 53. hét okozza a legtöbb problémát.

Tartalomjegyzék

• A heti DAX-számítás időintelligencia-problémái
• Következtetés

A heti DAX-számítás időintelligencia-problémái

Ebben a példában a teljes azonnali árat használom. Az összesítéssel könnyebb elképzelni és beszélni.

Ebben az esetben minden évhez meg akarunk mutatni egy sort az 53. héthez, függetlenül attól, hogy volt-e 53. hét abban az évben vagy sem. Látható tehát, hogy 2018-ban és 2019-ben nincs 53. hét, 2020-ban viszont igen. Szeretnénk egységessé tenni, hogy minden évben az 53. sor kerüljön be. De akkor a mérőszám üres lenne azoknál az éveknél, amikor nem volt 53. év.

Ennek egyik gyakori módja az, hogy adat nélküli elemeket jelenítünk meg , és ellenőrizzük, hogy be van-e kapcsolva. Ebben az esetben be van kapcsolva, de ez nem segít, mert ez működik, ha van egy fizikai sor, de nincs hozzá társított adat. Ebben az esetben még a sor sem áll rendelkezésünkre.

Olyan technikák, mint a használatvagy A szűrők eltávolítása nem fog működni, mert nincs mit eltávolítani. Az adott sorban lévő szűrő egyszerűen nem létezik. Tehát a kérdés az, hogyan illesztjük be ezt a sort minden olyan évbe, amelyben nem létezik? És akkor ez valóban adatmodellezési problémává válik.

Az egyik lehetséges dolog, amit megtehetünk, hogy egy hópehely-sémát alkalmazunk, ahol a Dátumok táblázatot olyasmi alapján szűrjük, amely minden évben az 53. hetet a vizualizációnkba kényszeríti. A függvény, ami erről eszembe jut, az.

A CROSSJOIN két olyan mező párosítására szolgál, amelyeknek lehet, hogy nincs kapcsolata. Nem kell kapcsolatuk, ellentétben a legtöbb ill, vagy más táblázatfüggvények.

Ebben az esetben a CROSSJOIN két oszlopot vesz fel, és ennek a két oszlopnak minden kombinációját létrehozza, függetlenül attól, hogy létezik-e az adatkészletben vagy sem. Pontosan ezt akarjuk.

Létre kell hoznunk egy táblázatot az oszlopból. A CROSSJOIN két táblázatot vesz fel, majd az ISO-hétszámon a VALUES-t, és ezeket csak párosítjuk. Ez minden évben 53 hetet ad nekünk.

Ezután hozzáadunk egy harmadik oszlopot a táblázathoz. Ezt megtehetnénk a Power Queryben, de egyszerűbb megmutatni a logikát a DAX-ban. Amit itt csinálunk, az az, hogy az évet egy kötőjellel kapcsoljuk össze, majd a hét számát, így van egy kulcsmezőnk, amely a Dátumok táblázathoz illeszthető.

Itt azonban egy kicsit többet kell dolgoznunk, mert a Dátumok táblában a kulcsmező úgy működik, hogy egy négyjegyű Év kötőjel, majd egy kétjegyű hét. Tehát azokban az esetekben, amikor az ISO hét száma két számjegyből áll, elvégezhetjük az egyszerű összefűzést. Azokban az esetekben, amikor ez egy számjegy, vegyük az évszámot, majd kötőjellel, majd egy kezdő nullával, majd a hét számával fűzzük össze.

Ha ez megvan, használhatjuk a táblázatot az adatmodellben, és megkereshetjük a Hét és év oszlopunkat. Aztán csatlakozunk hozzájuk egy-a-többhöz viszonyban. Mindig szeretem ezt az opciót bekapcsolni a kapcsolódó mezők rögzítése a kártya tetejére , hogy ha ellenőrizzük, azonnal láthassuk.

Ha visszatérünk a látványhoz, meg kell változtatnunk a sorokat. Az Év és hét száma helyett a CROSSJOIN tábla Év és hét számát szeretnénk használni. És most megvan az 53. hét 2018-ban üresen, és az 53. hét 2019-ben üresen hagyva. 2020-ban van egy tényleges számunk, mivel az 53. hét.

Itt meg is állhatnánk, kivéve azt a tényt, hogy most kiléptünk a Star Schema modellből. Valahányszor eltávolodsz a LuckyTemplates Csillagsémájától, kívülre kerülsz az általában bevált gyakorlatnak tartott gyakorlaton.

Tehát a Snowflake Schema esetében ez nem jelent hatalmas szabálysértést. Vannak esetek, amikor mindenképpen érdemes használni, de ha el tudod kerülni, próbáld meg. Csökkenti a párhuzamosságot, de nem feltétlenül a méretet. Lehetővé teszi az egyenes számlálási mérőszámok használatát, de vannak teljesítményproblémák és potenciális használhatósági problémák, és határozottan növekszik a DAX bonyolultsága. Megakadályozza a táblák közötti hierarchiák felépítését, és valószínűleg az a legproblémásabb, hogy valóban összezavarhatja a szeletelők szinkronizálását a különböző mezők között.

Tehát bár ez megoldja a problémát, ez nem túl jó módon történik. Lássuk, tudunk-e ennél jobbat csinálni. Ugorjunk át egy másik adatmodellbe. Ebben a modellben pontosan ugyanazokat az adatokat, a dátumokat és az azonnali árat vettem, de ezúttal eltávolítottam a CROSSJOIN táblát. Még mindig létezik, de nincs csatlakoztatva.

De ha megnézzük a DAX-ot, látni fogjuk, hogy pontosan ugyanaz a DAX, amelyik létrehozta azt a táblát a másik jelentésben. Tehát ahelyett, hogy fizikai kapcsolatban kapcsolnánk össze, majd megszegnénk a csillagsémát, és azt Hópehely sémává alakítanánk, fenntarthatjuk a csillagsémát, és csak virtuális kapcsolatot használhatunk.

Ehhez egy függvényt fogunk használni. Létrehozza ezt a kapcsolatot a táblák között, de virtuálisan. Ezt azért használjuk, mert megváltoztatjuk a kontextust. Ebben az esetben a kontextus a kapcsolatra vonatkozik. Tehát megvan a teljes azonnali árunk, majd a TREATAS. Az oszlopot táblázattá kell alakítanunk.

Aztán itt van az Év és hét mező, ami az általunk létrehozott kulcs. Ezt virtuálisan összekapcsoltuk a hét és év elemmel a Dátumok táblázatban. Tehát most megkaptuk azt a Crossjoint táblát, amely ugyanúgy szűri a Dátumok táblát, mint amikor fizikai kapcsolatunk volt, de a csillagséma megsértése nélkül.

Most már felvehetjük a mátrixba azt a Total Spot Price TREATAS-t, és amit látunk, az pontosan ugyanaz a végösszeg. Ily módon ezt úgy tettük meg, hogy nem bontottuk meg adatmodellünket, és nem tapasztaltuk meg azokat a hátrányokat, amelyekről a Snowflake Schema kapcsán beszéltünk.

Következtetés

Ebben az oktatóanyagban bemutattam néhány módszert a DAX heti számítási probléma megoldására a LuckyTemplates alkalmazásban. Az egyik a CROSSJOIN használata, de van néhány hátránya. A második módszer a TREATAS használata, virtuális kapcsolat létrehozása és a Star Schema megközelítés megsértése.

Ez az egyik technika, amely nagyon hasznos az 53. heti probléma kezelésében. Remélem hasznosnak találtad. Szeretném tudni a gondolatait erről. Tudassa velem az alábbi megjegyzésekben.

Minden jót,