Adatlekérési útmutató lapszámozott jelentésekhez

  • Cikk

Ez a cikk többoldalas Power BI-jelentéseket tervező jelentéskészítőként szolgál. Javaslatokat nyújt a hatékony és hatékony adatlekérés megtervezéséhez.

Adatforrástípusok

A többoldalas jelentések natív módon támogatják a relációs és az elemzési adatforrásokat is. Ezek a források tovább vannak kategorizálva, felhőalapú vagy helyszíniként. A helyszíni adatforrásokhoz – akár helyszíni, akár virtuális gépen üzemeltetett – adatátjáróra van szükség, hogy a Power BI csatlakozni tud. A felhőalapú szolgáltatás azt jelenti, hogy a Power BI közvetlenül internetkapcsolattal tud csatlakozni.

Ha kiválaszthatja az adatforrás típusát (esetleg egy új projekt esetében), javasoljuk, hogy felhőalapú adatforrásokat használjon. A többoldalas jelentések kisebb hálózati késéssel tudnak csatlakozni, különösen akkor, ha az adatforrások ugyanabban a régióban találhatók, mint a Power BI-bérlő. Emellett az egyszeri bejelentkezés (SSO) használatával is csatlakozhat ezekhez a forrásokhoz. Ez azt jelenti, hogy a jelentésfelhasználó identitása áramolhat az adatforrásba, lehetővé téve a felhasználónkénti sorszintű engedélyek kikényszerítését. Az egyszeri bejelentkezés jelenleg csak a helyszíni SQL Server- és Oracle-adatforrásokhoz támogatott (lásd a Többoldalas Power BI-jelentések támogatott adatforrásait).

Feljegyzés

Bár jelenleg nem lehet SSO használatával csatlakozni a helyszíni adatbázisokhoz, továbbra is kényszerítheti a sorszintű engedélyeket. Ez úgy történik, hogy átadja a UserID beépített mezőt egy adathalmaz-lekérdezési paraméternek. Az adatforrásnak úgy kell tárolnia a felhasználónév (UPN) értékeit, hogy megfelelően szűrhesse a lekérdezés eredményeit.

Tegyük fel például, hogy az egyes értékesítők egy sorként vannak tárolva a Salesperson táblában. A tábla oszlopokat tartalmaz az UPN-hez és az értékesítő értékesítési régiójához. Lekérdezéskor a táblázatot a jelentésfelhasználó UPN-je szűri, és egy belső illesztés használatával kapcsolódik az értékesítési adatokhoz is. Így a lekérdezés hatékonyan szűri az értékesítési ténysorokat a jelentésfelhasználó értékesítési régiójának soraihoz.

Relációs adatforrások

A relációs adatforrások általában jól illeszkednek az üzemeltetési stílusú jelentésekhez, például az értékesítési számlákhoz. Olyan jelentésekhez is alkalmasak, amelyeknek nagyon nagy adathalmazokat kell lekérniük (több mint 10 000 sort). A relációs adatforrások tárolt eljárásokat is meghatározhatnak, amelyeket jelentésadatkészletek hajthatnak végre. A tárolt eljárások számos előnnyel járnak:

  • Paraméterezése
  • A programozási logika beágyazása, amely összetettebb adatelőkészítést tesz lehetővé (például ideiglenes táblák, kurzorok vagy skaláris, felhasználó által definiált függvények)
  • Továbbfejlesztett karbantarthatóság, amely lehetővé teszi a tárolt eljáráslogika egyszerű frissítését. Bizonyos esetekben a lapszámozott jelentések módosítása és ismételt közzététele nélkül is elvégezhető (az oszlopnevek és adattípusok változatlanok maradnak).
  • Jobb teljesítmény, mivel a végrehajtási tervek gyorsítótárazva vannak az újrafelhasználáshoz
  • Tárolt eljárások újrafelhasználása több jelentésben

A Power BI Jelentéskészítő a relációs lekérdezéstervezővel grafikusan létrehozhat egy lekérdezési utasítást, de csak Microsoft-adatforrásokhoz.

Elemzési adatforrások

Az analitikus adatforrások – más néven adatmodellek vagy csak modellek – jól használhatók mind a működési, mind az elemzési jelentésekhez, és gyors összegzett lekérdezési eredményeket biztosítanak még nagyon nagy adatmennyiségeken is. A modellmunkák és KPI-k összetett üzleti szabályokat foglalnak össze az adatok összegzéséhez. Ezek az adatforrások azonban nem alkalmasak olyan jelentésekre, amelyeknek nagy mennyiségű adatot kell lekérniük (több mint 10 000 sort).

