Adattárház tervezés

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...

Régóta nem foglalkoztunk adattárház témával itt a BI projekt blogon, úgyhogy itt az ideje előhúzni egy alaptémát: a historizációt

Forrásrendszer oldalon? Vagy adattárház oldalon? Kiderül a cikkből.

A mostani cikk apropóját a böngészőben futó Power BI riport frissítés gombja adja. Mi történik ha rányomunk a frissítés gombra? Mi fog frissülni? Az adat? Vagy csak az aktuális riport? Nagyon sok félreértés származik ebből, úgyhogy most ennek járunk utána.

Örök dilemma, hogy használjunk-e hosszú, mindenki által érthető, megnevezéseket az adatpiacokban, ad-hoc elemzésekre szánt adatkockákban, vagy használjuk inkább azok rövidebb, a szakterületek által használt megfelelőit...

1996-ban azt írtam zöldfülűként a szakdolgozatomban, hogy a XXI. század vállalatai már egységes adattárházban tárolják majd az információikat, ahol minden információ logikusan lesz szervezve és minden szükséges adat pillanatok alatt rendelkezésére áll. Mi valósult meg mára ebből? Utánajárunk a cikkben.

Adott egy vállalat sok-sok szervezeti egységgel. Kérdés: Melyik szervezeti egységnek kell önkiszolgáló BI rendszert adnunk és melyiknek lenne jobb a hagyományos IT vagy külső szállító által felépített BI-t? Van olyan ismérv, ami mentén szegmentálhatnák a szervezeti egységeket?

Adott egy adattárház amely 7 különböző ország adatait tartalmazza. Kérdés: Készítsünk külön-külön adatkockákat az egyes országoknak vagy mindenki használja a „nagy” adatkockát?

A GRAPHISOFT-nál a BI bevezetés indikátora ugyanaz volt, mint bármely más hasonló cég esetében: Hozzáférést szerettek volna kapni saját adataikhoz. Nem riportokra vágytak, hanem egy adattárházra, amelyből minden kérdésükre nagyon rövid időn belül választ kaphatnak. Ebben eddig nincs semmi különös. Abban azonban már igen, ahogyan az adattárházukat fel akarták építeni. Ők ugyanis saját maguk szerették volna felépíteni a világ minden tájáról táplált, budapesti központú adattárházukat. Nem szállítót vagy erőforrást kerestek a probléma megoldásra, hanem szaktudást. Így találtunk egymásra 2012 tavaszán...

Tépelődtünk már egy párszor itt a BI projekt blogon a nyelvi különbségek kezeléséről. A magyar nyelvvel már foglalkoztunk eleget, most jöjjön a német nyelv :-)

A most következő cikkel az a célom, hogy bemutassam a legjobb best practice tanulmányokat és ezáltal segítsek az adattárház fejlesztőknek, hogy jó, szerethető és sikeres BI rendszereket vagy adattárházakat építsenek. Olyanokat amelyre évek múltán visszatekintve is büszkék lesznek. És nem csak ők, hanem a megrendelőik is.

Az SQL Server 2012-ben debütált Data Quality Services-zel tovább nőtt az adattisztításra használható eszközeink száma, úgyhogy ideje áttekinteni az SQL Server adatminőség javítással kapcsolatos kínálatát.

Jó rég óta ismerjük, használjuk az OLAP technológiát. Felmerülhet a kérdés, hogy miért váltsunk egy újabb oszlopalapú adatbázis-kezelőre, amely közel ugyanolyan felhasználói élményt biztosít mint az OLAP, ugyanakkor koránál és egyéb adottságainál fogva most még kevesebbet tud társánál? A cikkben erre a kérdésre keressük a választ egy, a marketing dossziékból valószínűleg kimaradó példán bemutatva.

Az OLAP adatbázis-kezelők gyorsaságának egyik oka az, hogy előre felaggregálják azokat az adatokat, amelyekről úgy gondolják, hogy szükségük lesz rájuk a felhasználóknak. A kérdés csak az, hogy honnan tudják, hogy mire lesz szükségük a felhasználóknak? A cikkben ezt a témát járjuk körbe, illetve a végén megosztunk egy szolgálati közleményt is.