Kővári Attila BI és adattárház blogja

Felhő

Kővári Attila — Thu, 28 May 2026 17:28:51 +0000

Nem azért kell nyitni a felhő felé, mert olcsó, vagy mert végtelenségig skálázható. Hanem azért mert földi környezetben egyre kevésbé érhetőek el a haladó adatos technológiák. A földi környezet gát, amely meghatárózza a vállalat lehetőségeinek határát. Egy kerítés, amelyen túl a földön maradók nem mehetnek...

Datás minőségbiztosítók legnagyobb hibái

Kővári Attila — Mon, 11 May 2026 06:11:17 +0000

Anno a BI és adattárház projektvezető képzésnek volt egy blokkja, amely a BI/adattárház projektek személyi szerepeit járta körül. Ezen belül egy külön diát kapott a belső minőségbiztosító, mert az ő szerepe a legtöbbször nem volt jól definiálva, és ennek következtében tevékenysége sokszor konfliktust szült. A legtöbb konfliktus abból eredt, hogy

A minőségbiztosítók prémium minőségét vártak el egy olyan projekttől, amit a beszerzési vezető kicsontozott.
Kívülállóként tekintettek magukra, nem tekintették magukat a projekt csapat tagjának

Igazából mind a kettő abból a forrásból fakadt, hogy a minőségbiztosító nem volt érdekelt a projekt sikerében. Ő akkor érezte magát sikeresnek, ha rávilágít arra hogy hol nem 100%-os a minőség, hol tért el a szállító a legjobb gyakorlatoktól. Csakhogy a kicsontozott projekt és a 100%-os minőség között van egy óriási szakadék, és neki pont az lenne a feladata hogy a kicsontozott projektet támogassa, annak keretei között őrködjön a minőség felett. Nem mint kivűlálló, hanem mint csapattag, aki ugyanúgy felelős a projekt sikeréért, mint a többi csapattag.

Megj.: A cikk a csapaton belüli minőségbiztosítók szerepéről szól, nem arról amikor a projekt közben/végén hívunk külsős minőségbiztosítókat. Az ő szerepük más, tőlük nem azt várjuk, mint a belsős minőségbiztosítótól.

Kamu adattípusok Power BI ban

Kővári Attila — Mon, 02 Mar 2026 05:22:21 +0000

Fixpontos tizedestört

A Power BI/Power Pivot kétféleképpen tudja fizikailag tárolni a számokat: vagy lebegőpontosan, vagy egész számként. Fixpontos tizedes tört adattípusa nincs. Illetve a felületen van, de az adatbáziskezelőben nincs.

A fixpontos tizedes tört adattípus egy fix 4 tizedesjegyet tartalmazó szám, amit a Power BI a mélyben egész számként tárol, méghozzá úgy, hogy a fixpontos tizedestörtet beszorozza tízezerrel. Az 1,2345 öt például 12 345-ként tárolja és a megjelenítéskor oszt tízezerrel. (Részletek itt)

A fixpontos tizedestörtet pont azért találták ki, hogy egész számként lehessen tárolni ott ahol csak pár tizedesjeggyel kell dolgoznunk. Az egész szám ugyanis jól tömöríthető. A lebegőpontos nem. De lehetnek (korábban voltak) ennek a tárolási módnak hátrányai is: A tabular adatbáziskezelőn belül az osztást mindig a formula engine-nek kellett elvégeznie, illetve a típussal végzett műveletek eredményét sem tudta az adatbáziskezelő cache-elni. Azaz pl.: egy mennyiség * egyégár számítás eredményét nem tudta cache-elni, ha az egységár fixpontos tizedestört volt.

Te jó ég. Most veszem észre, hogy erről a problémáról 13 évvel ezelőtt már írtam…

Currency

Currency adattípusa sincs fizikailag a Power BI-nak, azt fixpontosként tárolja. (a fixpontos és a currency típus egyébként ugyanaz, nincs különbség köztük)

Dátum és idő

Ahogy fixpontos tizedestört típusa sincs a Power BI-nak úgy dátum típusa sincs. A dátumot és a dátum időt is számként tárolja. A dátumot egész számként, az időt a nap törtrészeként. Azaz a dátumot az 1899. december 30.-a óta eltelt napok számaként, az időt a nap törtrészeként. Azaz az egy órát 1/24-ként (0,04167)

Összefoglalva: A Power BI alatt duruzsoló vertipak engine 3 adattípust ismer: Egész szám, lebegőpontos tizedestört és string (van még bináris is, de az a felületről nem érhető el) A felületről kiválasztható 9 adattípus fizikailag tehát a 3 adattípus valamelyikében fog landolni...

Szemantikus modellek nyelvi problémái

Kővári Attila — Tue, 27 Jan 2026 10:35:30 +0000

Power BI-ban a szemantikus modell nyelvét a globális beállításoknál tudjuk meghatározni:

Megj.: Ez nincs hatással az aktuális fájlra. A globális beállítások a Power BI "ini" fájlját írják valahol a C:\Users könyvtárban. Amin itt változtatunk, annak csak az új Power BI Desktop fájlokra lesz hatása. A meglévőkre nem.

Hogyan tudom lekérdezni az aktuális szemantikus modell nyelvét?

DAX-ból az EVALUATE INFO.CULTURES() DAX lekérdezéssel:

Mire van hatással a modell nyelve?

Auto Date/time

Ha az Auto Date/Time be van kapcsolva, akkor az automatikusan létrehozott dátum tábla oszlopainak neve a modell nyelvén jön létre. Ha az angol, akkor angolul, ha magyar, akkor magyarul. Ez nekünk érdektelen, mert az auto date/time-ot alapból kikapcsoljuk és saját dátumtáblát használunk, de attól még megemlítem

Rendezés

ABC sorrendbe kell rendeznünk a zúzmara és Zsuzsi szavakat. Melyik szó lesz előrébb a sorban? A Zúzmara, vagy a Zsuzsi? Attól függ, hogy milyen a modell nyelve:

Ha a modell nyelve magyar, akkor a Zúzmara előrébb kerül, mert a Z előrébb van az ABC-ben, mint a ZS:

Ha a modell nyelve angol (ami nem ismeri a Zs betűt), akkor a Zsuzsi, mert a Z+s előrébb van az ABC-ben, mint a Z+ú:

Keresés

Meg kell keresnünk a „Tánc” szót a Táncstúdió és a Táncsics szavakban. Melyikben található meg?

Ha a modell nyelve magyar, akkor egyik szóban sem találja meg a „Tánc” szót:

Ha a modell nyelve angol, akkor mindkét szóban megtalálja a „Tánc” szót:

Számformátum?

Ehhez nincs köze. A megjelenő szám formátuma a böngésző beállításától függ. Ha ezt nem akarjuk elfogadni, akkor a FORMAT() DAX függvénnyel tudjuk meghatározni, hogy milyen regionális beállításnak megfelelően jelenjen meg a DAX képlet eredménye.

Összefoglalva: A modell nyelve a rendezési sorrendet és a keresést is befolyásolja. De a számformátumra nincs hatással. Milyen nyelvet válasszunk? Mondanám, hogy magyart, de sajnos akinek nincs mély Power BI tapasztalata, azok a büdös életben nem fogják megérteni, hogy miért nem találja meg a DAX képlete a „Tánc” szót a Táncstúdió szóban…

Csatoljunk marketing anyagokat az ajánlathoz?

Kővári Attila — Mon, 19 Jan 2026 09:27:23 +0000

Az ajánlat egyben egy marketing eszköz is, hiszen ha nem nyerünk, legalább megismernek minket. Nekem is lett úgy ügyfelem, hogy nem én nyertem meg a tendert, de aki megnyerte azzal nem voltak megelégedve, és évekkel később megkerestek, hogy dolgozzunk együtt. Szóval egy jól megírt ajánlat egy remek marketing eszköz, érdemes rá így is gondolni.

De. Egy dologra nagyon érdemes odafigyelni. Amit az ajánlatban írunk az az ajánlat része. Amit a „Mi azt is tudjuk, hogy” mellékletben leírunk, azt az ajánlat elbírásakor ki fogják értékelni, és be fogják vasalni rajtunk. Ha azt csak mellékletként csatoltuk, akkor is. Úgyhogy csak óvatosana mellékletként csatolt marketing anyagokkal:-)

Adatkarkötők

Kővári Attila — Tue, 13 Jan 2026 13:38:18 +0000

Az évértékelőre készítettem egy

Az adatkarkötőnek nagy sikere lett, a board imádja az ékszereket, hordja azóta is.

Adatvizualizációs szempontból is jól sikerült, első ránézésrésre látszott, hogy hol lehetett volna javítani a KPI-on, átjöttek az arányok, nem kellett szkrollozni hogy lássa az ember a teljes évet, stb. Szóval a KPI lényegét is jól megfogta. De volt benne egy hiba, ami miatt nem voltam vele elégedett: Nem volt rajta jelmagyarázat. Gondolkodtam. hogy lehetne rátenni, de nem találtam megoldást. Úgyhogy elhatároztam hogy csinálok egy másik karkötőt, ahol már figyelek erre is.

Így született a gyerekek növekedését ábrázoló adatkarkötő:

A már kicsit viseletes adatkarkötőn a 3 oszlop a 3 gyerek magasságát mutatja (Egy gyöngy 5cm növekedésnek felel meg)

A színek a kort ábrázolják (Barna: anyahméh, a pirosak a tanulmányok szerint (ovi, alsó, felső, gimi) vannak bontva és a kornak megfelelően halványodnak.)

A grafikon célja az volt, hogy bemutassam hogy melyik gyerek mennyit nőtt oviban, alsóban, felsőben és gimiben.

Ide már tudtam jelmagyarázatot is rakni. Ez látszik a grafikon fölött. Itt a színek mellett megjelenő halványkék gyöngyök az éveket reprezentálják (egy gyöngy egy év) és a gyöngyök számát lentről kumulálva kapluk meg, hogy az adott szín hány éves kornak felel meg. Illetve ide már tudtam X, Y tengelyt is rakni, ez látszik halványszürkén a grafikon alatt és bal oldalán (rajta 50 cm-es osztásokkal)