A Power BI Jelentéskészítő két lekérdezéstervező közül választhat: az Analysis Services DAX lekérdezéstervezője és az Analysis Services MDX lekérdezéstervezője. Ezek a tervezők használhatók Power BI szemantikai modell (korábbi nevén adathalmaz) adatforrásokhoz, vagy bármely SQL Server Analysis Services- vagy Azure Analysis Services-modellhez – táblázatos vagy többdimenziós.

Javasoljuk, hogy a DAX-lekérdezéstervezőt használja, feltéve, hogy teljes mértékben megfelel a lekérdezési igényeknek. Ha a modell nem határozza meg a szükséges mértékeket, lekérdezési módra kell váltania. Ebben a módban a lekérdezési utasítást kifejezésekkel szabhatja testre (összegzés megvalósításához).

Az MDX-lekérdezéstervező megköveteli, hogy a modell mértékeket tartalmazzon. A tervezőnek két képessége van, amelyeket a DAX-lekérdezéstervező nem támogat. Pontosabban a következőt teszi lehetővé:

  • Lekérdezésszintű számított tagok definiálása (MDX-ben).
  • Adatrégiók konfigurálása kiszolgálói aggregátumok kéréséhez nem részletes csoportokban. Ha a jelentésnek fél- vagy nem additív mértékeket (például időintelligencia-számításokat vagy eltérő darabszámokat) kell bemutatnia, akkor valószínűleg hatékonyabb lesz a kiszolgálói aggregátumok használata, mint az alacsony szintű részletes sorok lekérése és a jelentés számítási összegzései.

Lekérdezés eredményének mérete

Általában ajánlott csak a jelentéshez szükséges adatokat lekérni. Ezért ne kérje le azokat az oszlopokat vagy sorokat, amelyeket a jelentés nem igényel.

A sorok korlátozásához mindig a legkorlátozóbb szűrőket kell alkalmaznia, és összesítő lekérdezéseket kell meghatároznia. A lekérdezések csoportosítása és a forrásadatok összegzése a nagyobb szemcsés eredmények lekéréséhez. Tegyük fel például, hogy a jelentésnek az értékesítői értékesítések összegzését kell bemutatnia. Az összes értékesítési rendelési sor beolvasása helyett hozzon létre egy adatkészlet-lekérdezést, amely üzletkötők szerint csoportosítja, és összegzi az egyes csoportok értékesítéseit.

Kifejezésalapú mezők

A jelentésadatkészletek kifejezésen alapuló mezőkkel bővíthetőek. Ha például az adatkészlet az ügyfél utónevét és vezetéknevét adja meg, érdemes lehet egy olyan mezőt használni, amely összefűzi a két mezőt az ügyfél teljes nevének előállításához. A számítás elvégzéséhez két lehetősége van. A következőket teheti:

  • Hozzon létre egy számított mezőt, amely egy kifejezésen alapuló adathalmazmező.
  • Adjon meg egy kifejezést közvetlenül az adathalmaz-lekérdezésbe (az adatforrás natív nyelvének használatával), amely egy normál adathalmazmezőt eredményez.

Az utóbbi lehetőséget javasoljuk, amikor csak lehetséges. Két jó oka van annak, hogy a kifejezések közvetlenül az adathalmaz-lekérdezésbe való beszúrása jobb:

  • Lehetséges, hogy az adatforrás úgy van optimalizálva, hogy hatékonyabban értékelje ki a kifejezést, mint a Power BI (különösen a relációs adatbázisok esetében).
  • A jelentés teljesítménye javul, mivel a Power BI-nak nem kell számított mezőket létrehoznia a jelentés renderelése előtt. A számított mezők jelentősen megnövelhetik a jelentésmegjelenítési időt, amikor az adathalmazok nagy számú sort kérnek le.

Mezőnevek

Adathalmaz létrehozásakor a rendszer automatikusan elnevezi a mezőket a lekérdezésoszlopokról. Lehetséges, hogy ezek a nevek nem barátságosak vagy intuitívak. Az is lehetséges, hogy a forrás lekérdezés oszlopnevei a jelentésdefiníciós nyelv (RDL) objektumazonosítóiban (például szóközökben és szimbólumokban) tiltott karaktereket tartalmaznak. Ebben az esetben a tiltott karaktereket aláhúzásjelre (_) cseréli a rendszer.

Javasoljuk, hogy először győződjön meg arról, hogy minden mezőnév barátságos, tömör, mégis értelmes. Ha nem, javasoljuk, hogy nevezze át őket a jelentés elrendezésének megkezdése előtt . Ennek az az oka, hogy az átnevezett mezők nem változnak át a jelentéselrendezésben használt kifejezéseken. Ha a jelentés elrendezésének megkezdése után úgy dönt, hogy átnevezi a mezőket, meg kell keresnie és frissítenie kell az összes hibás kifejezést.

Szűrés és paraméter

