Miért használjuk az oszlopalapú adatbázist az OLAP adatbázis helyett?


Nemsokára megjelenik az SQL Server 2012 ahol majd szabadon választhatunk az oszlopalapú és a többdimenziós modell között és eldönthetjük például, hogy ugyanazt a vezetői információs rendszert melyik adatbázis kezelővel építsük fel. A múltkori cikkben már pedzegettem, hogy a két modell közötti döntés - tekintettel a nagy hasonlóságra - nem lesz könnyű. Ha megnézzük például a felhasználó szempontjából a különbséget, akkor azt látjuk hogy az közel zéró: Az Excel Pivot tanfolyamot ugyanúgy megtarthatnám az oszlopalapú adatbázison, ahogy a többdimenzióson. Ugyanígy az önkiszolgáló BI workshop dashbordjait is elkészíthetnénk mindkét adatbázis adataiból.

Persze a memóriában futó adatbázis lehet gyorsabb, a marketing anyagokból sok minden más mellett azt is meg fogjuk tanulni, hogy sokkal rövidebb a tanulási ciklusa, mint az OLAP adatbázis-kezelőké. De mindent összevetve az oszlopalapú adatbázis még kevesebbet tud, mint a tizenx éve itt lévő OLAP.

Tehát van (lesz) egy oszlopalapú adatbázis-kezelőnk, amely a felhasználók szempontjából pont olyan mint az OLAP. Ráadásul még kevesebbet is tud, mint az OLAP. Felmerülhet a kérdés, hogy akkor miért válasszuk?

Nos. Mondok egy okot, amely biztosan kimarad majd a marketing anyagokból: Létrehozhatunk vele olyan számított oszlopokat, amelyek

  • letárolódnak és a
  • felépítésükhöz nem kell feltölteni újra az egész kockát és így
  • úgy módosíthatjuk az adatmodellt, hogy a forrásoldalon semmit sem kell változtatnunk

Vesézzük ki egy kicsit ezt a pontot, mert bár jelentéktelennek tűnik, de nem az. Olyannyira nem, hogy egyik ügyfelemmel pont emiatt választottuk az oszlopalapú modellt. (igaz még nem a szerveres változatát, hanem a kliens oldalon futót (PowerPivot))

Képzeljen el egy olyan szervezetet, ahol az informatikának nagyon gyorsan kell reagálnia az üzleti igények változásaira, és ahol az üzleti problémák jellemzően olyanok, hogy a meglévő információkat kell más és más szempontból elemezhetővé tenni. Magyarul: ahol nagyon gyakran kell új attribútumokat létrehozni és hozzáadni a már meglévő adatokhoz. Mondjuk egy szegmentálás eredményét, egy új aggregálási csomópontot, egy szűrési feltételt, egy klasztert stb.

OLAP oldalon ennek megvalósításához rendszerint módosítani kell a relációs csillagsémás adatbázist, a betöltőket, és újra kellett tölteni a kockát. Vagy írhatunk egy iszonyú bonyolult MDX lekérdezést, aminek eredményét kitettük egy fix riportra.

Ugyanakkor az oszlopalapú adatbázist használva a feladat annyi, hogy létre kell hozni egy új számított oszlopot és kész. A teljesítménye jó lesz, a felhasználók az új attribútumot, szűrőfeltételt, klasztert, nevezzük bárhogy is, egyből tudják majd használni a Pivot táblán keresztül is. És így végső soron nagyon gyorsan tudunk neki segíteni, még akkor amikor a probléma fontos, fókuszban van.

Összességében keressük még ennek az új oszlopalapú adatbázis-kezelőnek a helyét a vállalati BI stratégiában, de már vannak típusesetek amikor tudjuk hogy melyik fogja jobban szolgálni a vállalat érdekeit.

Más. Végül egy jó hír: Megvan a BI és adattárház projektvezető képzések történetének 100. jelentkezője, így már biztos hogy ki fogok sorsolni egy 50000 + ÁFA értékű bónt a résztvevők között a júniusi önkiszolgáló BI workshopra :-) Ha már régóta kacérkodik a gondolattal hogy eljön, akkor tegye most mert a 200. jelentkezőig nem lesz még egy ilyen 50000 forintos bón. Jelenkezés itt

Elválasztó

Már készül a következő cikk. Kérjen értesítést a megjelenéséről itt.

|

Szóljon hozzá!

Szabály: Legyen kedves, segítõkész és vállalja a nevét.
A mező tartalma nem nyilvános.
  • A web és email címek automatikusan linkekké alakulnak.
  • Engedélyezett HTML elemek: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • A sorokat és bekezdéseket automatikusan felismeri a rendszer.
ANTI SPAM
A robot regisztrációk elkerülésére.
Image CAPTCHA
Figyeljen a kis és nagybetűk használatára