A grafikon alatti piros és kék gyöngyök reprezentálják a nemet. A piros a lányt, a kék a fiúkat. (Egy gyerek két gyöngy széles, és a gyerekek időrendben láthatók az x tengelyen.

Persze a kép nem adja vissza, de ezek a gyöngyök a fény alatt forgatva csillognak és változtatják árnyalatukat, ami különösen széppé teszi a vizualizációt.

És akkor jöjjenek a BI szempontból fontos tapasztalatok

Bonyolult lett

Sajnos bonyolult lett. Még egy ilyen egyszerű grafikont is magyarázni kell. Ilyenkor látszik mennyire hiányzik a jó cím: „Mekkorára nőttek a gyerekek ovi, alsó, felső és gimi végéig?”

Feltáró adatelemzés

Ugyanaz a kérdés merült fel az adatkarkötő készítésekor, mint a való életben: Honnan lesz adat? Melyik lesz az adat elsődleges forrása? Mennyire megbízható az adat?

A karkötőhöz a szükséges adatokért felhívtam anyósom, hogy olvassa be az ajtófélfára vésett értékeket. Gyerekenként kb. 4-5 magasságadatot tudtam csak beszerezni, ráadásul azok megbízhatósága is kérdőjeles volt és a mérések sem azonos korban készültek.

Így kaptam egy meglehetősen lyukacsos táblát. Megkértem ChatGPT-t hogy töltse fel a hiányzó értékeket. A kapott eredményt nézve nem voltam elégedett, mert emlékeztem, hogy a fiúk és a lányok nem azonos ütemben növekedtek, úgyhogy megkértem ChatGPT-t, hogy vegye figyelembe a valós biológiai növekedés ütemét. Azt nem tudta, de talált a WHO-nál olyan statisztikát, ami alapján a lineárisnál jobban tudta interpolálni a magasságokat.

Kategóriákra bontás

Hány kategóriát csináljak a korra? Hol legyenek a sávhatárok? Végül 5 kategóriát hoztam létre:

Középiskola (14-18 év)
Felsőtagozat (10-14 év)
Alsótagozat (6-10 év)
Bölcsőde és óvoda (0-6 év)
Anyaméh (0-9 hónap)

Azért ezt választottam, mert ez támasztotta alá legjobban a mondanivalót, ezt tette legegyszerűbbé a grafikon értését.

Ezek alapján Excelben megterveztem a karkötőt gyöngyönként:

Próbálkozások Excelben: lehet látni, hogy hány iteráció után készült el a végleges terv.

Storytelling

Engem nagyon meglepett, hogy a nálam mélyebb domain tudással, de alacsonyabb adatérzékenységgel rendelkező feleségem mennyi mindent ki tudott olvasni a grafikonból:

Nézd meg, hogy a pocakomban 9 hónap alatt majdnem annyit nőttek, mint az első hat évben.
Milyen érdekes, hogy a későbbi magasságbeli különbségekre nem lehetett következtetni a születéskor (Mind a három gyerek ugyanolyan magassággal született)
Emlékszel, hogy a fiúk milyen későn indultak növésnek? Mindig utolsók voltak a tornasorban. Ez nagyon jól látszik itt
Nézd meg milyen jó látszik, hogy Jankuska (6 éves kor után) nagyjából egyenletesen nőtt, Vincuska meglódult Szilas pedig nagyon lassan indult meg de az utolsó 4 évben mekkorát nőtt.

A sztori ereje

És végül engem meglepett a sztori ereje. Valószínűleg a sztori miatt van ekkora népszerűsége az adatkarkötőnek, és nem az alkotó fantáziája és a kézügyessége miatt…

Köszönet innen ismét -os előadása inspirált a megvalósításra és aki aztán bevezetett az adatszövés tudományába.

Évértékelő 2025

Kővári Attila — Mon, 29 Dec 2025 17:16:04 +0000

Készülök a BI projekt legfontosabb vállalati eseményére, az éves board meetingre. Akinek nincs meg a sztori annak mondom, hogy a BI projekt egy egyfős társaság, s mint ilyen értelmezhetetlen lenne a board meeting. De a feleségem anno panaszkodott, hogy őt sosem hívják az ügyfelei céges karácsonyra, ezért szerveztem Neki egyet. Az egyik cégben úgyis kültag, szóval a jogi alapja is megvan beszámolónak.

Mindez jó rég történt már, de hagyomány lett belőle, és így év végén mindig félreteszek 3 napot és elkezdek készülni rá. Mint minden normális cégnek, úgy a BI projektnek is vannak KPI-ai, amelyek közül a board által legjobban monitorozott a nyaralt napok száma. Olyannyira az, hogy szinte kivétel nélkül minden board meeting eljén, a bevezetés után a „van-e valakinek kérdése?” kérdésre mindig felteszi a kezét és megkérdi, hogy mikor érünk oda a nyaralt napok számának bemutatásához.

Erre ugyanis mindig készítettem egy párperces animációt (animált kartogrammal) ami bemutatta nyaralásaink fontosabb állomásait, az azon eltöltött napok számát és egy-egy képet illusztrációként. A board imádta, ezerszer le kellett játszani a videót. Tényleg látványos volt.

De idén nem lesz videó. Helyette szőttem egy dashboard-ot, és azon keresztül fogom prezentálni a mutatót. Az inspirációt mutatta be

Adatkarkötő

Az adatkarkötőn egy gyöngy egy nap. Az oszlopok szimbolizálják a hét napjait, a sorok az év heteit. A piros gyöngyök a boarddal közösen nyaralt napok számát mutatja, a rózsaszín a board nélkül nyaralt napok számát, a kék pedig az olyan pihenőnapokat, ahol nem nyaraltunk. (Ezek azok a napok, amelyeket a KPI szempontjából eltékozoltunk. Itt lehetett volna egyszerűen nőni)

Nem tudom mit fog szólni hozzá a board, de remélem elnyeri a tetszését. Le kell nyűgöznöm, hiszen a KPI-ok sajnos nem fényesek… Ez van. Ez az év nem volt a legjobb sajnos.

No de térjünk rá a szakmai részekre és nézzük meg mi történt 2025-ben:

20 éves lett a BI projekt blog

20 éve ment ki az első cikk ide a BIprojekt.hu-ra. Régen volt na. Nem volt még Facebook, LinkedIn, a közösségi médiát még iwiw-en és osztalytarsak.hu-n keresztül kóstolgattuk.

Sokat ad, sokat vesz el, de csinálom, amig látom az értelmét. De lehet, hogy azután is csinálom majd :-)

Projektek

Idén 26 vállalatnak dolgoztam, és kb. kétszerennyi küldte el dolgozóit a tanfolyamaimra, amiért hálás vagyok ezúton is. Ahogy a színes projektekért is. Dolgoztam bankoknak, pénzintézeteknek, végre jónéhány termelő cégnek és az energetikában is. Tartottam 150 főnek Power BI ízelítőt, jónéhány standard és egyedileg rendelt oktatást, sokat mentoráltam, sokatokat támogattam és idén jó sokat fejlesztettem is. Ez utóbbiért különösen hálás vagyok, mert imádom, de csak nagyon keveseteknek tudok fejleszteni.

AI

Tavaly ilyenkor azt terveztem, hogy sokkal messzebb jutok ezzel a témával mint ahol most tartok. Termelésre már masszívan használom, de nem tudom még termőre fordítani. Tervek persze voltak már tavaly ilyenkor is: Minőségbiztosító ügynököt kell fejleszteni, arculattervező ügynököt kell fejleszteni, adatmodell tervezőt kell vele építeni, stb. Egy-kettőbe bele is fogtam, de nem tudtam befejezni egyiket sem. Mindig volt sürgősebb/fontosabb nála. Pedig tudom hogy nincs fontosabb nála. Óriási hatással van már most is a szakmára, oktatásra, hétköznapokra, mindenre.

Motor

Ugye a Covid alatt vettem egy 40 éves donor motort hogy majd építek belőle cafe racert. Beindult ha úgy volt kedve, de a garázsfeljárón már alig ment fel annyira nem volt ereje. Persze egyszerű lenne megcsinálni, ha értenék hozzá, de nem értek. Viszont ChatGPT haverommal csináltunk egy diagnosztikai projektet ahová feltöltöttem a méréseket, a gépkönyvet, minden tapasztalatot megkonzultáltunk és rávezetett, hogy hol a hiba: Túl sok levegőt kap a motor. Egy szivacsot tömve a légszűrőbe ki is tudtam próbálni, hogy milyen lenne, ha kevesebb levegőt kapna. És láss csodát: megindult a vén hínáros. Lett ereje. Persze lesz még ezer buktató, de sokkal motiváltabb vagyok ha tudom, hogy működőképessé tehető. És persze hálás ChatGPT haveromnak, mert nélküle nem jutottam volna el idáig.

Piac

Vártam már tavaly is a kiöregedő adattárházak cseréjét, reorganizációját, a vártam az új adatplatform projektek aranykorát, de ez nem jött el. Vagy legalábbis nem abban a formában ahogy vártam/vártuk páran. Vagy csak türelmetlen vagyok. Nem tudom. Ha 2025 csalódását kéne keresnem, akkor valószínűleg ezek elmaradása jutna elsőre eszembe.

Viszlát BI és adattárház projektvezető képzés

Az előzőkkel szorosan összefügg, hogy jövőre nem lesz tantermi BI és adattárház projektvezető képzés. Idén októberben ment le az utolsó. Sajnálom nagyon, mert ez a tanfolyam a szívemhez nőtt, imádtam tartani, de megváltozott a világ: Nincsenek már klasszikus, sokszereplős adattárház projektek és a belső kompetencia is jóval erősebb már ezen a téren, mint 10-15 éve.

