Olap excel kockák. OLAP-kocka létrehozása a Microsoft Query segítségével

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 felcserélését. Ezenkívül az adatkocka elforgatása a nem táblázatos méretek áthelyezését jelenti a megjelenített oldalon lévő méretek helyére, és fordítva.

Az OLAP nem egyetlen szoftvertermék, nem programozási nyelv, és nem is egy konkrét technológia. Ha megpróbálja lefedni az OLAP-ot annak minden megnyilvánulásában, akkor ez a szoftvertermékek alapjául szolgáló fogalmak, elvek és követelmények összessége, amelyek megkönnyítik az elemzők számára az adatokhoz való hozzáférést. Találjuk ki Miért az elemzőknek valami különlegesre van szükségük megkönnyíti adat hozzáférés.

Az a tény, hogy az elemzők különleges fogyasztók vállalati információ. Az elemző feladata, hogy nagy adathalmazokban mintákat találjon. Ezért az elemző nem fog figyelni arra az egyetlen tényre, hogy csütörtökön a negyedik napon egy adag fekete tintát adtak el Csernov partnernek - információra van szüksége százról és ezerről hasonló eseményeket. Az adatbázisban szereplő egyes tények érdekesek lehetnek például egy könyvelőnek vagy az értékesítési osztály vezetőjének, akinek a hatáskörébe tartozik a tranzakció. Egy elemzőnek nem elég egy rekord – például egy adott fiók vagy képviselet összes tranzakciójára szüksége lehet egy hónapig vagy egy évig. Ugyanakkor elemző eldobja szükségtelen részletek, például a vevő TIN-száma, pontos címe és telefonszáma, szerződési index és hasonlók. Ugyanakkor az elemző munkájához szükséges adatok szükségszerűen számértékeket tartalmaznak - ez tevékenysége lényegének köszönhető.

Tehát egy elemzőnek sok adatra van szüksége, ezek az adatok szelektívek és természetük is van." attribútumkészlet - szám Ez utóbbi azt jelenti, hogy az elemző a következő típusú táblázatokkal dolgozik:

Itt " Egy ország", "Termék", "Év" attribútumok vagy mérések, A" Az értékesítés volumene" - így számérték ill intézkedés. Az elemző feladata, ismételjük, az attribútumok és a numerikus paraméterek közötti tartós kapcsolatok azonosítása.. A táblázatot nézve láthatja, hogy könnyen lefordítható három dimenzióra: az egyik tengelyre országokat, a másikra az árukat, a harmadikra ​​az éveket helyezzük. És ennek a háromdimenziós tömbnek az értékei a megfelelő értékesítési mennyiségek lesznek.

A táblázat 3D-s ábrázolása. A szürke szegmens azt mutatja, hogy nincsenek adatok Argentínáról 1988-ban

Az OLAP szempontjából pontosan egy ilyen háromdimenziós tömböt nevezünk kockának. Valójában a szigorú matematika szempontjából egy ilyen tömb nem mindig lesz kocka: egy valódi kocka esetében az elemek számának minden dimenzióban azonosnak kell lennie, míg az OLAP kockákra nincs ilyen korlátozás. E részletek ellenére azonban az "OLAP-kockák" kifejezés rövidsége és képszerűsége miatt általánosan elfogadottá vált. Egy OLAP kockának egyáltalán nem kell 3D-snek lennie. A megoldandó problémától függően lehet kétdimenziós és többdimenziós is. A különösen tapasztalt elemzőknek körülbelül 20 mérésre lehet szükségük – és a komoly OLAP-termékeket csak ennyire tervezték. Az egyszerűbb asztali alkalmazások körülbelül 6 dimenziót támogatnak.

mérések Az OLAP kockák ún jelek vagy tagjai. Például az „Ország” dimenzió az „Argentína”, „Brazília”, „Venezuela” és így tovább címkékből áll.

A kocka minden elemét nem kell kitölteni: ha nincs információ a gumitermékek Argentínában 1988-ban történő értékesítéséről, akkor a megfelelő cellában lévő érték egyszerűen nem kerül meghatározásra. Az sem szükséges, hogy egy OLAP-alkalmazás feltétlenül többdimenziós struktúrában tárolja az adatokat - a lényeg az, hogy a felhasználó számára ezek az adatok pontosan így nézzenek ki. Mellesleg, a többdimenziós adatok kompakt tárolásának speciális módjainál a kockákban történő "vákuum" (kitöltés nélküli elemek) nem vezet memóriapazarláshoz.

Maga a kocka azonban nem alkalmas elemzésre. Ha még mindig lehetséges egy háromdimenziós kockát megfelelően ábrázolni vagy ábrázolni, akkor hat-tizenkilenc dimenzióval sokkal rosszabb a helyzet. Ezért használat előtt közönséges kockákat vonnak ki egy többdimenziós kockából kétdimenziós asztalok. Ezt a műveletet a kocka "vágásának" nevezik. Ez a kifejezés ismét csak képletes. Az elemző úgymond veszi és "levágja" a kocka méreteit az őt érdeklő jelek szerint. Ily módon az elemző megkapja a kocka kétdimenziós szeletét, és azzal dolgozik. Körülbelül ugyanígy számolják a favágók az évgyűrűket egy fűrészvágáson.

Ennek megfelelően általában csak két méret marad "vágatlan" - a táblázat méreteinek számától függően. Előfordul, hogy csak a méret marad "vágatlan" - ha a kocka többféle számértéket tartalmaz, akkor azokat a táblázat valamelyik mérete szerint lehet ábrázolni.

Ha közelebbről megnézi az általunk először ábrázolt táblázatot, láthatja, hogy a benne lévő adatok valószínűleg nem elsődlegesek, hanem a táblázat eredményeként származnak. összegzés kisebb tárgyakhoz. Például egy év negyedévekre, negyedévekre hónapokra, hónapokra hetekre, hetekre napokra oszlik. Egy ország régiókból, a régiók pedig helységekből állnak. Végül magukban a városokban is megkülönböztethetők a kerületek és az egyes kiskereskedelmi egységek. A termékek kombinálhatók árucsoportok stb. Az OLAP szempontjából az ilyen többszintű csatlakozásokat logikusan hívják hierarchiák. Az OLAP eszközök lehetővé teszik, hogy bármikor a hierarchia kívánt szintjére lépjünk. Sőt, ugyanazon elemekhez általában többféle hierarchia is támogatott: például nap-hét-hónap vagy nap-tized-negyed. A forrásadatokat a hierarchiák alsó szintjeiről veszik, majd összegzik a magasabb szintek értékeit. Az átállási folyamat felgyorsítása érdekében a különböző szintek összegzett értékeit egy kockában tároljuk. Így ami a felhasználó oldaláról egy kockának tűnik, durván szólva sokkal primitívebb kockákból áll.

Hierarchia példa

Ez az egyik lényeges pont, amely az OLAP – termelékenység és hatékonyság – megjelenéséhez vezetett. Képzeljük el, mi történik, ha egy elemzőnek információhoz kell jutnia, és az OLAP-eszközök nem állnak rendelkezésre a vállalatban. Az elemző önállóan (ami nem valószínű) vagy programozó segítségével elvégzi a megfelelő SQL lekérdezést és jelentés formájában megkapja az érdeklődésre számot tartó adatokat, vagy táblázatba exportálja. Sok probléma van ezzel. Először is, az elemző kénytelen valami mást csinálni, mint a munkáját (SQL programozás), vagy megvárni, amíg a programozók elvégzik helyette a feladatot - mindez negatívan befolyásolja a munka termelékenységét, a támadást, a szívinfarktus és a stroke szint növekedését stb. . Másodszor, egyetlen jelentés vagy táblázat általában nem menti meg a gondolkodás óriásait és az orosz elemzés atyjait - és az egész eljárást újra és újra meg kell ismételni. Harmadszor, amint azt már megtudtuk, az elemzők nem kérnek apróságokat - mindenre egyszerre van szükség. Ez azt jelenti (bár a technológia ugrásszerűen fejlődik), hogy az elemző által elért vállalati relációs adatbázis-kiszolgáló mélyen és hosszan gondolkodhat, blokkolva a többi tranzakciót.

