Kibontott táblázatok a LuckyTemplatesben

Ebben az oktatóanyagban egy nagyon konkrét forgatókönyvet veszünk szemügyre, amellyel biztos vagyok benne, hogy mindannyian találkoztak már a DAX-szal végzett munka során – a kiterjesztett táblázatot . A kibontott táblázatok összezavarhatják a számítást, ha nem tudja, hogyan működnek valójában. Az oktatóanyag teljes videóját a blog alján tekintheti meg.

Ebben a példában a Contoso adatbázist használjuk, amely tartalmazza az értékesítési táblázatot , a vevőtáblát , a dátumtáblázatot , a terméktáblázatot , a termékkategória táblát és a termékek alkategória tábláját .

A bal oldalon egy-a többhez kapcsolat van a termékek, kategória, alkategória és értékesítési táblázatok között. Az ügyfél és az értékesítés, valamint a dátumok és az eladások között egy-a többhez kapcsolatunk is van.

Tartalomjegyzék

• 1. példa
• 2. példa
• Red Sales #1
• Red Sales #2
• Red Sales #3
• Kibontott táblázatok ellenőrzése
• Kiterjesztett táblázatok meghatározása
• A kategóriaoszlop szeletelése és a kibontott táblázatok használata
• A Red Sales magyarázata 2
• A Red Sales magyarázata 3
• A DAX Studio használata a kiterjesztett táblák ellenőrzésére
• Következtetés

1. példa

Tegyük fel, hogy ebből a kategóriaoszlopból szeretnénk jelentést készíteni a kategóriatáblázatban, és olyan mértéket használunk, amely kiszámítja, hogy hány ügyfél van az ügyféltáblázatban. Az ügyfél táblázatának számát kategóriánként szeretnénk felszeletelni.

Ha a kategóriatáblára teszek egy szűrőt, akkor az a szűrő az alkategória táblába kerül, majd a termékek táblájába, majd végül eléri és szűri az értékesítési táblát. De ez a szűrő nem lesz képes szűrni az ügyfél táblázatát, hacsak nem kapcsoljuk be a kétirányú szűrést.

A számítás javításához térjünk vissza a jelentéshez. Ezt a számítást becsomagolhatjuk a CALCULATE függvénybe, majd írhatjuk az Értékesítést. Láthatjuk, hogy ezúttal nem ugyanazt a számot ismételjük a vizualitás minden cellájához.

Annak ellenőrzésére, hogy ez a számítás helyes-e, behozhatjuk a vevőkulcsot az értékesítési táblából az összesítéshez, majd elvégezhetjük a Count (Distinct) értékét.

Láthatja, hogy minden sorhoz ugyanazt az értéket adjuk vissza. A SZÁMÍTÁS függvényen belüli értékesítési táblázat használatával javítani tudtuk a számítást.

2. példa

Térjünk át a következő példára. Ehhez a piros termékek eladási összegét szeretnénk azonosítani 2007-ben, 2008-ban vagy 2009-ben. A szeletelő kiválasztásától függően szintén egy évet szeretnék visszamenni.

Például, ha a 2009-et választom, akkor a 2008-as piros eladásokat szeretném jelenteni. Ha a 2008-at választom, akkor a 2007-es piros eladásokat is szeretnék jelenteni.

Red Sales #1

Összes értékesítésünk számítása alapvetően az értékesítési adatok összege. A sor összefüggésben a mennyiséget megszorozzuk a nettó árral.

Hozzon létre egy új mértéket, és nevezze el Red Sales néven. Azt fogjuk írni, hogy CALCULATE, majd Total Sales. Az Értékesítési táblázathoz megyünk, hogy megmutassuk, hogy a termékek színe megegyezik a pirossal.

Ezután a dátum oszlopba írjuk át a dátumokat.

Ha ezt a számítást egy kártyavizuálban hozzuk létre, üres értéket kapunk.

Red Sales #2

Mi történik itt? Próbáljuk meg újraírni ezt a számítást, és nézzük meg, hogy sikerül-e eredményt elérni. Létre fogunk hozni egy új mértéket, és elnevezzük Red Sales 2-nek, és a számítás első részét használjuk a Red Sales 1-re.

