LuckyTemplates Matrix | A LuckyTemplates mátrixösszegek javítása

Ebben az oktatóanyagban megmutatom, hogyan javíthatja ki a LuckyTemplates mátrix összegeit, különösen a végösszegeket és a részösszegeket, ha a létrehozott mértékek eredetileg nem adják meg a megfelelő eredményeket. Az oktatóanyag teljes videóját a blog alján tekintheti meg.

Két oka van annak, hogy ezzel a problémával foglalkozni akartam. Az egyik az, hogy elég gyakran előfordul. Ez olyasvalami, ami nagyon előkerül a. Látjuk, hogy ez a kérdés újra és újra megismétlődik különböző formákban. A második ok az, hogy ha egy mátrix kontextusában foglalkozunk vele, akkor valószínűleg ez a legnehezebb a törött összegek problémái közül.

Ha megtanulja, hogyan kell kezelni a mátrixban, akkor tudni fogja, mit kell tennie az összegek rögzítéséhez a kártyákon, a táblázatokon és más olyan látványelemeken, ahol az összegek eltörhetnek. Végigmegyek egy szisztematikus folyamaton a LuckyTemplates mátrixösszegeinek rögzítésére, amelyek töredezettek, és valóban lebontják az összetevőkre.

Ebben a példában az intézkedés elég összetett volt ahhoz, hogy meglehetősen látványosan megtörje a végösszegeket. A valóban törött összegekkel akartam kezdeni, hogy megmutassam, hogyan lehet még a legrosszabb törött összesítési problémákat is kijavítani.

Tartalomjegyzék

• Helytelen összegek a LuckyTemplates mátrixban
• A LuckyTemplates mátrix összegeinek javítása SWITCH TRUE logikával
• Hibakeresés a táblázatos szerkesztővel 3
• Következtetés

Helytelen összegek a LuckyTemplates mátrixban

Nézzük meg az intézkedések kontextusát ebben a példában. Először is van egy Spread Revenue nevű mérőszámunk, amely az összes lehetőség bevétele és a keresési skálázási tényező ága .

A teljes lehetőség bevétele csak egy egyszerűmérték, míg a Lookup Scaling Factor egy bonyolultabb, amolyan többkritériumú keresés, amelyet szűrőfeltételek sorozatára alapozunk.

Ez csak egy példa arra, hogy a végösszeg megtörhet. Ha vesszük ezt a Spread Revenue-t, és bedobjuk a mátrix mezőjébe, akkor ez történik (lásd alább).

Mint látható, az alapsorok megfelelően számolnak, de az összes sor nem számítja ki. Sok esetben, ha vannak végösszegei, részösszegei és végösszegei, a LuckyTemplates legalább tippelni fog. És gyakran ez a tipp téves, és javítania kell az összegeket.

De ebben az esetben a LuckyTemplates csak a vállrándítás megfelelőjét adja. Fogalma sincs, mik legyenek ezek az összegek. Még csak sejtése sincs. Csak üresnek címkézi ezeket. Ennek megoldásához fel kell építenünk néhány további logikát, amely megmondja a LuckyTemplatesnek, hogy mit kell tennie a sorösszegekben, az oszlopösszegekben és a végösszegekben.

Sok esetben, amikor több feltételt vizsgál, ezt beágyazottként is megtehetinyilatkozat. De van egy jobb konstrukció a LuckyTemplatesben, amely sokkal könnyebbé teszi a logika áttekintését, ami a nyilatkozat.

A LuckyTemplates mátrix összegeinek javítása SWITCH TRUE logikával

Van egy SWITCH TRUEstatementünk, amely az általánosról a konkrétra épül, és szeretném megmutatni, hogy ez miért nem működik. A SWITCH TRUE utasítás az az, hogy átmegy az összes feltételen. Kilép az elsőből, ami igaz.

És ebben az esetben a tábornoktól indulunk el. Azt mondja, „ha az állatok osztálya monotrémek, erszényesek és méhlepények, akkor megkapja az emlős címkét”. Ebben a példában ez az emlősök egyetlen három osztálya. Ha emlősről van szó, akkor e három típus egyike lesz.

Ha megnézzük, mi történik, akkor bejönnek az adatok, és áttérünk a SWITCH TRUE-re. És ha ez az egyik ilyen osztály, akkor „emlős” lesz. Ez azt jelenti, hogy soha nem fog lemenni ehhez a kritériumhoz, az erszényes állathoz, vagy ahhoz, amit akarunk, ami a kenguru, mert ezek mind emlősök. Tehát, ha ez az állítás igaz, akkor ki fog tűnni.

