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.

Az OLAP nem egy külön szoftvertermék, nem programozási nyelv, de még csak nem is egy speciális technológia. Ha megpróbáljuk az OLAP-ot minden megnyilvánulásában lefedni, akkor ez egy olyan koncepció, alapelvek és követelmények összessége, amelyek a szoftvertermékek alapját képezik, 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 adatokhoz való hozzáférést.

Az a tény, hogy az elemzők a vállalati információk különleges fogyasztói. Az elemző feladata, hogy nagy mennyiségű adatban mintákat találjon. Ezért az elemző nem fog figyelni arra a külön tényre, hogy csütörtökön negyediken 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, aki a tranzakcióért felelős. Egy elemzőnek nem elég egy rekord - például szüksége lehet egy adott fiók vagy képviselet összes tranzakciójára egy hónapig vagy egy évig. Ugyanakkor elemző eldobja szükségtelen részletek, mint a vevő TIN-je, pontos címe és telefonszáma, szerződési index és hasonlók. Ugyanakkor az elemző által a 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 az elemzőnek sok adatra van szüksége, ezek az adatok szelektívek, és egyben a " 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" - ezáltal a 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 erős kapcsolatok azonosítása. A táblázatot nézve észreveheti, hogy könnyen háromdimenzióssá alakítható: 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 háromdimenziós ábrázolása. A szürke szegmens azt mutatja, hogy nincsenek adatok Argentínáról 1988-ban

Pontosan ezt a háromdimenziós tömböt nevezik OLAP kifejezéssel kockának. Valójában a szigorú matematika szempontjából egy ilyen tömb nem mindig lesz kocka: egy valódi kockának minden dimenzióban ugyanannyi elemet kell tartalmaznia, de az OLAP kockáknak nincs ilyen korlátozása. E részletek ellenére azonban az „OLAP-kockák” kifejezés rövidsége és figuratív jellege miatt általánosan elfogadottá vált. Az OLAP kockának nem kell háromdimenziósnak lennie. A megoldandó problémától függően lehet két- és többdimenziós is. A különösen tapasztalt elemzőknek körülbelül 20 méretre lehet szükségük – a komoly OLAP-termékeket pedig pontosan 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éket tartalmazza.

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. Egyáltalán nem szükséges, hogy egy OLAP-alkalmazás szükségszerűen többdimenziós struktúrában tárolja az adatokat - a lényeg az, hogy ezek az adatok pontosan így nézzenek ki a felhasználó számára. Egyébként éppen a többdimenziós adatok kompakt tárolásának speciális módszerei az, hogy a kockákban történő „vákuum” (kitöltés nélküli elemek) nem vezet a memória elvesztéséhez.

Maga a kocka azonban nem alkalmas elemzésre. Ha egy háromdimenziós kockát még megfelelően el lehet képzelni vagy ábrázolni, akkor egy hat-tizenkilenc dimenziós kockával sokkal rosszabb a helyzet. Ezért használat előtt a közönségeseket egy többdimenziós kockából vonják ki 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. Hasonló módon a favágók megszámolják a kivágott fán az évgyűrűket.

Ennek megfelelően általában csak két méret marad „vágatlan” - a táblázatban szereplő méretek számának megfelelően. Előfordul, hogy csak egy méret marad "vágatlan" - ha a kocka többféle számértéket tartalmaz, akkor azokat a táblázat egyik dimenziója mentén lehet ábrázolni.

Ha még alaposabban megnézi az általunk elsőként ábrázolt táblázatot, észre fogja venni, hogy a benne szereplő adatok valószínűleg nem elsődlegesek, hanem ennek eredményeként nyert adatok. összegzés kisebb elemeken. 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 lakott területekből állnak. Végül magukban a városokban is azonosíthatók a kerületek és a konkrét kiskereskedelmi egységek. A termékek összevonhatók termékcsoportokba és így tovább. Az OLAP kifejezéssel az ilyen többszintű társításokat logikusan nevezik hierarchiák. Az OLAP eszközök lehetővé teszik, hogy bármikor a kívánt hierarchiaszintre 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 hierarchia alacsonyabb szintjeiről veszik, majd összegzik a magasabb szinteken lévő értékeket. 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ót kell szereznie, de a vállalatban nincsenek OLAP-eszközök. 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. Ebben az esetben nagyon sok probléma merül fel. 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ív hatással van a munka termelékenységére, növeli a rohamok, szívinfarktus és stroke arányá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érdeznek apróságokat - mindenre szükség van egyszerre. Ez azt jelenti (bár a technológia ugrásszerűen fejlődik), hogy az elemző által elért vállalati relációs DBMS szerver mélyen és hosszan tud gondolkodni, 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 metajelentések. A metariportok (azaz kockák) dimenziók mentén történő vágásával az elemző ténylegesen megkapja az őt érdeklő „hétköznapi” 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 ugyanazok a funkciók). 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ő számára is jelentősen megnő az adatokhoz való hozzáférés sebessége. Ezen túlmenően, amint már említettük, a teljesítmény a kocka felépítésének időpontjában a hierarchiák és egyéb összesített értékek részösszegeinek kiszámításával is javul. Vagyis ha kezdetben az adataink egy adott termék napi bevételéről tartalmaztak információt egyetlen üzletben, akkor a kocka alkotá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 fizetni kell a termelékenység ilyen módon történő növeléséért. 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 mérés? Adj rá példákat.

Tudnak intézkedéseket egy OLAP-kockában nem numerikus értékeket tartalmaznak.

Mi az adattárház?

A Raktárnak néha egy másik célja is van - az összes vállalati adat integrálása, az információk integritásának és relevanciájának megőrzése az összes információs rendszerben. Hogy. a repository nemcsak analitikai, hanem szinte minden információt felhalmoz, és azt könyvtárak formájában vissza tudja szolgáltatni más rendszereknek.

Egy tipikus adattárház jellemzően eltér egy tipikus relációs adatbázistól. Először is, a rendszeres adatbázisok célja, hogy segítsék a felhasználókat a napi munka elvégzésében, míg az adattárházakat a döntéshozatalhoz. Például az áruk értékesítése, a számlák kiállítása tranzakciófeldolgozásra kialakított adatbázis segítségével, az értékesítés dinamikájának több éves elemzése, amely lehetővé teszi a beszállítókkal való tervezést, adattárház segítségével történik.

Másodszor, míg a hagyományos adatbázisok folyamatosan változnak a felhasználók munkavégzése során, addig az adattárház viszonylag stabil: a benne lévő adatok rendszerint ütemezés szerint frissülnek (például heti, napi vagy óránkénti, az igényektől függően). Ideális esetben a dúsítási folyamat egyszerűen új adatok hozzáadása egy bizonyos időszakon keresztül anélkül, hogy az áruházban már meglévő információkat módosítaná.

Harmadszor pedig a rendszeres adatbázisok a leggyakrabban a raktárba kerülő adatok forrásai. Ezenkívül a tárat külső forrásokból, például statisztikai jelentésekből lehet feltölteni.

Hogyan épül fel egy raktár?

• Extraction – adatok kinyerése külső forrásból érthető formátumban;
• Transzformáció – a forrásadatok szerkezetének átalakítása olyan struktúrákká, amelyek alkalmasak egy analitikai rendszer felépítésére;

Térjünk vissza az elemzéshez.

Mi az elemzés és miért van rá szükség?

Itt érdemes rámutatni a különbségre a DSS-sel végzett munka és a szabályozott és nem szabályozott jelentések egyszerű halmaza között. Az elemzés a DSS-ben szinte mindig interaktív és iteratív. Azok. az elemző az adatokba mélyedve elemző lekérdezéseket készít, korrigál, jelentéseket kap, amelyek szerkezete előre ismeretlen lehet. Erre az alábbiakban részletesebben visszatérünk, amikor a lekérdezési nyelvet tárgyaljuk. MDX.

OLAP

A komplex többdimenziós adatelemzés technológiáját OLAP-nak (On-Line Analytical Processing) hívják. Az OLAP a hagyományos adattárház kulcseleme. Az OLAP fogalmát Edgar Codd, neves adatbázis-kutató és a relációs adatmodell szerzője írta le 1993-ban. 1995-ben a Codd által meghatározott követelmények alapján megfogalmazták az úgynevezett FASMI-tesztet (Fast Analysis of Shared Multidimensional Information), amely a következő követelményeket tartalmazza a többdimenziós elemzési alkalmazásokhoz:

• a felhasználó rendelkezésére bocsátani az elemzési eredményeket elfogadható időn belül (általában legfeljebb 5 s), még kevésbé részletes elemzés árán is;
• az adott alkalmazásra jellemző bármilyen logikai és statisztikai elemzés elvégzésének és a végfelhasználó számára elérhető formában történő mentésének képessége;
• 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;
• 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 egyik legfontosabb követelménye);
• minden szükséges információhoz való hozzáférés lehetősége, függetlenül azok mennyiségétől és tárolási helyétől.

Mielőtt a különféle OLAP-megvalósításokról beszélnénk, nézzük meg közelebbről, hogy logikai szempontból mik is azok a kockák.

Többdimenziós fogalmak

Kocka

• Rendelés dátuma
• Egy ország
• Város
• Ügyfél neve
• Szállítócég
• termék név
• Áruk mennyisége
• Rendelési ár

• Mennyi az adott ország vásárlói által leadott megrendelések összértéke?
• Mennyi a vevők által adott országban leadott és egy bizonyos cég által kiszállított megrendelések összértéke?
• Mennyi a vevők által adott évben adott országban leadott és egy adott cég által leszállított megrendelések összértéke?

A lekérdezés eredménye mindig egy számoszlop és az azt leíró attribútumok listája (például ország) lesz – ez egy egydimenziós adatkészlet vagy matematikai nyelven egy vektor.

Képzeljük el, hogy információt kell szereznünk az összes országból érkező rendelések összköltségéről és azok szállítási cégek közötti megoszlásáról - kapunk egy számtáblázatot (mátrixot), ahol az oszlopfejlécekben a szállító cégek, a sorban országok szerepelnek. fejléceket, és a cellákban a rendelések mennyisége lesz látható. Ez egy kétdimenziós adattömb. Ezt az adathalmazt pivot táblának ( Pivot tábla) vagy kereszttábla.

Ha ugyanazokat az adatokat szeretnénk megkapni, de évenként is, akkor újabb változás jelenik meg, pl. az adathalmaz háromdimenzióssá válik (feltételes 3. rendű tenzor vagy 3 dimenziós „kocka”).

Nyilvánvalóan a maximális dimenziószám az összes attribútum (Dátum, Ország, Vevő stb.) száma, amely leírja összesített adatainkat (rendelések mennyisége, termékek száma stb.).

Így jutunk el a multidimenzionalitás fogalmához és megtestesüléséhez - többdimenziós kocka. Egy ilyen táblázatot fogunk nevezni ténytáblázat" Méretek vagy kockatengelyek ( méretek) olyan attribútumok, amelyek koordinátáit ezen attribútumok egyedi értékei fejezik ki a ténytáblázatban. Azok. ha például 2003-tól 2010-ig a rendelésekre vonatkozó információkat tartották fenn a rendszerben, akkor az idei év tengelye 8 megfelelő pontból áll majd. Ha három országból érkezik megrendelés, akkor az országtengely 3 pontot tartalmaz stb. Függetlenül attól, hogy hány ország szerepel az Országkönyvtárban. A tengely pontjait „tagjainak” nevezzük ( tagok).

Ebben az esetben magukat az összesített adatokat nevezzük „intézkedéseknek” ( Intézkedés). A „méretekkel” való összetéveszthetőség elkerülése érdekében az utóbbiakat lehetőleg „tengelyeknek” nevezzük. A mértékkészlet egy másik "Mérések" tengelyt alkot ( Intézkedések). Annyi tagja (pontja) van, ahány mérőszám (összesített oszlop) van a ténytáblázatban.

A méretek vagy tengelyek tagjai egy vagy több hierarchiával kombinálhatók ( hierarchia). Egy példával magyarázzuk el, mi a hierarchia: a városok a rendekből körzetekké, a kerületek régiókká, egy ország régióivá, az országok kontinensekké vagy más entitásokká egyesíthetők. Azok. van egy hierarchikus struktúra - kontinens- ország-régió-kerület-város– 5 szint ( Szint). Egy régióra vonatkozóan a rendszer összesített adatokat tartalmaz a benne szereplő városokról. Egy olyan régióhoz, amely az összes várost magában foglalja, stb. Miért van szükségünk több hierarchiára? Például a rendelés dátuma tengelyen szeretnénk pontokat (azaz napokat) hierarchiába csoportosítani. Év hónap nap vagy által Év-hét-nap: mindkét esetben három szint van. Nyilvánvaló, hogy a Hét és a Hónap eltérően csoportosítja a napokat. Vannak hierarchiák is, amelyekben a szintek száma nem determinisztikus, és az adatoktól függ. Például a számítógép lemezén lévő mappák.