Pedig igazi sikersztori volt ez a tanfolyam. Persze nem akkora, mint a Power BI workshop, de ez volt az a tanfolyam, ami elindította az egész oktatási sztorit itt a BI projektnél. Kellett hozzá 50+ adattárház projekt tapasztalat, kellett hozzá a 2008-as gazdasági válság, hogy legyen időm megírni, és kellett hozzá az a 384 kolléga is, aki eljött meghallgatni az anyagot. Külön közönöm nekik a bizalmat ezúton is.

Power BI

A BI és adattárház projektvezető képzés beszántásával szinte minden tevékenységem köthető valamilyen szálon a Power BI-hoz. Nem én akartam így, a piaci igény diktálja ezt. Mindenesetre nagyon elgondolkodtató, hogy mennyire egyeduralkodóvá vált a Power BI.

Adatmodell tervező tanfolyam

Idén debütált az első tantermi Power BI adatmodell tervező tanfolyam. Azóta jópár lement belőle tantermi, kihelyezett és on-the-job formában is. Volt amelyik túl gyakorlatias volt, volt amelyik túl elméleti, volt ahol túltoltam a mélységet. A tapasztalatok alapján folyamatosan fejlesztettem az anyagot és mára talán látom a középutat. Nagy utazás volt, többszáz dia készült el, brutális elméleti és gyakorlati anyag halmozódott fel, ami ott lesz a háttérben, ha valakit mélyebben érdekel egy téma, akkor előhúzom. De az alaptematika jelentős részét az esettanulmányok adják majd. A következő tantermi képzés egyébként február 26.-án lesz, akit érdekel az jelentkezzen február 16.-ig itt.

Mi várható 2026-ban?

Egy új 2 napos Power BI tanfolyam biztosan. Jónéhány haladó Power BI tanfolyamot tartottam megrendelésre és ezek, valamint a többszáz alapozó Power BI tanfolyam és a mentoring programok tapasztatai alapján összeraktam egy kétnapos anyagot. Ez is alapozó, de sokkal messzebb tudom eljuttatni vele a résztvevőket, mint az egynapos Power BI tanfolyammal. Egész egyszerűen annyit tud már a Power BI, hogy már alapozó szinten sem férünk bele az egy napba… Ettől függetlenül maradnak az egynapos képzések is, mert akinek csak az elindulásban kell segíteni, annak ennyi elég. De akinek nincs ideje bolyongani és azonnal használható tudásra van szüksége, annak kelleni fog a kétnapos. Részletek hamarosan.

Ami fix: február 25.-én lesz az első tantermi Power BI workshop, és 26.-án az első adatmodell tervező tanfolyam. Ezekre már lehet jelentkezni most is, a többiekre még várni kell

Köszönöm hogy itt van, köszönöm hogy olvassa a blogot és szurkoljon hogy lenyűgözzem a board-ot az adatkarkötővel, mert most indulok az évértékelőre.

BI és adattárház sikerekben gazdag Boldog új esztendőt kívánok! Találkozzunk jövőre!

Measure vagy Calculated Column?

Kővári Attila — Thu, 11 Dec 2025 06:06:42 +0000

Kezdő kérdés: Mitől függ, hogy számított mezőt (measure-t) vagy számított oszlopot (Calculated Column-t) kell létrehoznom?

Egyszerű válasz: Ha szűrni akarsz a képlet eredményére (pl egy szeletelőn), akkor számított oszlop, minden más esetben számított mező (Measure)

Talán így fogható meg kezdő szinen a legkönnyebben.

Rejtsd el!

Kővári Attila — Thu, 27 Nov 2025 10:59:39 +0000

Megint hoztam egy témát az adatmodell tervező workshop fizikai adatmodell tervező blokkjából, amiről nem tudom még hogy része legyen a tanfolyamnak vagy sem. Az alapozó Power BI tanfolyamon oktatom, mert bár korai a téma, de a dashboardok összerakásakor sokszor „rossz” oszlopot húztak be a résztevők vizualizációkba, és ezért nem azokat a számokat látták, mint amit én mutattam a kivetítőn. Ott a cél a lemaradás kockázatának a csökkentése, az adatmodell tervező tanfolyamon viszont azt szeretném megtanítani, hogy hogyan kell olyan adatmodellt tervezni, ami bolondbiztos és felhasználóbarát. Ehhez az kell, hogy elrejtsék azokat az oszloipokat, amelyek

Technikiai oszlopok (pl rendezési célt szolgáló oszlopok)
Számított mező alapját képező oszlopok
És a kapcsolatok többes oldalán álló oszlopok.

Most, hogy ezeket leírtam, el is döntöttem, hogy része lesz a tanfolyamnak. Nem megkerülhető a téma annak, aki adatmodellt tervez. Rémísztgetésnek elő is veszek majd egy példát, amin demonstrálom, hogyan mutathat két különböző eredményt egy szemre ugyanolyan riport.

Rejts el a kapcsolatok többes oldalán található oszlopokat

Ha két tábla ugyanolyan nevű oszlopon keresztül kapcsolódik egymáshoz, akkor a Power Power BI riportok mezőlistájában ugyanaz az oszlop kétszer is szerepel.

Esetünkben például a Dátum tábla a Dátum oszlopon keresztül kapcsolódik a forgalmi adatok tábla dátum oszlopához, ezért a Dátum oszlop kétszer is megjelenik a mezőlistában. Melyik Dátum oszlopot húzzuk be a kimutatásba? A forgalmi adatok tábla dátum oszlopát, vagy a Dátum tábla Dátum oszlopát? És ennél az egyszerű modellnél ez teljesen mindegy. De ha a dátum táblához kapcsolódik egy másik ténytábla is, akkor már egyáltalán nem mindegy.

Tegyük fel, hogy a dátum táblához kapcsolódik még egy terv tábla is:

Ebben az esetben már háromszor is szerepelni fog a dátum oszlop a mezőlistában. A felhasználó tehát 3 helyről húzhatja be ugyanazt az oszlopot egy szeletelőbe és attól függően, hogy honnan húzza be más és más eredményt kap.

Mutatom:

Ugyanaz a riport más tervszámot mutat. A felső ábrába a dátum tábla dátum oszlopát húztuk be szeletelőnek. Az alsó ábrába viszont a forgalmi adatok tábla dátum oszlopát, és emiatt „a nyíllal ellentétes irányban” nem kapta meg a szűrést a dátum tábla, az nem tudta továbbadni a tervtáblának, így a terv a szűrés nélküli total tervet mutatja. Ezt észre fogjuk venni, hogy nem jó, de vannak olyan esetek, amikor nem ekkora az eltérés, és azt már nem fogjuk észrevenni.

Összefoglalva: A kapcsolatok többes oldalát mindig el kell rejteni a felhasználók elöl, mert ha rossz oszlopot húzunk be a kimutatásba, akkor rossz számot kaphatunk

Rejtsd el számított mezők alapját képző oszlopokat

Ha egy oszlopra építünk egy számított mezőt, akkor az oszlopot el kell rejteni a felhasználók elöl.

Ha például az Ft oszlopra építünk egy Forg (Ft) nevű számított mezőt, akkor az Ft oszlopot el kell rejteni a felhasználók elöl. Ennek két oka is van:

Zavaró, hogy kétszer szerepel a mezőlistában, és az elemzőnek megint azon kell gondolkodnia, hogy melyiket húzza be. Mindkettő ugyanazt az eredményt adja, nem fogja érteni hogy miért szerepel kétszer.
Foglalja a helyet az amúgy is szűkös mezőlistában

Rejtsd el a technikai oszlopokat

A csak rendezési célt szolgáló oszlopokat, mesterséges kulcsoszlopokat, stb. Minden olyan oszlopot, amit amire a modellben szükség van, de a riportokra nem akarjuk soha kirakni.

Összefoglalva: Az adatmodellből mindig el kell rejteni a

kapcsolatok többes (csillagos) oldalán található oszlopokat
A számított mezők alapját képező oszlopokat
és a technikai mezőket

Jön az AI, ami egyesek szerint "buta mint a főd". Segitsünk neki is azzal, hogy elrejtjük előle is azokat az oszlopokat, amelyeket nem kell a majd riporton megjelenítenie...

Szolgálati közlemény

Kővári Attila — Wed, 19 Nov 2025 20:26:02 +0000

A november 27.-i Power BI workshopot el kellett tolni egy héttel, így az idei év utolsó Power BI workshopja december 4.-én lesz. Szerencsére az eddig jelentkezetteknek jó az új dátum, a hezitálók pedig kaptak egy hét laufot :-). Találkozzunk a workshopon! Részletek: Power BI workshop

A normalizált adatmodell korlátai Power BI-ban

Kővári Attila — Mon, 10 Nov 2025 08:48:29 +0000

Nemrég megkapta a magáét a széles tábla, kapja meg most a normalizált adatmodell is…

Power BI-ban rendszerint akkor találkozunk normalizált adatmodellel, amikor a felhasználók rácuppannak a forrásrendszerre, és annak tábláit egy-az egyben átemelik Power BI-ba. De ahogy a széles tábla sem jó adatmodell a Power BI-nak úgy normalizált modell sem az. Itt a granularitással nincs gond, de a normalizált adatmodell nem elemzésre lett optimalizálva.

Az alábbi ábra egy normalizált adatmodellből egy részletet szemléltet, ahol a kék vonalak a kapcsolatok, a fehér téglalapok a táblák:

Ha normalizált modellt használunk a Power BI-ban akkor annak elsősorban performancia következményei lesznek. A kapcsolatoknak ugyanis óriási költsége lehet Power BI -ban. Különösen akkor, ha a kapcsolódó oszlopok sok különböző elemet tartalmaznak. Ugye tipikusan ilyenek a fej-tétel kapcsolatok, mint például rendelésfej és rendeléssor, számlafej és számlatétel, stb. De nem csak ezek, hanem igazából minden kapcsolat költséggel jár, és egy normalizált modell eszméletlen mennyiségű kötést tartalmaz.