Egy másik SZÁMÍTÁST fogunk kezdeményezni az első CALCULATE helyett.

Vigyük be ezt a mértéket a mátrixba, és nézzük meg az eredményeket. Ha 2008-at választjuk, 51 947-et kapunk. Ha 2009-et választunk, 24 343-at kapunk. Végül, ha 2010-et választunk, 39 724-et kapunk.

Red Sales #3

Van egy másik módja ennek a számításnak. Írunk egy új mértéket, és hívjuk Red Sales 3-nak, majd használjuk a CALCULATE funkciót.

Kiszámoljuk a teljes értékesítést, és felírjuk, hogy a termékek színe megegyezik a pirossal. Ezután használja a SAMEPERIODLASTYEAR funkciót a dátumokon.

Ha behúzzuk a 3. mértéket a kártyavizuálba, láthatjuk, hogy ez a két kártyaérték ugyanazt az értéket adja vissza, ami helyes.

De valami nem stimmel az első számításunkkal, mert üres értéket adunk vissza, és nem a helyes értéket.

Lássuk, mi is történik itt valójában. Most, hogy láttunk néhány számítást a kiterjesztett táblázatokon, értsük meg a mögöttük rejlő elméletet.

Mielőtt megértené, mi az a kiterjesztett tábla, meg kell értenie, hogy az itt található összes táblát alaptáblázatnak nevezzük .

Tehát mikor lesznek ezek a táblák kibontott táblák? Miután létrehoz egy több az egyhez kapcsolatot egy tábla és egy másik tábla között, az alaptábla lesz a kibontott tábla.

Kibontott táblázatok ellenőrzése

De hogyan ellenőrizhetjük, hogy valóban megtörténik-e a táblabővítés? Nos, a kapcsolódó kulcsszót bármelyik táblázaton használhatja. Ha egy oldalról hozzáférhet az oszlophoz, akkor tudni fogja, hogy megtörténhet a táblázat bővítése.

Menjünk az értékesítési táblázathoz, és hozzunk létre egy új számított oszlopot.

Tegyük fel, hogy ehhez a termékkulcshoz szeretnénk lekérni a termék színét a terméktáblázatból. A RELATED-et fogjuk használni, amely csak az IntelliSense oszlopainak listáját adja meg, amelyek ténylegesen bővíthetők az értékesítési táblázatból.

Láthatjuk, hogy a vásárlói tábla és az értékesítési tábla több-az-egy kapcsolata van. Láthatjuk a vevőtáblázatok, a dátumtáblázatok és a termékoszlopok listáját is.

Amikor kiválasztjuk a Termékek[Szín], a RELATED kulcsszó segítségével új oszlopot hozhatunk létre az értékesítési táblázatban. A RELATED csak a tábla azon oszlopaihoz ad hozzáférést, amelyekre az alaptábla ténylegesen kiterjeszthető.

Ha megváltoztatjuk ennek a kapcsolatnak a természetét a sok-egyről a sok-sok kapcsolatra, akkor ez a számítás leáll.

Változtassuk meg ennek a kapcsolatnak a jellegét a sok-sokhoz. Alul láthatjuk, hogy figyelmeztető szimbólumot kapunk.

Amikor visszatérünk az értékesítési táblázathoz, azt a hibaüzenetet látjuk, amely szerint a Termékek [Szín] oszlop vagy nem létezik, vagy nincs kapcsolata egyetlen táblával sem.

A jelenlegi helyzetben a kapott figyelmeztetés nem túl felhasználóbarát. Alapvetően ez azt jelenti, hogy az értékesítési tábla nem bővülhet ki a terméktáblázatba, mert nem tudunk csak egyetlen értéket elérni az adott sorhoz.

És mivel a sok a sokhoz kapcsolatot használjuk, a tábla kibővítése nem történik meg, és a RELATED nem működik.

Térjünk vissza a diagramnézethez, és javítsuk ki ezt a számítást. Módosítjuk a kapcsolat jellegét több az egyhez kapcsolatra, és aktiváljuk ezt a kapcsolatot, hogy a számítás működjön.

Kiterjesztett táblázatok meghatározása

Mielőtt elkezdenénk megvizsgálni a jelentésben már elvégzett számításokat, ismételjük meg a kiterjesztett táblázat definícióját.