Az OLAP koncepciója pontosan az ilyen problémák megoldására tűnt fel. Az OLAP kockák alapvetően meta-jelentések. A meta-riportok (vagyis kockák) dimenziókra vágásával az elemző ténylegesen megkapja az őt érdeklő "rendes" kétdimenziós jelentéseket (ezek nem feltétlenül a szó szokásos értelmében vett jelentések - adatstruktúrákról beszélünk). ugyanazokkal a funkciókkal). A kockák előnyei nyilvánvalóak - egy relációs DBMS-ből csak egyszer kell adatokat kérni - a kocka felépítésénél. Mivel az elemzők általában nem dolgoznak olyan információkkal, amelyeket menet közben egészítenek ki és változtatnak, a generált kocka meglehetősen hosszú ideig releváns. Ennek köszönhetően nemcsak a relációs DBMS-szerver működésének megszakításai szűnnek meg (nincs több ezer és millió válaszsoros lekérdezés), hanem maga az elemző adatelérési sebessége is látványosan megnő. Ezen túlmenően, amint már említettük, a teljesítményt a hierarchiák és egyéb összesített értékek alösszegeinek kiszámítása is javítja a kocka felépítése idején. Vagyis ha kezdetben az adataink egy adott termék napi árbevételéről tartalmaztak információt egyetlen üzletben, akkor a kocka kialakításakor az OLAP alkalmazás a különböző szintű hierarchiák (hetek és hónapok, városok és országok) összesítését számolja ki.

Természetesen a termelékenység növeléséért ilyen módon fizetni kell. Néha azt mondják, hogy az adatstruktúra egyszerűen "felrobban" – egy OLAP-kocka tízszer vagy akár százszor több helyet foglalhat el, mint az eredeti adat.

Válaszolj a kérdésekre:

Mi történt kocka OLAP?

Mi történt címkéket konkrét dimenzió? Adj rá példákat.

Tudnak intézkedéseket V OLAP kocka, nem numerikus értékeket tartalmaznak.

Megjegyzés: Ez az előadás az OLAP adattárházak adatkockáinak tervezésének alapjait ismerteti. A példa bemutatja, hogyan lehet adatkockát felépíteni a CASE eszközzel.

Az előadás célja

Az előadás anyagának tanulmányozása után tudni fogja:

• miben van egy adatkocka OLAP adattárház ;
• hogyan tervezzünk adatkockát OLAP adattárházak ;
• mi az adatkocka dimenzió ;
• hogyan kapcsolódik a tény az adatkockához;
• mik azok a dimenzióattribútumok;
• mi az a hierarchia;
• mi az adatkocka-metrika;

és tanulni:

• épít többdimenziós diagramok ;
• tervezés egyszerű többdimenziós diagramok.

Bevezetés

Az OLAP technológia nem önálló szoftver, Nem programozási nyelv. Ha megpróbálja lefedni az OLAP-ot annak minden megnyilvánulásában, akkor ez a szoftvertermékek alapjául szolgáló fogalmak, elvek és követelmények összessége, amelyek megkönnyítik az elemzők számára az adatokhoz való hozzáférést.

Az elemzők a vállalati információk fő fogyasztói. Az elemző feladata, hogy nagy adathalmazokban mintákat találjon. Ezért az elemző nem fog figyelni arra az egyetlen tényre, hogy egy adott napon egy tétel golyóstollat ​​eladtak a vevő Ivanovnak - több száz és több ezer hasonló eseményről van szüksége információra. Az adattárházban található egyedi tények érdekesek lehetnek például egy könyvelőnek vagy az értékesítési osztály vezetőjének, akinek a kompetenciája egy konkrét szerződés támogatása. Egy elemzőnek nem elég egy rekord – például szüksége lehet információra az összes értékesítési pontról szóló szerződésről egy hónapra, negyedévre vagy évre. Előfordulhat, hogy az Analytics nem érdekli a vevő TIN-jét vagy telefonszámát – konkrét számadatokkal dolgozik, ami szakmai tevékenységének lényege.

A központosítás és a kényelmes strukturálás messze nem minden, amire egy elemzőnek szüksége van. Szüksége van egy eszközre az információk megtekintésére, megjelenítésére. A hagyományos – akár egyetlen adattárházra épülő – riportok azonban megfosztanak bizonyos rugalmasságtól. Nem lehet őket "csavarni", "kibontani" vagy "összecsukni", hogy az adatok kívánt nézetét kapják. Minél több adat "szeletét" és "szeletét" tud feltárni egy elemző, annál több ötlete van, amelyek viszont egyre több "szeletet" igényelnek az ellenőrzéshez. Az adatfeltárás ilyen eszközeként az elemző az OLAP.

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

A működési adatokat különféle forrásokból gyűjtik, tisztítják, integrálják és hozzáadják az adattárházhoz. Ugyanakkor különböző jelentéskészítő eszközökkel már elemzésre is rendelkezésre állnak. 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 adattárházban hagyhatók. Az OLAP használatának legfontosabb eleme a metaadatok, azaz a szerkezetre, a helyre, ill adatátalakítás. Ezeknek köszönhetően a különböző tárolóelemek hatékony interakciója biztosított.

És így, Az OLAP az adattárházban felhalmozott adatok többdimenziós elemzésére szolgáló eszközkészletként definiálható.. Elméletileg az OLAP eszközök közvetlenül alkalmazhatók a működési adatokra ill pontos másolatok. Fennáll azonban annak a veszélye, hogy olyan adatokat is elemzésnek vetnek alá, amelyek nem alkalmasak erre az elemzésre.

OLAP a kliensen és a szerveren

Az OLAP középpontjában a többdimenziós adatelemzés áll. Különféle eszközökkel állítható elő, melyek feltételesen feloszthatók kliens és szerver OLAP eszközökre.

Az ügyféloldali OLAP-eszközök olyan alkalmazások, amelyek összesített adatokat (összegeket, átlagokat, maximumokat vagy minimumokat) számítanak ki és jelenítenek meg, és maguk az összesített adatok az OLAP-eszköz címterében vannak gyorsítótárban.

Ha a forrásadatokat egy asztali DBMS tartalmazza, az összesített adatokat maga az OLAP eszköz számítja ki. Ha a forrásadatok forrása egy kiszolgálói DBMS, akkor sok ügyfél OLAP-eszköz GROUP BY záradékot tartalmazó SQL-lekérdezéseket küld a kiszolgálónak, és ennek eredményeként a kiszolgálón kiszámított összesített adatokat kap.

Általános szabály, hogy az OLAP funkciókat eszközökben valósítják meg statisztikai feldolgozás adatok (az orosz piacon az ebbe az osztályba tartozó termékekről a Stat Soft és az SPSS termékeit széles körben használják) és egyes táblázatokban. Különösen a Microsoft Excel 2000 rendelkezik jó többdimenziós elemző eszközökkel, ezzel a termékkel létrehozhat és menthet egy kis helyi többdimenziós OLAP-kockát fájlként, és megjelenítheti annak két- vagy háromdimenziós részeit.

Sok fejlesztő eszközök osztályok vagy összetevők könyvtárait tartalmazzák, amelyek lehetővé teszik olyan alkalmazások létrehozását, amelyek a legegyszerűbb OLAP-funkciókat valósítják meg (például a Borland Delphi és a Borland C++Builder Decision Cube összetevőit). Ezen kívül sok cég kínál vezérlők ActiveX és más, hasonló funkciókat megvalósító könyvtárak.

Vegye figyelembe, hogy a kliens OLAP-eszközöket általában kis számú dimenzióval (általában hatnál nem több ajánlott) és ezeknek a paramétereknek kevés értékével használják - elvégre a kapott összesített adatoknak illeszkedniük kell a egy ilyen eszköz címterét, és számuk exponenciálisan nő a mérések számának növekedésével. Ezért általában még a legprimitívebb kliens OLAP-eszközök is lehetővé teszik, hogy előzetesen kiszámítsa a szükséges mennyiséget. véletlen hozzáférésű memória hogy többdimenziós kockát hozzunk létre benne.

Sok (de nem mindegyik) ügyféloldali OLAP-eszköz lehetővé teszi az összesített adat-gyorsítótár tartalmának fájlként való tárolását, ami viszont megakadályozza azok újraszámítását. Vegye figyelembe, hogy ezt a lehetőséget gyakran használják az összesített adatok elidegenítésére más szervezeteknek való továbbítás vagy közzététel céljából. Tipikus példa ilyen elidegenített összesített adat az előfordulási statisztikák a különböző régiókban és különböző területeken korcsoportok, ami nyílt információ, amelyet a különböző országok egészségügyi minisztériumai és az Egészségügyi Világszervezet tette közzé. Ugyanakkor maga az eredeti adat, amely konkrét betegségekre vonatkozó információ, egészségügyi intézmények bizalmas adatai, és semmi esetre sem kerülhetnek biztosítótársaságok kezébe, nemhogy nyilvánosságra kerüljenek.

Az aggregált adatok gyorsítótárának fájlban való tárolásának gondolatát a szerveroldali OLAP eszközökben fejlesztették tovább, amelyekben az aggregált adatok tárolását, módosítását, valamint az azokat tartalmazó tároló karbantartását a egy OLAP szerver nevű külön alkalmazás vagy folyamat. Az ügyfélalkalmazások kérhetnek ilyen többdimenziós tárolást, és válaszként kaphatnak néhány adatot. Egyes kliens alkalmazások is létrehozhatnak ilyen tárolókat, vagy frissíthetik azokat a megváltozott forrásadatoknak megfelelően.

