OLAP

„A válaszidőknek gyorsnak kell lennie” olvasható szinte minden BI ajánlati felhívásban. De miért kell gyorsnak lennie és mit jelent a gyors? Miért rugózunk ennyire ezen a témán? Ennek járunk utána a következő cikkben...

Az üzleti felhasználók sok esetben a pivot tábla lefúrható megjelenítése helyett táblázatos formában szeretnék megjeleníteni az adatokat. Mutatom:

Ehelyett:

Így szeretnék megjeleníteni ugyanazokat az adatokat:

Miért?

Arról már írtam, a korrekciók háttérszínének módosítása című cikk első részében, hogy hogyan állítható be OLAP (Analysis Services) oldalon egy measure (tehát nem egy számított mező) háttérszíne.

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

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.

A cikkben case sensitive adattárházak problémáit járjuk körül, és azt vizsgáljuk hogy hol ütközhetünk falakba a kis- és nagybetűk megkülönböztetésének következményeként

Az egyik projekten olyan architektúrát raktunk össze, amelyben szétválasztottuk a felösszegzéseket és a lekérdezéseket. Azaz egyik szerver csak a felösszegzéseket végzi, a másik csak a lekérdezéseket szolgálja ki. Nagyon sok előnye van ennek az ar...

Érdemes-e tény (fact) típusú relációt definiálni az Analysis Servicesben a ténytábla és a degenerált (Fact, Degenerate) dimenziók között? Nem mert az Analysis Services hétköznapi 1-n-es kapcsolatként kezeli Mert az Analysis Services csak 1 Fact tí...

Egy SSAS attribútumhoz mindig tartozik egy kulcs és tartozhat hozzá egy név es egy értek paraméter is. Ebben semmi új sincs. Azt viszont eddig nem tudtam, hogy a kulcsokhoz minden esetben letárol az Analysis Services egy megnevezés párt is. Még ak...

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.

Az Analysis Services 2012 OLAP motor több mint 300 apró továbbfejlesztést tartalmaz, de új szívet melengető funkció nem jelent meg: Eltűnt a 4 gigás attribútum fájl méretkorlát, de sosem ütköztem még bele Új Xevents eseménye...

Az SQL Server 2012-es verziójában szerveroldalon is megjelenik a memóriában futó adatbázis-kezelő ami egy sor lehetőséget nyit majd meg a döntéstámogató rendszerek építése előtt. A 2012-es verzióban használhatunk majd többdimenziós és oszlopalapú adatbázis-kezelőt is, de dönthetünk úgy is, hogy maradunk relációs adatbázisban és a csillagsémára épített indexeket toljuk fel a memóriába. Melyik lesz a jó irány? Ezt bizony most még nehéz eldönteni.

Mutatom hogy lehet összetett, több dimenziót érintő szűrést megvalósítani az Excel KOCKA.HALM() függvényével:=KOCKA.HALM("PowerPivot Data"; "CrossJoin({[Dátum].[hónap].[január]},{[Termék].[Termékcsop].[A]})")Vagy ahogy most tanultam az Excel kocka...