Ha van egy csillagsémával rendelkező adatmodell , akkor a ténytábla az adatmodell összes táblájára bővül, ha több az egyhez kapcsolat van a dimenziók és a ténytábla között.

Ha rendelkezik hópehely sémával , akkor a termék alkategória tábla és a kategória táblázat az alaptáblázattá bővül, amely ebben az esetben a termékek táblázata. Az értékesítési táblázat az alaptábla, amely az összes többi asztalra bővül.

A színfalak mögött az értékesítési táblázat összes oszlopa egyetlen táblázatban lesz. Vegye figyelembe, hogy a táblabővítés csak egy logikai fogalom, így nem fogja kiterjeszteni és növelni az adatmodell méretét.

A kibővített tábla csak akkor jelenik meg a képben, ha egy táblára hivatkozik (ami az alaptábla), és ha több az egyhez kapcsolata van más táblákkal.

A kategóriaoszlop szeletelése és a kibontott táblázatok használata

Próbáljuk kijavítani azokat a számításokat, amelyeket a jelentés nézetben már elvégeztünk. Ebben a példában a termékkategória-táblázat kategóriaoszlopa szerint szeletelünk, és megpróbáljuk megszámolni, hogy hány vásárló van.

Szóval mit csinálunk itt valójában? Referenciaként a kibővített értékesítési táblázatot használjuk. Miután a szűrőkontextus tartalmaz egy értéket a kategóriatáblázatból, ez a szűrő az alkategóriás termékekből közvetlenül az értékesítések felé éri el az értékesítési táblázatot.

Mivel az értékesítés egy kibővített tábla, és ezt a hivatkozást használjuk a CALCULATE függvényen belül, így az értékesítési tábla tartalmazza majd a vevőtábla oszlopát is. Amikor szűrőt alkalmazunk az értékesítési táblára, akkor közvetve a vevőtáblát is szűrjük.

Térjünk vissza piros értékesítési számításainkhoz, és próbáljuk megérteni, mi is történik valójában. Kezdjük az üres számítással. Ha ezt a mértéket választjuk, láthatja, hogy beágyazott kódot írunk. Van SZÁMÍTÁS, majd a teljes értékesítés, a SZŰRÉS az eladások felett, és a SAMEPERIODLASTYEAR.

Törjük meg ezt a számítást lépésről lépésre. Először is meg kell határoznunk a számításon kívüli külső szűrőkörnyezetet.

A naptári évszám szeletelőben 2008-at választottuk ki.

Ebből a szűrőkörnyezetből kiértékeli az értékesítési táblázatot. Az értékesítési táblázat csak a 2008-as naptári év sorát tartalmazza, a termék színe pedig piros lesz. Itt két szűrőnk van: az egyik, amelyet a szűrőkörnyezet , a másik pedig a szűrő által jön létre .

A SAMEPERIODLASTYEAR a 2008-as évszámú szűrőkontextusban kerül kiértékelésre. 2008-ban kap egy listát a dátumokról, és ezeket a 2008-as dátumokat 2007-re tolja el. Az így visszaadott táblázat csak azt fogja tartalmazni, hogy a dátumok 2007.

Amint ez a két művelet befejeződött, a CALCULATE függvény előkészíti a szűrőkörnyezetet, és alkalmazza ezt a két szűrőt a szűrőkörnyezetben. Ha ezt alkalmazzuk, akkor a termék színének szűrőkörnyezete megegyezik a pirossal, az év oszlopban pedig egy 2007-es és 2008-as szűrővel.

Tehát ennél az adatmodellnél nincs egyetlen tranzakció, amely két különböző évben létezne. Amikor a CALCULATE megpróbálja összevonni ezt a két szűrőt egy és állapotban, akkor azt fogja mondani, hogy az év 2008 és 2007 legyen, a termék színe pedig piros.

Amikor az értékesítési táblázatot a 2008-as szűrőkontextussal szűrjük, akkor közvetetten a dátumtáblázatot is szűrjük. Az értékesítési istállónak több az egyhez viszonya van a dátumistállóhoz.