Az adatok összesítése több szabványos függvény használatával történhet: összeg, minimum, maximum, átlag, szám.

MDX

Részletesen megvizsgáljuk, mert ez az egyetlen nyelv, amely az általános XMLA protokoll szabvány keretein belül kapott szabványos státuszt, másodszor pedig azért, mert a cég Mondrian projektje formájában nyílt forráskódú implementációja is van. Pentaho. Más OLAP-elemző rendszerek (például az Oracle OLAP Option) általában a saját SQL-szintaxis-kiterjesztéseiket használják, de deklarálják az MDX támogatását is.

Az analitikai adatkészletekkel való munka csak azok olvasását jelenti, nem pedig írást. Hogy. Az MDX-nek nincsenek adatmódosítási záradékai, de csak egy kiválasztási záradék – a select.

Az OLAP-ban többdimenziós kockákat készíthet szeleteket– azaz amikor az adatokat egy vagy több tengely mentén szűrjük, ill előrejelzések– amikor a kocka egy vagy több tengely mentén „összeesik”, adatok összesítése. Például az első példánk az országokból érkező rendelések mennyiségére a kocka kivetítése az Ország tengelyre. Az MDX-lekérdezés ebben az esetben így fog kinézni:

Válassza a ...Children on rows from
Mi van itt?

Válassza ki– kulcsszóés kizárólag a szépség miatt szerepel a szintaxisban.
a tengely neve. Az MDX-ben minden tulajdonnév szögletes zárójelben van.
a hierarchia neve. Esetünkben ez az Ország-Város hierarchia
– ez a hierarchia első szintjén lévő tengelytag neve (azaz ország) Mind – ez egy metatag, amely a tengely összes tagját egyesíti. Minden tengelyben van egy ilyen meta-kifejezés. Például az év tengelyen ott van a „Minden év” stb.
Gyermekek egy tagfüggvény. Minden tagnak több funkciója van. Ilyen például a Szülő. Szint, Hierarchia, rendre visszaadja az őst, a hierarchia szintjét és magát a hierarchiát, amelyhez ebben az esetben a tag tartozik. Gyermekek – Ennek a tagnak a gyermektagjait adja vissza. Azok. esetünkben – országok.
sorokon– Jelzi, hogyan kell elrendezni ezeket az adatokat a kapott táblázatban. Ebben az esetben - a sorok fejlécében. Lehetséges értékek itt: oszlopokon, oldalakon, bekezdéseken stb. Lehetőség van egyszerűen indexszel is jelezni, 0-tól kezdve.
tól től– ez azt a kockát jelzi, amelyből a kiválasztás történik.

Mi van akkor, ha nem minden országra van szükségünk, hanem csak néhány konkrét országra? Ehhez a kérelemben kifejezetten megadhatjuk azokat az országokat, amelyekre szükségünk van, ahelyett, hogy mindent a Gyermekek funkcióval választunk ki.

Válassza ki ( ..., ... ) a következő sorokon
A göndör kapcsos zárójel ebben az esetben a halmaz deklarációja ( Készlet). A halmaz egy lista, a tagok felsorolása egy tengelyről.

Most írjunk egy lekérdezést a második példánkhoz – a kimenet egy kézbesítő kontextusában:

Válassza a ...Children on rows .Members on columns from lehetőséget
Ide hozzáadva:
– tengely;
.Tagok– egy tengelyfüggvény, amely az összes kifejezést visszaadja. A hierarchia és a szint ugyanazt a funkciót tölti be. Mert Ezen a tengelyen csak egy hierarchia van, akkor ennek jelzése elhagyható, mert a szint és a hierarchia is megegyezik, akkor az összes tagot egy listában jelenítheti meg.

Azt hiszem, már most nyilvánvaló, hogyan folytathatjuk ezt a harmadik példánkkal évenkénti részletességgel. De inkább ne fúrjuk le évenként, hanem szűrjük - pl. szeletet építeni Ehhez a következő lekérdezést írjuk:

Válassza a ..Gyermekek a sorokon .A Tagok az oszlopokon lehetőséget, ahonnan (.)
Hol van itt a szűrés?

ahol- kulcsszó
a hierarchia egyik tagja . A teljes név az összes kifejezéssel együtt a következő lenne: .. , hanem azért, mert Mivel ennek a tagnak a neve egyedi a tengelyen belül, a név minden közbenső pontosítása elhagyható.

Miért van zárójelben a dátum kifejezés? A zárójel egy sor ( tuple). A sor egy vagy több koordináta különféle tengelyek Például, ha egyszerre két tengely mentén szeretne szűrni, zárójelben felsorolunk két kifejezést különböző a méréseket vesszővel elválasztva. Vagyis a sor meghatározza a kocka egy „szeletét” (vagy „szűrést”, ha az ilyen terminológia közelebb áll).

A sor nem csak szűrésre szolgál. A sorok sor/oszlop/oldal fejlécében stb. is lehetnek.

Erre például egy háromdimenziós lekérdezés eredményének kétdimenziós táblázatban való megjelenítéséhez van szükség.

Válassza ki a crossjoin(...Gyermekek, ..Gyermekek) elemet a sorokon .Members az oszlopokon, ahonnan (.)
Crossjoin egy függvény. Két halmaz derékszögű szorzatából származó sorokat ad vissza (igen, egy halmaz tartalmazhat sorokat is!). Azok. a kapott halmaz az országok és évek összes lehetséges kombinációját fogja tartalmazni. A sorfejlécek így egy értékpárt tartalmaznak: Ország-év.

A kérdés az, hogy hol van annak jelzése, hogy milyen számszerű jellemzőket kell megjeleníteni? Ebben az esetben az ehhez a kockához definiált alapértelmezett mértéket használjuk, azaz. Rendelési ár. Ha egy másik mértéket akarunk származtatni, akkor emlékezzünk arra, hogy a mértékek egy dimenzió tagjai Intézkedések. És pontosan ugyanúgy járunk el, mint a többi tengellyel. Azok. egy lekérdezés szűrése az egyik mérték szerint pontosan ezt a mértéket fogja megjeleníteni a cellákban.

Kérdés: Mi a különbség a hol szűrés és a tengelytagok soron belüli megadásával történő szűrés között? Válasz: gyakorlatilag semmi. Egyszerűen ott, ahol egy szelet van feltüntetve azoknak a tengelyeknek, amelyek nem vesznek részt a címsorok kialakításában. Azok. ugyanaz a tengely nem tud egyszerre legyen jelen sorokon, és be ahol.

Számított tagok

taggal. mint '.CurrentMember / ..', FORMAT_STRING='0,00%' válassza ki a ...Gyermekek a sorokon, ahonnan .
A számítás egy olyan cellában történik, amelyben minden koordináta attribútuma ismert. A megfelelő koordinátákat (tagokat) a CurrentMember függvénnyel kaphatjuk meg minden kockatengelyhez. Itt meg kell értenünk azt a kifejezést .Jelenlegi Tag/..’ nem oszt egy tagot a másikkal, hanem oszt releváns összesített adatok kocka szeleteket! Azok. a jelenlegi területre vonatkozó szelet az összes terület szeletére lesz osztva, azaz. az összes megrendelés összértéke. FORMAT_STRING – beállítja az értékek megjelenítési formátumát, pl. %.

Egy másik példa a számított tagra, de az évek tengelyén:

taggal. mint '. -.'
Nyilvánvalóan a jelentés nem egységet fog tartalmazni, hanem a megfelelő szakaszok különbségét, pl. a rendelések mennyiségének különbsége ebben a két évben.

Megjelenítés ROLAP-ban

Navigáció

Fúró– ez a jelentés részletezése az adataggregáció mértékének csökkentésével, más tengely (vagy több tengely) mentén történő szűréssel kombinálva. Többféle fúrás létezik:

• lefúrás– szűrés a jelentés egyik forrástengelye mentén, a kiválasztott szűrési tag hierarchiáján belüli leszármazottak részletes információinak megjelenítésével. Például, ha van jelentés a rendelések eloszlásáról országokra és évekre lebontva, akkor a 2007-es évre kattintva megjelenik egy jelentés 2007 azonos országaira és hónapjaira lebontva.
• fúróoldali– egy vagy több kiválasztott tengely alatti szűrés és egy vagy több másik tengely mentén történő összesítés eltávolítása. Például, ha van jelentés a rendelések eloszlásáról országokra és évekre lebontva, akkor a 2007-es évre kattintva egy másik jelentés jelenik meg, például országokra és beszállítókra lebontva, 2007-ig szűrve.
• fúróvályú– az összes tengely mentén történő összesítés eltávolítása és egyidejű szűrés ezek mentén – lehetővé teszi a forrásadatok megtekintését abból a ténytáblából, amelyből a jelentésben szereplő érték származott. Azok. Ha rákattint egy cella értékére, megjelenik egy jelentés az összes olyan rendelésről, amely ezt az összeget adta. Egyfajta azonnali fúrás a kocka „mélységébe”.

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

Főoldal Feltételek Cikkek Tanfolyamok Vállalati tapasztalatok Blog Tippek Letöltések Partnerek Kapcsolatok Promóciók

Cikkek > Költségvetés automatizálása és vezetői számvitel >

Alexander Karpov, a bud-tech.ru projektmenedzser, a „100% gyakorlati költségvetés-tervezés” című könyvsorozat és a „A vezetői számvitel szervezése és automatizálása” című könyv szerzője

www.bud-tech.ru

Talán egyesek számára kissé egzotikusnak tűnik az OLAP technológia (On-line Analytic Processing) használata riportok készítésekor, így számukra az OLAP-CUBE használata egyáltalán nem tartozik a legfontosabb követelmények közé a költségvetés és a vezetői számvitel automatizálása során.

Valójában nagyon kényelmes többdimenziós CUBE használata a vezetői jelentéskészítés során. A költségvetési formátumok fejlesztése során találkozhat a többváltozós űrlapok problémájával (erről bővebben a 8. „Költségvetés beállításának technológiája egy vállalatnál” című könyvben és a „Vállalati számvitel beállítása és automatizálása” című könyvben olvashat).

Ez annak köszönhető, hogy egy vállalat hatékony irányítása egyre részletesebb vezetői beszámolót igényel. Vagyis a rendszer egyre több különböző elemzési részt használ (az információs rendszerekben az elemzést referenciakönyvek halmaza határozza meg).

Ez természetesen oda vezet, hogy a vezetők minden őket érdeklő analitikai szekcióban jelentést szeretnének kapni. Ez azt jelenti, hogy a jelentéseket valahogy „lélegezni” kell. Más szóval azt mondhatjuk, hogy ebben az esetben arról beszélünk, hogy ugyanaz a jelentés különböző elemzési szempontokból adjon információt. Ezért a statikus jelentések sok modern vezetőnek már nem felelnek meg. Szükségük van arra a dinamikára, amit egy többdimenziós CUBE tud nyújtani.

Így az OLAP technológia már a modern és jövőbeli információs rendszerek kötelező elemévé vált. Ezért a szoftvertermék kiválasztásakor figyelni kell arra, hogy az OLAP technológiát használ-e.

Sőt, meg kell tudni különböztetni a valódi KOCKÁKAT az utánzatoktól. Az egyik ilyen szimuláció a pivot táblák az MS Excelben. Igen, ez az eszköz úgy néz ki, mint egy CUBE, de valójában nem az, mivel ezek statikus, nem dinamikus táblázatok. Ezen túlmenően, sokkal rosszabb a lehetőségük arra, hogy hierarchikus könyvtárak elemeiből készítsenek jelentéseket.

A CUBE használatának relevanciájának megerősítésére az építés során vezetői jelentés Adhat egy egyszerű példát az értékesítési költségvetésre. A vizsgált példában a következő elemzési részek relevánsak a vállalat számára: termékek, fióktelepek és értékesítési csatornák. Ha ez a három elemzés fontos a vállalat számára, akkor az értékesítési költségvetés (vagy jelentés) több változatban is megjeleníthető.

Meg kell jegyezni, hogy ha három elemzési szakaszon alapuló költségvetési sorokat hoz létre (mint a vizsgált példában), ez lehetővé teszi meglehetősen összetett költségvetési modellek és részletes jelentések készítését a CUBE segítségével.

Például egy értékesítési költségvetés összeállítható egyetlen elemzés (könyvtár) használatával. A „Termékek” elemzése alapján felépített értékesítési költségvetés példája itt található 1.ábra.

Rizs. 1. Példa egy értékesítési költségvetésre, amely az INTEGRAL szoftvercsomag OLAP-CUBE-jában található „Termékek” elemzése alapján készült

Ugyanaz az értékesítési költségvetés két elemzés (könyvtár) segítségével összeállítható. A két „Termékek” és „Ágazatok” elemzése alapján felépített értékesítési költségvetés példája itt található. 2. ábra.