A szerver OLAP eszközök használatának előnyei a kliens OLAP eszközökhöz képest hasonlóak a szerver DBMS használatának előnyeihez az asztali eszközökhöz képest: szervereszközök használata esetén az összesített adatok számítása és tárolása a szerveren, illetve a kliens alkalmazáson történik. csak a lekérdezések eredményeit kapja meg, ami lehetővé teszi a hálózati forgalom általános csökkentését, átfutási idő az ügyfélalkalmazás által felhasznált kérések és erőforrásigények. Vegye figyelembe, hogy az elemző eszközök és a vállalati szintű adatfeldolgozás általában pontosan a szerver OLAP-eszközökön alapul, mint például az Oracle Express Server, Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, Crystal Decisions, Business Objects, Cognos, SAS Institute termékek. Mivel az összes vezető szerver DBMS gyártó gyárt (vagy más cégektől licencelt) bizonyos szerver OLAP eszközöket, a választékuk meglehetősen széles, és szinte minden esetben ugyanattól a gyártótól vásárolhat OLAP szervert, mint maga az adatbázisszerver.

Vegye figyelembe, hogy számos kliens OLAP-eszköz (különösen a Microsoft Excel 2003, a Seagate Analysis stb.) lehetővé teszi a szerver OLAP-tárolóinak elérését, amelyek ebben az esetben végrehajtó ügyfélalkalmazásokként működnek. hasonló kéréseket. Ezenkívül számos olyan termék létezik, amely különféle gyártók OLAP-eszközök kliens alkalmazása.

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

A többdimenziós adattárházak különböző részletességű aggregált adatokat tartalmaznak, például értékesítési mennyiségeket nap, hónap, év, termékkategória stb. szerint. Az összesített adatok tárolásának célja a csökkentése átfutási idő kéri, hiszen az elemzéshez, előrejelzéshez a legtöbb esetben nem részletező, hanem összefoglaló adatok az érdekesek. Ezért egy többdimenziós adatbázis létrehozásakor bizonyos összesített adatok mindig kiszámításra és tárolásra kerülnek.

Vegye figyelembe, hogy az összes összesített adat mentése nem mindig indokolt. A helyzet az, hogy új dimenziók hozzáadásakor a kockát alkotó adatok mennyisége exponenciálisan nő (néha az adatmennyiség "robbanásszerű növekedéséről" beszélnek). Pontosabban, az összesített adatnövekedés mértéke a kocka dimenzióinak számától és a dimenziók tagjaitól függ a dimenziók hierarchiájának különböző szintjein. A "robbanásszerű növekedés" problémájának megoldására különféle sémákat használnak, amelyek lehetővé teszik, hogy az összes lehetséges összesített adattól távol számítva a lekérdezés végrehajtásának elfogadható sebességét érjék el.

A forrás és az összesített adatok egyaránt tárolhatók relációs vagy többdimenziós struktúrákban. Ezért jelenleg három módja van az adatok tárolásának.

• MOLAP(Többdimenziós OLAP) - a forrás és az összesített adatok egy többdimenziós adatbázisban tárolódnak. Az adatok többdimenziós struktúrákban való tárolása lehetővé teszi az adatok többdimenziós tömbként történő kezelését, így az összesített értékek kiszámításának sebessége bármelyik dimenziónál azonos. Ebben az esetben azonban a többdimenziós adatbázis redundáns, mivel a többdimenziós adat teljes mértékben tartalmazza az eredeti relációs adatokat.
• ROLAP(Relációs OLAP) – Az eredeti adatok ugyanabban a relációs adatbázisban maradnak, ahol eredetileg voltak. Az összesített adatok speciálisan a tárolásukra létrehozott szolgáltatási táblákban kerülnek elhelyezésre ugyanabban az adatbázisban.
• HOLAP(Hibrid OLAP) - Az eredeti adatok ugyanabban a relációs adatbázisban maradnak, ahol eredetileg voltak, míg az összesített adatok egy többdimenziós adatbázisban tárolódnak.

Egyes OLAP eszközök csak relációs struktúrákban támogatják az adattárolást, mások csak többdimenziós struktúrákban. A legtöbb modern OLAP kiszolgálóeszköz azonban mindhárom adattárolási módot támogatja. A tárolási mód megválasztása a forrásadatok mennyiségétől és szerkezetétől, a lekérdezés végrehajtásának sebességétől és az OLAP-kockák frissítésének gyakoriságától függ.

Azt is megjegyezzük, hogy a modern OLAP-eszközök túlnyomó többsége nem tárol „üres” értékeket (az „üres” értékre példa lehet a szezonális áruk szezonon kívüli értékesítésének hiánya).

OLAP alapfogalmak

FAMSI teszt

A komplex többdimenziós adatelemzés technológiáját OLAP-nak (On-Line Analytical Processing) nevezik. Az OLAP az adattárház-szervezet kulcsfontosságú összetevője. Az OLAP fogalmát Edgar Codd, az ismert adatbázis-kutató és a relációs adatmodell szerzője írta le 1993-ban. 1995-ben a Codd által megfogalmazott követelmények alapján az ún FASMI teszt(Megosztott többdimenziós információk gyors elemzése) – a megosztott többdimenziós információk gyors elemzése, beleértve a többdimenziós elemzési alkalmazások alábbi követelményeit:

• Gyors(Gyors) - ésszerű időn belül (általában legfeljebb 5 s) a felhasználó rendelkezésére bocsátja az elemzési eredményeket, még kevésbé részletes elemzés árán is;
• Elemzés(Elemzés) - bármely jellemző logikai és statisztikai elemzés elvégzésének lehetősége ez az alkalmazás, és annak megőrzése a végfelhasználó számára hozzáférhető formában;
• megosztott(Megosztott) - többfelhasználós hozzáférés az adatokhoz megfelelő zárszerkezetek és engedélyezett hozzáférési eszközök támogatásával;
• Többdimenziós(Többdimenziós) - Az adatok többdimenziós fogalmi megjelenítése, beleértve a hierarchiák és a többszörös hierarchiák teljes körű támogatását (ez az OLAP kulcsfontosságú követelménye);
• 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.

Meg kell jegyezni, hogy az OLAP funkcionalitás megvalósítható különböző utak, kezdve az irodai alkalmazások legegyszerűbb adatelemző eszközeivel és a szervertermékeken alapuló elosztott elemző rendszerekkel.

Az információ többdimenziós reprezentációja

Kuba

Az OLAP kényelmes, nagy sebességű 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 adatmodell, többdimenziós kockák (Cubes) formájú rendszerezése. A többdimenziós koordinátarendszer tengelyei a vizsgált üzleti folyamat fő jellemzői. Például értékesítés esetén lehet termék, régió, vevő típusa. A mérések egyikeként az időt használják. A mérési tengelyek metszéspontjain (Dimensions) a folyamatot kvantitatívan jellemző adatok - intézkedések (Measures) találhatók. Ezek lehetnek darabos vagy pénzben kifejezett értékesítési mennyiségek, készletek egyenlege, 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 évek szerint), vagy fordítva, részletes (hetente) információkat és egyéb olyan manipulációkat hajt végre, amelyek az elemzés során eszébe jutnak.

ábrán látható háromdimenziós kockában mérve. 26.1, az értékesítési mennyiségeket, valamint az időt, a terméket és az üzletet használják mérésként. 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ós időpontok pedig hónaponként vannak csoportosítva. Kicsit később részletesebben megvizsgáljuk a csoportosítási szinteket (hierarchiákat).

Rizs. 26.1.

A 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 láthatóak legyenek a vizsgált mértékek értékei. Mit is mondhatnánk a háromnál több dimenziójú kockákról? A kockában tárolt adatok megjelenítéséhez általában a szokásos kétdimenziós, azaz táblázatos ábrázolásokat használjuk, amelyek összetett hierarchikus sor- és oszlopfejlécekkel rendelkeznek.

Egy kocka kétdimenziós ábrázolását úgy kaphatjuk meg, hogy egy vagy több tengely (dimenzió) mentén átvágjuk: minden dimenzió értékét rögzítjük, kivéve kettőt, és egy szabályos kétdimenziós képet kapunk. asztal. A táblázat vízszintes tengelye (oszlopfejlécek) egy dimenziót, a függőleges tengely (sorfejlécek) egy másik dimenziót, a táblázat cellái pedig mértékértékeket képviselnek. Ebben az esetben tulajdonképpen a mértékkészletet tekintjük az egyik dimenziónak: vagy kiválasztunk egy mértéket megjelenítésre (majd két dimenziót helyezhetünk el a sorok és oszlopok fejlécében), vagy megjelenítünk több mértéket (majd egy a táblázat tengelyei közül a mértékek nevei foglalják el, a másikat pedig egyetlen "nem vágott" méret értékei).

