Adattárház tervezés

Adattárház tervezéssel kapcsolatos cikkek, amelyek megválaszolják az adattárházak bevezetésének stratégiai kérdéseit, bemutatják a logikai és a fizikai adatmodell tervezés lépéseit.

Összeérő idősort építsünk az adattárházban?

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

Tovább

Fájl alapú interfészek előnyei

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

Tovább

DWless BI

20+ évvel ezelőtt a BI rendszereket közvetlenül textfájlokra építettük, aztán jött 20 év amikor mindig tettünk alá relációs adatbázisokat. Most megint textfájlokra építünk BI rendszereket...

Tovább

Adatfrissítés Power BI-ban

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.

Tovább

Adjuk-e historikus stage-et a felhasználóknak?

Most vagyunk túl egy kísérleten, ahol azt vizsgáltuk, hogy pusztán a forrásrendszer tábláinak szabványos interfészen történő átadása (historizált stage formájában) elegendő-e az üzleti felhasználóknak ahhoz, hogy abból önállóan, IT támogatás nélkül legyenek képesek önkiszolgáló BI rendszereket építeni. Következzenek az eredmények.

Tovább

Kódok vagy megnevezések?

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

Tovább

Szoftverfrissítési ciklusok rövidülése

Az SQL Server 2000 és 2005 megjelenése között 5 év telt el. Ennyi év kellett ahhoz, hogy a Microsoft új szoftververziót dobjon piacra. Ezt követően még 2005-ben bejelentették, hogy az új stratégiának megfelelően rövidíteni fogják a termékek megjelenése között eltelt időt, és az SQL Serverből 3 évente új verziót fognak piacra dobni. Ma a felhős BI és az önkiszolgáló BI világában már ott tartunk, hogy hetente jelennek meg újdonságok. Jó ez nekünk? Utánajárunk a cikkben

Tovább

A XXI. század adattárháza a múlt századból nézve

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.

Tovább

Bátor Tábor önkiszolgáló BI esettanulmány

Sok szó esik itt a BI projekt blogon a nagy cégek BI rendszereiről és adattárházairól. Most beszéljünk egy kicsit a kicsikről és nézzük meg, hogy hogyan történik náluk a döntéstámogatás. Milyen problémákkal küzdenek, milyen BI rendszereket használnak és milyen eredményeket érnek el a döntéstámogató rendszerek használatával. Következzen a Bátor Tábor BI rendszerének bemutatása.

Tovább

7 ország 7 adatkocka?

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?

Tovább

Bérelhető adattárház architektúrák

Pár hete jelentette be a Microsoft a felhőben futó adattárház ajánlatát, melynek eredményeképp adattárházra optimalizált hardvert és szoftvert kínálnak bérelhető konstrukcióban. Milyen, hogy működik, mennyibe kerül? Kiderül a cikkből

Tovább

GRAPHISOFT BI és adattárház esettanulmány

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

Tovább

UPC BI esettanulmány

A UPC-s BI projektet anno nagyon szerettem volna megnyerni… Megnyertük. Aztán megcsináltuk. Ma pedig ott tartunk, hogy esettanulmány is készült belőle. Olvassa el. Sokat tanulhat belőle és betekinthet a kulisszák mögé, amire ritkán nyílik csak lehetőség.

Tovább

Címek, személyek modellezése Data Vault-ban

Jó egy éve sokat foglalkoztam a Data Vault adattárház adatmodellezéssel, és anno felírtam magamnak kérdésként, hogy hogyan érdemes az üzleti kulcsok nélküli entitásokat modellezni a Data Vault-ban. Akkor nem tudtam rá a választ, de visszafejtve Li...

Tovább

MS BI és adattárház best practice cikkek

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.

Tovább

Építsünk hierarchiákat?

Most, hogy vége van a nyárnak ideje felpörögni. Az első bejegyzés a hierarchiák fontosságával illetve az alternatív hierarchiák megvalósítási lehetőségeivel fog foglalkozni.

Tovább

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

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.

Tovább

Csillag vagy hópehely séma?

Nagy általánosságban – és a legjobb gyakorlatoknak megfelelően – kerüljük a hópehelyséma használatát. Vannak azonban olyan esetek, amikor érdemes elgondolkodni a használatán. A cikkben ezen ritka esetekre kerestem egy-két példát

Tovább

Miért gyorsak az OLAP adatbázis-kezelők?

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.

Tovább

Oldalak