Adattárház tervezés

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.

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.

Összesen 2^31-1 azaz kicsit több, mint kétmilliárd kockát építhetünk egy Analysis Services-en alapuló BI megoldásba. Jó tudni, nehogy a kockák gyártása közben véletlenül túlszaladjunk ezen a korláton. JAz Analysis Services felső korlátairól a Maxi...

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

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

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.

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.

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.

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.

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.

írtam Önnek egy dzsoli dzsóker cikket amellyel egyszer és mindenkorra megoldhatja a magyar nyelv sajátosságaiból származó problémák egyik felét...

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.

Előfordul, hogy az üzleti folyamatok olyanok, hogy a tranzakció keletkezésekor még fogalmunk sincs arról, hogy például ki a vevő. (Így viselkednek egyes hűségprogramok) Persze később majd kiderül, hogy ki áll a vásárlási tranzakció mögött, csakhogy addigra mi már betöltöttük az adott vásárlást az adattárházba egy ismeretlen vevőre. Olvassa el a cikket, és megtudja, hogy milyen technikák léteznek az ilyen problémák leküzdésére