BI PROJEKT: ADATTÁRHÁZ ÉS
ÜZLETI INTELLIGENCIA

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
Elolvasom a teljes cikket

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.
Elolvasom a teljes cikket

Június 15.-én ötödszörre kerül megrendezésre a BI és adattárház projektvezető képzés. Ár, tematika, helyszín és egyéb részletek a cikkben
Elolvasom a teljes cikket

A BI és adattárház bevezetést támogató segédszoftverek ismertetését ezúttal a minőségbiztosítást, dokumentálást és üzemeltetést támogató ingyenesen letölthető segédszoftverek bemutatásával folytatjuk.
Elolvasom a teljes cikket

A most következő cikkben átnézzük mindazon ingyenesen letölthető segédszoftvereket, amelyeket évek óta, nap mint nap használunk adattárházak és BI rendszerek bevezetéséhez. Sok időt, energiát takarítottunk már meg velük, úgyhogy bízom benne, hogy hasznosak lesznek az Ön számára is.
Elolvasom a teljes cikket

Adott egy multinacionális vállalat, amely eltérő időzónájú országokban is értékesít. A kérdés az, hogy milyen időponton szerepeltessük az eseményeket az adattárházban? Lokális, vagy valamilyen egyezményes időponton mint például az UTC? Ennek járunk most utána.
Elolvasom a teljes cikket

Nemrég lehetőségem nyílt közelebbről is szemügyre venni egy Fast Track Data Warehouse referencia architektúra alapján összeállított adattárházat, és ennek tapasztalatairól szeretnék most beszámolni. Elsősorban arra keresem a választ, hogy mit tudunk átvenni a nagyoktól és mit tudunk a referencia architektúra ajánlásaiból használni akár kisebb méretekben is.
Elolvasom a teljes cikket

Nemrég jelent meg a Microsoft adattárház appliance-e, a Parallel Data Warehouse Edition és ennek kapcsán egy kicsit szemügyre vesszük a kistesót, a magyarországi méretekhez jobban passzoló 4-48 terára optimalizált Fast Track Data Warehouse referencia adattárház architektúrát.
Elolvasom a teljes cikket

A múlt heti cikkben a „sok kis adatkocka vagy egy nagy” dilemmát az üzleti felhasználók oldaláról közelítettük meg. Azt vizsgáltuk, hogy a felhasználói élmény szempontjából melyik a jobb megoldás. Most átülünk a fejlesztők székébe és a technológia lehetőségei felöl közelítjük meg a problémát...
Elolvasom a teljes cikket

Adatpiacok, vezetői információs rendszerek tervezése során gyakran felmerül a kérdés, hogy egy nagy adatkockát építsünk, vagy szakterületenként/üzleti folyamatonként egy-egy kicsit. A most következő cikkben ennek járunk utána, és első körben a felhasználók szempontjából vizsgáljuk meg a problémát
Elolvasom a teljes cikket

A könnyedebb témákról átmegyünk egy kicsit az adattárház adatmodell tervezési kérdéseire, és megvizsgáljuk, hogy milyen lehetőségeink vannak a szervezet/dolgozók/üzletkötők, ... típusú hierarchiák modellezésére.
Elolvasom a teljes cikket

Amíg csak adattárház elméletről, módszertanról keresünk könyvet addig viszonylag egyszerű dolgunk van: ki kell választanunk egyet Inmon vagy Kimball könyvei közül, és kész. Nem nagyon tudunk mellényúlni. Ha azonban olyan könyvet keresünk, amely megmutatja azt is, hogy hogyan kell felépíteni egy adattárházat a rendelkezésre álló Microsoft szoftverek felhasználásával, akkor már komoly problémákba ütközünk. Túl sok könyv létezik ugyanis, és ezek közül nehéz kiválasztani azt, amely valóban segíteni tud egy adattárház felépítésében. Ebben próbálok most segíteni
Elolvasom a teljes cikket

Még februárban kezdtem el írni egy cikket annak apropóján, hogy Kimball-nak új adattárház könyve jelent meg, de végül nem publikáltam. Nem publikáltam, mert 1) akartam még érlelni egy kicsit az első benyomásaimat 2) írni akartam még azokról az adattárház könyvekről is, amelyekről azt gondolom, hogy segítséget fognak nyújtani másoknak is. Ezek következnek most.
Elolvasom a teljes cikket

A minap a Decathlonban jártam és egy olyan adattárház problémába botlottam, amelyet a sportáruház példáján keresztül remekül lehet szemléltetni. Ez következik most.
Elolvasom a teljes cikket

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?
Elolvasom a teljes cikket

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.
Elolvasom a teljes cikket

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
Elolvasom a teljes cikket

Itt a biprojekt.hu-n eddig nem sokat foglalkoztunk az adattárház adatmodelljének kialakításával. Pedig az adattárház lelke az adatmodell. Ha az rossz, akkor rossz az egész. Jöjjön velem, és nézze meg hogyan alakul ki a végső adatmodell.
Elolvasom a teljes cikket

A cikkben megpróbáltam összeszedni azokat az általánosan bevált indexelési stratégiákat, amelyeket fel fogsz tudni használni az adattárházad első indexelési tervének kialakításához.
Elolvasom a teljes cikket

A magyar adattárházak nyelvi problémáinak vizsgálatát ez alkalommal adattisztítás oldaláról járjuk körül és arra keressük a választ, hogy az SQL Server milyen segítséget nyújt az ékezetes adatok tisztításához.
Elolvasom a teljes cikket

Valószínűleg sokan meg fognak rám orrolni azért amit most fogok írni, de szükségesnek tartom hogy beszéljünk erről a témáról. Havi legyen az adattárház feltöltése vagy napi?
Elolvasom a teljes cikket

A héten megjelent a „Designing SQL Server 2005 Analysis Services Cubes for Excel 2007 PivotTables” című dokumentum, mely segítséget nyújt Excel 2007-re optimalizált Analysis Services adatkockák építéséhez.
Elolvasom a teljes cikket

Hol hozzunk létre a Year To Date típusú kalkulációkat? A measure-ök között, vagy az idő diemnzió egy hierarchiájában? Külön dimenzióban, vagy az idő dimenzió egy új attribútumában? A következő cikkben ezekre a kérdésekre keresem a választ.
Elolvasom a teljes cikket

Hol célszerű elhelyezni az OLAP kockák felépítéséhez szükséges üzleti logikát? Adatbázis nézetben vagy az OLAP és relációs adatbázis között elhelyezkedő logikai rétegben, az úgynevezett adatforrás nézetben (Data Source View)?
Elolvasom a teljes cikket

Egy Integration Services csomagot három különböző módon (helyen) tárolhatunk: Az SSIS package store-ban, fájlrendszerben vagy az msdb adatbázisban. De ezek közül melyik az ideális?
Elolvasom a teljes cikket

Milyen alternatívák léteznek eltérő részletezettségű adatok (Pl.: Terv - Tény) megjelenítésére egy MSOLAP 2000-es kockában?
Elolvasom a teljes cikket