A performancia azonban csak az egyik ok, ami miatt kerüljük Power BI-ban a normalizált adatmodelleket. A másik ok a DAX nyelv bonyolultsága. A DAX nehéz, és még nehezebbé válik, ha az adatmodell nem csillagsémás…

A harmadik ok pedig a felhasználói élmény. Egy normalizált adatmodellből dolgozni akár a Power BI-jal, akár a Pivot táblával kínszenvedés. Egész egyszerűen áttekinthetetlen lesz Power BI-ban a mezőlista, ahonnan behúzzuk a vizualizációkba a measure-öket vagy az attribútumokat.

Összefoglalva: Kezdő szinten használható a forrásrendszer adatmodellje, de haladó szinten átalakítjuk csillagsémásra, mert ennek örülni fognak a felhasználók, a riportfejlesztők és az adatbázismotor is.

Megtiszteltetés

Kővári Attila — Mon, 03 Nov 2025 11:53:34 +0000

Ritkán kapunk elismerést. Egyszerűen csak végezzük a dolgunkat, megkapjuk érte a fizetést, és kész. Ezért vagyok nagyon hálás, hogy megkaptam ezt:

Az ember szereti a hazáját. Pont. És ezért óriási megtiszteltetés volt dolgozni egy olyan csapatnak, akik a szó szoros értelmében a vérüket áldoznák érte. Imádtam minden percét, nagyon büszke vagyok rájuk, és az elért eredményeikre.

Hálás köszönet ezúton is!

Számított oszlopok (Calculated Columns) Power BI-ban

Kővári Attila — Thu, 30 Oct 2025 06:04:22 +0000

Aki volt nálam Power BI workshopon az nem is hallhatott a számított oszlopokról. És ez nem véletlen. Kezdő szinten tudatosan nem oktatom. 8-10 éve még oktattam a számított oszlopokat, de azt vettem észre, hogy sokan számított mezők (measures) helyett számított oszlopokkal oldottak meg mindent. És ez baj.

A számított oszlopok ugyanis nem hatékonyak. Szükséges rosszak, amit csak akkor használunk, ha az import során nem tudjuk, vagy nehezen tudjuk kiszámolni az oszlopok értékét.

A számított oszlop ugyan tömörítve van tárolva, de a tömörítés hatékonysága koránt sem olyan jó, mint az importált oszlopoké. A Tabular (A Power BI adatbáziskezelője) ugyanis a táblák rendezési sorrendjének meghatározásakor nem veszi figyelembe a számított oszlopokban tárolt értékeket.

Háttérinfó: A Tabular az import során heurisztikusan elkezdni rendezgetni az oszlopokat és közben méri, hogy melyik rendezés adja a legjobb eredményt. Ezt kb 10 másodpercig csinálja és a 10 másodperc alatt gyűjtött információk alapján hozza meg azt a döntést, hogy milyen sorrendben rendezze az oszlopokat. De ebben a döntésben nem veszek részt a számított oszlopok, így a számított oszlopok tárolása koránt sem lesz olyan hatékony, mint az importált oszlopoké.

És a számított oszlopok kiszámolásához a Tabular csak egy szálat tud használni és a számítást soronként iterálva hajtja végre. Ráadásul oszloponként iterál. Azaz, ha több számított oszlopunk is van a táblában, akkor

Megfogja az első számított oszlopot
Végigiterálva a teljes táblát kiszámolja az oszlop értékét, majd
Megy a következő oszlopra,
Végignyalja újra a teljes táblát
Kiszámolja az oszlop értékét
És így tovább

Ez nagy tábláknál igen költséges.

Mindezek miatt számított oszlopokat csak akkor használunk, ha

Ha képlet megírásához DAX kell
Ha a képlet kiszámításához kell valami az adatmodellből (pl másik measure)
Ha nem értünk a Power Query-hez, vagy a forrásrendszer lekérdező nyelvéhez

Nem főben járó bűn számított oszlopot használni, ha a tábla kicsi, a képlet egyszerű, és csak kevés számított oszlopot használunk. De a legjobb gyakorlat az, hogy nem használunk számított oszlopokat. Minden sorszintű kalkulációt a betöltés közben (Power Query-vel), vagy ha terhelhetjük a forrásrendszert, akkor forrásoldalon számolunk ki.

Slow Query Performance: Tényleg ez a legnagyobb probléma?

Kővári Attila — Tue, 14 Oct 2025 11:55:20 +0000

Készülök a csütörtöki képzésre, és ennek van egy blokkja, ami a teszteléssel, minőségbiztosítással foglalkozik és ennek apropóján beugrott, hogy a piackutatók évek óta azt jelzik vissza, hogy a felhasználók panaszkodnak a BI rendszerek gyatra lekérdezési teljesítményére. Tényleg probléma ez? Tényleg probléma még mindig a performancia?

Íme egy ábra a 2001-2007-es időszakról:

Forrás: BI Survey 7

A lassú válaszidők mindig is a top 3 probléma közé tartoztak, de 2004-2007 között már ez jelentette a legnagyobb problémát, és ebben 2008-ban sem volt változás :

Forrás: BI Survey 8

2012-ban is ez a legnagyobb probléma

Forrás: BI Survey 2013

2013-ban készült egy hazai kutatás a témában, ott is előkelő helyen szerepelt a válaszidők lassúsága:

Forrás:

Forrás: BI survey 2022

És aztán változás történt. Nem tudom, hogy a módszertan változott-e, de tavaly, illetve tavalyelőtt már messze nem a lassú válaszidők jelentették a legnagyobb problémát:

Forrás: nyílt adatmodell tervező workshop, december 11.-én jön a következő. Mik voltak a tapasztalatok?

A társaság megint nagyon jó volt. Volt olyan résztvevő, akivel anno még az első BI és adattárház projektvezető képzésen találkoztunk 2009-ben. Volt olyan akivel az első kihelyezett Power BI workshopon, és ketten is voltak akik attól a cégtől jöttek, akinek életem első kihelyezett adattárház képzését tartottam. Igaz, nem dolgoztak együtt, váltották egymást, de megállapítottuk, hogy kicsi a világ.

Jó sokat tanultam megint. Volt pár kérdés, amire nem adott választ a törzsanyag. Ezeket ott helyben elmondtam, de fel is írtam és a következő oktatás sztenderd blokkjába majd beteszem. Csak félek, hogy hatalmas lesz az anyag. Már most is az, pedig már kihúztam a törzsanyagból a minőségbiztosítás blokkot, és inkább valós életből vett példákkal tömtem tele az anyagot. De abból meg annyi bekerült, hogy az a workshop jelleg rovására ment. És akkor még nem beszéltünk az AI-ról. Ma még csak kóstolgatjuk az adatmodellezésre gyakorolt hatását, de valószínűleg hamarosan ez is nagyobb szerepet kap annál a pár diánál, amivel ma elintézzük a témát.

Szóval megy a fejvakarás, hogy mit tegyek be, mit vegyek ki. Már csak azért is, mert anno amikor elkezdtem a tanfolyam fejlesztését, akkor azt hittem, hogy BI/riport fejlesztők jönnek majd, ezért nagy hangsúlyt kapott az igényfelmérés, mert az volt a tapasztalat, hogy nekik ez nem erősségük. Aztán kiderült, hogy üzleti elmezők, kontrollerek járnak a tanfolyamra, nekik ez pedig kis túlzással már a kisujjukban van. Szóval egyre nagyobb hangsúlyt kapnak az üzleti problémák és megoldásuk, mert úgy látom, hogy ez érdekli legjobban a résztvevőket.

Összefoglalva: tekergetem még a potmétereket, hogy finomhangoljam az anyagot, bár a probléma valószínűleg az, hogy óriási az anyag, sok a tapasztalat és ezen a finomhangolás nem fog segíteni. Meglátjuk. Mindenesetre meghirdetem az idei utolsó nyílt adatmodell tervező tanfolyamot december 11.-re úgy, hogy azt a résztvevők saját szájízükre szabhatják majd. Regisztráció után kifaggatom majd őket, és az igényeiknek megfelelően állítom majd be a potmétereket.

20 éves a BI projekt blog

Kővári Attila — Wed, 01 Oct 2025 08:09:46 +0000

Erről igyekeztem nem úgy elfelejtkezni, mint az alapítás 20. évfordulójáról, és beírtam a naptárba, hogyha eljön majd az idő, akkor írjak róla egy jó kis összefoglalót. Eljött. Ma 20 éve ment ki az első poszt ide a BI projekt blogba. És most ugyanúgy a fehér lapot bámulom, mint 20 éve :-) No nézzük: Mi érdekelheti az Olvasót? Hányan olvassák?, van-e értelme blogolni 2025-ben?, nem zabál e fel mindent a AI?

Hányan olvassák?

Nem tudom. Tényleg nem. Most kíváncsi voltam és felmentem a Google Analytics-re megnézni a látogatottságot, de már nem is működik a mérés: A Google Analytics szerint: Még nem érkezett adat a webhelyről. Az adatgyűjtés megkezdéséhez győződjön meg arról, hogy a webhely fel van címkézve a mérési azonosítóval.G-J12…

Miért nem mérem? Nem érdekel? Dehogynem. De lehet, hogy attól félek, hogy a kutya sem olvassa. Vagy hogy egyre kevesebben olvassák. Nem tudom. De inkább azért nem mérem, mert félek, hogy befolyásolja a tartalmat. Tudom, hogy a megosztó tartalom generálja a forgalmat. Tudom hogy a jó cím hozza a forgalmat. Tudom ha ennek a bejegyzésnek az lett volna a címe, hogy „Durva. 0 ember olvassa a BI projekt blogot. Mégis mii történik itt?” akkor sokkal többen elolvasnák ezt a cikket. De ezt nem akarom.