Valószínű, hogy a lapszámozott jelentéstervek jelentésparaméterekkel fognak rendelkezni. A jelentésparaméterek gyakran arra kérik a jelentés felhasználóját, hogy szűrje a jelentést. Többoldalas jelentéskészítőként kétféleképpen érheti el a jelentésszűrést. A jelentésparamétert a következőre képezheti le:

  • Adathalmazszűrő, amely esetben a jelentésparaméter(ek) az adathalmaz által már lekért adatok szűrésére szolgálnak.
  • Adathalmazparaméter, amely esetben a jelentésparaméter(ek) az adatforrásnak küldött natív lekérdezésbe lesznek injektálva.

Feljegyzés

Minden jelentésadatkészlet munkamenetenként gyorsítótárazva van, legfeljebb 10 percig, a legutóbbi használatuk után. Az adatkészletek újra felhasználhatók új paraméterértékek beküldésekor (szűrés), a jelentés más formátumban való renderelése vagy a jelentésterv valamilyen módon történő kezelésekor, például a láthatóság vagy a rendezés összesítésekor.

Ezután vegyük példaként azt az értékesítési jelentést, amely egyetlen jelentésparaméterrel rendelkezik a jelentés egyetlen év szerinti szűréséhez. Az adatkészlet minden évre lekéri az értékesítéseket. Ez azért van így, mert a jelentésparaméter az adathalmaz szűrőire van leképezésre. A jelentés a kért év adatait jeleníti meg, amely az adathalmaz adatainak egy részhalmaza. Amikor a jelentés felhasználója egy másik évre módosítja a jelentésparamétert , majd megtekinti a jelentést, a Power BI-nak nem kell forrásadatokat lekérnie. Ehelyett egy másik szűrőt alkalmaz a már gyorsítótárazott adatkészletre. Az adathalmaz gyorsítótárazása után a szűrés nagyon gyors lehet.

Most fontolja meg egy másik jelentéstervet. A jelentésterv ezúttal az értékesítési év jelentésparaméterét egy adathalmazparaméterre képezi le. Így a Power BI beszúrja az év értékét a natív lekérdezésbe, és az adatkészlet csak az adott évre vonatkozóan kér le adatokat. Minden alkalommal, amikor a jelentés felhasználója módosítja az év jelentésparaméterének értékét – majd megtekinti a jelentést –, az adatkészlet éppen arra az évre vonatkozóan kér le egy új lekérdezési eredményt.

Mindkét tervezési módszer képes szűrni a jelentésadatokat, és mindkét terv jól használható a jelentéstervekhez. Az optimalizált kialakítás azonban az adatok várható mennyiségétől, az adatingadozástól és a jelentésfelhasználók várható viselkedésétől függ.

Az adathalmaz-szűrést akkor javasoljuk, ha előre látható, hogy az adathalmazsorok egy másik részhalmaza többször is újra felhasználva lesz (így időt takaríthat meg a rendereléshez, mert nem kell új adatokat beolvasni). Ebben a forgatókönyvben felismerheti, hogy a nagyobb adathalmazok lekérésének költsége azzal a hányszor lesz újra felhasználható. Ezért hasznos az olyan lekérdezések esetében, amelyek létrehozása időigényes. Ügyeljen azonban arra, hogy a nagy adathalmazok felhasználónkénti gyorsítótárazása negatív hatással lehet a teljesítményre és a kapacitás átviteli sebességére.

Az adathalmaz paraméterezését akkor javasoljuk, ha előre látható, hogy nem valószínű, hogy az adathalmazsorok egy másik részhalmaza lesz kérve – vagy ha a szűrni kívánt adathalmazsorok száma valószínűleg nagyon nagy (és nem hatékony a gyorsítótárazáshoz). Ez a kialakítási megközelítés akkor is jól működik, ha az adattár változékony. Ebben az esetben minden jelentésparaméter értékének módosítása a naprakész adatok lekérését eredményezi.

Nem natív adatforrások

Ha többoldalas jelentéseket kell fejlesztenie olyan adatforrások alapján, amelyeket nem támogatnak natív módon a lapszámozott jelentések, először ki kell dolgoznia egy adatmodellt a Power BI Desktopban. Így több száz , a Power BI által támogatott adatforráshoz csatlakozhat. Miután közzétette a Power BI szolgáltatás, létrehozhat egy lapszámozott jelentést, amely csatlakozik a Power BI szemantikai modelljéhez.

Adatintegráció

Ha több adatforrásból származó adatokat kell kombinálnia, két lehetősége van:

  • Jelentésadatkészletek egyesítése: Ha az adatforrásokat a lapszámozott jelentések natív módon támogatják, érdemes lehet olyan számított mezőket létrehozni, amelyek a Keresési vagy a LookupSet Jelentéskészítő függvényeket használják.
  • Power BI Desktop-modell fejlesztése: Valószínűleg hatékonyabb azonban, ha adatmodellt fejleszt a Power BI Desktopban. A Power Query használatával bármilyen támogatott adatforráson alapuló lekérdezéseket kombinálhat. Miután közzétette a Power BI szolgáltatás, létrehozhat egy lapszámozott jelentést, amely csatlakozik a Power BI szemantikai modelljéhez.

