Blog

Brutális visszaesés, vagy vendégforgalom növekedés volt a Balatonon? Kiderül a cikkből

Vége a vakációnak itt a BI projekt blogon is, nézzük mi várható szeptember-októberben

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

A múltkori személyek modellezése Power BI-ban című cikkben megnéztük, hogy hogyan tudjuk lekezelni az azonos nevű személyek megkülönböztetését adatmodell oldalon, de nem beszéltünk róla, hogy 1) ezt hogyan valósítja meg a háttérben a Power BI, 2) milyen pofonokat kaphatunk a módszer használata közben. Ezekről olvashat a most következő cikkben

Ha több dátum szerint is szeretnénk elemezni ugyanazt az adatkört Power BI-ban, akkor a) vagy annyi dátum táblát hozunk létre, ahány dátum szerint szeretnénk elemezni az adatsort b) vagy egy dátum táblát hozunk létre és annyi számított mezőt, ahányféleképpen elemezni akarjuk az adatkört. A kérdés csak az, hogy melyik modellezési módszert válasszuk? Kiderül a cikkből…

A múltkori ismétlődő szóközök megtartásával foglalkozó cikkben elkezdtük már pedzegetni, hogy milyen megoldások vannak Power BI-ban az azonos nevű személyek összevonásának elkerülésére. Ott az volt a megoldás, hogy az az azonos nevű személyek nevéhez hozzáfűztünk 1, 2, 3… n láthatatlan szóközt. Ezzel be tudtuk csapni a Power BI-t hiszen ő 1,2,3…n különböző személyt látott, de megjelenítésben nem látunk köztük különbséget. Működik ez a megoldás most is de ma már mást használunk helyette. Mit? Erről szól a most következő cikk…

Az adattárházak historizáltak, azaz az adattárház minden egyes soráról meg tudjuk állapítani, hogy az mettől meddig volt érvényes. Tegyük fel hogy az érvényesség kezdetét a ValidFrom, a végét a ValidTo oszlopokban tároljuk. Kérdés: A korábbi rekord ValidTo-ja egyezzen a későbbi rekord ValidFrom-jával, vagy legyen közte egy miliszekundum rés? Másképpen fogalmazva összeérő idősort építsünk, vagy inkább össze nem érőt? A válasz kiderül a cikkből...

PBIDesktop.exe - System Warning

A Power BI vizualizációk alapértelmezetten kicserélik az ismétlődő szóközöket egy szóközre. De mi a teendő, ha ezekre szükség van? Hogyan tudjuk megtartani őket? Kiderül a cikkből.

Adott egy vizualizáció, amely elkészítéséhez egy speciális számított mezőt (measure-t) kell létrehoznunk. A számított mező csak a vizualizáció kontextusában van értelmezve, más kontextusban nem. A measure-t nem akarom betenni az adatmodellbe, mert a vizualizáción kívül nem biztos, hogy minden szűrésre helyes eredményt ad vissza. Mit tehetek ebben az esetben? Kiderül a cikkből...

A keddi Power BI meetupon arról fogok beszélni, hogy hogyan tudjuk minőségbiztosítani a Power BI dataseteket. De miért annyira fontos ez a téma? Miért kell minőségbiztosítani egy önkiszolgáló módon készített Power BI megoldást? Kiderül a cikkből

Tévhit: „Power BI-ban ha valakitől megvonom a hozzáférést egy régióhoz, akkor ő biztos, hogy nem láthatja a régió adatát”

Miért kell állandóan számított mezőt csinálni, amikor a Power BI kiszámolja nekünk az oszlop összegét? (Miért ne használjunk implicit measure-t?) Kiderül a cikkből

Adott egy vállalat. Feltételes formázást szeretne használni Power BI-ban, de standard ikonkészlet számára kevés. 5 „jelzőlámpát” szeretne használni a 3 helyett ráadásul a gyári ikonok színe sem felel meg az arculati kézikönyvnek. Tovább tetézi a nehézségeket, hogy a vállalat Power BI Riport Servert használ, amelyik nem lát rá a publikus internetre. Hogyan tudnánk neki segíteni? Kiderül a cikkből.

Power BI táblázatokban tudjuk a cellák háttérszínét feltételesen formázni vagy tudunk a számokhoz (értéküktől függően) ikonokat rendelni. Ehhez kapunk egy űrlapot ahol mindent össze tudunk kattintgatni, de lehetőségünk van arra is, hogy egy számított mező (measure) adja vissza a színt, vagy az ikont, amit a Power BI-nak meg kell jelenítenie. A következő cikkben ez utóbbival fogunk foglalkozni, és megnézzük hogyan tudjuk egy számított mezővel visszaadni a megjelenítendő ikon nevét a Power BI-nak