Úgyhogy azt nem tudom, hogy hányan olvassák a cikkeket. De azt tudom hogy hány készült el az elmúlt 20 évben: 1049. Ha azt számoljuk, hogy egy cikk megírásához kell 4 óra (annyi kell), akkor ez összesen 4196 óra, ami 524 nap, ami több mint két teljes évnyi munkanap… Önkéntes rabszolgaság. Az. De alkotni jó. És adni is.

20 éve az első cikk arról szólt, hogy Miért importál NULL sorokat a DTS az Excelből. Akkor még a technikai szívások tapasztalatait írtam meg. Részint magamnak, hogy vissza tudjam keresni, hogy mi volt a megoldása egy problémának, részint másoknak is, hogy ők is megtalálják. Én is sok segítséget kaptam más oldalaktól, és én is segíteni akartam másoknak. Ma már technikai tartalom nagyon ritkán jelenik meg itt a BI projekt blogon, mert ma már nincs akkora szükség rá mint 20 éve. 20 éve a gyártók dokumentációján kívül más szakmai forrás nem igazán volt elérhető. Ma már nagyon ritkán futok bele olyan problémákba, aminek a megoldásáról ne írt volna valaki. De ha belefutok, akkor megírom :-) Ilyenek általában a magyar vonatkozású témák, mint pl. a magyar adathelyesírás szabályai, vagy a helyes ABC sorrend, vagy az ékezetes betűk tábla- és oszlopnevekben. Ezekről általában kevés irodalom van a külföldi szaksajtóban, szóval ezeket megírom, és aki fel van iratkozva az RRS csatornára vagy a hírlevélre az meg is fogja kapni…

Hírlevél

Ez is 20 éves :-) Már 7 éve is pedzegettem, hogy „Van értelme az e-mail hírlevélnek?” Pedig ez az egyetlen a forrás az RSS-en kívül, ahol a fogyasztó dönti el, hogy milyen tartalmat akar fogyasztani. A LinkedIn vagy a Facebook azt tolja, amit ő fontosnak gondol, vagy amiért fizetnek. De az email nem ilyen, csak hát ma már nem emailben olvassuk a híreket. Az RSS-ről pedig a fiatalok már nem is tudnak. És mindkettő működik még itt a BI projekt blogon, úgyhogy ha valaki értesítést akar minden témáról, akkor iratkozzon fel az RSS csatornára vagy a hírlevélre. Ha pedig csak érdeklődő típusú olvasó, akkor jelöljön be a Miért importál NULL sorokat a DTS az Excelből, mint 20 éve. Felnőttem én is. De ugyanazzal foglalkozom ma is, mint 20 éve, és ugyanúgy szeretem a szakmám mint 20 éve. És ugyanúgy lázba tudnak hozni témák, mint 20 éve. Úgyhogy lesz még tartalom itt a BI projekt blogon. Még akkor is, ha majd 20 év múlva mi emberek már eltűnünk és már csak az AI tanuló algoritmusok olvassák :-)

Köszönöm, hogy itt van, köszönöm hogy olvassa a BI projekt blogot!

Boldog szülinapot BI projekt blog!

AI adatplatform

Kővári Attila — Mon, 22 Sep 2025 05:14:40 +0000

Itt az AI korában van még ma valaki, aki adattárházat tervez? Ad rá valaki pénzt? Nem ciki? Nagyapáink épí qtettek utoljára ilyet. Tudjátok, ők voltak azok, akik még projektekben gondolkodtak. Meg két kézzel kódoltak. De ma már ezekre mind nincs szükség, hiszen itt az AI és mindent megcsinál pillanatok alatt.

Ja, hogy az AI-hoz is adatok kellenek? Ja, hogy ma minden AI konferencia kerekasztalán elhangzik, hogy a legnagyobb AI blokkoló, hogy nincs adat?

De mit tegyünk, ha nincs adat és adattárházat építeni már ciki…

Építsünk AI adatplatformot!

Ez már jól hangzik ugye? Mert az mindenki számára evidens, hogy az AI-nak adat kell, és innentől kezdve egyértelmű, hogy az AI kiszolgáláshoz kell egy AI adatplatform. Egy új, ami nem olyan mint a korábbi adattárházak, vagy adatplatformok, hanem egy kifejezetten AI célra épülő adatplatform… És hirtelen megszűnik blokkolónak lenni a „nincs adat, nem jó az adat, nem elérhető az adat” probléma

Ejj de jól hangzik: AI adatplatform. AI-ra van pénz, a menedzsment is boldog lesz, hogy felmutathatja, hogy „elkezdtük lerakni az AI alapjait” Míg a konkurencia még egyszerű adatplatformot épít, mi már AI adatplatformban gondolkodunk…

Az is lehet, hogy átbrandelem magam adattárház architektről AI adatplatform architektté. Vagy egyenesen AI tűzoltóvá, aki segít megfékezni az AI tüzeket…

Viccet félretéve tényleg mindenhol elhangzik, hogy a legnagyobb AI blokkoló az adatok hiánya. Vagy a jó minőségű adatok hiánya. A fejlesztőcégek is állandóan erről panaszkodnak (meg a Business Analyst/Data Analyst kompetencia hiányáról, de ezzel talán egy majd másik cikkben foglalkozunk).

A lényeg, hogy kelleni fognak továbbra is az adattárházak. Megváltozik a funkciójuk, az építési módjuk és tényleg találóbb szó lesz rájuk az adatplatform, mint az adattárház. De szükség lesz továbbra is egy olyan adatarchitektúrára, amelyre ráengedhetjük majd az AI-t. Ahol kontextusban lesznek az adatok, ahol nem a forrásrendszert terhelik az AI asszisztensek/ügynökök, stb. Nevezhetjük egyébként tényleg AI adatplatformnak, ha így kapunk felhatalmazást a megépítésre.

Akit egyébként érdekel, hogy milyen adatarchitektúrákat építünk ma, az jöjjön el a következő BI ás adattárház projektvezető képzésre, mert ott részletesen is átbeszéljük őket. Muszáj vagyok így reklámozni, mert annyira béna a neve (BI és adattárház projektvezető képzés), de nem volt még energiám új nevet kitalálni neki. Pedig a tartalom új…

Standalone Copilot in Power BI will be turned on by default...

Kővári Attila — Sun, 14 Sep 2025 20:25:12 +0000

Olvasom, hogy

Mit jelent ez nekünk? Hogy el fog jönni az idő, amikor már nem (csak) riportok alá kell adatmodellt terveznünk. Ma még szinte csak akkor tervezünk csillagsémás modellt, ha sok riportot kell kiszolgálnunk, ha ad-hoc elemzésre is tervezzük, stb. De ez nagy valószínűséggel meg fog változni, ha jön a Copilot és rácuppan minden adatmodellünkre és megpróbálja belőle kiforgatni a kért számot. Valószínűleg hatványozottan fontosabb lesz a csillagséma, az igényfelmérésen alapuló adatmodell tervezés, az adatmodell dokumentációja, a best practice-ek alkalmazása, mint ma.

Lehet, hogy egy nagy ámokfutás lesz belőle. Lehet, hogy óriási pofáraesés lesz az adatokkal chatelés, de lehet hogy „phd szintű” elemzői válaszokat köp majd ki a Copilot. Nem tudom. Mindenesetre fel fogja forgatni a világot, és az, ami ma úri huncutságnak számít, az innentől kezdve kötelező lesz. Mikre gondolok: Legyen csillagsémás az adatmodell, rejtsük el a felesleges mezőket, töltsük ki a description-öket, stb. Pont, mint amit eddig best practice-ként tanítottunk az adatmodell tervezés során.

Nem szeretnék riogatni senkit, haladó szinten eddig is szükség volt ezeknek az alapelveknek a betartására, de gyönyörűszép dashboardokat tudtunk építeni csillagsémás adatmodell nélkül is description-ök nélkül is, és best practice-ek nélkül is. Csakhogy ezekre nem engedtük rá sosem az AI ügynököket/asszisztenseket, most viszont, ha akarjuk, ha nem, rá fog ugrani a Copilot, és megpróbálja majd a nem ad hoc-ra tervezett adatmodellekből megmondani a tutit. És ahogy egy elemzőnek, úgy valószínűleg a Copilotnak is bele fog törni a bicskája. Csakhogy amíg az elemző érzi, hogy nem jó szám jött ki, addig a Copilot teljes mellszélességgel kiállva kiköpi majd, hogy 43…

Megj.: Az október 2.-i i adatmodell-tervező workshopon elkezdünk majd foglalkozni ezzel a témával is. Egyelőre csak elméleti szinten, de készülünk már arra a korra, amikor az adatmodellt majd AI ügynökökre/asszisztensekre is kell optimalizálni…

Üdv újra!

Kővári Attila — Sun, 24 Aug 2025 17:06:29 +0000

Vége a vakációnak itt a BI projekt blogon, nézzük mi várható a közeljövőben.

A mi már fix:

2025. szeptember 18-19: Power Pivot videókurzus… „Az Excelnél nincs jobb ad-hoc adatelemző eszköz, csak nagyon máshogy kell használni, mint ahogy most használjuk.” Ezt szinte minden előadáson elmondom, mert az a tapasztalat, hogy mindenki szereti fikázni az Excelt, pedig nem egy rossz eszköz, csak okosan kell használni…
2025. szeptember 25: Power BI workshop: Klasszikus alapozó Power BI tanfolyam azoknak, akik még csak most ismerkednek a Power BI-jal. Többszáz tanfolyam lement már belőle, óriási anyag. Mára gyakorlatilag egyeduralkodóvá vált és de facto szabvány lett a Power BI az elemzői, kontrolleri munkakörökben.
2025. október 2. Power BI Adatmodell tervező tanfolyam. Pár hónapja ment le belőle az első nyílt képzés, és annak tapasztalatit felhasználva a mostani képzésen nagyobb hangsúlyt kap majd a BA szerep, az üzleti igényfelmérés és követelmény elemzés, mert az a tapasztalat, hogy ebből a tudásból nagyobb hiány van, mint gondoltam. És e nélkül nem lehet jó adatmodellt tervezni. Ráadásul itt dörömböl az ablakon az AI, és ahhoz hogy chatelni tudjunk az adatainkkal, meg kell tanulnunk szisztematikusan felmérni az igényeket és a felmérés eredményét vissza kell tudnunk csatornázni az adatmodellbe. Egyelőre még csak sejtéseink vannak, hogy mitől lesz az AI-nak jobb kimenete, de elindulunk ebbe az irányba is. Semmit sem vesztünk egy jól dokumentált adatmodellel...
Október 16: BI és DW projektvezető képzés: Ezt a tanfolyamot tavaly teljesen újraírtam. Át kéne brandelni, mert már inkább vezetői, mint projektvezetői a képzés, adattárházak helyett Delta Lake-ekkel foglalkozunk, stb. De még nem találtam meg a jó címet.