OLAP alkalmazásarchitektúra

Mindaz, amit fentebb az OLAP-ról elmondtunk, valójában az adatok többdimenziós megjelenítésére vonatkozott. Durván fogalmazva, sem a végfelhasználó, sem az ügyfél által használt eszköz fejlesztői nem törődnek az adatok tárolásának módjával.

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

• Többdimenziós adatreprezentáció - többdimenziós megjelenítést és adatkezelést biztosító végfelhasználói eszközök; a többdimenziós reprezentációs réteg elvonatkoztat az adatok fizikai struktúrájától, és többdimenziósként kezeli az adatokat.
• A többdimenziós feldolgozás egy eszköz (nyelv) többdimenziós lekérdezések megfogalmazására (hagyományos relációs SQL nyelv itt használhatatlannak bizonyul) és egy olyan processzort, amely képes feldolgozni és végrehajtani egy ilyen kérést.
• Többdimenziós tárolás - Eszközök fizikai szervezettség többdimenziós lekérdezések hatékony végrehajtását biztosító adatok.

Az első két szint minden OLAP-eszközben kötelező. A harmadik szint, bár széles körben használatos, nem szükséges, mivel a többdimenziós ábrázoláshoz szükséges adatok a hétköznapi relációs struktúrákból is lekérhetők; a többdimenziós lekérdezés processzor ebben az esetben a többdimenziós lekérdezéseket SQL lekérdezésekké fordítja, amelyeket egy relációs DBMS hajt végre.

Az egyes OLAP-termékek általában vagy egy többdimenziós adatmegjelenítő eszköz (OLAP-kliens – például Pivot Tables az Excel 2000-ben a Microsofttól vagy a ProClarity a Knosys-től), vagy egy többdimenziós háttér-DBMS (OLAP-kiszolgáló – például Oracle Express Server vagy Microsoft OLAP). szolgáltatások).

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

/ Kubista módon. Az OLAP kockák alkalmazása a nagyvállalatok vezetési gyakorlatában

Kapcsolatban áll

osztálytársak

Konsztantyin Tokmacsev, rendszerépítész

kubista módon.
Az OLAP kockák alkalmazása a nagyvállalatok vezetési gyakorlatában

Talán már eltelt az idő, amikor a vállalat számítási erőforrásait csak az információk és a számviteli jelentések nyilvántartására fordították. Ugyanakkor a vezetői döntések „szemből” születtek az irodákban, értekezleteken, üléseken. Talán Oroszországban ideje visszatérni a vállalati számítástechnikai rendszerekhez fő erőforrás– vezérlési feladatok megoldása a számítógépen regisztrált adatok alapján

Az üzleti intelligencia előnyeiről

A vállalatirányítási körben a „nyers” adatok és a kezelt objektumot befolyásoló „karok” között „teljesítménymutatók” - KPI-k találhatók. Mintha egy „műszerfalat” alkotnak, amely a vezérelt objektum különféle alrendszereinek állapotát tükrözi. A vállalat informatív teljesítménymutatókkal való felszerelése, számításuk és a kapott értékek ellenőrzése egy üzleti elemző munkája. A vállalat elemző munkájának megszervezésében jelentős segítséget nyújthatnak az automatizált elemző szolgáltatások, mint például az MS SQL szerver Az Analysis Services (SSAS) és fő jellemzője egy OLAP-kocka.

Itt még egy megjegyzést kell tenni. Például az amerikai hagyományban az OLAP-kockákkal való munkavégzésre összpontosító szakterületet BI-nek (Business Intelligence) hívják. Nem lehetnek illúziók arról, hogy az amerikai BI megfelel az orosz "üzleti elemzőnek". Nem sértődj meg, de üzleti elemzőnk gyakran „alulkönyvelő” és „alulprogramozó”, elmosódott tudású, kis fizetésű szakember, akinek valóban nincs saját eszköze és módszertana.

A BI-szakember tulajdonképpen alkalmazott matematikus, magas színvonalú szakember, aki a modern matematikai módszereket a cégek szolgálatába állítja (ezt nevezték Operations Research – műveletkutatási módszerek). A BI jobban megfelel a korábban a Szovjetunióban működő „rendszerelemző” szaknak, amelyet a Moszkvai Állami Egyetem VMK kara készített. M.V. Lomonoszov. Az OLAP-kocka és az elemző szolgáltatások ígéretes alapokká válhatnak egy orosz üzleti elemző munkahelyén, talán azután, hogy némileg javult a képzettsége az amerikai BI irányába.

A közelmúltban egy újabb káros tendencia jelent meg. A specializációnak köszönhetően elveszett a kölcsönös megértés a vállalat alkalmazottainak különböző kategóriái között. Egy könyvelő, menedzser és programozó, mint egy "hattyú, rák és csuka" az I.A. meséjében. Krylov, különböző irányokba húzva a vállalatot.

A könyvelő elfoglalt a jelentéskészítéssel, annak összegei mind jelentésben, sem dinamikában nem kapcsolódnak közvetlenül a cég üzleti folyamatához.

A menedzser az üzleti folyamat saját szegmensével van elfoglalva, de nem tudja globálisan, a vállalat egészének szintjén felmérni tevékenységének eredményeit és kilátásait.

Végül a programozó, aki egykor (az oktatásnak köszönhetően) haladó műszaki ötletek karmestere volt a tudomány szférától az üzleti szféráig, a könyvelő és menedzser fantáziájának passzív végrehajtójává vált, így már nem ritka, amikor a könyvelők és általában mindenki, aki nem lusta. Az avatatlan, írástudatlan, de viszonylag jól fizetett 1C programozó igazi csapás az orosz vállalatok számára. (Majdnem úgy, mint egy hazai futballista.) Nem az úgynevezett „közgazdászokról és jogászokról” beszélek, róluk már régen minden elhangzott.

Tehát a programozás és a számvitel alapjait ismerő, csúcstechnológiás SSAS apparátussal felszerelt üzleti elemző pozíciója képes megszilárdítani a vállalat munkáját az üzleti folyamat elemzésével és előrejelzésével kapcsolatban.

Az OLAP kockák előnyei

OLAP kocka az modern létesítmény a vállalati számítógépes rendszer adatbázisának elemzése, amely lehetővé teszi a hierarchia minden szintjén dolgozó munkavállalók számára a szükséges mutatók készletét, amelyek jellemzik a vállalat termelési folyamatát. A lényeg nem csak az felhasználóbarát felületés az MDX-kocka rugalmas lekérdezési nyelve (MultiDimensional eXpressions) lehetővé teszi a szükséges analitikai mutatók megfogalmazását és kiszámítását, de ezt az OLAP-kocka rendkívüli gyorsasággal és egyszerűen megteheti. Ezen túlmenően ezek a gyorsaság és egyszerűség bizonyos határokon belül nem függ a számítások összetettségétől és az adatbázis mennyiségétől.

Az OLAP némi megértése
kocka adhat" Pivot tábla» MS Excel. Ezek az objektumok hasonló logikával és hasonló interfészekkel rendelkeznek. De ahogy a cikkből kiderül, az OLAP funkcionalitása összehasonlíthatatlanul gazdagabb, a teljesítmény pedig összehasonlíthatatlanul magasabb, így a „pivot tábla” továbbra is helyi asztali termék marad, míg az OLAP vállalati szintű termék.

Miért alkalmas egy OLAP-kocka olyan jól analitikai problémák megoldására? Az OLAP-kocka úgy van kialakítva, hogy minden lehetséges szakaszban minden mutató előre kiszámított (egészben vagy részben), és a felhasználónak csak a szükséges mutatókat (mérések, mértékek) és szakaszokat (méretek méretek) kell „kihúznia” ) az egérrel, és a program újrarajzolja a lemezeket.

Az összes lehetséges elemzés minden szekcióban egyetlen hatalmas mezőt alkot, vagy inkább nem egy mezőt, hanem csak egy többdimenziós OLAP-kockát. Bármilyen kéréssel is forduljon egy felhasználó (menedzser, üzleti elemző, menedzser) az analitikai szolgáltatáshoz, a válaszadás sebessége két dolognak köszönhető: egyrészt könnyen megfogalmazható a kívánt elemzés (vagy név szerint kiválasztható a listából, vagy képlet segítségével megadható). MDX nyelven ), másodszor pedig általában már ki lett számítva.

Az analitika megfogalmazása három változatban lehetséges: vagy adatbázismező (pontosabban raktármező), vagy kocka tervezési szinten meghatározott számítási mező, vagy MDX nyelvi kifejezés a kockával interaktív munka során.