Ha az állítás nem igaz, akkor a két állítás nem lesz igaz. Az alapértelmezettre fog menni, ami nem emlős. Tehát ahelyett, hogy az általánosból a konkrét felé építkezne, a SWITCH TRUE állítást a konkrétról az általánosra kell felépítenie , majd a végén a mindent összefoglalót.

Ha ezt visszavesszük a mátrixösszegek rögzítésének példájára, akkor valójában ugyanaz a dolog. Az A itt a konkrétumok, ez lesz az első állítás a SWITCH TRUE-ben. És akkor D-t adjuk a fogásnak. Középen ez a két B és C feltétel van. B-nek van kontextusa az oszlophoz, de nem a sorhoz, míg C-ben van kontextusa a sorhoz, de nem az oszlophoz.

Most pedig ugorjunk a Tabular Editor 3-ra (TE3), amely jelenleg a kedvenc módszerem a hibakeresésre és az intézkedések megértésére.

Hibakeresés a táblázatos szerkesztővel 3

Ezt az intézkedést (lent) úgy hívom, hogy a bevétel eloszlása ​​rögzített végösszegekkel. Elég hosszú, és bonyolult DAX-nak tűnik, de ezt komponensenként fogom lebontani.

Itt csak két változót találunk, amelyek alapvetően arövid hónapunkról és időszakunkról, és ez fogja meghatározni a kontextust. Ezután kapunk egy virtuális táblát, ami gyakorlatilag a mátrix virtuális változata ezen keresztülésépíteni.

Ha ezt egy DAX-lekérdezésben nézzük, láthatjuk, hogy alapvetően létrehozza a Period és a Short Month minden lehetséges kombinációját, amit a mátrix csinál.

A Tabular Editor 3-ban van egy másik módja ennek megjelenítésére, az úgynevezett Pivot Grid. Olyan vizualitást hoz létre, amely megegyezik a LuckyTemplates mátrixvizuálisával.

Visszatérve a Kifejezésszerkesztőben mért mértékünkhöz, fel kell építenünk azt a logikát, amely létrehozza az összegező mezőket. És így van ez a SWITCH TRUE kijelentésünk, ahol azt teszteljük, hogy van-e kontextus mind a két mezőben, amelyben kontextusra van szükségünk.

Az első feltétel, amely a legspecifikusabbtól a legkevésbé specifikusig terjed, az A feltétel, az alapsorok. Tehát, ha van kontextusunk az időszakra, és van kontextusunk a rövid hónapra vonatkozóan, akkor csak a Spread Revenue mérőszámot használjuk, mert ez a megfelelő eredményeket produkálta azokban az adatsorokban.

Most meg kell építenünk a B logikáját, ahol az oszlopban kontextus található. Tehát van HASONEVALUE a rövid hónapra, de nem az időszakra. Most erőltetni akarjuk a logikát, vegyük a virtuális mátrixot, és vegyük a Spread Revenue mérőszámunkat, majd összegezzük a periódus összes értékével.

A következő dolog a másik oldal, ahol a HASONEVALUE van a periódusban, de nem a rövid hónapban. Most vesszük aa virtuális tábla (Spread Revenue mérőszám), és összegezzük az összesrerövid hónap.

És végül megkaptuk a mindent átfogó mértéket, vagyis ha nincs kontextus a kettő közül, akkor csak a virtuális tábla teljes összegét vesszük.

Most, ha bevisszük a Rögzített végösszegekkel felszámított bevételt a mezőkbe, és bedobjuk az értékekbe, megkapjuk a megfelelő összegeket a sorösszegekhez, az oszlopösszegekhez és a végösszegekhez. A SWITCH TRUE logika átmegy, és kikényszeríti az összes logikát, amelyre szükségünk van a helyes összegek eléréséhez.

Következtetés

Ebben a blogban megmutattam, hogyan javíthatja ki a helytelen összegeket a LuckyTemplates mátrixban. Ez egy olyan konstrukció, amelyet felhelyezhet egy asztalra vagy egy kártyára, ahol az alapsorok virtuális logikáját építi fel, amely általában akkor működik, ha van megfelelő mértéke. És akkor csak kényszerítse ki azt a logikát, amelyre szüksége van a megfelelő összeg kikényszerítéséhez.

Összetettnek tűnik, de határozottan hasznos. Remélem, ez minden világos. Az alábbiakban megtekintheti a teljes oktatóvideót, és további kapcsolódó tartalmakért tekintse meg a linkeket.

Minden jót!