Ezen kívül futnak a Support/mentoring programok, le van már fixálva jónéhány kihelyezett képzés, mennek a fejlesztések is, és mindemellet zabálja az időt az AI, aminek még nagyon keresem a szerepét és a helyét...

Örülök, hogy itt van, örülök hogy olvassa a BI projekt blogot és remélem, hogy ősszel személyesen is találkozunk majd.

Vakáció!

Kővári Attila — Wed, 16 Jul 2025 15:15:11 +0000

Én nem, de a BI projekt blog most szabadságra megy…

Találkozunk szeptemberben!

Az első Power BI adatmodell tervező workshop tanulságai

Kővári Attila — Fri, 13 Jun 2025 12:33:34 +0000

Milyen volt az első Power BI adatmodell tervező workshop?

Hosszú… Amikor a tanfolyamot fejlesztettem, megfogadtam, hogy ezúttal a kevesebb több elvet követem. Aztán amikor eljött a tanfolyam előtti hétvége, rápillantottam a résztvevők listájára, és megijedtem: Mi lesz, ha kevés lesz? Mi lesz, ha valaki hiányol majd valamit? Pont, mint amikor vendégeket várunk: Mi lesz, ha elfogy a kaja? Mi lesz, ha a vendégek éhesen távoznak? Na, azt már nem!

Úgyhogy a hétvégén hozzácsaptam az amúgy sem rövid anyaghoz még vagy 60 diát. Olyan témák is bekerültek, mint például a historizáció. Pedig amikor a tanfolyamot összeraktam, határozott elképzelésem volt, hogy erről most nem beszélek. Haladó téma, inkább fókuszáljunk a módszertanra. Aztán jött a hétvége, és gyorsan ez is bekerült. Gondoltam elrejtem, és ha valaki rákérdez, akkor majd előveszem…

De nem rejtettem el. Ha pedig felvillan a kivetítőn, akkor nem lehet kihagyni vagy csak szőrmentén elmagyarázni. Úgyhogy elmondtam (ezt is). Az alábbi ábrán látszik is, ahogy veszettül magyarázom…

Konklúzió? Most úgy gondolom, hogy a következő képzésen nagyobb hangsúlyt kap a BA (Business Analyst) oldal, az adatmodell tervezés elméleti részét pedig visszahúzom az eredetileg tervezett szintre. Vagy tényleg elrejtem, és csak akkor veszem elő, ha kérdésként felmerül. :-) Meglátjuk.

Mindenesetre most hagyom még egy kicsit ülepedni az anyagot. Várok még visszajelzést a résztvevőktől, jött két konkrét igény kihelyezett képzésre is, és ezek tapasztalatai alapján fogom véglegesíteni a következő tanfolyam anyagát. (Ami valószínűleg október 2.-án lesz. Jelentkezni itt lehet majd: Power adatmodell tervező workshop)

Köszönöm az úttörőknek ezúton is, hogy eljöttek az első tanfolyamra. Ők azok, akik elsőként kapták meg az új anyagot, és az ő visszajelzéseik alapján lesz majd jobb a következő tanfolyam. Nekik hálás köszönet még egyszer, a többiekkel pedig találkozzunk a következő tanfolyamon!

Nem csillagsémát tanítok, hanem azt, hogyan kezdjen neki. Mert az a nehéz…

Kővári Attila — Tue, 03 Jun 2025 08:24:37 +0000

Sokan kérdezték, miben más ez az új tanfolyam? Mivel tud ez többet, mint más csillagsémás adatmodell tervező tanfolyam? És bár nem akarok kampányolni mellette, de hagy fejtsem ki itt is, hogy miben.

Aki csillagsémát oktat, az rendszerint végigmegy a dimenzió- és ténytábla típusokon, példákon keresztül bemutatja azok üzleti alkalmazásait, és bemutat jónéhány speciális esetet, mint a many-to-many kapcsolatok, kompozit dimenziók, stb. Így oktattam és is. De mi a baj ezzel a módszertannal? Hogy csak az tudja használni, aki már tervezett adatmodellt... Aki még nem tervezett adatmodellt, az nagyon nehezen fog tudni ezek alapján elindulni. A többség fel fogja tudni mondani a leckét, hogy vannak dimenziók meg ténytáblák, hogy van csillagséma és hópehelyséma, de önmaga nem lesz képes nulláról csillagsémát építeni.

Ez tavaly tudatosult bennem igazán egy kihelyezett tanfolyamon. Kívülről néztem a résztvevőket miközben mondtam az anyagot, láttam hogy értik, láttam hogy tudják követni, de amikor feltettem azt a kérdést, hogy holnap, amikor már nem leszek itt, és bejön a főni, hogy csináljatok x riportot, akkor hogyan fogtok nekiállni adatmodellt tervezni? Mit tudtok majd használni az eddig tanultakból? Akkor döbbent csend volt…

Leültem, és felírtam a Tapasztalatok.docx-be, hogy Ez így nem jó! Túl elméleti. Nem fogják tudni az elméletet használni.

Hazajöttem, és nekiálltam újraírni a tanfolyamot. Egy darabig próbáltam megmenteni ami menthető, aztán rájöttem, hogy tök felesleges. Kuka az egész. Nem elméletet kell oktatni, hanem gyakorlatot. Elővettem azt a módszertant, ahogy én terveztek adatmodellt, és ezt gyúrtam tanfolyammá. Onnan indultam, hogy van 15-20 riportra igény és ezek alá kell olyan adatmodellt tervezni, amiből mind a 15-20 riport elkészíthető. Pont mint a való életben. Megtanuljuk majd, hogy hogyan gyűjtjük össze, mérjük fel szisztematikusan az igényeket, hogy hogyan kell azokat átforgatni attribútumokká és mutatókká, majd ha ezekkel megvagyunk, akkor ezekből hogyan lesznek a közös dimenziók, mi lesz tény. A cél, hogy átadjam a módszertant, ami alapján reményeim szerint bárki el fog tudni indulni, és a módszertant lemásolva saját adatmodellt tervezni. Aki pedig tovább akar menni az kap annyi muníciót, hogy megértse, hogy miért van annyi dimenzió- és tény típus, melyiket mikor kell használni, stb.

Legalábbis ez a cél. Aztán hogy ezt mennyire sikerül megvalósítani, majd kiderül a jövő heti tanfolyamon…

A széles tábla bűvölete – és korlátai

Kővári Attila — Sun, 25 May 2025 15:40:48 +0000

Írtam korábban, hogy amikor kukáztam a régi csillagsémás tanfolyamot és csináltam egy újat, akkor három fő szempontot tartottam szem előtt:

Legyen gyakorlatias
Elemzőknek szóljon
és legyen teljes egészében Power BI-ra szabva

Ebben az elemzőknek szóljon nem csak azt jelenti, hogy használjam a terminológiájukat, hanem azt is, hogy az ő fejükkel gondolkodjak, onnan induljon a tanfolyam, ahol ők most tartanak. És ők előszeretettel használják a „széles táblákat”, ezért a tanfolyamot azzal kezdjük majd, hogy átbeszéljük a szélestáblát, megnézzük mikor jó, milyen korlátai vannak, és mikortól nem használható.

A széles tábla egy olyan „adatmodell” ami egy táblából áll: A széles táblából. (Angol terminológiában Flat vagy wide táblának is nevezik)

A széles tábla egy entitásra (pl. vevő) fűzi fel ez összes információt: Vevő neme, kora, forgalma, tavalyi forgalma, tavalyelőtti forgalma, panaszok száma, stb.

Az elemzők imádják a széles táblát. Az érvük egyszerű: Egy ilyen táblából pusztán az oszlopok szűrésével szinte minden lekérdezés igény kielégíthető. És ebben a kontextusban igazuk is van.

Ráadásul a Power BI is jó performanciával szolgálja ki a kérésüket. Az oszlopalapú adatbáziskezelők ugyanis pont az ilyen típusú kérések kiszolgálásban ügyesek, amikor egy oszlopot kell aggregálni ugyanazon tábla egy másik oszlopa alapján. Nem kell kapcsolatokon keresztül bolyongani a modellben, a kérdések jelentős részét meg tudja válaszolni a storage engine a formula engine nélkül is

Mégsem az legjobb gyakorlat hogy széles táblával elégítsük ki az elemzők igényét. Ez az adatmodellezési gyakorlat addig működik, amíg a lekérdezéseink egy entitásra (pl vevő) vonatkoznak. Nem árbevételt vagy a panaszok számának változását akarjuk elemezni, hanem a vevő árbevételét, vagy a panaszainak számát.

Igazából egy olyan területet tudok mondani, ahol a széles tábla lett domináns: Ez pedig a kampánymenedzsment. A kampánymenedzserek ugyanis egy olyan táblából szeretnek dolgozni, amelynek minden egyes sora egy ügyfelet tartalmaz, és minden mutatószám ügyfél szintre van előaggregálva. Nekik ugyanis arra van szükségük, hogy ügyfélcsoportokat tudjanak egyszerű szűrésekkel leválogatni, és erre ez a legjobb tárolási struktúra. Eszméletlen mennyiségű oszlop, és annyi sor, ahány ügyfél.

