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

Í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:

1. Legyen gyakorlatias
2. Elemzőknek szóljon
3. é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 :-)