Rizs. 2. Példa egy értékesítési költségvetésre, amely az INTEGRAL szoftvercsomag OLAP-CUBE-jában található két „Termékek” és „Ágazatok” elemzése alapján készült

.

Ha részletesebb riportok készítésére van szükség, akkor ugyanaz az értékesítési költségvetés három elemzéssel (könyvtárral) összeállítható. Példa egy értékesítési költségvetésre, amely három elemzés alapján: „Termékek”, „Ágazatok” és „Értékesítési csatornák” található 3. ábra.

Rizs. 3. Példa egy értékesítési költségvetésre, amely az INTEGRAL szoftvercsomag OLAP-CUBE-jában található három elemzés „Termékek”, „Ágazatok” és „Értékesítési csatornák” alapján készült

Emlékeztetni kell arra, hogy a jelentések generálására használt CUBE lehetővé teszi az adatok különböző sorrendben történő megjelenítését. Tovább 3. ábra Az értékesítési költségvetés először termékenként, majd ágazatonként, majd értékesítési csatornánként „bővül”.

Ugyanazok az adatok eltérő sorrendben is bemutathatók. Tovább 4. ábra ugyanazt az értékesítési költségvetést először termékenként, majd értékesítési csatornánként, majd ágazatonként „bontják ki”.

Rizs. 4. Példa egy értékesítési költségvetésre, amely az INTEGRAL szoftvercsomag OLAP-CUBE-jában található három elemzési elem „Termékek”, „Elosztási csatornák” és „Árak” alapján épül fel.

Tovább 5. ábra ugyanazt az értékesítési költségvetést először kirendeltségenként, majd termékekenként, majd értékesítési csatornákonként „bontják ki”.

Rizs. 5. Példa egy értékesítési költségvetésre, amely az „INTEGRAL” OLAP-CUBE szoftvercsomagban található három elemzési elem „ágak”, „termékek” és „értékesítési csatornák” alapján épül fel.

Valójában ez nem minden lehetséges lehetőség az értékesítési költségvetés visszavonására.

Ezenkívül figyelni kell arra a tényre, hogy a KUB lehetővé teszi a könyvtárak hierarchikus felépítésével való munkát. A bemutatott példákban a hierarchikus címtárak a „Termékek” és az „Értékesítési csatornák”.

A felhasználó szemszögéből ő az ebben a példában több vezetői jelentést kap (lásd Rizs. 1-5), és a szoftvertermék beállításai szempontjából ez egy jelentés. Egyszerűen a CUBE használatával többféleképpen is megtekintheti.

Természetesen a gyakorlatban nagyon sok lehetőség van a különböző vezetői jelentések kiadására, ha cikkük egy vagy több elemzőn alapul. Maga az elemzési készlet pedig a felhasználók részletszükségleteitől függ. Igaz, nem szabad elfelejteni, hogy egyrészt minél nagyobb az elemző, annál részletesebb jelentéseket lehet készíteni. Másrészt ez azt jelenti, hogy a pénzügyi költségvetés-tervezési modell összetettebb lesz. Mindenesetre, ha van KUB, a cégnek lehetősége lesz megtekinteni a szükséges beszámolókat különböző változatokban, az érdeklődési körnek megfelelően.

Szükséges megemlíteni az OLAP-CUBE néhány további funkcióját.

Egy többdimenziós hierarchikus OLAP-CUBE-ban több dimenzió van: sortípus, dátum, sorok, 1. könyvtár, 2. könyvtár és 3. könyvtár (lásd. Rizs. 6). Természetesen a jelentés annyi könyvtárat tartalmazó gombot jelenít meg, amennyi a könyvtárak maximális számát tartalmazó költségvetési sorban található. Ha egyetlen költségvetési soron sincs egyetlen referenciakönyv sem, akkor a jelentésben nem lesz egyetlen hivatkozási könyv gomb sem.

Rizs. 6. Az INTEGRAL szoftvercsomag OLAP-CUBE mérései

Kezdetben az OLAP-CUBE minden dimenzió mentén épül fel. Alapértelmezés szerint a jelentés elkészítésekor a méretek pontosan azokon a területeken helyezkednek el, amelyeken látható 6. ábra. Ez azt jelenti, hogy egy dimenzió, például a „Dátum” a függőleges méretek (méretek az oszlop területén), a „Sorok”, „1. könyvtár”, „2. könyvtár” és „3. könyvtár” méretek területén található - a a vízszintes méretek területe (méretek a terület soraiban), a „Sor típusa” dimenzió pedig a „ki nem bontott” méretek területén (méretek az oldal területén). Ha egy dimenzió az utolsó területen található, akkor a jelentésben szereplő adatok nem „bővülnek” az adott dimenzióban.

Ezen méretek mindegyike elhelyezhető a három terület bármelyikében. A mérések átvitele után a jelentés azonnal újjáépül, hogy megfeleljen az új mérési konfigurációnak. Például felcserélheti a dátumot és a sorokat referenciakönyvekkel. Vagy áthelyezheti az egyik referenciakönyvet a függőleges mérési területre (lásd. Rizs. 7). Más szóval, „csavarhatja” a jelentést az OLAP-CUBE-ban, és kiválaszthatja a felhasználó számára legkényelmesebb jelentéskimeneti opciót.

Rizs. 7. Példa egy jelentés újraépítésére az INTEGRAL szoftvercsomag mérési konfigurációjának megváltoztatása után

A mérési konfiguráció megváltoztatható a fő CUBE űrlapon vagy a változástérkép-szerkesztőben (lásd. Rizs. 8). Ebben a szerkesztőben az egérrel is áthúzhatja a méréseket egyik területről a másikra. Ezenkívül egy területen a méréseket felcserélheti.

Ezenkívül ugyanabban a formában beállíthat néhány mérési paramétert. Minden dimenziónál testreszabhatja az összegek helyét, az elemek rendezési sorrendjét és az elemek nevét (lásd. Rizs. 8). Azt is megadhatja, hogy melyik elem neve jelenjen meg a jelentésben: rövidített (Name) vagy teljes (FullName).

Rizs. 8. Az INTEGRAL szoftvercsomag mérési térképszerkesztője

A mérési paramétereket közvetlenül mindegyikben szerkesztheti (lásd. Rizs. 9). Ehhez kattintson a mérés neve melletti gombon található ikonra.

Rizs. 9. Példa egy címtár szerkesztésére 1 Termékek és szolgáltatások az INTEGRAL szoftvercsomagban

Ezzel a szerkesztővel kiválaszthatja a jelentésben megjeleníteni kívánt elemeket. Alapértelmezés szerint minden elem megjelenik a jelentésben, de szükség esetén egyes elemek vagy mappák elhagyhatók. Ha például csak egy termékcsoportot kell megjelenítenie a jelentésben, akkor a mérésszerkesztőben törölnie kell az összes többi jelölését. Ezt követően a jelentés csak egy termékcsoportot fog tartalmazni (lásd. Rizs. 10).

Ebben a szerkesztőben az elemeket is rendezheti. Ezenkívül az elemek többféleképpen átrendezhetők. Egy ilyen átcsoportosítás után a jelentés azonnal újjáépül.

Rizs. 10. Példa a kimenetre az INTEGRAL szoftvercsomagban csak egy termékcsoport (mappa) jelentésében

A dimenziószerkesztőben gyorsan létrehozhat saját csoportokat, az ott található könyvtárakból elemeket húzhat át stb. Alapértelmezés szerint csak az Egyéb csoport jön létre automatikusan, de más csoportok is létrehozhatók. Így a dimenziószerkesztő segítségével beállíthatja, hogy a referenciakönyvek mely elemei és milyen sorrendben jelenjenek meg a jelentésben.

Meg kell jegyezni, hogy az összes ilyen átrendezést nem rögzítik. Vagyis a jelentés bezárása vagy újraszámítása után minden könyvtár megjelenik a jelentésben a beállított módszertannak megfelelően.

Valójában az összes ilyen változtatást kezdetben a vonalak felállításakor meg lehetett volna tenni.

A korlátozások segítségével például azt is megadhatja, hogy mely elemek vagy könyvtárcsoportok jelenjenek meg a jelentésben, és melyek ne.

jegyzet: ennek a cikknek a témáját részletesebben tárgyaljuk a workshopokon "Vállalkozás költségvetésének kezelése"És „A vezetői számvitel szervezése és automatizálása” a cikk szerzője, Alexander Karpov vezette.

Ha a felhasználónak szinte rendszeresen csak bizonyos elemeket vagy könyvtármappákat kell megjelenítenie a jelentésben, akkor érdemes ezeket a beállításokat előre elvégezni a jelentéssorok létrehozásakor. Ha a felhasználó számára fontosak a jelentésekben a címtárelemek különféle kombinációi, akkor a módszertan beállításakor nem kell semmilyen korlátozást beállítani. Az összes ilyen korlátozás gyorsan konfigurálható a mérésszerkesztővel.

Általános információ

Microsoft Excel lehetővé teszi, hogy az online analitikai feldolgozás (OLAP) forrásadatai alapján PivotTable-jelentéseket hozzon létre. Amikor olyan kimutatásokkal dolgozik, amelyek OLAP-forrásadatokon és nem OLAP-forrásadatokon alapulnak, eltéréseket észlelhet az eszköz működésében és teljesítményében. Ez a cikk az OLAP-forrásadatokon alapuló kimutatások és a nem OLAP-forrásadatokon alapuló kimutatások közötti főbb különbségeket tárgyalja.

Adatok fogadása és a különbségek frissítése

Az OLAP adatbázisok úgy vannak megszervezve, hogy megkönnyítsék a nagy mennyiségű adat lekérését és elemzését. Mielőtt az Excel összesített adatokat jelenítene meg egy kimutatástáblában, az OLAP-kiszolgáló számításokat végez az adatok összegzéséhez. Csak a szükséges összesítő adatok kerülnek vissza az Excelbe szükség szerint.

Külső, nem OLAP adatbázisok esetén minden egyedi rekord visszaküldésre kerül, és az Excel elvégzi az összegzést. Következésképpen az OLAP adatbázisok lehetővé teszik az Excel számára, hogy lényegesen nagyobb mennyiségű külső adatot elemezzen.

Az OLAP-kiszolgáló új adatokat küld az Excelbe, amikor megváltozik egy kimutatás vagy kimutatás elrendezése vagy nézete. Ha nem OLAP-forrásadatokat használ, az adatok másként frissülnek, és különböző frissítési lehetőségek állnak rendelkezésre a Kimutatás beállításai párbeszédpanelen.

A nem OLAP adatok külső adattartományként, kimutatásként vagy kimutatásdiagramként visszaküldhetők a Microsoft Excelbe. Az OLAP-adatok csak kimutatás-jelentésként vagy kimutatásdiagramként küldhetők vissza az Excelbe.

Háttér kérés

A Kimutatás beállításai párbeszédpanelen nem engedélyezhető a háttérlekérdezés, ha a kimutatás OLAP adatforráson alapul.

Lekérdezések paraméterekkel

Az OLAP-adatforráson alapuló kimutatás-jelentések nem támogatják a paraméterlekérdezések használatát.

Memória optimalizálás

A Memória optimalizálása jelölőnégyzet a Kimutatás beállításai párbeszédpanelen nem érhető el, ha a kimutatás OLAP adatforráson alapul.

Oldalmező beállításai

A nem OLAP-forrásadatokon alapuló kimutatásjelentésekben oldalmezőparaméterekkel kérheti le az egyes elemek adatait külön-külön vagy az összes elemre vonatkozóan egyszerre. Ezek az oldalmező-beállítások nem érhetők el az OLAP-forrásadatokon alapuló jelentésekben. A forrás OLAP adatok mindig szükség szerint lekérhetők minden egyes elemhez, így a jelentések megjeleníthetik a nagy OLAP adatbázisokból származó információkat.

Különbségek a számításban

Oldalmező beállításai

Az OLAP-forrásadatokon alapuló kimutatás-jelentés adatmezőinek összegzésére szolgáló függvény nem módosítható. Ez a korlátozás azért jelentkezik, mert a végösszegeket az OLAP-kiszolgáló számítja ki. Összefoglaló funkciók

Nem hozható létre számított mező vagy számított elem a kimutatásban OLAP adatforrás alapján.

Számított mezők és számított tételek

Amikor részösszegekkel dolgozik egy kimutatásban, amely OLAP-forrásadatokon alapul, a következő korlátozások érvényesek.

A kimutatásban szereplő részösszegek összesített függvénye nem módosítható.

OLAP-CUBE (dinamikus vezetői jelentéskészítés)

Nem jeleníthetők meg a belső vagy belső oszlopmezők részösszegei a kimutatásban.