Ez az OLAP-kockák több vonzó tulajdonságát jelenti egyszerre. Valójában megszűnik az akadály a felhasználó és az adatok között. Gát egy alkalmazásprogramozó formájában, akinek először is meg kell magyaráznia a problémát (feladatot kell kitűznie). Másodszor, meg kell várni, amíg az alkalmazásprogramozó elkészíti az algoritmust, megírja és hibakeresi a programot, majd módosítani lehet. Ha sok alkalmazott van, és az igényeik változatosak és változékonyak, akkor alkalmazott programozók egész csapatára van szükség. Ebben az értelemben egy OLAP-kocka (és egy képzett üzleti elemző) az elemzői munka szempontjából egy egész csapat alkalmazás-programozót helyettesít, mint ahogy egy erős kotrógép egy kotrógép vezetővel árokásáskor egy egész brigád vendégmunkás ásót vált ki!

Ebben az esetben a kapott analitikai adatok másik nagyon fontos minősége érhető el. Mivel az OLAP kocka egy az egész cégnek, i.e. Mivel ez ugyanaz a mező, ahol az elemzők mindenki számára elérhetők, az adatok bosszantó következetlensége kizárt. Amikor egy menedzsernek ugyanazt a feladatot kell kitűznie több független munkatársnak a szubjektivitási tényező kiküszöbölése érdekében, de mégis más-más válaszokat hoznak, amiket mindenki vállalkozik valamilyen módon elmagyarázni stb. Az OLAP kocka biztosítja az analitikai adatok egységességét a vállalati hierarchia különböző szintjein, pl. ha a vezető részletezni akar egy számára érdekes mutatót, akkor minden bizonnyal azokhoz az alacsonyabb szintű adatokhoz fog eljutni, amelyekkel a beosztottja dolgozik, és ez csak az az adat lesz, amely alapján a magasabb szintű mutatót kiszámítják. , és nem valami más adat, más módon, máskor kapott stb. Vagyis az egész vállalat ugyanazt az elemzést látja, de a konszolidáció különböző szintjein.

Vegyünk egy példát. Tegyük fel, hogy egy vezető felügyeli a követeléseket. Amíg a lejárt kintlévőségek KPI-je zöld, addig minden normális, nincs szükség kezelési lépésekre. Ha a szín sárgára vagy pirosra változott, akkor valami nem stimmel: értékesítési osztályonként levágjuk a KPI-t, és azonnal „pirossal” látjuk a felosztásokat. A következő szakasz a menedzserekről és az eladóról szól, akinek az ügyfelei késnek a fizetéssel. (Továbbá a késedelem mértéke vevőkre, feltételekre stb. bontható.) A társaság vezetője bármilyen szinten közvetlenül megszólíthatja a szabálysértőket. De általában ugyanazt a KPI-t (a hierarchia szintjein) látják mind az osztályvezetők, mind az értékesítési vezetők. Ezért a helyzet korrigálása érdekében nem is kell várniuk a „szőnyegre hívásra”... Természetesen magának a KPI-nek nem kell feltétlenül a késedelem mértékének lennie - ez lehet súlyozott átlag késedelmi időszak vagy általában a követelések forgalmának mértéke.

Vegye figyelembe, hogy az MDX nyelv összetettsége és rugalmassága, valamint a gyors (néha azonnali) eredmények lehetővé teszik a megoldást (figyelembe véve a fejlesztés és a hibakeresés szakaszait) kihívást jelentő feladatokat vezérlők, amelyek más feltételek mellett talán egyáltalán nem lettek volna beállítva az alkalmazott programozók bonyolultsága és a megfogalmazás kezdeti bizonytalansága miatt. (Hosszú időkeretek az alkalmazásprogramozóknak az analitikai problémák megoldására a rosszul értelmezett megfogalmazás és a hosszú programmódosítások miatt, amikor a körülmények gyakran változnak a gyakorlatban.)

Ügyeljünk arra is, hogy a cég minden dolgozója az általános mezőről pontosan azt a termést szedje össze az OLAP elemzővel, amelyre szüksége van a munkához, és ne elégedjen meg azzal a „csíkkal”, amelyet a közösségi „standard jelentésekben” vágott. ”.

Az OLAP kockával kliens-szerver módban történő munkavégzéshez többfelhasználós felület lehetővé teszi, hogy minden alkalmazott, másoktól függetlenül, saját (akár saját termelési képességgel rendelkező) elemzési blokkokkal (jelentésekkel) rendelkezzen, amelyek definiálása után automatikusan frissítve – más szóval, mindig naprakész állapotban vannak.

Vagyis az OLAP-kocka lehetővé teszi, hogy az analitikai munkát (amit valójában nemcsak a jegyzetelemzők végeznek, hanem a vállalat szinte minden alkalmazottja, még a logisztikusok és az egyenlegeket és szállítmányokat irányító menedzserek is) szelektívebbé tegyük. az arcról nem általános kifejezésben” , ami megteremti a feltételeket a munka javításához és a termelékenység növeléséhez.

Bevezetőnket összefoglalva megjegyezzük, hogy az OLAP kockák használata magasabb szintre emelheti egy vállalat irányítását. Az analitikai adatok egységessége a hierarchia minden szintjén, megbízhatóságuk, összetettségük, indikátorok létrehozásának és módosításának egyszerűsége, egyedi beállítások, nagy adatfeldolgozási sebesség, végül az alternatív elemzési utak támogatására fordított pénz és idő megtakarítása (alkalmazásprogramozók, függetlenek alkalmazott számításai), nyílt kilátások az OLAP-kockák használatára a nagy orosz vállalatok gyakorlatában.

OLTP + OLAP: vázlat Visszacsatolás a vállalatirányítási láncban

Most fontolja meg az OLAP kockák általános elképzelését és alkalmazási helyét a vállalatirányítási láncban. Az OLAP (OnLine Analytical Processing) kifejezést Edgar Codd brit matematikus vezette be a korábbi OLTP (OnLine Transactions Processing) kifejezése mellé. Erről később lesz szó, de E. Codd természetesen nem csak a terminusokat, hanem az OLTP és az OLAP matematikai elméleteit is javasolta. Anélkül, hogy belemennénk a részletekbe, az OLTP modern értelmezése szerint egy relációs adatbázis, amelyet az információk regisztrálásának, tárolásának és visszakeresésének mechanizmusának tekintenek.

Megoldás módszertana

Az ilyen ERP-rendszerek (Enterprice Resource Planning), mint az 1C7, 1C8, MS Dynamics AX, felhasználó-orientált szoftverfelülettel (dokumentumok bevitele és javítása stb.), valamint relációs adatbázissal (DB) rendelkeznek a ma bemutatott információk tárolására és visszakeresésére. szoftver termékekírja be: MS SQL Server (SS).

Ne feledje, hogy az ERP rendszer adatbázisában nyilvántartott információk valóban nagyon értékes erőforrások. Nem csak az a lényeg, hogy a nyilvántartott információk biztosítsák a társaság aktuális munkafolyamatát (okmánykiállítás, azok javítása, kinyomtatás és egyeztetés lehetősége stb.), és ne csak a számítási lehetőség. pénzügyi kimutatások(adók, könyvvizsgálat stb.). Vezetési szempontból sokkal fontosabb, hogy egy OLTP-rendszer (relációs adatbázis) valójában egy vállalati tevékenység tényleges digitális modellje teljes méretben.

A folyamat irányításához azonban nem elegendő az ezzel kapcsolatos információk regisztrálása. A folyamatot a lefolyását jellemző numerikus mutatók (KPI) rendszereként kell bemutatni. Ezenkívül meg kell határozni az indikátorok megengedett értéktartományait. És csak akkor, ha a mutató értéke meghaladja a megengedett intervallumot, akkor egy ellenőrzési műveletet kell követni.

Az irányítás efféle logikáját (vagy mitológiáját) tekintve mind az ókori görög filozófus, Platón, aki megalkotta a kormányos (kibernosz) képét, aki az evezőre támaszkodik, amikor a csónak letér az irányról, mind a Norbert Wiener amerikai matematikus, aki a számítógépek korszakának küszöbén megteremtette a kibernetika tudományát.

Az OLTP módszerrel történő információrögzítés szokásos rendszerén kívül még egy rendszerre van szükség - egy rendszerre az összegyűjtött információk elemzésére. Ez a bővítmény, amely a vezérlőkörben a felügyelet és a vezérlőobjektum közötti visszacsatolás szerepét tölti be, egy OLAP rendszer vagy röviden egy OLAP kocka.

