Folytatjuk sorozatunkat a LuckyTemplates projekttervezésről és -végrehajtásról. Ezúttal az adatkészlet-tervezésről , a profilalkotásról és a módokról lesz szó . Tekintse meg projekttervezési sorozatunk első részét, amely a következővel foglalkozik, és a második részét, amely arról szól.
Tartalomjegyzék
Adatkészlet tervezés a LuckyTemplates projekt megvalósításához
Beszéljünk az adatkészlet-tervezési folyamatról , és beszéljük meg az adattárház buszmátrixát , amely egy olyan eszköz, amely már régóta létezik.
A teljesítményalapú BI-adatkészletek tervezése hasonló az adattárházak tervezéséhez. Tehát mind az adatkészletek, mind az adattárházak hasonló koncepciókkal rendelkeznek, mint például a tény- és dimenziótáblázatok, a csillagsémák, a lassan változó dimenziók, a ténytábla granularitása és a táblák közötti kapcsolatok kiépítéséhez szükséges helyi információs kulcsok.
4 lépés az adatkészlet tervezéshez
Az adatkészlet-tervezési folyamat négy lépésből áll: válassza ki az üzleti folyamatot , deklarálja a ténytáblázatok szemcséit , azonosítsa a dimenziókat , majd határozza meg a tényeket .
Válassza ki az üzleti folyamatot.
Az első lépésben minden üzleti folyamatot egy ténytáblázat képvisel a dimenziók csillagsémájával.
A felderítési vagy követelménygyűjtési folyamat során nehéz egyetlen üzleti folyamatra elszigetelten összpontosítani, mivel a felhasználók rendszeresen több üzleti folyamatot is elemzik egyidejűleg.
A LuckyTemplates megvalósítás során kerülendő anti-minta
A LuckyTemplates projektekben elkerülendő általános anti-minta (amely egy ismétlődő, általában nem hatékony és potenciálisan kontraproduktív problémára adott válasz) az adatkészletek fejlesztése konkrét projektekhez vagy csapatokhoz, nem pedig az üzleti folyamatokhoz .
Például egy adatkészlet fejlesztése kizárólag a marketingcsapat számára, és egy másik adatkészlet az értékesítési szervezet számára. Ez a megközelítés természetesen erőforrások elpazarlásához vezet, mivel ugyanazok az értékesítési adatok kétszer kerülnek lekérdezésre és frissítésre mindkét adatkészletben. Ezek a LuckyTemplates szolgáltatásban tárolt erőforrásokat is fogyasztanak.
ez néhány ok, amiért jó adatkészlet-tervezési folyamaton szeretne keresztülmenni. Az elszigetelt megközelítés kezelhetőségi és verziókezelési problémákhoz vezet, mivel az adatkészletek változatokat és átalakításokat tartalmazhatnak.
Bár a LuckyTemplates projektek prioritása a felhasználók vagy csapatok elemzési igényei, fontos a fenntartható megoldások tervezése is, amelyek végül megoszthatók a csapatok között.
Kijelenti a gabonát.
A ténytáblák végső soron lefedik az elemző lekérdezések részletezettségi szintjét, valamint az elérhető adatok mennyiségét.
Tehát a nagyobb szemcsésség több részletet jelent, míg az alacsonyabb szemcsésség kevesebb részletet jelent. Példa erre, ha szeretné lekérni az értékesítési rendelés sor szintjét, vagy ha azt szeretné, hogy a projekt csak az egyes értékesítési rendelések összesítő szintjét tartalmazza, és ne térjen le az értékesítés részeként megrendelt konkrét termékekre.
Néha ez a gabona az időkerettől függően változhat. Számos olyan ügyféllel találkoztam, aki nagyon aprólékos ténytáblázatokat szeretne az aktuális negyedévre vonatkozóan, de az előző negyedévekre vonatkozóan csak tudniuk kellett, hogy mekkora volt a negyedév teljes értékesítése.
Ebben a lépésben meg szeretné határozni, hogy a különböző üzleti folyamatok egyes sorai mit képviselnek . Például az adattárházunk értékesítési ténytáblájának minden sora egy vevőtől származó értékesítési rendelés sorát jelöli.
Ezzel szemben az értékesítési és árrésterv sorai egy naptári hónapban, termék-alkategóriában és értékesítési terület régióban lesznek összesítve. tehát ebben az esetben két különböző ténytáblázat és két különböző szemcse van. Ha össze akarja hasonlítani a kettőt, akkor némi adatmodellezési munkával jár.
Határozza meg a méreteket.
A méretek csak az előző tervezési lépésben kiválasztott szem természetes melléktermékei.
Tehát a ténytáblázat egyetlen mintasorában egyértelműen jelezni kell az adott folyamathoz tartozókat, például az egyedi projektet vásárló vevőt, a terméket egy adott napon és időpontban. Az alacsonyabb szemcséket ábrázoló ténytáblázatok kisebb méretűek.
Például egy beszerzési rendelés fejlécszintjét reprezentáló ténytábla azonosíthatja a szállítót, de nem az egyes termékvásárlást a szállítótól. így ebben az esetben nem kell termékkategóriát vagy termékalkategória dimenziót megadnia.
Határozza meg a tényeket.
A tények a ténytáblázatok numerikus oszlopait jelentik. Tehát míg a 3. lépés dimenzióoszlopait a kapcsolatokhoz használják, addig a tényoszlopokat az összesítési logikát tartalmazó mérőszámokban, például egy mennyiségoszlop összegében vagy egy ároszlop átlagában.
Data Bus Matrix a LuckyTemplates projekt megvalósításához
Az adattárház buszmátrix a Ralph Kimball adattárház-architektúra alapeleme, amely növekményes és integrált megközelítést biztosít az adattárház tervezéshez.
Az itt látható architektúra a The Data Warehouse Toolkit 3. kiadásából származik, Ralph Kimballtól. Lehetővé teszi a méretezhető adatmodelleket, amelyekre gyakran több üzleti csapatnak vagy funkciónak van szüksége ahhoz, hogy ugyanazokat az üzleti folyamatokat és dimenziókat érje el.
Hasznos az adattárház buszmátrixának megőrzése. amikor kitölti, tudni fogja, hogy vannak-e más adatkészletek, amelyek hasonló internetes ténytáblákat és dimenziótáblázatokat tartalmaznak. ez elősegíti a projekt újrafelhasználhatóságát és javítja a projekt kommunikációját.
Tehát minden sor egy fontos és ismétlődő üzleti folyamatot tükröz, például a főkönyv havi zárását. minden oszlop egy üzleti entitást jelöl, amely egy vagy több üzleti folyamathoz kapcsolódhat, míg az árnyékolt sorok a projektbe bevont üzleti folyamatot jelölik.
Adatprofilozás a LuckyTemplates megvalósításához
Miután azonosította a szemcsét, és a négy lépésből álló adatkészlet-tervezési folyamat befejeződött, azt azonnal követnie kell a tény- és mérettáblázatok forrásadatainak technikai elemzésének .
A műszaki metaadatok, beleértve az adatbázis-diagramokat és az adatprofilozási eredményeket, elengedhetetlenek a projekttervezési szakaszban.
Ez az információ annak biztosítására szolgál, hogy a Power BI-adatkészlet tükrözze a tervezett üzleti meghatározásokat, és megbízható és megbízható forrásra épüljön.
Tehát három különböző módszer a profilalkotási információk összegyűjtésére, ami az első lépés, amelyet az emberek megtesznek, miután kilépnek a tervezési folyamatból.
SQL Server integrációs szolgáltatások
Ennek több módja is van. Az egyik módszer egy adatprofilozási feladat használata egy SQL Server Integration Services (SSIS) csomagon belül.
Az adatprofilozási feladathoz ADO.NET kapcsolatokra van szükség, és kimenetét XML-fájlba vagy SSIS-változóba írhatja.
Ebben a példában az ADO.NET forrásadata egy AdventureWorks adattárház, adatbázis és SQL-kiszolgáló, a cél pedig egy XML-fájl.
Tehát a feladat végrehajtása után az XML-fájl olvasható az SQL-kiszolgáló adatprofil-nézegetőjén keresztül. Az eredményeket a nullszámláló és a nulla százalékos arányban tekintheti meg.
DAX Stúdió
Az adatprofilalkotás másik módja a DAX Studio. Valójában be kell töltenie az adatokat egy LuckyTemplates adatkészletbe úgy, hogy felkeresi a DAX Studiot, lépjen a Speciális lapra, és futtassa a .
Ugyanazokat az információkat jeleníti meg az oszlopok számossága körül, így tudni fogja, melyek foglalják el a legtöbb helyet az adatmodellben. tartalmazza az adatok körüli összes különféle statisztikát.
LuckyTemplates Desktop
Az adatprofilozás a LuckyTemplates asztali számítógépen található power query-ben is elérhető. ha a Nézet lapra lép , akkor olyan dolgokat kapcsolhat be, mint az oszlopminőség, az oszlopeloszlás és az oszlopprofil. Legalább az első ezer sorban láthatók az olyan információk, mint a hibák, nullák, átlagok és szórások.
Adatkészlet tervezése a LuckyTemplates megvalósításához
A forrásadatok profilozása és a négylépéses adatkészlet-tervezési folyamatban meghatározott követelmények alapján történő kiértékelése után a BI-csapat tovább elemezheti az adatkészlet megvalósítási lehetőségeit.
Szinte minden power BI projektben, még azokban is, amelyek jelentős beruházásokat hajtanak végre a vállalati adatokba, raktárba, architektúrába és ETL-eszközökbe és folyamatokba, bizonyos szintű további logikára, integrációra vagy átalakításra van szükség a forrásadatok minőségének és értékének javításához.
Az adatkészlet-tervezési szakasz meghatározza, hogy az azonosított adatátalakítási problémák hogyan kezelhetők az adatkészlet támogatása érdekében. Ezenkívül a projektcsapatnak meg kell határoznia, hogy importálási módú adatkészletet , közvetlen lekérdezési adatkészletet vagy összetett adatkészletet fejleszt-e ki .
Az adatkészlet tervezési folyamatának tisztázása érdekében ez a diagram azonosítja az adattárház és a LuckyTemplates adatkészlet különböző rétegeit, ahol az átalakítás és az üzleti logika megvalósítható.
egyes projektekben minimális átalakításra van szükség, és könnyen beilleszthető a power BI adatkészletbe. Például, ha csak néhány további oszlopra van szükség egy dimenziótáblához, és egyértelmű útmutatás van ezeknek az oszlopoknak a kiszámításához, az IT-szervezet dönthet úgy, hogy ezeket az átalakításokat M power lekérdezéseken belül hajtja végre az adattárház felülvizsgálata helyett.
Ha a BI-szükségletek és a vállalati adattárház közötti jelentős szakadék fennmarad, akkor a LuckyTemplates-adatkészletek felépítése és karbantartása bonyolultabbá válik.
Az adatkészlet-tervezőknek rendszeresen elemezniük kell és közölniük kell az adatkészletek hatásait, ha az összetettség magasabb.
Ha azonban a szükséges átalakítási logika összetett vagy kiterjedt, több közös művelettel, sorszűrőkkel és adattípus-módosításokkal, akkor az IT-szervezet dönthet úgy, hogy lényeges változtatásokat hajt végre az adattárházban, hogy támogassa az új adatkészletet és a jövőbeli BI-projekteket.
Például szükség lehet egy átmeneti táblára és egy SQL-tároló eljárásra a folyamat támogatásához, felülvizsgálatához és frissítéséhez, vagy index létrehozására lehet szükség a DirectQuery-adatkészletek lekérdezési teljesítményének javításához.
Adatkészlet mód kiválasztása
Az adatkészlet-tervezéssel egy későbbi, de szorosan kapcsolódó lépés az alapértelmezett importálási mód, a DirectQuery/élő mód vagy az összetett mód közötti választás.
Egyes projektekben ez egy egyszerű döntés, ahol az ismert követelmények mellett csak egy lehetőség valósítható meg vagy reális, míg más projektek jelentős elemzést igényelnek az egyes tervek előnyeiről és hátrányairól.
Tehát ha egy adatforrás lassúnak vagy rosszul felszereltnek tekinthető nagy mennyiségű analitikai lekérdezés kezelésére, akkor nagy valószínűséggel az importálási módú adatkészlet a preferált lehetőség.
Hasonlóképpen, ha egy adatforrás közel valós idejű láthatósága elengedhetetlen, akkor a DirectQuery vagy az élő mód az egyetlen lehetőség ennek elérésére. a DirectQuery és az élő mód nagyon hasonlóak egymáshoz. Mindkét módszer nem tárol adatokat magában az adatkészletben, és mindkettő közvetlenül lekérdezi a forrásrendszert az adatok lekéréséhez a felhasználói műveletek alapján. Mostantól rendelkezünk DirectQuery for LuckyTemplates adatkészletekkel és DirectQuery for Analysis Services-szel.
Néhány kérdés, amelyet fel kell tenni az adatkészlet-módok kiválasztásakor
Íme néhány kérdés, amelyeket fel kell tenni, amikor eldönti, melyik módot használja. egyetlen forrás van az adatkészletünkhöz? Ha nincs egyetlen forrás, akkor a múltban nem használhatta a DirectQuery/Live forrást.
Annak ellenére, hogy ma már vannak összetett módú adatkészleteink, még mindig jó kérdést feltenni az elején, mert ha nincs egyetlen forrás, akkor az import vagy összetett lesz.
Ha a DirectQuery/Live forrás egy opció, a forrás képes támogatni az analitikai lekérdezéseket? Ha több milliárd vagy billió sorral dolgozik, akkor lehet, hogy egy importálási módú adatkészlet nem kivitelezhető, és le kell mennie a DirectQuery vagy az összetett módra, hogy megbizonyosodjon arról, hogy az adatkészlet használható.
Ha a DirectQuery/Live forrás képes támogatni a munkaterhelést, akkor a DirectQuery/Live kapcsolat értékesebb, mint az importmodell által biztosított teljesítmény és rugalmasság?
Következtetés
Ez a bejegyzés a LuckyTemplates projektek tervezéséről szóló sorozatot zárja le. szerintem ezek az alapvető lépések minden power BI-projekthez, amelyen dolgozik. Ezek a lépések fontosak az átvilágítás során, különösen vállalati üzleti intelligencia környezetben.
Minden jót,
Greg Deckler
Ebből a blogból megtudhatja, hogyan mentheti automatikusan az e-mail mellékleteket a SharePointba, majd törölheti az e-maileket a Power Automate segítségével.
A Microsoft LuckyTemplates irányítópult 18 legjobb példája 2023
Ismerje meg, hogyan hozhat létre <strong>Power Automate</strong> folyamatokat a semmiből. Sablon használata helyett mi magunk hozzuk létre a kiváltó okokat és a műveleteket.
4 módszer a Pi használatára a Pythonban példákkal
Ebben az útmutatóban bemutatom, hogyan lehet Pénzügyi információk mátrixát létrehozni a Profit és veszteség (P&L) kimutatással a LuckyTemplates alkalmazásban.
Fedezze fel, hogyan lehet dinamikusan egyesíteni oszlopokat a Power Query Table.CombineColumns függvény segítségével.
Ismerje meg, hogyan adhatjuk hozzá és szinkronizálhatjuk SharePoint-fájljainkat az asztalon és a OneDrive-on.
Tudja meg, miért fontos egy dedikált dátumtáblázat a LuckyTemplatesben, és ismerje meg ennek leggyorsabb és leghatékonyabb módját.
Ez a rövid oktatóanyag kiemeli a LuckyTemplates mobil jelentési funkcióját. Megmutatom, hogyan készíthet hatékony jelentéseket mobileszközökön.
Ebben a LuckyTemplates bemutatóban olyan jelentéseket tekintünk át, amelyek professzionális szolgáltatáselemzést mutatnak be egy olyan cégtől, amely több szerződéssel és ügyfél-elkötelezettséggel rendelkezik.