Hozzon létre egy új számítást annak meghatározására, hogy hány sor van a dátumtáblázatban a kapcsolódó dátumokhoz. A dátumtáblázatból ezután a CALCULATE-t fogjuk írni. Ezután az ÖSSZES értékesítési táblát SZŰRÜNK, és azt mondjuk, hogy a naptári év számában a KAPCSOLÓDÓ dátumok 2008-mal egyenlőek legyenek.

A CALCULATE-ban nem hivatkoztunk semmilyen szűrőre a dátumtáblázaton. Egyszerűen azt ellenőrizzük, hogy a naptári évszámban szereplő dátumok 2008-ból származzanak. Ideális esetben ez a szűrő nem tudja szűrni a dátumtáblázatot. A függvényt is használjuk, amely figyelmen kívül hagyja a szeletelőből származó szűrőkörnyezetet.

Ehhez a számításhoz hozzunk létre egy új kártyát. láthatja, hogy 348 sort adunk vissza.

Tehát hogyan lehetséges, hogy egy 2500 soros dátumtáblázatból csak 348 sort adunk vissza? Ha kibővített táblát használunk, akkor közvetve szűrjük a másik táblát is, amely több-az-egy kapcsolaton keresztül kapcsolódik.

Noha nincs szűrőnk az aktuális évre vonatkozóan, továbbra is korlátozzuk az egyik oldalon található dimenziótáblázatban látható sorok számát.

Az értékesítési táblázat visszaküldésekor a dátumtáblázat, a vevőtáblázat, a terméktáblázat, a termékkategória táblázat és a termék alkategória táblázat szűrt változatát is visszaküldjük.

A Red Sales magyarázata 2

Térjünk át a következő számításra, ami a Red Sales 2. Kezdjük a külső CALCULATE-vel, mert ha bármilyen forgatókönyvben beágyazzuk ezt a függvényt, akkor a külső CALCULATE készítse elő a szűrőkörnyezetet a belső CALCULATE számára.

A szeletelőn kiválasztjuk a 2008-as naptári évet. Amikor a SAMEPERIODLASTYEAR függvény megkapja a 2008-as dátumot, 2007-ben el fogja tolni ezeket a dátumokat, és ez lesz a SZŰRŐ környezet a belső számításhoz. Ez a belső SZÁMÍTÁS a 2007-es évet fogja értékelni.

A SZŰRŐ funkció kiszűri az értékesítési táblát, és az értékesítési tábla csak arra a sorra lesz korlátozva, ahol az évszám 2007. Miután megvannak a 2007-es sorok, ellenőrizzük, hogy a kapcsolódó termékek megegyeznek-e a pirossal.

Az első számítással ellentétben nem két különböző szintet adunk vissza. Ez a két különböző szint nem kerül alkalmazásra a SZŰRŐ kontextusban, így a FILTER függvény által visszaadott tábla tartalmazza az értékesítési tábla összes sorát.

A szűrő alkalmazása után megkapjuk a 2007-es eladási összeget, valamint a pirossal megegyező termékeket, míg az első számításban a 2008-as és 2007-es évet adtuk vissza.

Ezúttal a SAMEPERIODLASTYEAR függvény használatával és a CALCULATE függvény beágyazásával egy másik CALCULATE-be készítettük el az értékesítési tábla szűrőkontextusát.

A Red Sales magyarázata 3

A harmadik példában van egy nagyon egyszerű CALCULATE függvényünk, amely két állítást tartalmaz: az egyik a termék színe egyenlő a pirossal, majd a SAMEPERIODLASTYEAR a dátumokon.

A SAMEPERIODLASTYEAR függvény egy szűrőkontextusban kerül kiértékelésre, amely csak a 2007-es dátumokat tartalmazza. A termékek színe piros szűrőkontextust alkalmaz a terméktáblázaton, ami viszont szűri az értékesítési táblázatot, és csak a következő sorokat tartalmazza. a piros termékek.

Ha ezt a két értéket alkalmazza a szűrőkontextusban, akkor az értékesítési táblát szűrik, a kibontott értékesítési táblát nem. láthatja, hogy a kódban sehol nem hivatkoztunk a kiterjesztett értékesítési táblázatra.