Mint szoftver megvalósítás OLAP, figyelembe vesszük az MS Analysis Services segédprogramot, amely az MS SQL Server (rövidítve SSAS) szabványos szállításának része. Vegyük észre, hogy E. Codd elképzelése szerint az OLAP kockának az analitikában ugyanazt a kimerítő cselekvési szabadságot kell biztosítania, mint az OLTP rendszernek és a relációs adatbázisnak (SQL Server) az információk tárolása és visszakeresése során.

OLAP logisztika

Most nézzük meg a külső eszközök, alkalmazások és technológiai műveletek sajátos konfigurációját, amelyen az OLAP kocka automatizált működése alapul.

Feltételezzük, hogy a vállalat ERP rendszert használ, például 1C7 vagy 1C8, amelyen belül az információkat a szokásos módon regisztrálják. Ennek az ERP-rendszernek az adatbázisa egy bizonyos szerveren található, és az MS SQL Server tartja karban.

Azt is feltételezzük, hogy a szoftver egy másik kiszolgálóra van telepítve, beleértve az MS Analysis Services (SSAS) segédprogrammal rendelkező MS SQL Servert, valamint az MS SQL Server Management Studio, MS C#, MS Excel és MS Visual Studio programokat. Ezek a programok együtt alkotják a szükséges kontextust: az OLAP kocka fejlesztője számára szükséges eszközöket és felületeket.

Az SSAS szerveren telepítve van a freeware blat, amelyet (paraméterekkel) innen hívnak parancs sorés postai szolgáltatások nyújtása.

Alkalmazotti munkaállomásokon, belül helyi hálózat, többek között MS Excel programok (legalább 2003-as verziók) vannak telepítve, és esetleg speciális sofőr hogy az MS Excel együttműködjön az MS Analysis Services szolgáltatással (kivéve, ha a megfelelő illesztőprogram már szerepel az MS Excelben).

A határozottság kedvéért feltételezzük, hogy az alkalmazottak munkaállomásai rendelkeznek operációs rendszer Windows XP és szervereken - Windows Server 2008. Tegyük fel, hogy az MS SQL Server 2005-öt használják SQL Serverként, és az Enterprise Edition (EE) vagy a Developer Edition (DE) telepítve van a szerveren az OLAP-kockával. Ezekben a kiadásokban lehetőség van az ún. "félig additív intézkedések", azaz további összesített függvények(statisztika) a szokásos összegektől eltérő (például szélső vagy átlagos érték).

OLAP-kocka tervezés (OLAP-kubizmus)

Ejtsünk néhány szót magáról az OLAP-kocka kialakításáról. A statisztika nyelvén az OLAP-kocka teljesítménymutatók összessége, amelyeket az összes szükséges szakaszban kiszámítanak, például egy szállítási mutatót szakaszokban vásárlók, áruk, dátumok szerint stb. Az OLAP-kockákra vonatkozó orosz szakirodalomban az angolról való közvetlen fordítás miatt a mutatókat "méréseknek", a vágásokat pedig "dimenzióknak" nevezik. Ez egy matematikailag helyes, de szintaktikailag és szemantikailag nem túl sikeres fordítás. Az orosz "measure", "measurement", "dimension" szavak jelentése és helyesírása szinte nem különbözik egymástól, míg az angol "measure" és "dimension" eltér mind helyesírási, mind jelentési szempontból. Ezért előnyben részesítjük a hagyományos orosz statisztikai kifejezéseket, amelyek jelentésükben hasonlóak az "indikátor" és a "kivágás" kifejezésekhez.

Az OLAP kocka szoftveres megvalósítására több lehetőség is kínálkozik az OLTP rendszerrel kapcsolatban, ahol az adatok naplózódnak. Csak egy sémát fogunk figyelembe venni, a legegyszerűbb, legmegbízhatóbb és leggyorsabb.

Ebben a sémában az OLAP-nak és az OLTP-nek nincsenek közös táblái, és az OLAP-elemzés a lehető legrészletesebben kerül kiszámításra a használati szakaszt megelőző kockafrissítési (folyamat) szakaszban. Ezt a sémát MOLAP-nak (Multidimensional OLAP) hívják. Hátránya az ERP-vel való aszinkronitás és a magas memóriaköltségek.

Bár formálisan egy OLAP-kockát fel lehet építeni egy ERP-rendszer relációs adatbázisának összes (ezer) táblájából adatforrásként, és azok összes (több száz) mezőjéből indikátorként vagy szakaszként, a valóságban ezt nem szabad megtenni. Oda-vissza. A kockába való betöltéshez helyesebb külön adatbázist készíteni, amelyet „kirakatnak” vagy „raktárnak” (raktárnak) neveznek.

Ennek több oka is van.

• Először, egy OLAP-kocka összekapcsolása egy valós adatbázis tábláival minden bizonnyal létrehozza technikai problémák. A táblázatban lévő adatok megváltoztatása kiválthatja a kocka frissítését, és a kocka frissítése nem feltétlenül gyors folyamat, így a kocka állandó újraépítési állapotban lesz; ugyanakkor a kocka frissítési eljárása blokkolhatja (olvasás közben) az adatbázis táblák adatait, lelassítva a felhasználók munkáját az adatok ERP rendszerben történő rögzítésében.
• Másodszor, a túl sok jelző és vágás jelenléte drámaian megnöveli a kocka tárolóterületét a szerveren. Ne felejtsük el, hogy az OLAP kocka nem csak a kezdeti adatokat tárolja, mint az OLTP rendszerben, hanem az összes lehetséges szakaszon (sőt az összes szekció összes kombinációján) összesített mutatót is. Emellett ennek megfelelően lelassul a kocka frissítési sebessége és végső soron az elemzések és az ezek alapján készült felhasználói jelentések elkészítésének, frissítésének sebessége is.
• Harmadik, túl sok nagyszámú mezők (intézkedések és szempontok) problémákat okoznak az OLAP fejlesztői felületén, mert az elemek listája végtelenné válik.
• Negyedik, Az OLAP-kocka nagyon érzékeny az adatintegritás megsértésére. Kocka nem építhető fel, ha a kulcsadatokat nem a kockamezők hivatkozási struktúrájában megadott hivatkozás található. Az integritás ideiglenes vagy tartós megsértése, az üres mezők gyakoriak egy ERP rendszer adatbázisában, de ez kategorikusan nem alkalmas OLAP-ra.

Azt is hozzáteheti, hogy az ERP rendszernek és az OLAP kockának különböző szervereken kell elhelyezkednie a terhelés megosztása érdekében. De akkor, ha vannak közös táblák az OLAP-hoz és az OLTP-hez, akkor is probléma van hálózati forgalom. Gyakorlatilag megoldhatatlan problémák jelennek meg ebben az esetben, ha több heterogén ERP rendszert (1C7, 1C8, MS Dynamics AX) egy OLAP kockába kell összevonni.

Valószínűleg tovább halmozhatók a technikai problémák. De ami a legfontosabb, ne feledje, hogy az OLTP-vel ellentétben az OLAP nem az adatok regisztrálásának és tárolásának eszköze, hanem egy elemző eszköz. Ez azt jelenti, hogy nincs szükség "piszkos" adatok betöltésére és betöltésére az ERP-ből az OLAP-ba "csak abban az esetben". Ellenkezőleg, először ki kell dolgozni egy koncepciót egy vállalat menedzselésére, legalább a KPI rendszer szintjén, majd meg kell tervezni egy alkalmazás adattárházat (raktárt), amely ugyanazon a szerveren található, mint az OLAP-kocka, és kis finomított mennyiségű ERP-t tartalmaz. kezeléséhez szükséges adatok .

A rossz szokások előmozdítása nélkül az OLAP-kocka az OLTP-vel kapcsolatban a jól ismert "alembikushoz" hasonlítható, amelyen keresztül az "erjesztett masszából" valódi regisztráció a „tiszta terméket” visszanyerjük.

Tehát azt kaptuk, hogy az OLAP adatforrása egy speciális adatbázis (raktár), amely ugyanazon a szerveren található, mint az OLAP. Ez alapvetően két dolgot jelent. Először is speciális eljárásoknak kell lenniük, amelyek ERP-adatbázisokból raktárt hoznak létre. Másodszor, az OLAP kocka aszinkron az ERP rendszereivel.

A fentiek figyelembevételével a számítási folyamat architektúrájának következő változatát javasoljuk.

Megoldás architektúra

Legyen egy adott vállalatnak (holdingnak) sok ERP rendszere különböző szervereken, amelyek elemzési adatait egy OLAP kockán belül szeretnénk látni. Hangsúlyozzuk, hogy a leírt technológiában az ERP-rendszerekből származó adatokat raktárszinten kombináljuk, az OLAP kocka kialakítását változatlanul hagyva.

Az OLAP szerveren képfájlokat (üres másolatokat) készítünk az összes ilyen ERP-rendszer adatbázisáról. Ezekre az üres másolatokra időszakonként (éjszakánként) végrehajtjuk a megfelelő aktívan futó ERP-k adatbázisainak részleges replikációját.