Mivel a végösszegeket az OLAP-kiszolgáló számítja ki, a Kimutatás beállításai párbeszédpanel közbenső rejtett oldalelemei nem módosíthatók.

Részösszegek

A Kimutatás beállításai párbeszédpanel Összesen * beállítása csak az OLAP-forrásadatokon alapuló kimutatásjelentésekben használható. Ez az opció minden részösszeget és végösszeget csillaggal (*) jelöl, jelezve, hogy ezek az értékek rejtett és megjelenített elemeket is tartalmaznak.

Elrendezési és tervezési különbségek

Méretek és méretek

Ha OLAP-forrásadatokon alapuló kimutatásjelentéssel dolgozik, az elemző csak sor-, oszlop- vagy oldalmezőként használható. A mértékek csak adatmezőként használhatók. Amikor egy méretet egy mezőadat-területre, vagy egy méretet egy sorba, oszlopba vagy oldalmargó területre húz, a következő hibaüzenet jelenik meg:

Az áthelyezni kívánt mező nem helyezhető el a kimutatás ezen területére.

Ha az OLAP-forrásadatokon alapuló kimutatás-jelentés aktív, a Kimutatás eszköztár minden mezősor mellett egy ikont jelenít meg. Az ikon mutatja, hogy az Excel hova teszi lehetővé a mező elhelyezését a kimutatásban. Ha az ikon a bal felső sarokban van, akkor a mező egy olyan méret, amelyet a területek oldalon egy sorba, oszlopba vagy mezőbe húzhat. Ha az ikon a jobb alsó sarokban van, akkor a mező egy mérték, amelyet az adatmezők területére húzhat.

Méretek és méretek

A Microsoft Excel lehetővé teszi a kimutatásokhoz hozzáadott mezők átnevezését. Ha egy kimutatás OLAP-forrásadatokon alapul, a felhasználónév elveszik, amikor töröl egy mezőt a kimutatásból.

Elemek csoportosítása és csoportosítása

Az Excel 2000 programban nem csoportosíthat elemeket az OLAP-forrásadatokon alapuló kimutatásokban;

Mezők átnevezése

Az OLAP-forrásadatokon alapuló kimutatás-jelentések lehetővé teszik az OLAP-kiszolgálón elérhető legalacsonyabb szintű adatok megjelenítését.

Elemek csoportosítása és csoportosítása

Nem OLAP-forrásadatok esetén az új kimutatásban szereplő elemek először az elemnév szerint növekvő sorrendben jelennek meg.

Részletek

Az Oldalak megjelenítése parancs nem érhető el az OLAP-forrásadatokon alapuló kimutatásjelentésekben.

Adat nélküli elemek megjelenítése

A Kimutatásmezők párbeszédpanel Elemek megjelenítése adat nélkül opciója nem érhető el az OLAP-forrásadatokon alapuló kimutatásjelentésekben.

Az alábbiakban felsoroljuk az Információtechnológia az MFPU/MFPA „Szinergizmus” kezelésében témával kapcsolatos kérdéseket.

... egy interaktív automatizált rendszer, amely segít a ...

Az OLAP a szó szűk értelmében úgy értelmezhető...

Az OLAP rendszerek (online analitikai feldolgozás)...

Kiderült, hogy az OLTP-rendszerek nem használnak semmit, mert...