Más elemzési területen ugyanakkor a széles tábla már csak korlátokkal alkalmazható. Onnantól kezdve ugyanis, ha már csak bejön a dátum, mint elemzési szempont, a széles tábla megbukik. Márpedig dátum minden elemzéshez kell. Mindent dátumra nézünk, minden korábbi dátumokhoz viszonyítunk, stb.

Ráadásul a széles táblát nagyon nehéz karbantartani, nem lehet historizálni, …Számtalan OK van, ami miatt a széles táblát csak ritkán használjuk. Nagyon ritkán.

Hááát valahogy így fogom bevezetni a tanfolyamon a csillagsémás modellezés elméletét. Rugózunk még egy kicsit majd azon is, hogy nyers forrásrendszeri modellekkel mi a baj, ezt hogyan tudjuk egy kicsit jobbá tenni, ha nem akarjuk a csillagsémát megtervezni, és azon is, hogy mennyire készítsük elő az adatokat megjelenítésre, mikor kell előaggregálni az adatokat stb. Aztán ráfordulunk a csillagsémás modellek tervezésére. Legalábbis ez a terv :-)

Riportgyár

Kővári Attila — Tue, 20 May 2025 07:55:02 +0000

Ma már nem az a gond, hogy nincs adatunk, vagy nincs olyan infrastruktúránk amely nagy mennyiségű adatot képes kiszolgálni, hanem az, hogy nem tudjuk a technológiát termőre fordítani. Nem tudjuk a BI-t használni, nem tudjuk az eredményeit beépíteni a vállalati kultúrába.

Sok oka van annak, hogy miért nem. Az első, hogy még mindig riportokban gondolkodunk: Legyen kész ez a riport, váltsuk ki azt a riportot, csináljon a szállító 100 riportot, stb.

Anno, amikor ezt a szakmát kezdtük, még nem voltak BI rendszerek. BI rendszerek helyett vezetői információs rendszereket építettünk, és a BI-t vezetés támogató eszköznek tekintettük. Miért? Mert mindig valamilyen vezetői cél köré építettük. A vezetőknek volt valamilyen víziója, vagy valamilyen intézkedése, aminek hatását vissza akarta mérni. "Csökkenjen X. Most mennyi? Fogalmam sincs. Most csak feltételezem, hogy sok. Tudjam meg mennyi, kezdjük el mérni, lesz bázisunk, és a jövő évi célkitűzésünk az lesz, hogy csökkentsük X-et 30%-kal."

Aztán átfordultunk riportgyárba. Az lett a cél, hogy elkészüljön a riport. Nem tudom, hogy érzi-e a különbséget, de amíg a csökkenjen az X elvárás beépült a vállalat folyamataiba, addig egy riport nem tölti be ugyanazt a szerepet. Anno könnyű volt visszamérni a VIR sikerességét: Csökkent x 30%-kal? Igen. Kitermelte a VIR-t? igen. Akkor megérte.

Ugyanezt egy riportról már nehezen mondhatjuk el. Persze lehet, hogy a 100 riport mögött többszáz vezetői cél bújik meg, mégsem érzem azt, hogy az ezekből hozott döntések visszaépülnek a vállalat folyamataiba. Ahogy azt sem, hogy célokat fogalmaznának meg a riportok alapján… Inkább azt érzem, hogy a riport lett a cél. Ha elkészül, akkor pipa. A probléma megoldva...

Pokolba a csillagsémával

Kővári Attila — Tue, 13 May 2025 06:42:55 +0000

A csapból is az folyik, és én magma is veszettül hangoztatom, hogy Power BI-ban a datasetek/szemantikus modellek építésekor a csillagséma a legjobb megoldás.

De amivel nem tudok azonosulni, az a csillagséma egyetlen jó megoldásnak történő elfogadása. A minap például a szemem láttára koncoltak fel egy fejlesztőt, mert letért a csillagsémás útról egy olyan esetben, amikor a csillagséma nem adott jó megoldást. "Pokolba a csillagsémával, ha nem az adja a legjobb megoldást" - mondta.

A téma supply chain, a megrendelő azt szerette volna látni, hogy hány termék lett kiszállítva és hány termék lett visszahozva. Hogyan modellezzük ezt a csillagsémás módszertan szerint? Építünk egy Kiszállítás ténytáblát, és egy Visszáru ténytáblát majd összekötjük őket a közös dimenziótáblákkal.

Igenám, de mi van akkor ha az a fránya ügyfél rendelésenként akarja látni, hogy mennyi volt egy rendelésen a kiszállított és visszahozott mennyiség? Hogyan modellezzük ezt egy csillagsémával?

Ha kőkeményen ragaszkodunk a csillagsémás modellezés alapelveihez, akkor sehogy:

Definíció szerint ténytáblát ténytáblával nem kötünk, azaz nem kötjük össze a kiszállítás és visszáru táblákat.
Definíció szerint nem építünk olyan dimenziótáblát, amelyek elemszáma közel annyi, mint a ténytábla elemszáma vagy ahol a dimenzió tábla a ténytábla sebességével növekszik. Ennek következtében nem köthetjük össze a kiszállítás és visszáru ténytáblát a rendelésszám dimenziótáblával, mert a rendelésszám dimenzió tábla elemszáma közel azonos a kiszállítás ténytábla elemszámával.

Régen, amikor EGY csillagsémás adattárháza volt a vállalatnak, akkor erre adattárház szinten nem adtunk megoldást. „Oldja meg a BI eszköz” puffogtattuk. Adjuk a kiszállítást, adjuk a visszárut, oldja meg az adattárház feletti BI eszköz az összekötését.

De ez régen volt. Ma már nem vállalatonként építünk egy csillagsémát, hanem riportonként egyet. Ma már nem egy fejlesztőcsapat építi az adattárházat, hanem milliónyi felhasználó épít milliónyi „mini adattárházat”. És ebben a világban az adott riport/probléma megoldásához kell a legjobb adatmodellt megtalálni, és az lehet, hogy nem tisztán csillagsémás lesz...

Összefoglalva: Power BI-ban továbbra is a csillagséma adja a legjobb megoldást. Erre lett optimalizálva az adatbázis kezelő, ezt tudják legkönnyebben lekérdezni a felhasználók, erre könnyű megírni a DAX képleteket, stb. De vannak problémák, amire a csillagséma nem ad megoldást, vagy nem a csillagséma adja a lejobb megoldást, és ekkor nyugodtan le lehet térni a királyi útról. De csak ekkor és kizárólag ekkor. Mert azért a csillagséma a király :-)

Melyik a legkorábbi nap, amit képes kezelni a Power BI?

Kővári Attila — Wed, 07 May 2025 00:50:43 +0000

Az adatmodell tervező tanfolyam fizikai adatmodell tervező blokkjában megbeszéljünk majd, hogy kerüljük a DateTime adattípust, hogy nem használunk DateTime oszlopot, hanem szétvágjuk Date és Time típusú oszlopokra.

Az okokat elolvashatja itt is (Miért kerüljük Power BI-ban a DateTime adattípust?), de a lényeget kiemelem ide is:

Emel az elemzői szabadságon, ha szétvágjuk a DateTime oszlopot két külön Date és Time oszlopra
És a Power BI hatékonyságát is növeli, mert a két oszlopot sokkal jobban tudja tömöríteni, mint az egyet
És ha kötni szeretnénk DateTime oszloppal, akkor a csillagsémás modellezés szerint létre kéne hoznunk egy DateTime típusú dimenzió táblát is, ami ezer sebtől vérzik. Szóval nem használjuk.

Amikor ezt magyarázom, figyelem majd hogy mennyire köti le a téma a résztvevőket. Ha unják, akkor ennél többet nem mondok. Ha csillog a szemük, akkor kicsit jobban kifejtem a külön tárolás előnyeit, vagy megmutatom egy példán, hogy mennyivel kevesebb helyet foglal a két oszlop, mint az egy, stb. Ha pedig azt látom, hogy fáradtak, akkor előhúzok egy sztorit, amivel kicsit felébresztem őket. Mondjuk ezt:

„Nem tudom, hogy tudjátok-e, de a VeriPaq DateTime adattípusának a legkisebb értéke 1899-12-31, de az első, DAX által hivatalosan is támogatott nap a 1900. március elseje. Tehát hiába tudja az adatbázis kezelő 1900 január elsejétől tárolni a dátumokat, a DAX csak március elsejétől tud vele számolni. Illetve számolni korábbi időpontoktól is tud, csak van egy bug, ami miatt DAX kalkulációkban hivatalosan nem támogatottak a március elseje előtti napok. Ez annak köszönhető, hogy anno a Lotus 1-2-3 táblázatkezelő az 1900-as évet szökőévnek tekintette (holott nem volt az), ezt a hibát az Excel kompatibilitási okokból átvette és szintén kompatibilitási okokból a DAX is átvette. Úgyhogy az idősor kalkuláló függvények hibát, vagy pontatlan eredményt adhatnak, ha 1900. március elseje előtti időpontra ugranak :-)”

Persze sosem volt még szükség 1900. március 1. előtti DAX kalkulációkra, de arra jó lesz a sztori, hogy egy kicsit felrázzam a hallgatóságot, és aztán visszasüllyedjünk az adatmodellezés mocsarába :-)

A lyukacsos tér

Kővári Attila — Mon, 14 Apr 2025 07:54:24 +0000

Hozok egy teljesítmény romboló példát az adatmodell tervező tanfolyamról. Vaciláltam, (vacilálok még most is), hogy részévé tegyem-e a tanfolyamnak, mert az adatmodell tervezésre nincs közvetlen hatással, csak annak teljesítményét rombolja. Meglátjuk. De kidolgozom, opcionálisan lehet majd kérni ott is vagy akár a holnapi Power BI tanfolyamon is, illetve kiteszem ide a BI projekt blogba is, hogy miért káros beimportálni felesleges sorokat Power BI-ba.

Mikor felesleges egy sor?

Ha elavult
Ha nem használjuk
Ha túl részletes