Ezután elindul az SP (tárolt eljárás), amely ugyanazon az OLAP szerveren, hálózati forgalom nélkül, az ERP rendszerek adatbázisainak részleges replikái alapján létrehozza (vagy feltölti) a tárolót (raktárt) - az OLAP adatforrását. kocka.

Ezután elindul a szabványos eljárás a raktári adatok alapján történő kocka frissítésére / felépítésére (az SSAS felületen a Folyamat művelet).

Nézzük meg a technológia néhány vonatkozását. Milyen munkát végeznek az SP-k?

A részleges replikáció eredményeként a tényleges adatok megjelennek az OLAP-kiszolgálón lévő ERP-rendszerek képében. A részleges replikációt egyébként kétféleképpen is meg lehet valósítani.

Először is, az ERP rendszer adatbázisában lévő összes tábla közül a részleges replikáció során csak azokat másolják át, amelyek a raktár felépítéséhez szükségesek. Ezt a táblanevek rögzített listája vezérli.

Másodszor, a részleges replikáció azt is jelentheti, hogy a tábla nem minden mezője másolódik, hanem csak azok, amelyek részt vesznek a raktár felépítésében. A másolandó mezők listája vagy megadásra kerül, vagy dinamikusan jön létre az SP-ben a másolási képből (ha a táblázat másolata kezdetben nem tartalmazza az összes mezőt).

Természetesen nem lehet teljes táblasorokat másolni, hanem csak új rekordokat lehet hozzáadni. Ez azonban komoly kényelmetlenséget okoz az ERP-revíziók „visszadátumozásának” elszámolásakor, amely gyakran előfordul a valós rendszerekben. Így könnyebb minden további nélkül átmásolni az összes rekordot (vagy frissíteni a "farkat" bizonyos dátumtól kezdve).

Továbbá az SP fő feladata az ERP-rendszerekből származó adatok raktárformátumba konvertálása. Ha csak egy ERP-rendszer van, akkor az átalakítás feladata elsősorban a szükséges adatok másolására, esetleg újraformázására korlátozódik. De ha több, eltérő felépítésű ERP rendszert kell összevonni ugyanabban az OLAP kockában, akkor az átalakítások bonyolultabbá válnak.

Különösen nehéz feladat több különböző ERP rendszer egy kockában való összevonása, ha az objektumok halmazai (árukönyvtárak, vállalkozók, raktárak stb.) részben metszik egymást, akkor az objektumok ugyanazt a jelentést hordozzák, de természetesen eltérő leírásuk van a könyvtárakat különböző rendszerek(kódok, azonosítók, nevek stb. értelmében).

Valójában egy nagy holdingban egy ilyen kép alakul ki, amikor több, azonos típusú önálló társaság is megközelítőleg ugyanazon a területen végez hozzávetőlegesen azonos típusú tevékenységet, de saját és nem koordinált nyilvántartási rendszert alkalmaz. Ebben az esetben az adatok raktárszintű konszolidálásakor nem nélkülözheti a segédleképezési táblákat.

Fordítsunk egy kis figyelmet a raktári tárolási architektúrára. Az OLAP kocka sémát általában "csillagként" ábrázolják, azaz. mint adattábla, amelyet könyvtárak "sugarai" vesznek körül - másodlagos kulcsértékek táblázatai. A táblázat az "indikátorok" blokkja, a kézikönyvek a kivágásaik. Ugyanakkor a címtár lehet tetszőleges kiegyensúlyozatlan fa vagy kiegyensúlyozott hierarchia, például áruk vagy partnerek többszintű osztályozása. Egy OLAP-kockában a raktárból származó adattábla numerikus mezői automatikusan "mutatókká" (vagy mértékértékekké) válnak, a szakaszok (vagy dimenziók) pedig másodlagos kulcsok tábláin keresztül definiálhatók.

Ez egy vizuális "pedagógiai" leírás. Valójában egy OLAP-kocka architektúrája sokkal összetettebb lehet.

Először is, egy raktár több „csillagból” állhat, amelyek esetleg közös könyvtárakon keresztül kapcsolódnak egymáshoz. Ebben az esetben az OLAP-kocka több kocka (több adatblokk) uniója lesz.

Másodszor, a csillag "sugár" lehet, hogy nem egy könyvtár, hanem egy teljes (hierarchikus) fájlrendszer.

Harmadszor, a meglévő dimenzióvágások alapján az OLAP fejlesztői felületén új hierarchikus vágások definiálhatók (mondjuk kevesebb szinttel, eltérő szintrenddel stb.)

Negyedszer, új mutatók (számítások) definiálhatók a meglévő mutatók és szakaszok alapján az MDX nyelv kifejezésével. Fontos megjegyezni, hogy az új kockák, új mutatók, új szakaszok automatikusan teljes mértékben integrálódnak az eredeti elemekkel. Azt is meg kell jegyezni, hogy a rosszul megfogalmazott számítások és a hierarchikus vágások észrevehetően lelassíthatják az OLAP kocka munkáját.

MS Excel, mint interfész az OLAP-pal

Külön érdekesség az OLAP kockákat tartalmazó felhasználói felület. Természetesen maga az SSAS segédprogram biztosítja a legteljesebb interfészt. Ez egy OLAP-kocka fejlesztői eszközkészlet, egy interaktív jelentéstervező, és egy ablak az OLAP-kockákkal való interaktív munkavégzéshez, MDX nyelvű lekérdezések használatával.

Magán az SSAS-on kívül számos olyan program létezik, amely interfészt biztosít az OLAP-nak, kisebb-nagyobb mértékben lefedi a funkcionalitásukat. De van köztük egy, amelynek véleményünk szerint tagadhatatlan előnyei vannak. Ez az MS Excel.

Az MS Excel-lel való felületet egy speciális illesztőprogram biztosítja, amely külön letölthető vagy az Excelhez mellékelve. Nem fedi le az OLAP összes funkcióját, de az MS Excel verziószámának növekedésével ez a lefedettség egyre szélesebb (mondjuk az MS Excel 2007-ben megjelenik egy KPI-grafika, ami az MS Excel 2003-ban nem volt stb.).

Természetesen a meglehetősen teljes funkcionalitás mellett az MS Excel fő előnye ennek a programnak a mindenütt jelen lévő terjesztése és az, hogy az irodai felhasználók túlnyomó többsége közel ismeri. Ebben az értelemben, a többi interfész programtól eltérően, a cégnek nem kell semmit sem beszereznie, és senkit sem kell tovább képeznie.

Az MS Excel mint OLAP interfész nagy előnye az OLAP jelentésben kapott adatok további független feldolgozásának lehetősége (vagyis az OLAP-ból nyert adatok tanulmányozásának folytatása ugyanazon Excel más lapjain, már nem OLAP eszközöket, de hagyományos Excel eszközöket használva).

Éjszakai facubi kezelési ciklus

Most írjuk le az OLAP működés napi (éjszakai) számítási ciklusát. A számítás a C # 2005 nyelven írt facubi program vezérlése alatt történik, és a Task Scheduler segítségével elindítva egy raktárral és SSAS-szal rendelkező szerveren. Kezdetben a facubi hozzáfér az internethez, és leolvassa az aktuális árfolyamokat (egy pénznemben számos mutatót ábrázol). Ezután a következő lépéseket hajtják végre.

Először a facubi olyan SP-ket indít el, amelyek a helyi hálózaton elérhető különböző ERP-rendszerek (holding elemek) részleges adatbázis-replikációját hajtják végre. A replikáció, mint mondtuk, előre elkészített "yardokon" - az SSAS-kiszolgálón található távoli ERP-rendszerek képeinél - történik.

Másodszor, az SP-n keresztül leképezés történik az ERP-replikákról a raktári tárolóra – egy speciális adatbázisra, amely az OLAP-kockaadatok forrása és az SSAS-kiszolgálón található. Ez három fő feladatot valósít meg:

• ERP adatok a szükséges kockaformátumok alá kerülnek; táblákról és táblamezőkről beszélünk. (Néha a szükséges táblázatot „öntni kell”, mondjuk több MS Excel lapból.) A hasonló adatok eltérő formátumúak lehetnek a különböző ERP-kben, például az 1C7 könyvtárak kulcsazonosító mezőinek 36 karakteres, 8 hosszúságú kódja van. , és _idrref mezők az 1C8 könyvtárakban - 32 hosszúságú hexadecimális számok;
• feldolgozás során történik az adatok logikai ellenőrzése (beleértve a hiányzó adatok helyére alapértelmezett „alapértelmezett” értékek előírását, ahol lehetséges) és integritás-ellenőrzés, pl. az elsődleges és másodlagos kulcsok jelenlétének ellenőrzése a megfelelő osztályozókban;
• kódkonszolidáció objektumok, amelyeknek ugyanaz a jelentése a különböző ERP-kben. Például a különböző ERP-k könyvtárainak megfelelő elemei ugyanazt jelenthetik, mondjuk ez ugyanaz a partner. A kódkonszolidáció problémáját leképezési táblák felépítésével oldjuk meg, ahol különféle kódok ugyanazok a tárgyak kerülnek egységbe.

