Adatbekötés röviden
A Power Query az a réteg, amely a forrásrendszerekhez csatlakozik, és a nyers adatot riportra alkalmas formába hozza. A benne rögzített lépések minden frissítéskor újra lefutnak – vagyis a tisztítás egyszer készül el, és utána magától megismétlődik.
Két kulcsdöntés van itt: import vagy DirectQuery módban dolgozunk-e, és mennyi adatot engedünk be a modellbe. Mindkettő közvetlenül hat a riport sebességére és a licencigényre.
Milyen forrásokhoz lehet csatlakozni?
A Power BI több száz beépített csatlakozóval érkezik. A gyakorlatban a magyar cégeknél a következők fordulnak elő legtöbbször:
| Forrástípus | Jellemző példák | Amire figyelni kell |
|---|---|---|
| Fájlok | Excel, CSV, SharePoint-mappa | Fix elérési út és állandó szerkezet kell; a kézzel szerkesztett fájl a leggyakoribb hibaforrás. |
| Adatbázisok | SQL Server, PostgreSQL, MySQL, Oracle | Olvasó jogosultságú technikai felhasználó szükséges; helyi adatbázisnál adatátjáró is. |
| ERP | SAP, Dynamics 365 Business Central, Navision | Gyakran nem közvetlenül, hanem köztes nézeteken vagy exporton keresztül érdemes csatlakozni. |
| CRM és felhőszolgáltatások | Salesforce, HubSpot, Dataverse | API-korlátok (hívásszám) miatt érdemes inkrementálisan tölteni. |
| Marketing és webanalitika | GA4, Google Ads, Meta | Az adatok mintavételezettek vagy késleltetettek lehetnek; a csatlakozók változhatnak. |
| Egyedi API | REST/JSON végpontok | Hitelesítés, lapozás és hibatűrés kézzel építendő – a legnagyobb ráfordítású forrástípus. |
Import vagy DirectQuery?
Ez a döntés meghatározza a riport sebességét, frissességét és a forrásrendszer terhelését.
Import mód
- Az adat bemásolódik a modellbe, tömörítve.
- Nagyon gyors megjelenítés, teljes DAX-támogatás.
- Ütemezett frissítés kell hozzá.
- Az adat annyira friss, amennyire a legutóbbi frissítés.
- Az esetek nagy többségében ez a jó választás.
DirectQuery mód
- Minden interakció lekérdezést küld a forrásnak.
- Mindig aktuális adatot mutat.
- Lassabb, és terheli a forrásrendszert.
- Több DAX-funkció korlátozottan használható.
- Akkor indokolt, ha valós idejű adat kell, vagy az adat túl nagy importáláshoz.
Létezik összetett (composite) modell is, ahol a nagy tényadat DirectQuery-ben marad, a kisebb dimenziók pedig importálva vannak. Ez rugalmas, de összetettebb tervezést igényel.
Hogyan működik a Power Query?
A Power Query szerkesztőjében minden művelet egy lépésként rögzül a jobb oldali listában. Ezek a lépések sorban futnak le, és együtt alkotják a lekérdezést – amely a háttérben M nyelven íródik.
// Egyszerű lekérdezés: szűrés, típusállítás, oszlop elhagyása let Forras = Sql.Database("sql01", "Ertekesites"), Tetelek = Forras{[Schema="dbo", Item="SzamlaTetel"]}[Data], SzurtEv = Table.SelectRows(Tetelek, each [Datum] >= #date(2023, 1, 1)), Tipusok = Table.TransformColumnTypes(SzurtEv, {{"Datum", type date}, {"Netto", Currency.Type}}), ElhagyottOszl = Table.RemoveColumns(Tipusok, {"Megjegyzes", "RogzitoFelhasznalo"}) in ElhagyottOszl
Query folding – amiért érdemes odafigyelni
Ha a lépések „visszahajthatók" a forrásba (query folding), akkor a szűrést és az összesítést maga az adatbázis végzi el, és csak a szükséges adat érkezik meg. Ez drámaian gyorsíthatja a frissítést. A folding megtörik például egyedi M-függvényeknél vagy sorindex hozzáadásánál – ezért az ilyen lépéseket érdemes a lekérdezés végére tenni.
Tipikus tisztítási lépések
- Felesleges oszlopok elhagyása – a legnagyobb hatású, mégis leggyakrabban kihagyott lépés. Amit nem használ a riport, annak nincs helye a modellben.
- Adattípusok beállítása – dátum legyen dátum, szám legyen szám. A szöveges dátum minden későbbi számítást elront.
- Sorok szűrése – csak a releváns időszak és a valós tételek (sztornók, tesztadatok kizárása).
- Kategóriák egységesítése – „Budapest", „budapest", „BP" ugyanaz kell legyen.
- Táblák összefűzése – ugyanolyan szerkezetű havi fájlok egyesítése egyetlen táblába (Append).
- Kulcsok előállítása – az összekapcsoláshoz szükséges, tiszta azonosítók létrehozása.
- Kereszttábla kibontása – az Excel-jellegű, oszlopokba írt hónapok átalakítása sorokká (unpivot). Ez a lépés teszi riportolhatóvá a legtöbb kézi táblát.
Adatátjáró és ütemezett frissítés
Ha a riport a felhőben (Power BI Service) fut, de az adat a cégen belüli szerveren van, akkor kell egy adatátjáró (on-premises data gateway): egy kis szolgáltatás, amely egy mindig bekapcsolt gépen fut, és biztonságos csatornát nyit a felhő felé.
- Telepítése az IT feladata; érdemes szerverre tenni, nem egy felhasználó laptopjára.
- Standard módban több felhasználó is használhatja ugyanazt az átjárót.
- A frissítés akkor sikeres, ha a tárolt hitelesítő adatok érvényesek – lejáró jelszó a leggyakoribb hibaok.
- A napi ütemezett frissítések megengedett száma licencfüggő – lásd a licenc-áttekintőt.
Nagy táblák esetén érdemes inkrementális frissítést beállítani: ilyenkor csak a változott időszak töltődik újra, nem a teljes előzmény.
Karbantartható lekérdezések
Egy fél év múlva is módosítható lekérdezés néhány egyszerű szabályt követ:
- Paraméterezze a kapcsolatot – a szervernevet és az adatbázis nevét paraméterként tárolja, így teszt- és éles környezet között váltani egy kattintás.
- Beszédes lépésnevek – a „Módosított típus1" helyett „Dátum típusának beállítása".
- Lekérdezéscsoportok – külön mappa a forrásoknak, a segédlekérdezéseknek és a modellbe töltött tábláknak.
- Ne töltsön be mindent – a segédlekérdezéseknél kapcsolja ki a betöltést („Enable load").
- Ismétlődő logika függvénybe – ha ugyanaz a tisztítás több forráson kell, érdemes M-függvényt írni rá.
- Dataflow, ha többen használják – ha ugyanaz az előkészített tábla több riportnak kell, tegye dataflow-ba, és így egyszer fusson le.
Sok forrásból kellene összeraknia a riportot?
A kalkulátorban jelölje be, milyen rendszerekből jönnének az adatok, és megmutatjuk, ez nagyságrendileg mekkora ráfordítást jelent.
Kalkulátor indítása