Automatizált vezérlőrendszer (automatikus információ…

Az MS Projectben...

Egy OLTP rendszerben adatfrissítések történnek...

Egy munkaterv elemzésére szolgáló diagram módszerekkel...

Az információs rendszer egymással összefüggő elemek összessége...

Az információs technológia...

Az információs támogatás...

Az információs technológiák a következő módokon befolyásolják a társadalom fejlődését...

Információcsere a szervezet vezető testületeinek felépítésében…

Vezetői információs rendszerek…

A „kis” információs rendszerek jellemzői közé tartozik...

A „közepes” méretű információs rendszerek jellemzői közé tartozik...

Az információfeldolgozási módszerek a...

A számviteli információs rendszerek felépítésének moduláris elve...

Az ábrán egy... típusú diagram töredéke látható, amely pro...

Az MS Project hálózati diagramján egy külső projektből származó feladat...

Az MS Project hálózati diagramján egy olyan feladat, amely nem kapcsolódik a...

Az MS Project programban lévő hálózati diagramon a hozzárendelt feladat...

Az MS Project hálózati diagramján összefoglaló feladat, kombinálva

A benne foglalt automatizált munkaállomások összetételéről és számáról...

Az információs tevékenységek, információs folyamatok és...

Információs rendszer szervezése, amelyben távoli szerveren...

Az OLAP rendszer fő célja...

Az ERP rendszerek fő célja az automatizálás...

Az MPS módszertan fő célja a...

Az OLAP rendszerek főbb jellemzői...

A műszaki támogatási alrendszer magában foglalja...

A technológiai lépések sorrendje az elsődleges...

Amikor személyi számítógépeket hálózatba kötünk intrapro...

Alkalmazott szoftver A számítógép arra szolgál, hogy...

A tantárgyinformatika példája a technológia...

A döntéstámogató folyamat magában foglalja...

A vállalati szintű hálózat vagy vállalati hálózat egy információ…

A mesterséges intelligencia rendszer…

A tranzakciófeldolgozó rendszerek olyan rendszerek, amelyek célja...

A tranzakciófeldolgozó rendszerek megfelelnek a...

Döntéstámogató rendszerek – DS…

Modern módszerek és eszközök a folyamatok elemzéséhez és tervezéséhez…

Integrált automatizált információs rendszerek létrehozása…

A létrehozott információs rendszerek használatra alkalmatlanná válnak...

A vezetéstámogató információs rendszer sajátossága megnyilvánul...

A hagyományos OLTP rendszerekkel...

A vállalati információs rendszerek felépítése...

A HR vezetők munkájának felgyorsítása és egyszerűsítése a cégnél...

A HR vezetők munkájának felgyorsítása és egyszerűsítése a cégnél...

A környező világ feljegyzett észlelt tényei reprezentálják...

Cselekvések láncolata, amely a legpontosabban tükrözi az irányítási folyamatot...

A párbeszéddel megoldott gazdasági problémák jellemzik...

A szakértői rendszereket úgy tervezték, hogy feldolgozzák...

A biztonság megsértése vagy a biztonsághoz kapcsolódik...

Az OLAP egyszerűvé tette

Csodálatos a közelben...

Munkám során gyakran kellett komplex riportokat készíteni, mindig igyekeztem valami közöset találni bennük, hogy egyszerűbben, univerzálisabban állíthassam össze őket, sőt írtam és publikáltam is a témában „Oszipov fája. ” A cikkemet azonban kritizálták, és azt mondták, hogy az általam felvetett problémákat már régóta megoldották az OLAP-ban (www.molap.rgtu.ru), és azt javasolták, hogy nézzenek meg pivot táblákat az EXCEL-ben.
Annyira egyszerűnek bizonyult, hogy zseniális kis kezeimet alkalmazva egy nagyon egyszerű sémát találtam ki az 1C7-ből vagy bármely más adatbázisból (a továbbiakban 1C jelentése bármilyen adatbázis) és az OLAP-ban való elemzéshez.
Szerintem sok OLAP feltöltési séma túl bonyolult, én az egyszerűséget választom.

Jellemzők :

1. A munkához csak EXCEL 2000 szükséges.
2. A felhasználó saját maga is készíthet jelentéseket programozás nélkül.
3. Feltöltés 1C7-ről egyszerű szöveges fájlformátumban.
4. Mert számviteli bejegyzések A kirakodáshoz már létezik egy univerzális feldolgozás, amely bármilyen konfigurációban működik. A mintafeldolgozás elérhető más adatok letöltéséhez.
5. A jelentésűrlapokat előre megtervezheti, majd újratervezés nélkül alkalmazhatja különböző adatokra.
6. Egészen jó teljesítmény. Az első hosszú szakaszban először egy szöveges fájlból importálják az adatokat az EXCEL-be, és felépítenek egy OLAP-kockát, majd erre a kocka alapján gyorsan bármilyen jelentést lehet készíteni. Például egy 6000 termékből álló kínálattal rendelkező üzlet 3 hónapos termékértékesítési adatai 8 perc alatt betöltődnek az EXCEL-be a Cel600-128M-en, a termék és csoport szerinti értékelés (OLAP jelentés) 1 perc alatt újraszámításra kerül.
7. Az adatok teljes egészében letöltődnek az 1C7-ből a megadott időszakra (minden mozgás, minden raktáron, cégen, számlán). Az EXCEL-be történő importáláskor lehetőség van olyan szűrők használatára, amelyek csak az elemzéshez szükséges adatokat töltik be (például minden mozgásból, csak értékesítésből).
8. Jelenleg a mozgások vagy maradványok elemzésére dolgoztak ki módszereket, de a mozgásokat és a maradványokat együtt nem, bár ez elvileg lehetséges.

Mi az OLAP : (www.molap.rgtu.ru)

Tegyük fel, hogy van egy kiskereskedelmi lánca. Töltsük fel a kereskedési műveletekre vonatkozó adatokat egy szöveges fájlba vagy táblázatba, így:

Dátum – a működés dátuma
Hónap - a működés hónapja
Hét - működés hete
Típus - vétel, eladás, visszaküldés, leírás
Ügyfél - ügyletben részt vevő külső szervezet
Szerző – a számlát kiállító személy

Az 1C-ben például ennek a táblázatnak egy sora a számla egy sorának felel meg; egyes mezők (Counterparty, Date) a számla fejlécéből származnak.

Az elemzésre szánt adatok általában meghatározott ideig kerülnek feltöltésre egy OLAP rendszerbe, amelyből elvileg betöltési szűrők segítségével egy másik időszak is kiválasztható.

Ez a táblázat az OLAP elemzés forrása.

A felhasználó maga határozza meg, hogy a táblázat melyik mezője legyen Dimenzió, mely adatok és milyen szűrők legyenek alkalmazandók. A rendszer maga készít egy jelentést vizuális táblázatos formában. A dimenziók elhelyezhetők a jelentéstáblázat sor- vagy oszlopfejlécében.
Mint látható, egyetlen egyszerű táblázatból rengeteg adatot kaphat különböző jelentések formájában.

Hogyan használd magad :

Csomagolja ki az adatokat a disztribúcióból pontosan a c:\fixin könyvtárba (kereskedési rendszernél ez a c:\reports-ban lehetséges). Olvassa el a readme.txt fájlt, és kövesse a benne található utasításokat.

Először meg kell írnia egy feldolgozást, amely feltölti az adatokat az 1C-ből egy szöveges fájlba (táblázatba). Meg kell határoznia a kiürítendő mezők összetételét.
Például egy kész univerzális feldolgozás, amely bármilyen konfigurációban működik, és egy bizonyos időszakra letölti a tranzakciókat az OLAP elemzéshez, a következő mezőket tölti le elemzésre:

Dátum|A hét napja|Hét|Év|Negyedév|Hónap|Dokumentum|Vállalat|Tartás|DtNómenklatúra
|DtGroupNomenclature|DtSectionNómenklatúra|Hitel|Összeg|Értékösszeg|Mennyiség
|Pénznem|DtCounterparties|DtGroupCounterparties|KtCounterparties|KtGroupCounterparties|
CTMiscellaneousObjects

Ahol a Dt(Kt) előtagok alatt Terhelési (Jóváírás) alszámlák találhatók, a Csoport az alszámla csoportja (ha van), a Szekció a csoport csoportja, az Osztály a szekció csoportja.

Kereskedési rendszer esetén a mezők a következők lehetnek:

Irány|Mozgás típusa|Készpénzért|Termék|Mennyiség|Ár|Összeg|Dátum|Vállalat
|Raktár|Pénznem|Dokumentum|A hét napja|Hét|Év|Negyedév|Hónap|Szerző
|Termékkategória|Mozgás kategória|Kereskedő fél kategória|Termékcsoport
|ValAmount|Cost|Counterparty

Az adatok elemzéséhez a "Movement Analysis.xls" ("Accounting Analysis.xls") táblákat használjuk. Megnyitásukkor ne tiltsa le a makrókat, különben nem tudja frissíteni a riportokat (VBA makrók futtatják őket). Ezek a fájlok forrásadataikat a C:\fixin\motions.txt (C:\fixin\buh.txt) fájlból veszik, különben ugyanazok.

OLAP alapok

Ezért előfordulhat, hogy át kell másolnia adatait ezen fájlok egyikébe.
Az adatok EXCEL-be való betöltéséhez válassza ki vagy írja be a szűrőt, és kattintson a „Létrehozás” gombra a „Feltételek” lapon.
A jelentéslapok a „Jelentés” előtaggal kezdődnek. Lépjen a jelentéslapra, kattintson a "Frissítés" gombra, és a jelentés adatai az utoljára betöltött adatok szerint változnak.
Ha nem elégedett a standard jelentésekkel, van egy ReportTemplate lap. Másolja át egy új lapra, és szabja testre a jelentéstípust egy pivot táblával ezen a lapon (a pivot táblákkal való munkavégzésről további információkért tekintse meg bármelyik EXEL 2000 könyvet). Azt javaslom, hogy készítsen jelentéseket egy kis adathalmazról, majd futtassa azokat egy nagy tömbön, mert... Nem lehet letiltani a táblázatok újrarajzolását minden alkalommal, amikor a jelentés elrendezése megváltozik.

Műszaki megjegyzések :

Amikor adatokat tölt fel az 1C-ből, a felhasználó kiválasztja a mappát, ahová a fájlt feltölti. Ezt azért tettem, mert a közeljövőben valószínűleg több fájl (maradványok és mozgások) is felkerül. Ezután az Intézőben a „Küldés” -> „OLAP elemzéshez EXCEL 2000-ben” gombra kattintva az adatok a kiválasztott mappából a C:\fixin mappába másolódnak. (Ahhoz, hogy ez a parancs megjelenjen a „Küldés” parancs listájában, be kell másolnia az „OLAP elemzéshez EXCEL 2000.bat-ban” fájlt a C:\Windows\SendTo könyvtárba) Ezért elnevezéssel azonnal töltse fel az adatokat. a motions.txt vagy buh.txt fájlokat.

Szöveges fájl formátum:
A szövegfájl első sora az oszlopfejlécek „|”-vel elválasztva, a többi sor ezen oszlopok értékeit tartalmazza „|”-vel elválasztva.

Szöveges fájlok Excelbe importálásához a Microsoft Query (az EXCEL egyik összetevője) szolgál; ennek működéséhez rendelkeznie kell egy shema.ini fájllal, amely a következő információkat tartalmazza az importálási könyvtárban (C:\fixin):

ColNameHeader=Igaz
Formátum=Határozott(|)
MaxScanRows=3
CharacterSet=ANSI
ColNameHeader=Igaz
Formátum=Határozott(|)
MaxScanRows=3
CharacterSet=ANSI

Magyarázat: motions.txt és buh.txt a szakasz neve, megfelel az importált fájl nevének, leírja, hogyan importálhat szöveges fájlt az Excelbe. A többi paraméter azt jelenti, hogy az első sor az oszlopok nevét tartalmazza, az oszlopelválasztó a "|", a karakterkészlet Windows ANSI (DOS-hoz - OEM).
A mező típusát az oszlopban található adatok (dátum, szám, karakterlánc) alapján a rendszer automatikusan határozza meg.
A mezők listáját nem kell sehol leírni - az EXCEL és az OLAP maga határozza meg, hogy az első sorban lévő fejlécek mely mezőket tartalmazzák a fájlban.

Figyelem, ellenőrizze a regionális beállításokat "Vezérlőpult" -> "Regionális beállítások". Az én feldolgozásom során a számok vesszőhatárolóval vannak feltöltve, a dátumok pedig "DD.MM.YYYY" formátumban vannak.

Amikor a "Létrehozás" gombra kattint, az adatok betöltődnek a "Bázis" lapon lévő pivot táblába, és a "Jelentés" lapokon lévő összes jelentés ebből a kimutatástáblából veszi az adatokat.

Megértem, hogy az MS SQL Server és a nagy teljesítményű adatbázisok rajongói morogni kezdenek, hogy minden túlságosan le van egyszerűsítve, hogy a feldolgozásomat kimeríti egy éves minta, de mindenekelőtt az OLAP elemzés előnyeit szeretném átadni a közepesnek. méretű szervezetek. Ezt a terméket a nagykereskedelmi vállalatok éves elemző eszközeként, a kiskereskedők negyedéves elemzéseként és bármely szervezet működési elemzéseként pozicionálnám.

A VBA-val kellett bütykölni, hogy egy tetszőleges mezőlistás fájlból lehessen venni az adatokat, és előre elkészíthessem a jelentési űrlapokat.

Az EXCEL-ben végzett munka leírása (felhasználóknak):

Útmutató a jelentések használatához:
1. Küldje el a letöltött adatokat elemzésre (egyeztesse meg a rendszergazdával). Ehhez kattintson a jobb gombbal arra a mappára, amelybe az 1C-ből adatokat töltött le, és válassza ki a „Küldés” parancsot, majd az „OLAP elemzéshez EXCEL 2000-ben” parancsot.
2. Nyissa meg a "Motion Analysis.xls" fájlt.
3. Válassza a Filter Value (Szűrőérték) lehetőséget; a szükséges szűrőket az „Értékek” lapon adhatja hozzá.
4. Kattintson a "Létrehozás" gombra, és a letöltött adatok betöltődnek az EXCEL-be.
5. Az adatok EXCEL-be való betöltése után különböző riportokat tekinthet meg. Ehhez egyszerűen kattintson a „Frissítés” gombra a kiválasztott jelentésben. A jelentéslapok a jelentéssel kezdődnek.
Figyelem! A szűrőérték módosítása után ismét a „Létrehozás” gombra kell kattintania, hogy az EXCEL-ben lévő adatok a szűrőknek megfelelően újratöltődjenek a feltöltési fájlból.

Feldolgozás a demo példából:

motionsbuh2011.ert feldolgozása – legújabb verzió tranzakciók feltöltése a Accounting 7.7-ből Excelben történő elemzéshez. Van egy „Fájlhoz csatolás” jelölőnégyzet, amely lehetővé teszi, hogy az adatokat időszakonként részenként töltse fel, ugyanahhoz a fájlhoz fűzve, ahelyett, hogy újra feltöltené ugyanabba a fájlba:

A motionswork.ert feldolgozása feltölti az értékesítési adatokat Excelben történő elemzés céljából.

Példák jelentésekre :

Bekötési sakk:

Üzemeltetői munkaterhelés számlatípusok szerint:

P.S. :

Nyilvánvaló, hogy egy hasonló séma használható az 1C8-ból származó adatok letöltésének megszervezésére.
2011-ben megkeresett egy felhasználó, akinek javítania kellett ezen a feldolgozáson az 1C7-ben, hogy nagy mennyiségű adatot tölthessen fel, találtam egy megbízót, és elvégeztem a munkát. Tehát a fejlesztés nagyon releváns.

A motionsbuh2011.ert feldolgozását továbbfejlesztették, hogy megbirkózzanak a nagy mennyiségű adat kiürítésével.

Az első egyértelmű meghatározás OLAP(On-line Analytical Processing) 1993-ban javasolta E.F. Codd az Arbor Software (ma Hyperion Software) támogatásával megjelent cikkében. A cikk 12 olyan szabályt tartalmazott, amelyek mára széles körben ismertté váltak, és bármelyik OLAP-alkalmazás-szolgáltató weboldalán le vannak írva. Később, 1995-ben további hat kevésbé ismert szabályt egészítettek ki, mindegyiket négy csoportra osztották, és "jellemzőknek" nevezték el. Íme az OLAP-alkalmazásokat meghatározó szabályok Nigel Pendse, az OLAP Report webhely egyik készítőjének megjegyzéseivel.

Az OLAP főbb jellemzői a következők:

1. Az adatmodell többdimenzióssága. Ezzel az állítással kevesen vitatkoznak, és ezt tartják az OLAP fő jellemzőjének. Ennek a követelménynek a része a modell különböző vetületeinek és metszete elkészítésének képessége.

2. Intuitív adatkezelési mechanizmusok. Codd úgy véli, hogy az adatok manipulálását közvetlenül a táblázatcellában kell végrehajtani, menük vagy összetett menük használata nélkül. Feltételezhetjük, hogy ez egérműveletek használatát jelenti, de Codd ezt nem állítja. Sok termék nem tartja be ezt a szabályt. A mi szempontunkból ez a jellemző kevés hatással van az adatelemzési folyamat minőségére. Úgy gondoljuk, hogy a programnak lehetőséget kell kínálnia a munkamodell kiválasztására, mert... nem minden felhasználó szereti ugyanazokat a dolgokat.

3. Elérhetőség. Az OLAP a közvetítő. Codd kifejezetten hangsúlyozza, hogy az OLAP-motor egy köztes program a heterogén adatforrások és a felhasználói felület között. A legtöbb termék biztosítja ezeket a funkciókat, de az adatokhoz való hozzáférés egyszerűsége gyakran kisebb, mint amit más szoftverszolgáltatók szeretnének.

4. Kötegelt adatkinyerés. Ez a szabály megköveteli, hogy a termékek kínáljanak saját adatbázisokat az elemzett adatok tárolására és dinamikus (élő) hozzáférést a külső adatokhoz. Ebben egyetértünk Codddal, és sajnáljuk, hogy kevés OLAP termék követi ezt. Még az ilyen funkciókat kínáló programok is ritkán teszik egyszerűvé és kellően automatizálttá. Ennek eredményeként a Codd támogatja a többdimenziós adatábrázolást, valamint a nagy, többdimenziós adatbázisok részleges előszámítását, átlátható, végpontok közötti hozzáféréssel a részletes információkhoz. Ma ez a hibrid OLAP definíciója, amely a legnépszerűbb architektúrává válik, így Codd nagyon pontosan látta a fő trendeket ezen a területen.

5. Kliens-szerver architektúra. Codd úgy véli, hogy nemcsak minden terméknek kliens-szerver terméknek kell lennie, hanem az OLAP-termékek minden szerverkomponensének kellően intelligensnek kell lennie ahhoz, hogy a különböző kliensek minimális erőfeszítéssel és programozással összekapcsolhatók legyenek. Ez sokkal összetettebb teszt, mint egy egyszerű kliens-szerver architektúra, és viszonylag kevés termék megy át rajta. Érvelhetnénk, hogy ez a teszt talán bonyolultabb a kelleténél, és nem szabad, hogy a rendszer architektúráját megszabja a fejlesztőknek.

6. Átláthatóság. Ez a teszt is nehéz, de szükséges. A teljes megfelelés azt jelenti, hogy mondjuk egy táblázat használója teljes hozzáférést kaphat az OLAP motor által biztosított szolgáltatásokhoz anélkül, hogy tudná, honnan származnak az adatok. Ennek eléréséhez a termékeknek dinamikus hozzáférést kell biztosítaniuk heterogén adatforrásokhoz és egy teljesen működőképes táblázatkezelő modult. A táblázat és az adattárház közé egy OLAP-kiszolgáló kerül elhelyezésre.

7. Többfelhasználós munka. A Codd meghatározza, hogy ahhoz, hogy stratégiai OLAP-eszköznek tekintsék, az alkalmazásoknak többet kell tenniük, mint csupán olvasniuk és értelmezniük az adatokat, és ennek megfelelően egyidejű hozzáférést kell biztosítaniuk (beleértve az adatok visszakeresését és frissítését is), integritást és biztonságot.

Különleges képességek

8. Normalizálatlan adatok kezelése. Ez azt jelenti, hogy lehetséges az integráció az OLAP-motor és a nem normalizált adatforrás között. Codd hangsúlyozza, hogy az OLAP-környezetben végzett adatok frissítése során lehetővé kell tenni a külső rendszerekben lévő nem normalizált adatok megváltoztatását.

9. Az OLAP eredményeket a forrásadatoktól elkülönítve tárolja. A valóságban ez inkább a termék megvalósításával, mint képességeivel kapcsolatos, de kevesen vitatkoznának ezzel az állítással. Cobb lényegében azt a széles körben elfogadott rendszert támogatja, amely szerint az OLAP-alkalmazásoknak közvetlenül a tranzakciós adatokra kell építeniük az elemzéseket, és az OLAP-adatok változásait elkülönítve kell tartani a tranzakciós adatoktól.

10. Hiányzó adatok kiemelése. Ez azt jelenti, hogy a hiányzó adatoknak különbözniük kell a null értéktől. Általános szabály, hogy minden modern OLAP rendszer támogatja ezt a funkciót.

11. Hiányzó értékek kezelése. Minden hiányzó értéket figyelmen kívül kell hagyni az elemzés során, függetlenül azok forrásától.

A jelentéskészítés jellemzői

12. Rugalmas jelentéskészítés. A különböző méreteket tetszőlegesen a felhasználó igényei szerint kell elrendezni. A legtöbb termék megfelel ennek a követelménynek a dedikált jelentésszerkesztőn keresztül. Bárcsak ugyanezek a funkciók elérhetők lennének az interaktív megtekintőkben is, de ez sokkal kevésbé gyakori. Ez az egyik oka annak, hogy előnyben részesítjük az elemzési és jelentéskészítési funkciók egy modulban történő kombinálását.

1. Az olapkocka fogalma

13. Egyenletes teljesítmény a jelentések elkészítésekor. Ez azt jelenti, hogy a rendszer teljesítménye a jelentések generálásakor nem csökkenhet jelentősen az adatbázis méretének vagy méretének növekedésével.

14. Automatikus fizikai rétegszabályozás. Az OLAP rendszernek automatikusan be kell állítania a fizikai struktúrát a modell típusához és szerkezetéhez.

Méretszabályozás

15. Általános funkcionalitás. Minden dimenziónak azonos képességekkel kell rendelkeznie a szerkezetben és a funkcionalitásban.

16. Korlátlan számú dimenzió és összesítési szint. Valójában korlátlan számon Codd 15-20-at jelent, azaz. olyan szám, amely nyilvánvalóan meghaladja az elemző maximális igényeit.

17. Korlátlan műveletek a különböző mérések adatai között. Codd úgy véli, hogy ahhoz, hogy egy alkalmazást többdimenziósnak lehessen nevezni, támogatnia kell minden számítást az összes dimenzióból származó adatok felhasználásával.

A Hyperion termékekkel kapcsolatos részletek a www.hyperion.ru weboldalon találhatók

nyomtatott változat

Vissza

10.8 Munkavégzés kimutatástáblákkal (PivotTable objektum)

Excel.PivotTable objektum, programozási munka kimutatástáblákkal és OLAP-kockákkal Excelben VBA-val, PivotCache objektum, pivot-tábla-elrendezés létrehozása

A legtöbb vállalkozás működése során a tevékenységekről ún. nyers adatok halmozódnak fel. Például egy kereskedelmi vállalkozás esetében az áruk értékesítésére vonatkozó adatok gyűjthetők - minden vásárláshoz külön; a mobil kommunikációs vállalkozások esetében - a bázisállomások terhelésének statisztikája stb. A vállalatvezetésnek nagyon gyakran van szüksége analitikus információkra, amelyeket nyers információk alapján állítanak elő – például annak kiszámításához, hogy az egyes termékek milyen mértékben járulnak hozzá a vállalkozás bevételéhez vagy a szolgáltatás minőségéhez egy adott területen. adott állomás. Nagyon nehéz ilyen információkat nyers információból kinyerni: nagyon összetett SQL-lekérdezéseket kell futtatni, amelyek végrehajtása hosszú időt vesz igénybe, és gyakran zavarja az aktuális munkát. Ezért a nyers adatokat egyre gyakrabban először egy archív adattárházba – a Data Warehouse-ba – konszolidálják, majd OLAP kockákba, amelyek nagyon kényelmesek az interaktív elemzéshez. Az OLAP kockákat legegyszerűbben többdimenziós tábláknak tekinthetjük, amelyekben a szokásos két dimenzió (oszlopok és sorok, mint a normál táblázatokban) helyett sok méret is előfordulhat. A "metszeti" kifejezést általában a kockában végzett mérések leírására használják. Például a marketing osztálynak szüksége lehet időre, régióra, terméktípusra, értékesítési csatornára stb. A kockák segítségével (szemben a szabványos SQL lekérdezésekkel) nagyon könnyű választ kapni olyan kérdésekre, mint „hány ilyen típusú terméket értékesítettek a tavalyi év negyedik negyedévében az északnyugati régióban regionális forgalmazókon keresztül.

Természetesen ilyen kockák nem hozhatók létre hagyományos adatbázisokban. Az OLAP kockákkal való munkavégzéshez speciális szoftvertermékekre van szükség. Az SQL Server a Microsoft Analysis Services nevű OLAP-adatbázisával érkezik. Vannak OLAP megoldások az Oracle, IBM, Sybase stb.

Az ilyen kockákkal való munkavégzéshez az Excel beépített klienssel rendelkezik.

Oroszul úgy hívják Pivot tábla(a grafikus képernyőn a menün keresztül érhető el Adat -> Pivot tábla), és angolul - Pivot tábla. Ennek megfelelően az ügyfél által képviselt objektumot PivotTable-nek nevezik. Megjegyzendő, hogy nem csak OLAP-kockákkal, hanem Excel-táblázatokban vagy adatbázisokban lévő hétköznapi adatokkal is működik, de sok képesség elveszik.

A PivotTable és a PivotTable a Panorama Software szoftvertermékei, amelyeket a Microsoft vásárolt meg és integrált az Excelbe.

Ezért a kimutatás-objektummal való munka némileg eltér a többi Excel-objektum használatától. Gyakran nehéz kitalálni, hogy mit kell tenni. Ezért ajánlatos aktívan használni a makrórögzítőt tippek fogadására. Ugyanakkor a pivot táblákkal való munka során a felhasználóknak gyakran ugyanazokat az ismétlődő műveleteket kell végrehajtaniuk, ezért sok helyzetben szükség van az automatizálásra.

Hogyan néz ki a pivot táblával végzett munka programozottan?

Az első dolog, amit tennünk kell, egy PivotCache objektum létrehozása, amely az OLAP-forrásból letöltött rekordok halmazát képviseli. Nagyon durván ez a PivotCache objektum egy QueryTable-hez hasonlítható. Kimutatás-objektumként csak egy kimutatás-gyorsítótár objektumot használhat. Egy PivotCache objektum a PivotCaches gyűjtemény Add() metódusával jön létre:

Dim PC1 PivotCache-ként

Set PC1 = ActiveWorkbook.PivotCaches.Add(xlExternal)

A PivotCaches szabványos gyűjtemény, a részletes átgondolást érdemlő metódusok közül csak az Add() metódus nevezhető meg benne. Ez a módszer két paramétert igényel:

• Forrás típus- kötelező, meghatározza a pivot tábla adatforrásának típusát. Megadhatja a kimutatás létrehozását egy Excel tartomány, adatbázisból, külső adatforrásból, másik kimutatásból stb. A gyakorlatban általában csak akkor van értelme az OLAP-nak, ha sok adat van - ennek megfelelően speciális külső tárolóra van szükség (például Microsoft Analysis Services). Ebben a helyzetben az xlKülső érték kerül kiválasztásra.
• SourceData- minden esetben kötelező, kivéve ha az első paraméter értéke xlExternal. Valójában ez határozza meg azt az adattartományt, amely alapján a kimutatás létrejön. Általában egy Range objektumot vesz fel.

A következő feladat a PivotCache objektum beállításainak konfigurálása. Mint már említettük, ez az objektum nagyon hasonlít a QueryTable-re, és tulajdonságai és metódusai nagyon hasonlóak. Néhány a legfontosabb tulajdonságok és módszerek közül:

• ADOConnection- egy ADO Connection objektum visszaküldésének képessége, amely automatikusan létrejön a külső adatforráshoz való csatlakozáshoz. A kapcsolat tulajdonságainak további konfigurálására szolgál.
• Kapcsolat- pontosan ugyanúgy működik, mint az azonos nevű QueryTable objektumtulajdonság. Képes elfogadni kapcsolati karakterláncot, kész Recordset objektumot, szöveges fájlt vagy webes kérést. Microsoft Query fájl. Az OLAP-pal végzett munka során leggyakrabban a kapcsolati karakterláncot közvetlenül írják (mivel például egy Recordset objektum beszerzése az adatok megváltoztatásához nincs sok értelme - az OLAP adatforrások szinte mindig csak olvashatók). Például ennek a tulajdonságnak a beállítása a Foodmart adatbázishoz (Analysis Services mintaadatbázishoz) a LONDON szerveren a következőképpen nézhet ki:

PC1.Connection = "OLEDB; Szolgáltató=MSOLAP.2; Adatforrás=LONDON1; Kezdeti katalógus = FoodMart 2000"

• tulajdonságait CommandTypeÉs CommandText leírják az adatbázis-kiszolgálónak küldött parancs típusát és magának a parancsnak a szövegét is. Például az értékesítési kockához való hozzáféréshez és annak teljes egészében a kliens gyorsítótárába kerüléséhez használhat olyan kódot, mint pl.

PC1.CommandType = xlCmdCube

PC1.CommandText = Tömb("Értékesítés")

• ingatlan Helyi kapcsolat lehetővé teszi az Excel segítségével létrehozott helyi kockához (*.cub fájlhoz) való csatlakozást. Természetesen nem ajánlott az ilyen fájlokat „előállítási” adatmennyiségekkel való munkavégzésre használni - csak elrendezések létrehozására stb.
• ingatlan Használt memória visszaadja a PivotCache által használt RAM mennyiségét. Ha az ezen a kimutatás-gyorsítótáron alapuló kimutatás még nincs létrehozva és megnyitva, akkor 0-t ad vissza. Használható annak ellenőrzésére, hogy az alkalmazás futni fog-e gyenge klienseken.
• ingatlan OLAP Igaz értéket ad vissza, ha a PivotCache csatlakozik az OLAP-kiszolgálóhoz.
• OptimizeCache- a gyorsítótár-struktúra optimalizálásának képessége. A kezdeti adatletöltés tovább tart, de ezután a sebesség megnőhet. Nem működik OLE DB forrásokhoz.

A PivotCache objektum többi tulajdonságai megegyeznek a QueryTable objektum tulajdonságaival, ezért itt nem tárgyaljuk őket.

A PivotCache objektum fő metódusa a CreatePivotTable() metódus. Ezzel a módszerrel a következő lépés kerül végrehajtásra - egy pivot tábla (PivotTable objektum) létrehozása. Ez a módszer négy paramétert vesz igénybe:

• TableDestination- az egyetlen szükséges paraméter.

  Elfogad egy Range objektumot, amelynek a bal felső sarkába kerül a pivot táblázat.

• Táblanév- a pivot tábla neve. Ha nincs megadva, a „PivotTable1” nézetnév automatikusan létrejön.
• ReadData- ha igazra van állítva, akkor a kocka teljes tartalma automatikusan a gyorsítótárba kerül. Nagyon óvatosnak kell lennie ezzel a paraméterrel, mivel a helytelen használata jelentősen megnövelheti a kliens terhelését.
• Alapértelmezett verzió- ez a tulajdonság általában nincs megadva. Lehetővé teszi a létrehozandó pivot tábla verziójának meghatározását. Alapértelmezés szerint a legfrissebb verzió használatos.

A pivot tábla létrehozása az első munkalap első cellájában így nézhet ki:

PC1.CreatePivotTable Range("A1")

Létrehoztunk egy pivot táblát, de közvetlenül a létrehozás után üres. Négy területet biztosít a forrásból származó mezők elhelyezésére (a grafikus képernyőn mindezt akár az ablak segítségével is beállíthatjuk A kimutatástáblázat mezőinek listája- automatikusan vagy gombbal nyílik Elrendezés a PivotTable varázsló utolsó képernyőjén):

• oszlopterület- tartalmazza azokat a dimenziókat („szakasz”, amelyben az adatokat elemzik), amelyek tagjai kisebbek;
• vonalterület- azok a méretek, amelyeknek több tagja van;
• oldal területe- azokat a méréseket, amelyeknél csak szűrni kell (például csak ilyen és olyan régióra vagy csak ilyen és ilyen évre vonatkozóan mutasson adatokat);
• adatterület- valójában a táblázat központi része. Azok a számszerű adatok (például az eladások mennyisége), amelyeket elemezünk.

Nehéz arra hagyatkozni, hogy a felhasználó helyesen helyezze el az elemeket mind a négy területen.

Ezenkívül ez eltarthat egy ideig. Ezért gyakran szükséges az adatokat programozottan elrendezni egy pivot táblában. Ezt a műveletet a CubeField objektum segítségével hajtják végre. Ennek az objektumnak a fő tulajdonsága az Orientation, ez határozza meg, hogy ez vagy az a mező hol lesz. Például helyezzük el az Ügyfelek dimenziót az oszlopok területére:

PT1.CubeFields(""). Orientation = xlColumnField

Ezután - az Idő mérése a vonal területére:

PT1.CubeFields("").Tájolás = xlRowField

Ezután - a Termék dimenziót az oldal területére:

PT1.CubeFields(""). Orientation = xlPageField

És végül a mutató (számadatok az elemzéshez) Egységértékesítés:

PT1.CubeFields(“.”).Tájolás = xlDataField

Most a pivot tábla létrejött, és már dolgozhat vele. Gyakran azonban szükség van még egy művelet végrehajtására - a dimenzióhierarchia kívánt szintjének kiterjesztésére. Például, ha érdekel minket a negyedéves elemzés, akkor ki kell bővítenünk az Idő dimenzió Negyed szintjét (alapértelmezés szerint csak a legfelső szint jelenik meg). Ezt persze a felhasználó saját maga is megteheti, de nem mindig lehet rá számítani, hogy kitalálja, hova kell kattintania. Például programozottan kiterjesztheti az Idő dimenzió hierarchiáját 1997-re a negyedév szintjére a PivotField és a PivotItem objektumok használatával:

PT1.PivotFields(“.”).PivotItems(“.”).DrilledDown = igaz

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

Kapcsolatban áll

osztálytársak

Konsztantyin Tokmacsev, rendszerépítész

Kubista stílusban.
OLAP kockák alkalmazása nagyvállalatok vezetési gyakorlatában

Talán elmúlt az az idő, amikor egy vállalat számítási erőforrásait csak információk rögzítésére és számviteli jelentések rögzítésére fordították. Ugyanakkor a vezetői döntések „szemből” születtek az irodákban, az üléseken, üléseken. Talán Oroszországban itt az ideje, hogy a vállalati számítástechnikai rendszereket visszahelyezzék fő erőforrásukba - a menedzsment problémák megoldása a számítógépen regisztrált adatok alapján

Az üzleti elemzés 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. Egyfajta „műszerfalat” alkotnak, amely a vezérelt objektum különféle alrendszereinek állapotát tükrözi. A cég informatív teljesítménymutatókkal való felszerelése, számításuk és a kapott értékek nyomon követése egy üzleti elemző munkája. Az automatizált elemző szolgáltatások, mint például az MS SQL Server Analysis Services (SSAS) segédprogram és annak fő eszköze, az OLAP kocka jelentős segítséget nyújthatnak a vállalat elemző munkájának megszervezésében.

Itt még egy pontot kell kiemelni. Tegyük fel, hogy az amerikai hagyomány szerint az OLAP-kockákkal való munkavégzésre összpontosító specialitást 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ó”, homályos tudású, csekély fizetésű szakember, akinek valóban nincs saját eszköze és módszertana.

A BI-szakember valójában alkalmazott matematikus, magasan képzett szakember, aki a modern matematikai módszereket a vállalat arzenáljába helyezi (úgy hívták, hogy Operations Research – az operációkutatás módszerei). A BI jobban megfelel a „rendszerelemző” szakterületnek, amely egykor a Szovjetunióban volt, és a Moszkvai Állami Egyetem Számítógépes Matematikai és Matematikai Karán végzett. M.V. Lomonoszov. Az OLAP kocka és elemzési szolgáltatások ígéretes alapjává válhatnak egy orosz üzleti elemző munkahelyének, talán némi továbbképzést követően 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állalati alkalmazottak különböző kategóriái között. Egy könyvelő, menedzser és programozó, mint „hattyú, rák és csuka” I.A. meséjében. Krylov, különböző irányokba húzzák a vállalatot.

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

A menedzser elfoglalt az üzleti folyamat saját részével, de nem tudja globálisan, a vállalat egészének szintjén értékelni tevékenységének eredményeit és kilátásait.

Végül a programozó, aki egykor (képzettségének köszönhetően) a tudomány szférájától az üzleti szféráig haladó műszaki ötletek karmestere volt, a könyvelő és menedzser fantáziájának passzív végrehajtójává vált, így nem már ritka, hogy a vállalatok informatikai részlegét könyvelők hajtják, és általában mindenki, akihez nem lusta. A kezdeményezés hiánya, az í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.) Az úgynevezett „közgazdászokról és jogászokról” nem is beszélek, róluk már régen minden el lett mondva.