Harmadszor, a facubi elindítja a szabványos Process cube adatfrissítési eljárást (az SSAS segédprogramokból).

Az ellenőrző listák szerint a facubi e-mail üzeneteket küld a feldolgozási lépések előrehaladásáról.

A facubi végrehajtása után a Feladatütemező több dolgot is futtat excel fájlokat, amelyek OLAP kocka metrikák alapján előre elkészített jelentésekkel rendelkeznek. Mint mondtuk, az MS Excel rendelkezik egy speciális programozási felülettel (külön letölthető vagy beépített illesztőprogram) az OLAP kockákkal való munkavégzéshez (SSAS-szal). Amikor elindítja az MS Excelt, az MS VBA-n futó programok (például makrók) jelennek meg, amelyek a jelentések adatainak frissítését biztosítják; a riportokat szükség esetén módosítjuk és ellenőrző listák szerint postai úton (blat program) küldjük el a felhasználóknak.

Az SSAS-kiszolgálóhoz hozzáféréssel rendelkező helyi hálózati felhasználók "élő" jelentéseket kapnak az OLAP-kockához konfiguráltan. (Elvileg ők maguk, mindenféle levél nélkül frissíthetik az OLAP jelentéseket MS Excelben, a helyi számítógépükön fekve.) A helyi hálózaton kívüli felhasználók vagy eredeti, de korlátozott funkcionalitású jelentéseket kapnak, vagy helyettük (az OLAP jelentések frissítése után) MS Excelben) speciális "halott" jelentések kerülnek kiszámításra, amelyek nem lépnek kapcsolatba az SSAS szerverrel.

Az eredmények értékelése

Fentebb beszéltünk az OLTP és az OLAP aszinkronjáról. A technológia figyelembe vett változatában az OLAP kocka frissítési ciklus éjszaka történik (mondjuk hajnali 1-kor kezdődik). Ez azt jelenti, hogy az aktuális munkanapon a felhasználók a tegnapi adatokkal dolgoznak. Mivel az OLAP nem naplózó eszköz (lásd a dokumentum legújabb verzióját), hanem felügyeleti eszköz (értse a folyamat trendjét), ez a lemaradás általában nem kritikus. Szükség esetén azonban akár a kocka architektúra (MOLAP) leírt változatában is lehetőség van naponta többszöri frissítésre.

A frissítési eljárások végrehajtási ideje az OLAP kocka tervezési jellemzőitől (több-kevesebb összetettség, többé-kevésbé sikeres indikátorok és szekciók meghatározása), valamint a külső OLTP rendszerek adatbázisainak mennyiségétől függ. A tapasztalatok szerint a raktárépítési eljárások több perctől két óráig tartanak, a kocka frissítése (Process) 1-20 percig tart. Ez körülbelülösszetett OLAP-kockákról, amelyek több tucat "csillag" típusú struktúrát egyesítenek, körülbelül tucatnyi közös "sugarukat" (referenciavágást), körülbelül száz indikátort. A külső ERP-rendszerek adatbázisainak mennyiségét dokumentumok szállításával becsülve évente több százezer dokumentumról és ennek megfelelően több millió terméksorról beszélünk. A felhasználót érdeklő feldolgozás történelmi mélysége három-öt év volt.

A leírt technológiát számos nagyvállalat alkalmazza: 2008 óta a Russian Fish Company (RRK) és az Russian Sea Company (RM), 2012 óta a Santa Bremor Company (SB). A vállalatok egy része túlnyomórészt kereskedelmi-beszerző cégek (RRK), mások termelő cégek (hal- és tengeri gyümölcsfeldolgozó üzemek a Moldovai Köztársaságban és a Biztonsági Tanács). Minden vállalat nagy holding, amely több vállalatot egyesít független és különféle számítógépes könyvelési rendszerekkel – a szabványos ERP-rendszerektől, mint például az 1C7 és 1C8, a DBF és Excel alapú „relic” számviteli rendszerekig. Hozzáteszem, hogy az OLAP kockák üzemeltetésének leírt technológiája (a fejlesztési szakasz figyelembevétele nélkül) vagy egyáltalán nem igényel speciális alkalmazottakat, vagy egy teljes munkaidős üzleti elemző feladatai közé tartozik. Évek óta pörög a feladat automatikus üzemmód, amely a vállalati alkalmazottak különböző kategóriáinak napi rendszerességgel látja el naprakész jelentését.

A megoldás előnyei és hátrányai

A tapasztalatok szerint a javasolt megoldás változata meglehetősen megbízható és könnyen kezelhető. Könnyen módosítható (új ERP-k csatlakoztatása/leválasztása, új indikátorok és szekciók létrehozása, Excel riportok és azok levelezési listáinak létrehozása, módosítása) a facubi vezérlő program változatlanságával.

Az MS Excel, mint interfész az OLAP-pal megfelelő kifejezőképességet biztosít, és lehetővé teszi, hogy gyorsan csatlakozzon az OLAP technológiához különböző kategóriákban irodai dolgozók. A felhasználó napi "standard" OLAP jelentéseket kap; az MS Excel interfész OLAP használatával, önállóan tud OLAP jelentéseket készíteni MS Excelben. Ezenkívül a felhasználó önállóan folytathatja az OLAP-jelentések információinak feltárását az MS Excel szokásos lehetőségeivel.

Egy „finomított” raktári adatbázis, amelyben több heterogén ERP rendszer konszolidálódik (a kockaépítés során), akár OLAP nélkül is, lehetővé teszi (SSAS szerveren, Transact SQL lekérdezési metódussal vagy SP metódussal stb.) egy sok alkalmazott menedzsment feladat. Emlékezzünk vissza, hogy a raktári adatbázis-struktúra egységes és sokkal egyszerűbb (a táblák számát és a táblamezők számát tekintve), mint az eredeti ERP adatbázis-struktúrái.

Külön megjegyezzük, hogy a javasolt megoldásunkban lehetőség van különböző ERP-rendszerek egy OLAP-kockában történő összevonására. Ez lehetővé teszi, hogy elemzéseket kapjon a teljes holdingra vonatkozóan, és fenntartsa az elemzések hosszú távú folytonosságát, amikor egy vállalat egy másik ERP-számviteli rendszerre költözik, például amikor 1C7-ről 1C8-ra lép át.

A MOLAP kocka modellt használtuk. Ennek a modellnek az előnyei a működési megbízhatóság és a felhasználói kérések gyors feldolgozása. Hátrányok - aszinkron OLAP és OLTP, valamint nagy mennyiségű memória az OLAP tárolására.

Végezetül mondjunk még egy érvet az OLAP mellett, ami talán a középkorban megfelelőbb lett volna. Mert bizonyító ereje a tekintélyen nyugszik. A szerény, egyértelműen alábecsült brit matematikus, E. Codd a 60-as évek végén dolgozta ki a relációs adatbázisok elméletét. Ennek az elméletnek az volt az erőssége, hogy most, 50 év után már nehéz nem relációs adatbázist és az SQL-től eltérő adatbázis-lekérdező nyelvet találni.

A relációs adatbázisok elméletén alapuló OLTP technológia volt E. Codd első ötlete. Valójában az OLAP-kockák koncepciója a második ötlete, amelyet a 90-es évek elején fogalmazott meg. Még ha nem is vagy matematikus, akkor is számíthatsz arra, hogy a második ötlet ugyanolyan hatékony lesz, mint az első. Vagyis a számítógépes elemzés szempontjából az OLAP-ötletek hamarosan elfoglalják a világot, és kiszorítják az összes többit. Egyszerűen azért, mert az analitika témaköre az OLAP-ban találja meg kimerítő matematikai megoldását, és ez a megoldás „megfelelő” (B. Spinoza kifejezése) az analitika gyakorlati feladatának. A „megfelelően” azt jelenti Spinozában, hogy még maga Isten sem tudott volna jobb ötletet kitalálni...

1. Larson B. Üzleti intelligencia fejlesztése Microsoft SQL Server 2005-ben. - Szentpétervár: "Piter", 2008.
2. Codd E. Az adatbázis-alnyelvek relációs teljessége, Data Base Systems, Courant Computer Science Sumposia Series 1972, v. 6, Englwood cliffs, N.Y., Prentice–Hall.

Kapcsolatban áll