Elavult

A minap pedzegettem, hogy felesleges beimportálni a 3-4 évvel ezelőtti adatokat, mert olyan gyorsan változik a világ, hogy az esetek jelentős részében nincs értelme a távoli múlthoz hasonlítani. Ugye ennek volt típuspéldája a Covid utáni időszak, amikor teljesen felesleges volt a Covid előtti időszakhoz hasonlítani.

Nem használjuk

Van értelme a dátum táblába betölteni a következő évet? Nincs. Illetve, ha nem tartoznak hozzá számok a ténytáblákban, akkor nincs. Tudom, hogy majd jönni fog a következő év és akkor már szükség lesz rá, de majd betöltjük akkor.

A felesleges sorok betöltése több szempontból is káros:

A felhasználóknak mindig át kell rágniuk magukat az üres éveken, mert a szeletelőkben, szűrökben megjelennek.
Teljesítmény problémát okoznak

Miért okoz 1 plusz év teljesítmény problémát? 365 napról van szó, ami 365 plusz sor egy táblában…

Mert a DAX függvények a dimenziók által kifeszített teljes teret bejárják függetlenül attól, hogy tartozik-e hozzájuk adat vagy sem. A FILTER() függvény például minden egyes napra kiértékeli a szűrőfeltétel teljesülését függetlenül attól, hogy az adott naphoz tartozik-e adat vagy sem. Ráadásul a FILTER() függvény sorról sorra haladva értékeli ki a feltételeket. Nem tud kötegelve feldolgozni mint az SQL, nem tud párhuzamosítani, mindent egyes kiértékelést sorról sorra, egymás után sorosan hajt végre. Hiába van többprocesszoros gépünk, nem fogjuk tudni kihasználni, a FILTER() csak egyet szálat tud használni.

De ez nem csak a dátum táblára igaz mindez. Ha csak a belföldi értékesítést elemezzük, akkor nem kell az export cikket betölteni, elég azokat amelyeket belföldre értékesítünk. És igy tovább. Ahogy anno a többdimenziós adatbázis kezelők teljesítményének sem tett jót a lyukacsos kocka, úgy a DAX teljesítményét is rontja a lyukacsos tér.

Túl részletes

Ha aggregálással úgy tudjuk csökkenteni a sorok számát, hogy nem vesztünk értékes információt akkor érdemes a táblákat még import előtt előaggregálni. Ezzel a kardinalitás nem csökken, de a sorok számának csökkentése is pozitív hatással van a teljesítményre.

Összefoglalva: Ha csak azokat a sorokat töltjük be, amelyekre valóban szükségünk van, akkor azzal három dolgot is nyerünk:

Kisebb lesz az adatbázisunk mérete
Kedvezünk a felhasználóknak azzal, hogy nem kell a felesleges elemeken állandóan átrágniuk magukat
Gyorsak lesznek a számított mezőink azáltal, hogy nekik sem kell az üres elemek által kifeszített többdimenziós teret feleslegesen bejárniuk

Mester, ha csak egyet mondhatna, mi lenne az?

Kővári Attila — Mon, 07 Apr 2025 09:24:31 +0000

Most, amikor készültem az új adatmodell tervező tanfolyamra, eszembe jutott egy sztori, aminek aktualitást a most kirobbani készülő vámháború ad...

Anno amikor Bill Inmon, az adattárházak egyik legelismertebb guruja Magyarországon járt valamikor a 2000-es évek elején, akkor valaki megkérdezte tőle, hogy

„Mester, ha csak egy adattárház optimalizálási módszert említhetne, akkor melyik lenne az?”
Mire ő azt felelte, hogy „Archiváljátok ki az adattárházból az öreg adatokat”

És ebben a mondatban óriási igazság van… Van értelme a 10 évvel ezelőtti forgalmat az idei forgalomhoz viszonyítani? Nincs. 10 évvel ezelőtt annyira más volt minden, hogy teljesen felesleges hozzá bármit hasonlítani. De nem kell ilyen messzire tekinteni. Covid előtt is más volt minden. És a most kirobbani készülő vámháború után is valószínűleg más lesz minden. Lehet hogy kukázhatjuk vagy parkolópályára tehetjük a SAMEPERIODLASTYEAR() DAX függvényt is, mert nem lesz értelme az előző évhez hasonlítani semmit. Ne legyen így, de az öreg adatokat ettől függetlenül érdemes kukázni.

Power BI-ban hatványozottan igazak a mester tanításai.

Új Power BI adatmodell tervező tanfolyam

Kővári Attila — Mon, 31 Mar 2025 12:15:22 +0000

Elkészült egy új Power BI adatmodell tervező tanfolyam!

Azaz elkészült a korábbi csillagsémás tanfolyamom egy teljesen új változata. Az elődverziót leadtam már jónéhányszor, és sajnos az volt a tapasztalat vele, hogy túl technikai. És ha őszintén visszanézek ezekre a tanfolyamokra, akkor én is úgy érzem, hogy túl korán tanítottam túl sokat. De a legfőbb baj az volt vele, hogy nem az elemzőknek szólt. Úgyhogy kukáztam és újraírtam az egészet. Nulláról. Úgy hogy az elemzők is értsék és szeressék.

Az ihletet az adta, hogy egy projekten megszorultunk időben. Többszáz riport alá kellett csillagsémát tervezni, és nagyon lassan haladtunk. Bonyolult volt az üzleti domain és rövid a határidő. Be kellett vonnunk pótlólagos erőforrást, és megkértük az üzleti felhasználókat, hogy szálljanak be és segítsenek ők is.

Ehhez meg kellett tanitanunk nekik a csillagsémás modellezés alapjait legalább olyan szinten, hogy szét tudják dobálni az igényeket dimenziókra és tényekre. Nyilván nem érdekelte őket a csillagsémás modellezés elmélete, beszélhettem volna nekik a híd táblák szerepéről, vagy a degenerált dimenziókról, magasról tojtak volna rá. Úgy kellett nekik a csillagsémás modellezést megtanítani, hogy nem azt tanítjuk. Úgyhogy a csillagsémás modellezés szépségei helyett azt kezdtem el magyarázni nekik, hogy egy riport elkészítéséhez minek kell dimenziónak lennie és minek ténynek. Elővettünk jópár valós riportot, és megmutattam nekik, hogy hogyan lehet az igényeket strukturáltan elemezni, egységesíteni és dimenziókká, tényekké szintetizálni.

És ez működött…

Az eredmények mindannyiunk várakozását felülmúlta, úgyhogy ugyanezt a módszert fogjuk használni az új Power BI adatmodell tervező tanfolyamon is. Ahelyett, hogy letolnám az elméletet, egyből elkezdünk dolgozni. Kvázi csillagsémás oktatás nélkül, csak arra koncentrálva, hogy egy riport összeállításához milyen adatmodellt kell készítenünk. Aztán ha ez megy, akkor mögé tesszük az elméletet és elmagyarázom, hogy miért így csináltuk. Így már lesz mihez kötni az elméletet, érthetőbbé válik az adatmodell tervezési folyamata és könnyebben megtanulják a csillagsémás adatmodell tervezést. Csak akkor megyek mélyebb technikai szintre, amikor nyitottak rá. Rájöttem ugyanis, hogy én is így tanultam meg anno a csillagsémás modellezést. Először nekiestem a feladatnak, és utána tanultam meg a mögötte lévő tudományt.

Ráadásul ezt a módszert követve kezdhetjük a tanfolyamot rögtön a résztvevők problémáinak megoldásával. Azaz hozhatják ők az igényeiket, riportjaikat, és már a kezdetektől fogva azon dolgozva tanulhatunk. A nyílt és kihelyezett Power BI adatmodell tervező tanfolyamra viszem én a valós példákat, de az on-the-job tanfolyamra hozhatják a résztvevők a sajátjukat.

Az első tanfolyam június 11.-én lesz. Előképzettség nem kell hozzá, együtt megyünk majd végig az üzleti igényfelmérés, feltáró adatelemzés, és adatmodell tervezés folyamatán, ezt egészítjük ki a Power BI specifikus témákkal és így adom át azt a módszertant, amit a napi rutinban rendszeresen használunk. A célközönség szokás szerint az elemző, kontroller, riportfejlesztő, adatelemző, data engineer lesz. Nevezzük bárhogy azokat, akik a Power BI riportot készítik.

Jelentkezni már lehet! Részletes tematika, ár és egyéb részletek itt:

Jöjjön el az első tantermi képzésre, és tervezzünk közösen adatmodellt!

Újabb publikusan elérhető hazai Power BI dashboardok

Kővári Attila — Thu, 13 Mar 2025 09:38:10 +0000

Újabb gyöngyszemmel bővült a publikusan elérhető hazai Power BI dashboardok tárháza. Most a Magyar Energetikai és Közmű-szabályozási Hivatal (MEKH) váltott a ppt-pdf alapú adatszolgáltatásról Power BI alapú adatszolgáltatásra, és tette közzé az adatait interaktív dashboardokon. A dashboardok itt tekinthetők meg:

Mindig hatalmas öröm számomra, ha valaki vált a hagyományos ppt-pdf alapú adatszolgáltatásról, valamilyen korszerűbb adatszolgáltatási formára. A pdf nem interaktív, nem mehet benne lefúrni, nem lehet belőle az adatokat kiexportálni. Ehhez képest egy Power BI-os megoldás űrugrás, ami ráadásul lehetőséget biztosít olyan részletezettségű adatok bemutatására is, amelyre a pdf nem ad lehetőséget.

Jó lenne egyre több ilyen példát látni. Hiszek abban, hogy ha odaadjuk vagy megmutatjuk az adatokat másoknak, akkor abból mások tanulhatnak, megérthetnek folyamatokat, összefüggéseket fedezhetnek fel amelyeket felhasználhatnak a munkájukhoz vagy saját maguk gyarapodására.

Szép munka, gratulálok innen is.

Az interaktív Power BI riportok itt érhetőek el: