Blog

Miért építsünk OLAP adatkockákat az adattárház fölé? Miért nem elégítjük ki a riportigényeket közvetlenül az adattárházból? Elvégre ezért építettük. Nem?

Aki nem ismeri a történelmet címmel pár hete írtam egy bejegyzést a múltbéli adatok elemzésének fontosságáról. A most következő cikkben pedig arra szeretném felhívni a figyelmet, hogy mekkora hibát követ el az, aki a múlt adataiból következtet a jövőre.

Egy érdekes cikket olvastam minap az adatok mobil eszközökön történő prezentációjáról és az ember vizuális feldolgozó képességének kapcsolatáról. Ez adta az ihletet, hogy összeírjam, mi mindenre kell odafigyelni, ha az ember igazán jó riportokat akar a döntéshozók vagy a főnöke elé tenni.

„FYI - új pályázati lehetőségek. Hátha kell valakinek BI EU-s pénzből...” - küldte a sógorom nemrég az e-mailt. Átfutottam őket és bár igaz, hogy az üzleti intelligencia definíció nem éppen a Howard Dresneri, de az tisztán látszik, hogy a kiíró szándéka az üzleti intelligencia rendszerek bevezetésének támogatása (is).

A Microsoft ingyenesen elérhetővé tette a PerformancePoint Planning nevű, üzleti tervezést támogató alkalmazás forráskódját. Részletek a cikkben.

Egy gondolat és egy rövid párbeszéd a múltbéli adatok fontosságáról.

Gyakran emlegetett fogalom ma a stressz teszt mely során nyomáspróbának vetik alá bankrendszert, hogy megállapítsák: mennyire tudnak a pénzintézetek ellenállni a gazdasági visszaesés okozta megpróbáltatásoknak. Nos. Lovagoljuk meg ezt a hullámot és nézzük meg, hogy hogyan lehet a bankrendszerekhez hasonlóan az üzleti intelligencia rendszerek stressztűrő képességét tesztelni és meggyőződni arról, hogy az OLAP alapú üzleti intelligencia rendszerünk bírni fogja-e a felhasználók rohamát...

Az Analysis Services-nek, mint a repülőgépeknek van egy fekete doboza (flight recorder). Ebbe a dobozba gyűjti működése során keletkezett információkat, így amikor összeomlik a szerver pontosan meg tudjuk mondani, hogy milyen események következtek be a „lezuhanás” előtt. Egy kis átalakítással azonban utasainkról, azaz a felhasználókról is gyűjthetünk a segítségével információkat. Erről szól a cikk

283 dia, kereken 100 oldal nyomtatott anyag, 9 átadott mintafájl, majdnem 10 óra közös munka, és teltház… Ezek a számok jellemzik a pár napja lezárult BI és adattárház projektvezető képzést. A szubjektív részletek kiderülnek a visszatekintő cikkből

A BI-t vagy adattárházat használó cégeknek szükségük van egy adattárház menedzserre, aki egyszemélyes felelőse lesz az adattárháznak vagy az üzleti intelligencia rendszernek. Olvassa el, hogy mit várunk el ettől az embertől és hogyan mérjük a teljesítményét

Gyűjtöm az anyagokat a BI és adattárház projektvezető képzéshez, ahol szó lesz a Scope-ról, vagy más néven az adattárház vagy üzleti intelligencia projektek terjedelméről: Mi az, miért fontos, mit tartalmazzon a Scope dokumentum, mekkora legyen a kezdeti scope, stb, és fogunk beszélni egy pár szót arról is, hogy mi legyen a kezdeti scope-ban, azaz mi legyen a BI vagy adattárház bevezetés első lépcsője?

Jön a mikroökonómia gyakorlati hasznosításának második, és egyben utolsó darabja. Az előző cikkben a kereslet árrugalmasságának OLAP technológiával történő elemzését jártuk körül, a most következő cikkben pedig arra keressük a választ, hogy melyik az az egységár, amelyen értékesítve az adott terméket, a legnagyobb fedezettömeget (nyereséget) érhetjük el.

Tegyük fel, hogy megmaradt egy csomó olyan terméke, amit szeretne villámgyorsan kipucolni a raktárból, hogy helyet csináljon a következő termelésnek. Gyorsan össze is dob egy marketing kampányt, ám amikor az eladási egységár meghatározásához ér, elgondolkodik. Vajon mennyiért kéne adnom a terméket, hogy azt a gyorsan elvigyék a vevők, úgy hogy nekem ez az adott körülmények között a legnagyobb profitot termelje? Vagy másképpen fogalmazva: Mennyivel fog tőlem többet vásárolni a piac vagy egy konkrét vevő, ha 1%-kal csökkentem az áraimat?

Szombaton István-aknán jártunk egy elhagyott bányában, ahol a foszladozó, kifakult szex naptárak között egy igazi gyöngyszemre bukkantam. Olvassa el a BI blog eddigi legrövidebb bejegyzését.

Az adattárházak és üzleti intelligencia projektek megtérülésével kapcsolatos kérdésekre a bevezetés előtt igen nehéz választ adni. Még ha sejtjük is hogy meg fog térülni az adattárház vagy üzleti intelligencia rendszer, hogyan fogjuk tudni mindezt számokkal alátámasztani? Egyáltalán érdemes-e számokkal alátámasztani? A most következő cikkben ezekre a kérdésre keressük a választ

Felkerültek és véglegesültek az adattárház projektvezető képzés újabb részletei. Meg van az ár, helyszín lefoglalva, és kidolgoztam a „dupláját fizetem vissza” garancia részleteit is. De ami legfontosabb: A jövő hét szerdáig jelentkezők 38% kedvezményt kapnak. Olvassa el a részleteket

Adott a következő probléma: Az üzleti terület látni szeretné, hogy egy adott könyvelési tétel milyen tranzakciókból tevődött össze, ki könyvelte azt a tételt stb. Mindezt úgy, hogy „rákattintva a könyvelt értékre feljöjjenek azok a számlák, amelyek a könyvelési tételt kiadják”. A most következő cikkben ezt a témát járjuk körül. (Plusz elkészült és felkerült az új adattárház projektvezetői tanfolyam tematikája is. Nézze meg őket)

Elég jó hónapnak nézünk elébe üzleti intelligencia és adattárház konferenciák tekintetében. Lesz az IIR-nek, az IQSYS-nek és a BI Consultingnak is e témákkal foglalkozó rendezvénye, de itt lesz a Google is, aki az elosztott architektúrájárol fog a BME-n beszélni. Részletek a cikkben.

Mark Rittman blogjában olvastam a minap egy interjút Margy Ross-szal (Margy Ross néhány kitűnő könyvet írt a csillagsémás adattárházakról). Az interjúból nem olvashatunk ki semmi újat, de jó egy ilyen autentikus személytől hallani, hogy melyek a legáltalánosabban elkövetett adattárház hibák, vagy melyek a legnagyobb kihívások egy adattárházat bevezető IT vezető számára. A most következő cikkben ebből az interjúból csemegézünk.

Bíztam benne, hogy megint megkapom, de azért ott motoszkált a fejemben, hogy lehet, hogy mégsem? Aztán tegnap megjött az e-mail, hogy újra megválasztottak MVP-nek.

„Egy felmérés szerint az Egyesült Államokban a vállalatoknál elindított változások 80 (!) százaléka a nem elégséges vagy helytelen kommunikáció miatt bukik meg.” (olvastam a Figyelő egy korábbi számában) Elgondolkodtató nem? Pedig ma már nagyon egyszerű és olcsó dolgok léteznek a hatékony kommunikáció támogatására. Az egyik ilyen a vállalati blog. Olvassa el, hogy hogyan segítheti az adattárházak, vagy üzleti intelligencia rendszerek bevezetését egy vállalati belső blog.

Vége. Sikeresen lezárult az üzleti intelligencia vagy adattárház bevezetés. A rendszer kész, a felhasználók kiképezve, a szállító emberei levonulnak a projektről. Mindenki örül. De mi lesz most? Hogyan fogják a felhasználók önállóan használni az adattárházat vagy az üzleti intelligencia rendszert? Egyáltalán használni fogják? Tegyünk valamit annak érdekében hogy használják, vagy várjuk meg amíg birtokba veszik úgy ahogy ők akarják?

Az átadás előtti pillanatokban az ember kapkod. Nincs idő minden alternatívát gondosan végiggondolni, sokszor csípőből kell dönteni. Ilyenkor fordul elő, hogy az ember a FORMAT C: parancs „Biztos vagy benne?” kérdésére kapásból rányomja a 3 YES-t! Aztán fogja a fejét, hogy mit tett. A minap ezt csináltam én is. A teszt adatbázis dimenziótáblája helyett az éles adattárház dimenziótábláját töröltem… A most következő cikkből megismerheti, hogy hogyan lehet visszafejteni az OLAP adatbázisból a törölt dimenziótábla tartalmát...

Véget ért az MVP Global Summit 2009. A Redmondban tartott 4 napos eseményen összegyűltek a Microsoft vezető fejlesztői és vagy 100 SQL Serveres független szakértő (MVP), hogy átbeszéljék a következő SQL Server verzió fontosabb újdonságait.

Az adattárház lelke az adatmodell. Ha az jó, akkor az adattárház felhasználói szeretni fogják az adattárházat. Ha nem, akkor az adattárház szép lassan el fog halni. Ennek az adatmodellnek a sikeressége elsősorban két dologtól függ: Egyrészt attól, hogy az adatmodell „üzletileg” mennyire jó másrészt attól, hogy az adatmodell fizikai valójában mennyire hatékonyan támogatja azt, amit az üzleti terület megálmodott. Jelen cikk ez utóbbiról, a fizikai adatmodell tervezésről fog szólni.

Most látom, hogy megjelentek elektronikus formában is a TechNet magazinban publikált cikkeim. Az alapozónak szánt cikkek az adattárházak, üzleti intelligencia rendszerek feltöltésének és a többdimenziós (OLAP) adatbázisok építésének alapjait járja körül.

Átalakult a BI blog. Új blog motort kapott az oldal, újra kategorizáltuk a cikkeket, stb. Aki az elmúlt két hétben járt már az oldalon annak nincs újdonság, aki nem annak összefoglaltam pár sorban, hogy mi változott a régi bloghoz képest.

A hír: A Microsoft bejelentette, hogy a PerformancePoint Server, mint önálló termék megszűnik. A ProClarity és a Scorecard Manager átkerül a SharePoint portál szerverbe, a Planning-et pedig kivezeti a piacról. Idén még lesz egy javítócsomag a Planning-hez, de ezután a cég nem invesztál többet a termékbe. Paff. A miértekről és a lehetséges okokról bővebben a cikkben olvashat

Adattárházak betöltése során a forrásrendszerekben tárolt természetes azonosítókat (pl vevőkód, cikkszám, számlaszám, …) betöltés közben lecseréljük jelentés nélküli mesterséges azonosítókra, és utána ezen mesterséges azonosítókat használjuk a dimenzió- és ténytáblák közti kapcsolat megteremtésére. Miért tesszük mindezt és a válasz ismeretében vajon érdemes-e minden természetes azonosítót, így például a dátumokat is lecserélni jelentés nélküli mesterséges azonosítókra? A cikkből mindezen kérdésekre választ kaphat

Adattárház fejlesztők és üzemeltetők figyelmébe: Megjelent az SQL Server 2005 SP3, azaz az SQL Server 2005 harmadik javítócsomagja és az SQL server 2005 helpjének, a books online-nak (BOL) a legújabb frissítése, valamint új konnektorokat kapott az Integration Services 2008 ORACLE-höz és Teradatához