Ez az ideális forgatókönyv, amelyet akkor érdemes használni, ha a kibővített táblázatra próbál hivatkozni. A kibővített táblázat használatakor a számítások nagyon bonyolulttá válhatnak, és néha nem tudja azonosítani, hogy a számítások miért adnak hibás eredményt.

Ha nem érti a kiterjesztett táblák fogalmát, akkor fejlesztheti ezt a kódot modellmértékként, majd üzembe helyezheti az éles környezetben. Előfordulhat, hogy más felhasználók más mértékeket hoznak létre ezen a mértéken keresztül, és előfordulhat, hogy nem tudják kitalálni, hogy miért nem működnek a számítások, mert egyszerűen nem rendelkeznek ilyen szintű megértéssel a DAX nyelvről.

Ha DAX-szal dolgozik, mindig próbálja meg egyetlen oszlop fölé helyezni a szűrőt, mert ha egyetlen oszlopot használ, a kiterjesztett táblák koncepciója nem érvényesül. Például, amikor a TERMÉKEK [Szín] = „Piros” értéket használja , a szűrő eléri az értékesítési táblázatot, de ez a szűrő nem tudja elérni az ügyfél asztalát, mert nem a kibontott értékesítési táblát használjuk.

Egy oszlop használatakor nem hivatkozunk a kiterjesztett táblák fogalmára. Egyszerűen egy alapszűrőt alkalmazunk az értékesítési táblára, amely nem terjed át a többi táblára.

A DAX Studio használata a kiterjesztett táblák ellenőrzésére

Mielőtt befejeznénk, a DAX Studio segítségével ellenőrizzük a Red Sales 3 kódunkat. Menjünk a Nézet fülre, kattintsunk a Performance Analyzer-re, majd indítsuk el a felvételt. Frissítjük a képet, és kiválasztunk egy üres kártyát.

A külső eszközök közül elindítjuk a DAX stúdiót

Láthatjuk, hogy az eredmény képernyő alján egy ürességet kapunk.

Bekapcsoljuk a szerveridőzítést, hogy megértsük a színfalak mögött generált lekérdezéseket. Lépjünk a Kiszolgálóidőzítések fülre, és bontsa ki, hogy mindent lásson.

A bal oldali eladó asztalon JOIN-t végzünk. A terméktáblázat termékkulcsán is végrehajtunk egy JOIN-t.

A WHERE záradékban kimondja, hogy a naptári évszámban szereplő dátumok 2008-mal egyenlőek, és a termék színe piros legyen.

Ezután van egy másik feltételünk, amely azt mondja, hogy Dátumok[Dátum], majd ezt követi egy dátumtartomány. Szóval mik ezek a dátumok? Ideális esetben ezeknek a dátumoknak 2008-hoz kell tartozniuk, de 2007-ből származnak, amikor megváltoztatjuk ezeknek a számoknak a formázását az Excelben.

Ezért üres értéket adunk vissza. Azt mondjuk, hogy a naptári évnek 2008-nak kell lennie, és alkalmazunk egy ÉS feltételt, hogy a dátumok 2007-ben legyenek. Ez a 2007-es év a számítás során használt SAMEPERIODLASTYEAR függvény miatt van.

Változtassuk meg a mértéket és a hivatkozást a Red Sales 2-re. A kód végrehajtása után láthatjuk, hogy a dátumtáblázatból kapjuk a dátumokat, majd a dátumok oszlopot a 2008-as naptári évszámra szűrjük.

Ezúttal azért tudunk eredményt visszaadni, mert nem alkalmazunk szűrőt a WHERE záradékra, és azt mondjuk, hogy a naptári év számában szereplő dátumoknak 2008-cal kell megegyezniük.

Következtetés

Remélhetőleg ez az oktatóanyag segített megérteni, mi az a kiterjesztett táblázat, és hogyan ronthatja el a számításait. A kiterjesztett táblázatok nem igazán intuitívak, és nem is könnyen érthetők.

A kibővített asztalokkal kapcsolatos további információkért ne felejtsen el előfizetni a LuckyTemplates TV csatornára. Rengeteg tartalom jön ki folyamatosan tőlem és egy sor tartalomkészítőtől, mindannyian elkötelezettek a LuckyTemplates és a Power Platform használatának javításáért.