Mikor használhatunk Power BI-ban ékezetes karaktereket tábla- és oszlopnevekben? Eddig azt tanítottam, hogy mindig, de most beleszaladtam egy pofonba...

Milyen volt 2022? Milyen lesz 2023? Kiderül a cikkből...

Sokan favorizálják azt a módszert, amely összegyűjti, és egy táblában jeleníti meg a Power BI adatmodell összes számított mezőjét (a measure-öket). Jó ez a gyakorlat vagy nem? Kiderül a cikkből.

Hogyan etessük az adattárházat? Közvetlenül a forrásrendszerből, vagy közvetve, interfész fájlokon keresztül? A közvetlen lekérdezés lehetőségének van számos előnye: Nem kell hozzá külső segítség, az adattárház fejlesztője közvetlenül le tudja kérdezni a forrásrendszert, ezáltal csökken a függőség, stb. Ez az előny azonban nagyvállalati környezetben könnyen elolvadhat, és a közvetlen kapcsolat helyett interfész fájlokon keresztül építjük fel az adattárház - forrásrendszer kapcsolatot. Mikor használunk közvetlen kapcsolat helyett interfész fájlokat? Kiderül a cikkből

SQL Serverben és más relációs adatbáziskezelőkben is megmondhatjuk, hogy hány tizedesjegy hosszan tároljuk az adatainkat de a Power BI / Power Pivot adatbáziskezelőjében (Vertipaq) erre nincs lehetőségünk. Miért nincs? Kiderül a cikkből.

Van egy nagyon nagy hajtóerő, egy láthatatlan kéz, ami a versenyszférát a BI/adatelemzés irányába tereli. Ez az állandó növekedési kényszer. Évről évre jobbnak, olcsóbbnak, hatékonyabbnak kell lenni. És ehhez kellenek az adatok, kell a múlt, amihez képest jobbnak kell lenni. A most következő cikkben hozok is egy sztorit, hogy mindezt gyakorlati példával is alátámasszam.

A mentoring programok egyik legnagyobb kockázata az, hogy a mentorált feláll a cégtől, és a felszedett tudást máshol kamatoztatja. Ennek kockázatát úgy tudjuk csökkenteni, hogy a mentorált képzésével párhuzamosan a BI szervezetet is „mentoráljuk” és olyan rendszereket, módszertanokat fejlesztünk, amelyek a mentoring program befejezése után is ott maradnak, és amelyek eredményeit az új belépők is élvezhetik.

Jöjjön egy rövid számvetés a BI projekt blog elmúlt 17 évéről és a blogolás mögötti motivációról

Megint csiszoltam egy kicsit a szeptemberi BI és adattárház projektvezető képzés anyagán. Illetve azon belül az adattárház bevezetések kockázatát tárgyaló blokk tartalmán. Ebben a blokkban van egy fejezet, ami a szervezeti ellenállással, és annak leküzdésével foglalkozik. De miért tiltakozik mindenki az adattárház ellen? Ki lesz a legnagyobb ellenlábasa az adattárháznak? Kiderül a cikkből...

A Welcome back után jöjjön az első nap és nézzük meg, hogyan kell előkészíteni az adattárház projektek első napjait…

Vége a nyárnak, tűrjük fel az ingek ujját, és és nézzük meg mi várható az év hátralevő részében…

Ha végre itt a nyár, és meleg az idő...

Jöjjön egy elgondolkodtató párbeszéd az adattárház projektek csatamezőiről...

A BI akkor segít igazán, ha vannak céljaink, és az azokhoz képesti eltérést szeretnénk megmutatni. Ekkor lehet igazán szép csilivi szines-szagos dashboardokat készíteni. De mi van, ha nincs még célunk, mert azt sem tudjuk, hogy hol tartunk? Mit tud segíteni ekkor a BI? Kiderül a cikkből

A kilencvenes évek végén/2000-es évek elején óriási népszerűségnek örvendtek a kiegyensúlyozott mutatószámrendszerek. Ezek is azt hangsúlyozták, hogy a pénzügyi mutatók mellett más (nem pénzügyi) aspektusokból is monitorozni kell egy vállalat teljesítményét. Egy KPI monitorozása önmagában ugyanis veszélyes lehet…