Tehát a programozási és számviteli alapismeretekben jártas, tudásintenzív 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 gyógymód a vállalati számítógépes rendszer adatbázisának elemzése, amely lehetővé teszi, hogy a hierarchia minden szintjén a munkavállalók rendelkezésére álljanak a szükséges indikátorkészletek, amelyek jellemzik a vállalat termelési folyamatát. A lényeg nem csak az, hogy az MDX-kocka kényelmes felülete és 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, hanem az a figyelemre méltó gyorsaság és egyszerűség, amellyel az OLAP-kocka ezt megteszi. Ezenkívül ez a sebessé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 méretétől.

Néhány bevezető az OLAP-ba
kockát az MS Excel „pivot táblája” adhat meg. 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 az OLAP kocka olyan jól analitikai problémák megoldására? Az OLAP kocka úgy van kialakítva, hogy az összes lehetséges szakaszon minden mutató előre kiszámított (egészben vagy részben), és a felhasználó csak a szükséges mutatókat (mértékeket) és méreteket (méreteket) tudja „kihúzni” a egérrel, és a program újra tudja rajzolni a táblázatokat.

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 fordul is a felhasználó (menedzser, üzleti elemző, ügyvezető) az analitikai szolgáltatáshoz, a válaszadás gyorsaságát két dolog magyarázza: egyrészt könnyen megfogalmazható a szükséges elemzés (vagy név szerint kiválasztható egy listából, vagy megadható). képlet az MDX nyelvben ), másodszor, általában már ki van számítva.

Az analitika megfogalmazása háromféleképpen lehetséges: vagy adatbázismező (vagy inkább raktármező), vagy kocka tervezési szinten definiált számítási mező, vagy MDX nyelvi kifejezés, amikor interaktívan dolgozik a kockával.

Ez az OLAP kockák számos vonzó tulajdonságát jelenti. Lényegében megszűnik az akadály a felhasználó és az adatok között. Az akadályt egy alkalmazásprogramozó jelenti, akinek először is meg kell magyaráznia a problémát (feladatot kell kitűznie). Másodszor, meg kell várnia, amíg az alkalmazásprogramozó létrehoz egy algoritmust, megírja és hibakeresi a programot, majd esetleg módosítja. Ha sok alkalmazott van, és az igényeik változatosak és változékonyak, akkor alkalmazásprogramozók egész csapatára van szükség. Ebben az értelemben egy OLAP-kocka (és egy képzett üzleti elemző) egy egész csapat alkalmazás-programozót helyettesít az analitikai munkában, ahogy egy nagy teljesítményű kotrógép egy kotrógép-kezelővel egy egész csapat migráns munkás lapáttal helyettesít egy árokásásnál!

Ezzel párhuzamosan a kapott analitikai adatok egy másik nagyon fontos minősége is megvalósul. Mivel az egész cégnek csak egy OLAP kocka van, i.e. Ez ugyanaz a mező, ahol az elemzők mindenki számára elérhetők, ami kiküszöböli az adatok bosszantó eltéréseit. Amikor egy menedzsernek ugyanazt a feladatot több független munkatársnak kell feltennie a szubjektivitás tényezőjének kiküszöbölése érdekében, de mégis különböző válaszokat hoznak, amit mindenki vállalkozik valamilyen módon megmagyará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 egy vezető részletezni akar egy számára érdekes mutatót, akkor minden bizonnyal eljut azokhoz az alacsonyabb szintű adatokhoz, amelyekkel a beosztottja dolgozik, és pontosan ez lesz az az adat, amely alapján a magasabb szintű mutatót kiszámítottá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 az összesítés különböző szintjein.

Mondjunk egy példát. Tegyük fel, hogy egy kezelő kezeli a követeléseket. Amíg a lejárt követelések KPI-je zöld, ez azt jelenti, hogy minden normális, és 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 részlegenként levágjuk a KPI-ket, és azonnal „pirossal” látjuk a részlegeket. A következő részben a menedzserek - és az eladó, akinek ügyfelei le vannak maradva a fizetéssel, az azonosításra kerül. (Továbbá a lejárt összeg megosztható vásárlókra, feltételekre stb.) A társaság vezetője bármilyen szinten közvetlenül kapcsolatba léphet a szabálysértőkkel. 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. A helyzet korrigálása érdekében tehát nem is kell a „szőnyegre hívásra” várniuk... Természetesen magának a KPI-nek nem kell feltétlenül a lejárt fizetések összegének lennie – lehet a a késedelmes fizetések súlyozott átlagos időtartama, vagy általában a követelések forgási üteme.

Vegyük észre, hogy az MDX nyelv összetettsége és rugalmassága a gyors (néha azonnali) eredményekkel együtt lehetővé teszi számunkra, hogy olyan összetett vezérlési problémákat oldjunk meg (figyelembe véve a fejlesztés és a hibakeresés szakaszait), amelyek egyébként fel sem merülhettek volna. az alkalmazásprogramozók bonyolultsága és a megfogalmazás kezdeti bizonytalansága miatt. (Hosszú határidők az alkalmazásprogramozóknak az analitikai problémák megoldására a rosszul értelmezett megfogalmazások és a programok hosszas módosításai miatt, amikor a feltételek megváltoznak a gyakorlatban.)

Ügyeljünk arra is, hogy a cég minden dolgozója az általános területről pontosan azt a termést tudja begyűjteni egy OLAP elemzőtől, amelyre a munkájához szüksége van, és ne elégedjen meg a neki közösen kivágott „csíkkal”. „standard jelentések”.

Az OLAP-kockákkal kliens-szerver módban történő munkavégzéshez használható többfelhasználós felület lehetővé teszi, hogy minden alkalmazott, másoktól függetlenül, saját (akár bizonyos készségekkel saját maga által készített) elemzési blokkokkal (jelentésekkel) rendelkezzen, amelyek meghatározá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 (amelyet valójában nemcsak a recepciós elemző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, „nem általánosságban” , ami feltételeket teremt a munka javításához és a termelékenység növeléséhez.

Bevezetésünket összefoglalva megjegyezzük, hogy az OLAP kockák használata magasabb szintre emelheti a 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, alkalmazott független számításai) távlatokat nyitnak az OLAP kockák használatára az orosz nagyvállalatok gyakorlatában.

OLTP + OLAP: visszacsatolási hurok a vállalatirányítási láncban

Most nézzük meg az OLAP kockák általános elképzelését és alkalmazási helyét a vállalati menedzsment láncban. Az OLAP (OnLine Analytical Processing) kifejezést Edgar Codd brit matematikus vezette be a korábban bevezetett 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, a modern értelmezés szerint az OLTP egy relációs adatbázis, amely információrögzítési, tárolási és visszakeresési mechanizmusnak tekinthető.

Megoldás módszertana

Az ERP-rendszerek (Enterprice Resource Planning), mint például az 1C7, 1C8, MS Dynamics AX, felhasználó-orientált szoftverfelülettel (dokumentumok bevitele és szerkesztése stb.) és relációs adatbázissal (DB) rendelkeznek az információk tárolására és visszakeresésére, amelyet ma szoftverek képviselnek. termékek, mint például az MS SQL Server (SS).

Vegye figyelembe, hogy az ERP-rendszer adatbázisában regisztrált 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 dokumentumáramlását (dokumentumok kinyerése, javítása, nyomtatási és egyeztetési 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 az OLTP rendszer (relációs adatbázis) valójában a vállalat tevékenységének valóságos, életnagyságú digitális modellje.

A folyamat irányításához azonban nem elegendő az ezzel kapcsolatos információk regisztrálása. A folyamatot a folyamat előrehaladását jellemző numerikus mutatók (KPI-k) rendszerében kell bemutatni. Ezenkívül a mutatók számára elfogadható értéktartományokat kell meghatározni. És csak akkor, ha a mutató értéke a megengedett intervallumon kívül esik, akkor ellenőrzési műveletet kell végrehajtani.

Az irányítás ilyen logikáját (vagy mitológiáját) tekintve („eltérés általi kontroll”) mindkettő ókori görög filozófus Platón, aki megalkotta a kormányos (kibernóz) képét, aki az evezőre támaszkodik, amikor a csónak letér a pályáról, és Norbert Wiener amerikai matematikus, aki a számítógépes korszak előestéjén megalkotta a kibernetika tudományát.

Az OLTP módszerrel történő információrögzítés szokásos rendszere mellett egy másik rendszerre van szükség - egy rendszerre az összegyűjtött információk elemzésére. Ez a kiegészítő, 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.

Az OLAP szoftveres megvalósításaként az MS Analysis Services segédprogramot fogjuk figyelembe venni, amely az MS SQL Server (rövidítve SSAS) szabványos szállításának része. Vegyük észre, hogy E. Codd terve szerint az OLAP kockának az analitikában ugyanolyan átfogó 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 az OLAP kocka automatizált működésének alapját képező külső eszközök, alkalmazásprogramok és technológiai műveletek sajátos konfigurációját.

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

Azt is feltételezzük, hogy egy másik szerveren van telepítve szoftver, 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 alkalmazásokat. Ezek a programok együtt alkotják a szükséges kontextust: az OLAP-kockák fejlesztője számára szükséges eszközöket és felületeket.

Az SSAS szerveren van egy szabadon terjesztett, blat nevű program, amelyet (paraméterekkel) innen hívnak parancs sorés postai szolgáltatást nyújt.

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, valamint adott esetben egy speciális illesztőprogram, amely biztosítja, 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 benne van 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. Ezenkívül az MS SQL Server 2005 használható SQL Serverként, az Enterprise Edition (EE) vagy a Developer Edition (DE) verzióval a kiszolgálóra az OLAP kockával együtt. Ezekben a kiadásokban lehetőség van az ún. „félig additív intézkedések”, azaz a közönséges összegeken kívüli további összesített függvények (statisztika) (például szélsőség vagy átlag).

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 minden szükséges szakaszban kiszámítanak, például a szállítási mutatót vevők, áruk, dátumok szerinti szakaszokban stb. Az OLAP-kockákkal foglalkozó orosz szakirodalomban az angolról való közvetlen fordítás miatt a mutatókat „méréseknek”, a szakaszokat pedig „dimenzióknak” nevezik. Ez egy matematikailag helyes, de szintaktikailag és szemantikailag nem túl sikeres fordítás. Az orosz „measure”, „dimension”, „dimension” szavak jelentése és írásmódja szinte megegyezik, 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 „mutató” és „kivágás” kifejezéseket, amelyek jelentésükben hasonlóak.

Az adatok rögzítésére szolgáló OLTP-rendszerrel kapcsolatban számos lehetőség kínálkozik az OLAP-kocka szoftveres megvalósítására. Csak egy sémát fogunk figyelembe venni, a legegyszerűbb, legmegbízhatóbb és leggyorsabb.

Ebben a kialakításban az OLAP és az OLTP nem osztja meg a táblákat, és az OLAP elemzés a lehető legrészletesebben kerül kiszámításra a kocka frissítési (folyamat) szakaszában, amely megelőzi a használati szakaszt. 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 az összes (ezer) ERP-rendszer relációs adatbázis-táblázatának 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 célszerűbb külön adatbázist készíteni, amelyet „kirakatnak” vagy „raktárnak” neveznek.

Több ok is rákényszerít bennünket erre.

• Először, OLAP-kocka táblákhoz kötése igazi bázis az adatok minden bizonnyal technikai problémákat okoznak. 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 folyamatos újjáépítés állapotában lesz; Ugyanakkor a kockafrissítési eljárás blokkolhatja (olvasáskor) az adatbázistá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 mutató és vágás drámaian megnöveli a kocka tárolóterületét a szerveren. Ne felejtsük el, hogy az OLAP-kocka nemcsak a forrásadatokat 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, 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 mező (jelzők és szakaszok) problémákat okoz az OLAP fejlesztői felületén, mert az elemek listája hatalmas lesz.
• Negyedszer, Az OLAP kocka nagyon érzékeny az adatintegritás megsértésére. A kocka nem építhető fel, ha a kulcsadatok nem a kocka mezőkapcsolatok felépítésében meghatározott hivatkozáson találhatók. Ideiglenes vagy állandó integritássértések, üres mezők gyakoriak az ERP rendszer adatbázisában, de ez abszolút 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ásához. De ha vannak közös táblák az OLAP-hoz és az OLTP-hez, akkor a hálózati forgalom problémája is felmerül. Gyakorlatilag megoldhatatlan problémák merülnek fel ilyenkor, amikor több, egymástól eltérő ERP rendszert (1C7, 1C8, MS Dynamics AX) kell egyetlen OLAP kockába összevonni.

Valószínűleg továbbra is halmozhatjuk a technikai problémákat. De ami a legfontosabb, ne feledje, hogy az OLTP-vel ellentétben az OLAP nem az adatok rögzítésének és tárolásának eszköze, hanem egy elemző eszköz. Ez azt jelenti, hogy nincs szükség „piszkos” adatok feltöltésére és letö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 a 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 tartalmaz egy kis , a menedzsmenthez szükséges finomított adatmennyiség az ERP-ből.

Promóció nélkül rossz szokások, az OLAP-kocka az OLTP-vel kapcsolatban a jól ismert „még kockához” hasonlítható, amelyen keresztül a valódi regisztráció „erjesztett tömegéből” nyerik ki a „tiszta terméket”.

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 általában 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úra következő változatát javasoljuk.

Megoldás architektúra

Tegyük fel, hogy egy bizonyos vállalatnak (holdingnak) sok ERP rendszere található különböző szervereken, amelyek elemzési adatait egy OLAP-kockán belül szeretnénk konszolidálni. Hangsúlyozzuk, hogy az ismertetett technológiában az ERP rendszerek adatait 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 ezen ERP rendszerek adatbázisaiból. Időnként (éjszakánként) végrehajtjuk a megfelelő aktív ERP-adatbázisok részleges replikációját ezekre az üres másolatokra.

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

Ezután elindul a raktári adatok alapján a kocka frissítésének/építésének standard eljárása (Folyamatművelet az SSAS felületen).

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 az aktuális adatok az OLAP-kiszolgálón lévő ERP-rendszerek képében jelennek meg. A részleges replikációt egyébként kétféleképpen lehet végrehajtani.

Először is, az ERP rendszer adatbázisában lévő összes táblábó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ásolat képében (ha nem minden mező szerepel kezdetben a táblázat másolatában).

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

Ezután az SP fő feladata az ERP rendszer adatainak raktár formá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ása, esetleg újraformázása. De ha több ERP-rendszert kell konszolidálnia ugyanabban az OLAP-kockában különböző szerkezetek, akkor az átalakítások bonyolultabbá válnak.

A több különböző ERP rendszer egy kockában való összevonásának feladata különösen nehéz, ha az objektumok halmazai (árukönyvtárak, vállalkozók, raktárak stb.) részben átfedik egymást, az objektumok jelentésük azonos, de természetesen eltérően íródnak le a könyvtárakban 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óan működő társasága megközelítőleg ugyanazon a területen végez megközelítőleg azonos típusú tevékenységet, de saját és nem egyeztetett regisztrációs 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 jellemzően „csillag” formájában á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 referenciakönyvek a részük. Ebben az esetben a címtár lehet tetszőleges kiegyensúlyozatlan fa vagy kiegyensúlyozott hierarchia, például áruk vagy vállalkozók 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ékekké) válnak, a szakaszok (vagy dimenziók) pedig másodlagos kulcstáblázatok segítségével határozhatók meg.

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, egy csillag „sugara” nem csak egy könyvtár lehet, hanem egy teljes (hierarchikus) fájlrendszer.

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

Negyedszer, a meglévő indikátorok és szakaszok alapján, MDX nyelvi kifejezések segítségével új mutatók (számítások) definiálhatók. 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 szakaszok jelentősen lelassíthatják az OLAP kocka működését.

MS Excel, mint interfész az OLAP-pal

Külön érdekesség az OLAP kockákat tartalmazó felhasználói felület. A legteljesebb interfészt természetesen maga az SSAS segédprogram biztosítja. Ez magában foglal egy OLAP-kocka fejlesztői eszközkészletet, egy interaktív jelentéstervezőt és egy ablakot 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ó interfészt egy speciális illesztőprogram biztosítja, amely külön letölthető vagy az Excel disztribúció része. Nem fedi le az OLAP összes funkcionalitását, de az MS Excel verziószámának növekedésével ez a lefedettség egyre szélesebb (pl. az MS Excel 2007-ben megjelenik a KPI grafikus ábrázolása, 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 széleskörű elterjedése, valamint az irodai felhasználók elsöprő számú ismeretsége. Ebben az értelemben, a többi interfész-programtól eltérően, a cégnek nem kell semmit sem vásárolnia, és senkit sem kell tovább képeznie.

Az MS Excel, mint az OLAP-pal való interfész nagy előnye, hogy az OLAP-jelentésben kapott adatokat önállóan tovább tudja feldolgozni (vagyis az OLAP-ból nyert adatok továbbtanulmányozása ugyanazon Excel más lapjain, már nem OLAP-eszközök használatával, hanem szokásos Excel eszközök használatával).

Facubi éjszakai kezelési ciklus

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

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) adatbázisainak részleges replikációját végzik. A replikáció, mint mondtuk, előre elkészített „háttérre” - az SSAS-kiszolgálón található távoli ERP-rendszerek képeire - 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 DB-re, amely az OLAP-kockaadatok forrása és az SSAS-kiszolgálón található. Ebben az esetben három fő feladatot oldanak meg:

• ERP adatok a szükséges kockaformátumokhoz igazítva; Táblákról és táblázatmezőkről is beszélünk. (Néha a szükséges táblázatot „módosítani” 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 számjegyű karakterkódja 8 hosszúságú. , és _idrref mezők az 1С8 könyvtárakban – 32 hosszúságú hexadecimális számok;
• feldolgozás során logikai adatellenőrzés (beleértve a hiányzó adatok helyére „alapértelmezett” írást, 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 címtárainak megfelelő elemei azonos jelentéssel bírhatnak, mondjuk ugyanazt a partnert jelentik. A kódok konszolidálásának problémáját leképezési táblák felépítésével oldják meg, ahol ugyanazon objektumok különböző kódjait egyesítik.

Harmadszor, a facubi elindítja a szabványos eljárást a Process kocka adatok frissítésére (az SSAS segédprogram eljárásaiból).

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

A facubi végrehajtása után a Task Scheduler sorra elindít több excel fájlt, amelyekben az OLAP kocka indikátorok alapján előre elkészítik a riportokat. Mint mondtuk, az MS Excel rendelkezik egy speciális szoftverfelülettel (külön letölthető vagy beépített illesztőprogram) az OLAP kockákkal (SSAS-szal) való munkavégzéshez. Az MS Excel indításakor az MS VBA programok (például makrók) aktiválódnak, amelyek biztosítják a jelentésekben szereplő adatok frissítését; 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, posta nélkül frissíthetik az OLAP jelentéseket a helyi számítógépükön található MS Excelben.) A helyi hálózaton kívüli felhasználók vagy az eredeti jelentéseket kapják meg, de korlátozott funkcionalitással, vagy helyettük (az OLAP frissítése után) jelentések MS Excelben) speciális „halott” jelentések kerülnek kiszámításra, amelyek nem érik el az SSAS szervert.

Az eredmények értékelése

Fentebb beszéltünk az OLTP és az OLAP aszinkronjáról. A vizsgált technológiai változatban 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 rögzítési eszköz (nézze meg a dokumentum legfrissebb változatát), hanem felügyeleti eszköz (értse a folyamat trendjét), az ilyen késés általában nem kritikus. Szükség esetén azonban a kocka architektúra (MOLAP) leírt változatában is naponta többször is elvégezhető a frissítés.

A frissítési eljárások végrehajtási ideje az OLAP kocka tervezési jellemzőitől (több-kevesebb bonyolultsá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 folyamat több perctől két óráig tart, a kockafrissítési eljárás (Process) 1-20 percig tart. Összetett OLAP kockákról beszélünk, amelyek több tucat csillag típusú struktúrát egyesítenek, több tucat közös „sugarról” (referencia szakaszról) és több száz indikátorról. Külső ERP rendszerek adatbázisainak mennyiségét a szállítási dokumentumok alapján 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ő történelmi feldolgozási mélység 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 cég (SB). Egyes vállalatok elsősorban kereskedelmi és beszerző cégek (PPC), mások termelő vállalatok (hal- és tenger gyümölcsei feldolgozó üzemek a Moldovai Köztársaságban és a Fehérorosz Köztársaságban). Valamennyi vállalat nagy holding, amely több vállalatot egyesít független és különféle számítógépes számviteli 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 főállású üzleti elemző feladata. A feladat évek óta automatikusan fut, és a vállalati alkalmazottak különböző kategóriáinak napi rendszerességgel látja el az aktuális jelentéseket.

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

A tapasztalat azt mutatja, hogy a javasolt megoldás meglehetősen megbízható és könnyen használható. Könnyen módosítható (új ERP-k csatlakoztatása/lekapcsolása, új indikátorok és szekciók létrehozása, Excel riportok és levelezési listáik 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, kellő kifejezőképességet biztosít, és lehetővé teszi a különböző kategóriájú irodai alkalmazottak számára, hogy gyorsan megismerjék az OLAP technológiát. 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 tanulmányozását az MS Excel szokásos lehetőségeivel.

A „finomított” raktári adatbázis, melyben több heterogén ERP rendszer konszolidálódik (a kocka építése során), akár OLAP nélkül is lehetővé teszi a megoldást (SSAS szerveren, a Transact SQL-ben lekérdezési módszerrel vagy SP metódussal). stb.) számos alkalmazott menedzsment probléma. 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 a teljes holdingra vonatkozó elemzések beszerzését és az elemzések hosszú távú folytonosságának fenntartását, amikor egy vállalat egy másik számviteli ERP 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: Az OLAP és az OLTP aszinkron, valamint nagy mennyiségű memória az OLAP tárolására.

Végezetül, itt van egy másik érv az OLAP mellett, amely alkalmasabb lehetett a középkorban. Mert bizonyító ereje a tekintélyen nyugszik. Egy szerény, egyértelműen alulértékelt 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 akkora ereje volt, 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 matematikus nélkül is számíthat 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 átveszik 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 átfogó matematikai megoldását, és ez a megoldás „megfelelő” (B. Spinoza kifejezése) az analitika gyakorlati problémájának. A „megfelelően” azt jelenti Spinozában, hogy Isten maga sem gondolhatott volna jobbat...

1. Larson B. Üzleti elemzés fejlesztése Microsoft SQL Server 2005-ben. – Szentpétervár: „Péter”, 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