Hálózati késleltetés

A hálózati késés hatással lehet a jelentések teljesítményére azáltal, hogy növeli a kérések Power BI szolgáltatás való eléréséhez és a válaszok kézbesítéséhez szükséges időt. A Power BI-bérlők egy adott régióhoz vannak rendelve.

Tipp.

A bérlő tartózkodási helyére a Hol található a Power BI-bérlő?

Amikor egy bérlő felhasználói hozzáférnek a Power BI szolgáltatás, a kéréseik mindig erre a régióra irányítják. Amikor a kérések elérik a Power BI szolgáltatás, a szolgáltatás további kéréseket küldhet – például az alapul szolgáló adatforrásnak vagy egy adatátjárónak –, amelyek szintén hálózati késésnek vannak kitéve. Általánosságban elmondható, hogy a hálózati késés hatásának minimalizálása érdekében törekedjen arra, hogy az adatforrások, az átjárók és a Power BI-kapacitás a lehető legközelebb legyen. Lehetőleg ugyanabban a régióban találhatók. Ha a hálózati késés problémát jelent, próbálja meg közelebb helyezni az átjárókat és az adatforrásokat a Power BI-kapacitáshoz úgy, hogy a felhőben üzemeltetett virtuális gépeken helyezi el őket.

AZ SQL Server összetett adattípusai

Mivel az SQL Server egy helyszíni adatforrás, a Power BI-nak átjárón keresztül kell csatlakoznia. Az átjáró azonban nem támogatja az összetett adattípusok adatainak lekérését. Az összetett adattípusok közé tartoznak a beépített típusok, például a GEOMETRY és a GEOGRAPHY térbeli adattípusok, valamint a hierarchia. A Microsoft.NET-keretrendszer közös nyelvi futtatókörnyezetben (CLR) egy szerelvény egy osztályán keresztül implementált, felhasználó által definiált típusokat is tartalmazhatnak.

A térbeli adatok és elemzések térképvizualizációban való ábrázolásához SQL Server térbeli adatokra van szükség. Ezért nem használható a térképvizualizáció, ha az SQL Server az adatforrás. Az egyértelműség érdekében működni fog, ha az adatforrása Azure SQL Database, mert a Power BI nem átjárón keresztül csatlakozik.

A képek segítségével emblémákat vagy képeket adhat hozzá a jelentés elrendezéséhez. Ha a képek a jelentésadatkészlet által lekért sorokhoz kapcsolódnak, két lehetőség közül választhat:

  • Lehetséges, hogy a rendszerképadatok is lekérhetők az adatforrásból (ha már egy táblában tárolták).
  • Amikor a rendszerképeket webkiszolgálón tárolja, dinamikus kifejezéssel hozhatja létre a kép URL-címét.

További információkért és javaslatokért tekintse meg a lapszámozott jelentések képekkel kapcsolatos útmutatóját.

Redundáns adatlekérés

Lehetséges, hogy a jelentés redundáns adatokat kér le. Ez akkor fordulhat elő, ha adathalmaz-lekérdezésmezőket töröl, vagy ha a jelentés nem használt adatkészleteket tartalmaz. Kerülje ezeket a helyzeteket, mivel ezek szükségtelen terhet rónak az adatforrásokra, a hálózatra és a Power BI-kapacitás erőforrásaira.

Törölt lekérdezésmezők

Az Adathalmaz tulajdonságai ablak Mezők lapján törölheti az adathalmaz lekérdezési mezőit (a lekérdezésmezők az adathalmaz-lekérdezés által lekért oszlopokra vannak megfeleltetve). Jelentéskészítő azonban nem távolítja el a megfelelő oszlopokat az adathalmaz-lekérdezésből.

Ha törölnie kell a lekérdezésmezőket az adathalmazból, javasoljuk, hogy távolítsa el a megfelelő oszlopokat az adathalmaz-lekérdezésből. Jelentéskészítő automatikusan eltávolítja a redundáns lekérdezésmezőket. Ha mégis törli a lekérdezésmezőket, mindenképpen módosítsa az adathalmaz lekérdezési utasítását is az oszlopok eltávolításához.

Nem használt adathalmazok

Jelentés futtatásakor a rendszer minden adathalmazt kiértékel – még akkor is, ha nincsenek jelentésobjektumokhoz kötve. Ezért a jelentés közzététele előtt mindenképpen távolítsa el a teszt- vagy fejlesztési adatkészleteket.

Kapcsolódó tartalom

A cikkhez kapcsolódó további információkért tekintse meg a következő forrásokat: