OLAP-CUBE (dinamikus vezetői jelentéskészítés). Bevezetés a többváltozós elemzésbe

Általában minden szakember tudja, mi az OLAP ma. Legalábbis az „OLAP” és a „többdimenziós adatok” fogalma szorosan összefügg a fejünkben. Mindazonáltal azt a tényt, hogy ez a téma ismét felvetődik, remélem, az olvasók többsége jóváhagyja, mert ahhoz, hogy valaminek a gondolata idővel ne avuljon el, időnként kommunikálni kell okos emberek vagy olvass cikkeket egy jó kiadványban...

Adattárházak (az OLAP helye a vállalat információs struktúrájában)

Az „OLAP” kifejezés elválaszthatatlanul kapcsolódik az „adattárház” (Data Warehouse) kifejezéshez.

Íme az adattárház „alapító atyja”, Bill Inmon által megfogalmazott definíció: „Az adattárház egy domain-specifikus, időhöz kötött, megváltoztathatatlan adatgyűjtemény, amely támogatja a vezetői döntéshozatalt.”

A raktárban lévő adatok operációs rendszerekből (OLTP-rendszerekből) származnak, amelyeket az üzleti folyamatok automatizálására terveztek. Ezenkívül a tárat külső forrásokból, például statisztikai jelentésekből lehet feltölteni.

Miért építsünk adattárházakat – elvégre nyilvánvalóan redundáns információkat tartalmaznak, amelyek már adatbázisokban vagy operációs rendszer fájlokban „élnek”? A válasz lehet rövid: lehetetlen vagy nagyon nehéz közvetlenül elemezni az operációs rendszerekből származó adatokat. Ennek számos oka lehet, többek között az adatok töredezettsége, különböző DBMS formátumokban való tárolása és a vállalati hálózat különböző „sarkaiban”. De még ha egy vállalat minden adatát egy központi adatbázis-kiszolgálón tárolja is (ami rendkívül ritka), az elemző szinte biztosan nem fogja megérteni a bonyolult, néha zavaros struktúrákat. A szerzőnek elég szomorú tapasztalata van arról, hogy az éhes elemzőket operatív rendszerekből származó „nyers” adatokkal próbálta „etetni” – ez „túl sok volt nekik”.

A repository célja tehát az, hogy egy helyen, egyszerű, érthető szerkezetben biztosítsa az elemzéshez szükséges „alapanyagokat”. Ralph Kimball "The Data Warehouse Toolkit" című könyvének előszavában azt írja, hogy ha az olvasó a teljes könyv elolvasása után csak egy dolgot ért meg - nevezetesen, hogy a raktár felépítésének egyszerűnek kell lennie -, akkor a szerző megfontolja feladat elvégezve.

Van még egy ok, ami indokolja a különálló tároló megjelenését - az operatív információk bonyolult elemző lekérdezése lassítja a vállalat aktuális munkáját, hosszú időre blokkolja a táblákat és lefoglalja a szerver erőforrásait.

Véleményem szerint a repository nem feltétlenül jelent hatalmas adathalmozódást - a lényeg az, hogy kényelmes legyen az elemzéshez. Általánosságban elmondható, hogy van egy külön kifejezés a kis tárolóhelyekre - Data Marts (adatkioszkok), de orosz gyakorlatunkban nem gyakran hallani.

OLAP - kényelmes elemző eszköz

A központosítás és a kényelmes strukturálás nem minden, amire egy elemzőnek szüksége van. Még mindig szüksége van egy eszközre az információk megtekintésére és megjelenítésére. A hagyományos jelentések, még azok is, amelyek egyetlen adattárra épülnek, egyvalami hiányzik: a rugalmasság. Nem lehet őket "csavarni", "kibontani" vagy "összecsukni", hogy az adatok kívánt nézetét kapják. Természetesen hívhatsz egy programozót (ha jönni akar), és ő (ha nincs elfoglalva) elég gyorsan készít új jelentést - mondjuk egy órán belül (írom és nem hiszem el) én magam – az életben nem történik ilyen gyorsan; adjunk neki három órát). Kiderült, hogy egy elemző naponta legfeljebb két ötletet tud tesztelni. És ő (ha jó elemző) óránként több ilyen ötlettel is előállhat. És minél több adat „szeletét” és „szeletét” látja az elemző, annál több ötlete van, amelyek viszont egyre több „szeletet” igényelnek az ellenőrzéshez. Ha lenne olyan eszköze, amellyel egyszerűen és kényelmesen bővítheti és összecsukhatja az adatokat! Az OLAP ilyen eszközként működik.

Bár az OLAP nem szükséges attribútuma egy adattárházban, egyre gyakrabban használják a raktárban felhalmozott információk elemzésére.

A tipikus tárolóban található komponensek az ábrán láthatók. 1.

Rizs. 1. Adattárház szerkezete

A működési adatokat különféle forrásokból gyűjtik, tisztítják, integrálják és egy relációs tárolóban tárolják. Sőt, már elérhetőek a különféle jelentéskészítő eszközökkel történő elemzéshez. Ezután az adatok (részben vagy egészben) előkészítésre kerülnek az OLAP elemzéshez. Betölthetők egy speciális OLAP adatbázisba, vagy relációs tárolóban tárolhatók. Legfontosabb eleme a metaadatok, azaz az adatok szerkezetére, elhelyezésére és átalakítására vonatkozó információk. Ezeknek köszönhetően a különböző tárolóelemek hatékony interakciója biztosított.

Összefoglalva, az OLAP-ot a raktárban felhalmozott adatok többdimenziós elemzésére szolgáló eszközkészletként határozhatjuk meg. Elméletileg az OLAP eszközök közvetlenül alkalmazhatók működési adatokra vagy azok adataira pontos másolatok(hogy ne zavarja a működő felhasználókat). De ezzel azt kockáztatjuk, hogy rálépünk a fentebb már leírt gereblyére, azaz elkezdjük elemezni az elemzésre közvetlenül nem alkalmas működési adatokat.

Az OLAP definíciója és alapfogalmai

Először is fejtsük meg: az OLAP az Online Analytical Processing, azaz az operatív adatelemzés. Az OLAP 12 meghatározó alapelvét 1993-ban E. F. Codd, a relációs adatbázisok „feltalálója” fogalmazta meg. Később a definícióját átdolgozták az úgynevezett FASMI tesztté, amely megköveteli, hogy az OLAP alkalmazás lehetővé tegye a megosztott többdimenziós információk gyors elemzését ().

FASMI teszt

Gyors(Gyors) – az elemzést egyformán gyorsan kell elvégezni az információ minden aspektusára vonatkozóan. Az elfogadható válaszidő 5 másodperc vagy kevesebb.

Elemzés(Elemzés) - lehetővé kell tenni az alkalmazásfejlesztő által előre meghatározott vagy a felhasználó által szabadon definiált alapvető numerikus és statisztikai elemzések elvégzését.

Megosztva(Megosztott) - sok felhasználónak hozzáféréssel kell rendelkeznie az adatokhoz, miközben ellenőrizni kell a bizalmas információkhoz való hozzáférést.

Többdimenziós A (többdimenziós) az OLAP fő, leglényegesebb jellemzője.

Információ(Információ) - az alkalmazásnak hozzá kell férnie minden szükséges információhoz, függetlenül annak mennyiségétől és tárolási helyétől.

OLAP = Többdimenziós nézet = Kocka

Az OLAP kényelmes, gyors eszközt biztosít az üzleti információk elérésére, megtekintésére és elemzésére. A felhasználó természetes, intuitív adatmodellt kap, többdimenziós kockák (Cubes) formájában rendezve azokat. A többdimenziós koordinátarendszer tengelyei a vizsgált üzleti folyamat fő jellemzői. Például értékesítés esetén ez lehet termék, régió, vevő típusa. Az idő az egyik dimenzió. A tengelyek metszéspontjain - dimenziók (Dimensions) - a folyamatot mennyiségileg jellemző adatok - intézkedések (Measures) találhatók. Ez lehet darabos vagy pénzben kifejezett értékesítési mennyiség, készletegyenleg, költségek stb. Az információkat elemző felhasználó különböző irányokba „vághatja” a kockát, összefoglalót kaphat (például évenként), vagy fordítva, részletes (hetenkénti bontásban). ) információkat és egyéb manipulációkat hajt végre, amelyek az elemzési folyamat során eszébe jutnak.

ábrán látható háromdimenziós kockában mérve. A 2. ábrán az értékesítési mennyiségek, méretként pedig az idő, a termék és az üzlet használatosak. A mérések meghatározott csoportosítási szinteken jelennek meg: a termékek kategóriánként, az üzletek országonként, a tranzakciók időzítési adatai pedig hónaponként vannak csoportosítva. Kicsit később részletesebben megvizsgáljuk a csoportosítás (hierarchia) szintjeit.


Rizs. 2. Kocka példa

Kocka "vágása".

Még egy háromdimenziós kockát is nehéz megjeleníteni a számítógép képernyőjén, hogy a kívánt mértékek értékei láthatóak legyenek. Mit mondhatunk a háromnál több dimenziójú kockákról? A kockában tárolt adatok megjelenítéséhez általában jól ismert kétdimenziós, azaz táblázatos nézeteket használnak összetett hierarchikus sor- és oszlopfejlécekkel.

A kocka kétdimenziós ábrázolása úgy érhető el, ha egy vagy több tengelyen (dimenzión) átvágjuk: kettő kivételével minden dimenzió értékét rögzítjük, és egy szabályos kétdimenziós táblázatot kapunk. A táblázat vízszintes tengelye (oszlopfejlécek) az egyik dimenziót, a függőleges tengely (sorfejlécek) egy másikat, a táblázat cellái pedig a mértékek értékeit képviselik. Ebben az esetben egy mértékegységet tulajdonképpen az egyik dimenziónak tekintünk - vagy kiválasztunk egy mértéket a megjelenítéshez (majd két dimenziót is elhelyezhetünk a sor- és oszlopfejlécekben), vagy több mértéket is megjelenítünk (majd az egyik a táblázat tengelyeit a mértékek nevei foglalják el, a többit pedig az egyetlen „nem vágott” dimenzió értékei).

Vessen egy pillantást az ábrára. 3 - itt van a kocka kétdimenziós szelete egy mértékhez - Eladási egység (eladott darabok) és két "vágatlan" méret - Store (Store) és Time (Time).


Rizs. 3. 2D kockaszelet egy mértékhez

ábrán. A 4. ábra csak egy „vágatlan” dimenziót mutat – az üzletet, de több mérőszám értékeit is megjeleníti – egységértékesítés (eladott egységek), bolti értékesítés (eladási összeg) és bolti költség (üzletköltség).


Rizs. 4. 2D kockaszelet több méréshez

Egy kocka kétdimenziós ábrázolása akkor is lehetséges, ha kettőnél több dimenzió marad „vágatlan”. Ebben az esetben a „kivágott” kocka két vagy több mérete a szelettengelyekre (sorokra és oszlopokra) kerül - lásd az ábrát. 5.


Rizs. 5. 2D kockaszelet több dimenzióval egy tengelyen

Címkék

A méretek mentén "lerakott" értékeket tagoknak vagy címkéknek nevezzük. A címkék mind a kocka „kivágására”, mind a kiválasztott adatok korlátozására (szűrésére) szolgálnak – amikor egy „vágatlan” dimenzióban nem az összes értékre vagyunk kíváncsiak, hanem azok egy részhalmazára, például három városra. több tucat közül. A címkeértékek a 2D kockanézetben sor- és oszlopfejlécként jelennek meg.

Hierarchiák és szintek

A címkék egy vagy több szintből álló hierarchiákba kombinálhatók. Például az Áruház dimenzió címkéi természetesen szintekkel hierarchiába vannak csoportosítva:

Ország

Állapot

Város

Bolt.

Az összesített értékeket a hierarchia szintjei alapján számítják ki, például az USA ("Ország" szint) vagy Kalifornia ("Állam" szint) értékesítési volumene. Egy dimenzióban több hierarchia is megvalósítható – mondjuk időre: (év, negyed, hónap, nap) és (év, hét, nap).

Az OLAP alkalmazások architektúrája

Minden, amit fentebb az OLAP-ról elmondtunk, alapvetően az adatok többdimenziós megjelenítésére vonatkozott. Az adatok tárolásának módja durván szólva nem érinti sem a végfelhasználót, sem az ügyfél által használt eszköz fejlesztőit.

Az OLAP alkalmazások többdimenzióssága három szintre osztható:

  • Többdimenziós adatábrázolás - végfelhasználói eszközök, amelyek többdimenziós megjelenítést és adatkezelést biztosítanak; A többdimenziós reprezentációs réteg elvonatkoztat az adatok fizikai szerkezetétől, és többdimenziósként kezeli az adatokat.
  • A többdimenziós feldolgozás a többdimenziós lekérdezések megfogalmazásának eszköze (nyelve) (a hagyományos relációs nyelv, az SQL ide nem alkalmas) és egy olyan processzor, amely képes feldolgozni és végrehajtani egy ilyen lekérdezést.
  • A többdimenziós tárolás az adatok fizikai rendszerezésének eszköze, amely biztosítja a többdimenziós lekérdezések hatékony végrehajtását.

Az első két szint minden OLAP-eszközben kötelező. A harmadik szint, bár széles körben elterjedt, nem szükséges, mivel a többdimenziós reprezentáció adatai a közönséges relációs struktúrákból kinyerhetők; A többdimenziós lekérdezésfeldolgozó ebben az esetben a többdimenziós lekérdezéseket SQL lekérdezésekké fordítja, amelyeket a relációs DBMS hajt végre.

Egyes OLAP-termékek általában egy többdimenziós adatmegjelenítési eszköz, egy OLAP-kliens (például Pivot Tables Excel 2000-ben a Microsofttól vagy ProClarity a Knosys-től), vagy egy többdimenziós szerver DBMS, egy OLAP-kiszolgáló (például Oracle). Express Server vagy Microsoft OLAP Services).

A többdimenziós feldolgozóréteg általában az OLAP-kliensbe és/vagy az OLAP-kiszolgálóba van beépítve, de tiszta formában is elkülöníthető, például a Microsoft Pivot Table Service összetevőjével.

A többdimenziós adattárolás technikai vonatkozásai

Ahogy fentebb említettük, az OLAP elemző eszközök közvetlenül is kinyerhetnek adatokat a relációs rendszerekből. Ez a megközelítés vonzóbb volt abban az időben, amikor az OLAP-kiszolgálók nem szerepeltek a vezető DBMS-gyártók árlistáiban. De ma már az Oracle, az Informix és a Microsoft teljes értékű OLAP szervereket kínál, és még azok az informatikai vezetők is megvásárolhatják (vagy inkább kérhetik, hogy a különböző gyártóktól származó szoftverek „állatkertjét” alakítsák ki hálózatukban). a vállalatvezetés ) A fő adatbázis-kiszolgálóval azonos márkájú OLAP-kiszolgáló.

Az OLAP-kiszolgálók vagy többdimenziós adatbázis-kiszolgálók többféleképpen tárolhatják többdimenziós adataikat. Mielőtt megvizsgálnánk ezeket a módszereket, beszélnünk kell egy olyan fontos szempontról, mint az egységek tárolása. A helyzet az, hogy bármely adattárházban - mind a hétköznapi, mind a többdimenziós - az operációs rendszerekből kinyert részletes adatok mellett összefoglaló mutatókat (összesített mutatók, összesítések) is tárolnak, mint például az értékesítési mennyiségek összege havi bontásban, árukategóriánként stb. Az aggregátumokat kifejezetten a lekérdezések végrehajtásának felgyorsítása céljából tárolják. Hiszen egyrészt általában nagyon nagy mennyiségű adat halmozódik fel a raktárban, másrészt az elemzőket a legtöbb esetben nem a részletes, hanem az általánosított mutatók érdeklik. És ha minden alkalommal több millió egyedi eladást kellene összeadni az év összértékesítésének kiszámításához, a sebesség valószínűleg elfogadhatatlan lenne. Ezért az adatok többdimenziós adatbázisba való betöltésekor az összes teljes mutatót vagy azok egy részét kiszámítja és tárolja.

De mint tudod, mindenért fizetni kell. Az összefoglaló adatokra vonatkozó kérések feldolgozásának gyorsasága érdekében pedig fizetni kell az adatmennyiség növekedéséért és a betöltési idő növekedéséért. Sőt, a mennyiség növekedése szó szerint katasztrofális lehet - az egyik közzétett standard tesztben a 10 MB forrásadatok teljes aggregátumainak kiszámításához 2,4 GB-ra volt szükség, vagyis az adatok 240-szeresére nőttek! Az aggregátumok kiszámításakor az adatok „duzzadásának” mértéke a kocka dimenzióinak számától és e dimenziók szerkezetétől függ, vagyis az „apák” és „gyermekek” számának arányától a különböző mérési szinteken. Az egységek tárolási problémájának megoldására néha használják őket összetett áramkörök, amelyek lehetővé teszik a lekérdezés teljesítményének jelentős növelését, ha nem minden lehetséges aggregátumot számítunk ki.

Most az információ tárolásának különféle lehetőségeiről. Mind a granulált adatok, mind az aggregátumok tárolhatók relációs vagy többdimenziós struktúrákban. A többdimenziós tárolás lehetővé teszi az adatok többdimenziós tömbként történő kezelését, amely biztosítja a teljes mutatók egyformán gyors számítását és a különböző többdimenziós transzformációkat bármely dimenzió mentén. Néhány évvel ezelőtt az OLAP termékek támogatták a relációs vagy többdimenziós tárolást. Ma általában ugyanaz a termék biztosítja mindkét ilyen típusú tárolást, valamint egy harmadik típust - vegyes. A következő feltételek érvényesek:

  • MOLAP(Többdimenziós OLAP) – mind a részletes adatok, mind az aggregátumok egy többdimenziós adatbázisban tárolódnak. Ebben az esetben a legnagyobb redundanciát kapjuk, mivel a többdimenziós adatok teljes mértékben tartalmaznak relációs adatokat.
  • ROLAP(Relációs OLAP) - a részletes adatok ott maradnak, ahol eredetileg „éltek” - a relációs adatbázisban; az aggregátumokat ugyanabban az adatbázisban tárolják, speciálisan létrehozott szolgáltatási táblákban.
  • HOLAP(Hibrid OLAP) - a részletes adatok a helyükön maradnak (egy relációs adatbázisban), az aggregátumokat pedig egy többdimenziós adatbázisban tárolják.

Ezen módszerek mindegyikének megvannak a maga előnyei és hátrányai, és ezeket a feltételektől függően kell használni - az adatmennyiség, a relációs DBMS teljesítménye stb.

Ha többdimenziós struktúrákban tárolja az adatokat, az üres értékek tárolása miatt lehetséges a "felfúvódás" probléma. Hiszen ha egy többdimenziós tömbben a dimenziócímkék minden lehetséges kombinációja számára le van foglalva a hely, de valójában csak egy kis része van kitöltve (például számos terméket csak kis számú régióban értékesítenek), akkor a legtöbb kocka üres lesz, bár a hely foglalt lesz. A modern OLAP termékek képesek megbirkózni ezzel a problémával.

Folytatjuk. A jövőben a vezető gyártók által gyártott konkrét OLAP termékekről lesz szó.

OLAP (On-Line Analytical Processing) Az elektronikus analitikai adatfeldolgozás olyan módszere, amely az adatok hierarchikus kategóriákba rendezését mutatja be előre kiszámított összegek felhasználásával. Az OLAP-adatok hierarchikusan vannak rendezve, és táblák helyett kockákban tárolódnak. Az OLAP-kockák egy többdimenziós adatkészlet, amelynek tengelyei paramétereket és cellákat tartalmaznak, amelyek paraméterfüggő összesített adatokat tartalmaznak. A kockákat nagy mennyiségű adat összetett, többdimenziós elemzésére tervezték, mivel csak összefoglaló eredményeket adnak jelentésekhez ahelyett. nagyszámú külön rekordok.

Az OLAP fogalmát a híres adatbázis-kutató és a relációs adatmodell szerzője, E. F. Codd írta le 1993-ban. Jelenleg az OLAP támogatás számos DBMS-ben és más eszközben van megvalósítva.

Az OLAP-kocka kétféle adatot tartalmaz:

· összértékek, értékek, amelyekre összesíteni kívánja, reprezentálja számított adatmezők;

· leíró információkat reprezentáló mérések vagy méretek. A leíró információk jellemzően részletezettségi szintekre vannak rendezve. Például: „Év”, „Negyed”, „Hónap” és „Nap” az „Idő” dimenzióban. A mezők részletezettségi szintjei szerinti rendszerezése lehetővé teszi a jelentéskészítő felhasználók számára, hogy megválasszák a megtekinteni kívánt részletességi szintet, kezdve a magas szintű összefoglaló adatokkal, majd a részletesebb nézetig, és fordítva.

A Microsoft Query eszközök lehetővé teszik OLAP-kockák létrehozását is olyan lekérdezésekből, amelyek adatokat töltenek be egy relációs adatbázisból, például a Microsoft Accessből, és egy lineáris táblát strukturált hierarchiává (kockává) alakítanak át.

Az OLAP kocka létrehozása varázsló egy beépített Microsoft Query eszköz. Relációs adatbázison alapuló OLAP-kocka létrehozásához a varázsló futtatása előtt végre kell hajtania a következő lépéseket.

1. Határozza meg az adatforrást (lásd: 6.1. ábra).

2. A Microsoft Query segítségével hozzon létre egy lekérdezést, amely csak azokat a mezőket tartalmazza, amelyek egy OLAP-kocka adatmezői vagy dimenziómezői lesznek; ha egy kockában egy mezőt többször használnak, akkor azt a lekérdezésben kell szerepeltetni. hányszor.

3. A lekérdezés-létrehozó varázsló utolsó lépésében állítsa a kapcsolót az elemre OLAP-kocka létrehozása adott lekérdezésből(lásd 6.2. ábra), vagy a kérés közvetlenül a Lekérdezés menü segítségével történő létrehozása után Fájl válassz egy csapatot Hozzon létre OLAP-kockát, amely után elindul az OLAP kocka létrehozása varázsló.

Az OLAP-kocka létrehozása varázsló három lépésből áll.

A varázsló első lépésénél (lásd 6.6. ábra) a adatmezők– számított mezők, amelyekhez összértéket kell meghatározni.



Rizs. 6.6. Adatmezők meghatározása

A varázsló a várt számított mezőket (általában numerikus mezőket) a lista elejére helyezi, ellenőrzi, és meghatározza ezeknek a mezőknek az eredményül kapott függvényét, általában - Összeg. Az adatmezők kiválasztásakor legalább egy mezőt ki kell választani számított mezőként, és legalább egy mezőt ki kell hagyni a méret meghatározásához.

OLAP-kocka létrehozásakor négy összefoglaló függvényt használhat − Összeg, Szám(értékek száma), Minimális, Maximális numerikus mezőkhöz és egy függvényhez Szám minden más területen. Ha ugyanabban a mezőben több különböző összegző függvényt szeretne használni, akkor azt a mezőt a szükséges számú alkalommal szerepeltetni kell a lekérdezésben.

A számított mező neve egy oszlopban megváltoztatható Adatmező neve.

A varázsló második lépésében meghatározzák a leíró adatokat és azok méreteit (lásd 6.7. ábra). Mérési mező kiválasztásához a listából kell kiválasztania Forrás mezők húzza a kívánt legfelső szintű méretmezőt a listára Mérések jelű területre Húzza ide a mezőket a méretek létrehozásához. OLAP-kocka létrehozásához meg kell határoznia legalább egy dimenziót. A varázsló ugyanabban a lépésében a helyi menü segítségével módosíthatja a dimenzió vagy a szintmező nevét.

Rizs. 6.7. Dimenziómezők meghatározása

Azok a mezők, amelyek elszigetelt vagy diszkrét adatokat tartalmaznak, és nem tartoznak hierarchiába, egyszintű dimenzióként definiálhatók. A kocka azonban hatékonyabb lesz, ha néhány mezőt szintekbe rendeznek. Ha egy dimenzió részeként szeretne szintet létrehozni, húzzon egy mezőt a listából Forrás mezők olyan mezőn, amely dimenzió vagy szint. A részletesebb információkat tartalmazó mezőket alacsonyabb szinteken kell elhelyezni. Például a 6.7. ábrán a mező Munka megnevezése a mező szintje Osztály neve.

Mező mozgatása alacsonyabb vagy magasabb szintre magas szint, akkor a dimenzión belül egy alacsonyabb vagy magasabb mezőbe kell húznia. A szintek megjelenítéséhez vagy elrejtéséhez használja a vagy a gombokat.

Ha dátum- vagy időmezőket használ legfelső szintű dimenzióként, az OLAP-kocka varázsló automatikusan létrehozza a szinteket ezekhez a dimenziókhoz. A felhasználó ezután kiválaszthatja, hogy mely szintek jelenjenek meg a jelentésekben. Kiválaszthat például heteket, negyedéveket és éveket vagy hónapokat (lásd: 6.7. ábra).

Ne feledje, hogy a varázsló csak akkor hoz létre automatikusan szinteket a dátum- és időmezőkhöz, ha létrehoz egy legfelső szintű dimenziót; Ha ezeket a mezőket egy dimenzió alszintjeként adja hozzá, az automatikus szintek nem jönnek létre.

A varázsló harmadik lépésében meghatározásra kerül a varázsló által létrehozott kocka típusa, három lehetőség közül választhat (lásd 6.8. ábra).

Rizs. 6.8. A létrehozandó kocka típusának kiválasztása a varázsló harmadik lépésében

· Az első két lehetőség egy kocka létrehozását jelenti minden egyes jelentés megnyitásakor (ha a kockát Excelből nézzük, akkor pivot tábláról beszélünk). Ebben az esetben a kérelemfájl és a fájl kocka definíciók *.oqy, amely a kocka létrehozására vonatkozó utasításokat tartalmazza. A *.oqy fájl Excelben megnyitható, így a kocka alapján riportokat készíthet, ha pedig módosítani kell a kockán, akkor a Query segítségével megnyitva újra futtassa a Kocka létrehozása varázslót.

Alapértelmezés szerint a kockadefiníciós fájlok, mint a lekérdezési fájlok, az Application Data\Microsoft\Que-ries felhasználói profilmappájában tárolódnak. Ha *.oqy fájlt ment a szabványos mappába, a kockadefiníciós fájl neve megjelenik a lapon OLAP kockákúj lekérdezés megnyitásakor a Microsoft Queryben vagy parancs kiválasztásakor Hozzon létre egy kérést(menü Adat, almenü Külső adatok importálása) Microsoft Excelben.

· A kockatípus harmadik opciójának kiválasztása esetén A kocka összes adatát tartalmazó kockafájl mentése, a rendszer lekéri a kocka összes adatát, és létrejön egy * kiterjesztésű kockafájl a felhasználó által megadott helyen .kölyök, amelyben ezeket az adatokat tárolják. Ez a fájl nem jön létre azonnal, amikor a gombra kattint Kész; a fájl akkor jön létre, amikor a kockadefiníciót fájlba menti, vagy amikor jelentést hoz létre a kocka alapján.

A kocka típusának kiválasztását több tényező határozza meg: a kocka által tartalmazott adatok mennyisége; a kocka alapján létrehozandó jelentések típusa és összetettsége; rendszererőforrások (memória és lemezterület) stb.

Külön *.cub kockafájlt kell létrehozni a következő esetekben:

1) gyakran változó interaktív jelentések esetén, ha van elegendő lemezterület;

2) amikor el kell mentenie a kockát egy hálózati kiszolgálóra, hogy hozzáférést biztosítson a többi felhasználó számára a jelentések létrehozásakor. A kockafájl adott adatokat szolgáltathat a forrásadatbázisból, miközben kihagyja azokat az érzékeny vagy érzékeny adatokat, amelyekhez meg akarja akadályozni, hogy más felhasználók hozzáférjenek.

Egy szabványos pivot táblában a forrásadatok a helyi merevlemezen tárolódnak. Így bármikor kezelheti és átszervezheti őket, még a hálózathoz való hozzáférés nélkül is. De ez semmiképpen sem vonatkozik az OLAP pivot táblákra. Az OLAP pivot táblákban a gyorsítótár soha nem tárolódik a helyi merevlemezen. Ezért közvetlenül a hálózatról való lekapcsolás után helyi hálózat a pivot tábla többé nem fog működni. Egyetlen mezőt sem fog tudni mozgatni benne.

Ha az offline állapotba kapcsolás után is elemeznie kell az OLAP-adatokat, hozzon létre egy offline adatkockát. Az offline adatkocka egy külön fájl, amely egy pivot tábla gyorsítótár, és a helyi hálózatról való leválasztás után megtekintett OLAP-adatokat tárolja. A pivot táblába másolt OLAP-adatok kinyomtathatók, ennek részletes leírása a http://everest.ua weboldalon található.

Önálló adatkocka létrehozásához először hozzon létre egy OLAP pivot táblát. Vigye a kurzort a pivot táblába, és kattintson az OLAP eszközök gombra az Eszközök kontextuális lapon, amely a Kimutatáseszközök kontextuális lapcsoport része. Válassza ki az Offline OLAP parancsot (9.8. ábra).

A képernyőn megjelenik az Offline OLAP Data Cube beállítások párbeszédpanel. Kattintson az Offline adatfájl létrehozása gombra. Elindította az Adatkockafájl létrehozása varázslót. Az eljárás folytatásához kattintson a Tovább gombra.

Először meg kell adnia azokat a méreteket és szinteket, amelyek szerepelni fognak az adatkockában. A párbeszédpanelen ki kell választania az OLAP adatbázisból importált adatokat. Az ötlet az, hogy csak azokat a méreteket adja meg, amelyekre szükség lesz, miután a számítógépet leválasztják a helyi hálózatról. Minél több méretet ad meg, az nagyobb méretűönálló adatkockával fog rendelkezni.

Kattintson a Tovább gombra, hogy a következő varázsló párbeszédpanelére lépjen. Ez lehetővé teszi olyan tagok vagy adatelemek megadását, amelyek nem fognak szerepelni a kockában. Különösen nincs szüksége az Internetes értékesítés kiterjesztett összegére, így a jelölőnégyzet törlődik a listából. A jelölőnégyzet törlése azt jelzi, hogy a megadott elem nem lesz importálva, és felesleges helyet foglal el a helyi merevlemezen.

Az utolsó lépésben adja meg az adatkocka helyét és nevét. Esetünkben a kockafájl neve MyOfflineCube.cub lesz, és a Work mappában található.

Az adatkocka-fájlok kiterjesztése .kölyök

Egy idő után az Excel elmenti az offline adatkockát a megadott mappába. A teszteléshez kattintson duplán a fájlra, amely automatikusan létrehoz egy Excel-munkafüzetet, amely a kiválasztott adatkockához társított pivot táblát tartalmaz. Létrehozása után az offline adatkockát szétoszthatja minden érdeklődő felhasználó számára, aki offline LAN módban dolgozik.

Miután csatlakozott a helyi hálózathoz, megnyithatja az offline adatkockafájlt, és frissítheti azt, valamint a megfelelő adattáblázatot. Fő elv kimondja, hogy az offline adatkocka csak a helyi hálózat leválasztásakor működik, de a kapcsolat helyreállítása után frissíteni kell. Az offline adatkocka frissítésének kísérlete a kapcsolat meghibásodása után hibához vezet.

E munka részeként a következő kérdéseket veszik figyelembe:

  • Mik azok az OLAP kockák?
  • Mik azok a mértékek, dimenziók, hierarchiák?
  • Milyen típusú műveleteket lehet végrehajtani az OLAP kockákon?
Az OLAP kocka fogalma

Az OLAP fő posztulátuma az adatmegjelenítés többdimenziós jellege. Az OLAP terminológiában a kocka vagy hiperkocka fogalmát egy többdimenziós diszkrét adattér leírására használják.

Kocka egy többdimenziós adatstruktúra, amelyből a felhasználó-elemző információkat tud lekérdezni. A kockák tényekből és méretekből jönnek létre.

Adat- ezek a vállalaton belüli tárgyakra és eseményekre vonatkozó adatok, amelyek elemzés tárgyát képezik. Az azonos típusú tények mércéket alkotnak. A mérték a kockacellában lévő érték típusa.

Mérések- ezek azok az adatelemek, amelyek alapján a tényeket elemzik. Az ilyen elemek gyűjteménye dimenzióattribútumot képez (például a hét napjai alkothatnak idődimenzió-attribútumot). Üzleti elemzési feladatokban kereskedelmi vállalkozások A dimenziók gyakran tartalmaznak olyan kategóriákat, mint az „idő”, „eladások”, „termékek”, „vevők”, „munkavállalók” és „földrajzi hely”. A dimenziók leggyakrabban hierarchikus struktúrák, amelyek logikai kategóriákat képviselnek, amelyek segítségével a felhasználó elemezheti a tényleges adatokat. Minden hierarchiának egy vagy több szintje lehet. Így a „földrajzi elhelyezkedés” dimenzió hierarchiája a következő szinteket tartalmazhatja: „ország – régió – város”. Az időhierarchiában például a következő szintsorokat különböztethetjük meg: Egy dimenziónak több hierarchiája is lehet (egy dimenzió minden hierarchiájának a dimenziótábla kulcsattribútumaival kell rendelkeznie).

A kocka egy vagy több ténytáblázatból származó tényleges adatokat tartalmazhat, és leggyakrabban több dimenziót is tartalmazhat. Minden adott kockának általában van egy meghatározott fókusza az elemzéshez.

Az 1. ábra egy példát mutat be egy kockára, amelyet egy adott vállalat kőolajtermékek értékesítésének régiónkénti elemzésére terveztek. Ezt a kockát három dimenziója van (idő, termék és régió) és egy mérték (pénzben kifejezett értékesítés). A mérési értékek a kocka megfelelő celláiban tárolódnak. Minden cellát egyedileg azonosít az egyes dimenziók tagjainak halmaza, úgynevezett sor. Például a kocka bal alsó sarkában található cellát (amely a $98399 értéket tartalmazza) a sor határozza meg [2005. július, Távol-Kelet, Diesel]. Itt a 98 399 dolláros érték a gázolaj Távol-Keleten 2005. júliusi értékesítési volumenét mutatja (pénzben kifejezve).

Azt is érdemes megjegyezni, hogy egyes cellák nem tartalmaznak értékeket: ezek a cellák üresek, mert a ténytábla nem tartalmaz rájuk vonatkozó adatokat.

Rizs. 1. Kocka információkkal a kőolajtermékek értékesítéséről a különböző régiókban

Az ilyen kockák létrehozásának végső célja az, hogy minimalizálja a lekérdezések feldolgozási idejét, amelyek a tényleges adatokból kinyerik a szükséges információkat. Ennek a feladatnak a végrehajtásához a kockák általában előre kiszámított összegeket tartalmaznak aggregációk(összesítések). Azok. a kocka a ténylegesnél nagyobb adatteret fed le - logikai, számított pontok vannak benne. Az aggregációs függvények lehetővé teszik a logikai térben lévő pontok értékeinek kiszámítását a tényleges értékek alapján. A legegyszerűbb összesítő függvények a SUM, MAX, MIN, COUNT. Így például a MAX funkció használatával a példában megadott kockánál azonosítható, hogy mikor következett be a dízeleladási csúcs a Távol-Keleten stb.

A többdimenziós kockák másik sajátossága az eredet meghatározásának nehézsége. Például hogyan állíthatja be a 0 pontot a Termék vagy régiók dimenzióhoz? A probléma megoldása egy speciális attribútum bevezetése, amely egyesíti a dimenzió összes elemét. Ez az attribútum (automatikusan létrehozva) csak egy elemet tartalmaz – Mind. Az olyan egyszerű összesítő függvényeknél, mint az összeg, az All elem egyenértékű az adott dimenzió tényleges terében lévő összes elem értékének összegével.

A többdimenziós adatmodellek egyik fontos fogalma az altér vagy alkocka. Az alkocka a kocka teljes területének egy része, a kockán belüli többdimenziós alakzat formájában. Mivel a kocka többdimenziós tere diszkrét és korlátozott, az alkocka is diszkrét és korlátozott.

Műveletek OLAP kockákon

A következő műveletek hajthatók végre egy OLAP-kockán:

  • szelet;
  • forgás;
  • konszolidáció;
  • részletezve.
Szelet(2. ábra) egy alkocka speciális esete. Ez az eljárás egy többdimenziós adattömb részhalmazának kialakítására, amely egy vagy több, ebben az alhalmazban nem szereplő dimenzióelem egyetlen értékének felel meg. Például annak megtudásához, hogy a kőolajtermékek értékesítése hogyan haladt az idő múlásával csak egy bizonyos régióban, nevezetesen az Urálban, rögzítenie kell a „Termékek” dimenziót az „Ural” elemen, és ki kell bontania a megfelelő részhalmazt (alkockát) a kocka.
  • Rizs. 2. OLAP kocka szelet

    Forgás(3. ábra) - a jelentésben vagy a megjelenített oldalon bemutatott mérések helyének megváltoztatásának művelete. Például egy elforgatási művelet magában foglalhatja egy táblázat sorainak és oszlopainak átrendezését. Ezenkívül az adatkocka elforgatásával a táblázatból kimaradt méretek a helyükre kerülnek a megjelenített oldalon lévő méretekkel, és fordítva.

    Jó ideje Habr lakója vagyok, de soha nem olvastam a többdimenziós kockák, OLAP és MDX témájú cikkeket, pedig a téma nagyon érdekes és napról napra egyre aktuálisabb.
    Nem titok, hogy az adatbázisok, az elektronikus könyvelés és az online rendszerek fejlesztésének rövid ideje alatt maga is rengeteg adat halmozódott fel. Most az archívum teljes elemzése, és talán egy kísérlet arra, hogy a jövőben hasonló modellek helyzetét előre jelezzék, szintén érdekes.
    Másrészt a nagyvállalatok akár több év, hónap vagy akár hét leforgása alatt is olyan nagy mennyiségű adatot halmozhatnak fel, hogy az alapelemzésük is rendkívüli megközelítést és szigorú hardverkövetelményeket igényel. Ezek lehetnek banki tranzakció-feldolgozó rendszerek, részvényügynökök, telefonkezelők stb.
    Azt hiszem, mindenki jól ismeri az adatbázis-tervezés két különböző megközelítését: az OLTP-t és az OLAP-ot. Az első megközelítés (Online Transaction Processing – valós idejű tranzakciófeldolgozás) a hatékony, valós idejű adatgyűjtést szolgálja, míg a második (Online Analytical Processing – valós idejű analitikai feldolgozás) kifejezetten az adatok leghatékonyabb mintavételére és feldolgozására irányul. út.

    Nézzük meg a modern OLAP kockák főbb képességeit, és milyen problémákat oldanak meg (az Analysis Services 2005/2008-as verzióját vesszük alapul):

    • gyors hozzáférés az adatokhoz
    • előcsoportosítás
    • hierarchia
    • idővel dolgozni
    • többdimenziós adatelérési nyelv
    • KPI (Key Performance Indicators)
    • datolya bányászat
    • többszintű gyorsítótár
    • többnyelvű támogatás
    Tehát nézzük meg kicsit részletesebben az OLAP kockák képességeit.

    Egy kicsit bővebben a lehetőségekről

    Gyors hozzáférés az adatokhoz
    Valójában az adatokhoz való gyors hozzáférés a tömb méretétől függetlenül az OLAP rendszerek alapja. Mivel ez a fő hangsúly, az adattárház általában a relációs adatbázisoktól eltérő elvekre épül.
    Itt az egyszerű adatok lekéréséhez szükséges időt a másodperc töredékeiben mérik, és a néhány másodpercet meghaladó lekérdezés valószínűleg optimalizálást igényel.

    Előcsoportosítás
    Amellett, hogy gyorsan lekéri a meglévő adatokat, lehetőséget biztosít a „legvalószínűbb felhasználásra” értékek előzetes összesítésére is. Például, ha napi nyilvántartásunk van egy bizonyos termék értékesítéséről, a rendszer Talán A havi és negyedéves értékesítési összegeket is előre összesíthetjük, ami azt jelenti, hogy ha havonta vagy negyedévente kérünk adatot, akkor a rendszer azonnal megadja az eredményt. Miért nem mindig jön létre az elő-aggregáció?Mert elméletileg lehetséges javak/idő/stb kombinációk. hatalmas szám lehet, ami azt jelenti, hogy világos szabályokkal kell rendelkeznie, hogy mely elemekre épül fel az aggregáció, és melyekre nem. Általánosságban elmondható, hogy ezeknek a szabályoknak a figyelembevétele és az aggregációk tényleges kialakítása meglehetősen kiterjedt, és önmagában külön cikket érdemel.

    Hierarchiák
    Természetes, hogy az adatok elemzése és a zárójelentések készítése során figyelembe kell venni azt a tényt, hogy a hónapok napokból állnak, és maguk is negyedéveket alkotnak, a városok pedig a területekhez tartoznak, amelyek viszont régiók vagy országok részét képezik. . A jó hír az, hogy az OLAP-kockák kezdetben az adatokat hierarchiákban és ugyanazon entitás más paramétereivel való kapcsolatokban tekintik meg, így a kockákban lévő hierarchiák felépítése és használata nagyon egyszerű.

    Munka az idővel
    Mivel az adatok elemzése főként időterületeken történik, az OLAP rendszerekben az idő kiemelt jelentőséget kap, ami azt jelenti, hogy ha egyszerűen meghatározzuk a rendszer számára, hogy hol van itt időnk, a jövőben könnyedén használhatunk olyan funkciókat, mint az Évtől dátumig, a hónapig. ( az év/hónap elejétől az aktuális dátumig tartó időszak), Párhuzamos időszak (ugyanazon a napon vagy hónapban, de tavaly) stb.

    Többdimenziós adatelérési nyelv
    MDX(Multidimensional Expressions) - lekérdező nyelv a többdimenziós adatstruktúrák egyszerű és hatékony elérésére. És ez mindent elmond – az alábbiakban lesz néhány példa.

    Kulcsteljesítménymutatók (KPI)
    Kulcsfontosságú teljesítménymutatók egy olyan pénzügyi és nem pénzügyi mérőrendszer, amely segít a szervezetnek meghatározni a stratégiai célok elérését. A kulcsfontosságú teljesítménymutatók egyszerűen meghatározhatók az OLAP rendszerekben, és felhasználhatók a jelentésekben.

    A bányászat dátuma
    Adatbányászat(Adatbányászat) - lényegében rejtett minták vagy a változók közötti kapcsolatok azonosítása nagy adathalmazokban.
    Az angol „Data Mining” kifejezésnek nincs egyértelmű orosz nyelvű fordítása (adatbányászat, adatbányászat, információbányászat, adatbányászat, adat/információ kinyerése), ezért a legtöbb esetben az eredetiben használják. A legsikeresebb közvetett fordítás az „adatbányászat” (DMA) kifejezés. Ez azonban egy különálló, nem kevésbé érdekes téma.

    Többszintű gyorsítótár
    Valójában a lehető legnagyobb sebességű adathozzáférés biztosítása érdekében a trükkös adatstruktúrák és előcsoportosítások mellett az OLAP rendszerek támogatják a többszintű gyorsítótárazást. Az egyszerű lekérdezések gyorsítótárazása mellett az áruházból kiolvasott adatok részei, az összesített értékek és a számított értékek is gyorsítótárazásra kerülnek. Így minél tovább dolgozik egy OLAP kockával, annál gyorsabban kezd el dolgozni. Létezik a „gyorsítótár bemelegítésének” koncepciója is – egy olyan művelet, amely felkészíti az OLAP rendszert meghatározott jelentésekkel, lekérdezésekkel vagy ezek kombinációjával való munkára.

    Többnyelvű támogatás
    Igen igen igen. Az Analysis Services 2005/2008 (bár Enterprise Edition) legalább natívan támogatja a többnyelvűséget. Elég, ha megadja az adatok karakterlánc-paramétereinek fordítását, és a nyelvét megadott ügyfél honosított adatokat kap.

    Többdimenziós kockák

    Tehát mik is pontosan ezek a többdimenziós kockák?
    Képzeljünk el egy 3 dimenziós teret, amelynek tengelyei az idő, a termékek és a vásárlók.
    Az ilyen mezőben lévő pont azt a tényt jelzi, hogy az egyik vásárló egy adott terméket vásárolt egy adott hónapban.

    Valójában a sík (vagy az összes ilyen pont halmaza) lesz a kocka, és ennek megfelelően az Idő, a Termékek és a Vevők a méretei.
    Kicsit nehezebb elképzelni (és megrajzolni) egy négydimenziós vagy több kockát, de a lényeg nem változik, és ami a legfontosabb, az OLAP rendszerek esetében egyáltalán nem mindegy, hogy hány dimenzióban fog dolgozni (ésszerű kereteken belül). határok természetesen).

    Egy kis MDX

    Tehát mi az MDX szépsége? Valószínűleg az, hogy nem azt kell leírnunk, hogyan akarjuk kiválasztani az adatokat, hanem Pontosan mit mi akarunk.
    Például,
    KIVÁLASZTÁS
    ( . ) OSZLOPON,
    ( ., . ) SOROKRA
    TÓL TŐL
    AHOL (., .)

    Ami azt jelenti, hogy annyi iPhone-t szeretnék eladni júniusban és júliusban Mozambikban.
    Egyben leírom melyik ezeket az adatokat akarom és Hogyan Szeretném látni őket a riportban.
    Gyönyörű, nem?

    Itt egy kicsit bonyolultabb:

    TAG AverageSpend AS
    . / .
    KIVÁLASZTÁS
    ( Átlagköltés ) OSZLOPON,
    ( .., .. ) SOROKRA
    TÓL TŐL
    AHOL (.)

    * Ezt a forráskódot a Source Code Highlighter kiemelte.

    Valójában először meghatározzuk az „átlagos vásárlási méret” kiszámításának képletét, és megpróbáljuk összehasonlítani, hogy ki (milyen nem) költ több pénzt az Apple bolt egyetlen látogatása során.

    Maga a nyelv tanulmányozása és használata egyaránt rendkívül érdekes, és talán sok vitát érdemel.

    Következtetés

    Valójában ez a cikk még az alapfogalmakból is nagyon keveset fed le, én „előételnek” nevezném – lehetőség arra, hogy a Habra közösséget felkeltsük ebben a témában, és továbbfejlesszük. Ami a fejlesztést illeti, itt hatalmas felszántatlan mező van, minden kérdésére szívesen válaszolok.

    P.S. Ez az első bejegyzésem az OLAP-ról, és az első publikáció a Habréról – nagyon hálás lennék az építő jellegű visszajelzésekért.
    Frissítés:Átvittem SQL-be, átteszem OLAP-ra, amint megengedik, hogy új blogokat hozzak létre.

    Címkék: Címkék hozzáadása