Adatkockák tervezése. OLAP-kocka létrehozása a Microsoft Query segítségével

Rizs. 2. OLAP kocka szelet

Forgás(3. ábra) - a jelentésben vagy a megjelenített oldalon bemutatott mérések helyének megváltoztatásának művelete. Például egy elforgatási művelet magában foglalhatja egy táblázat sorainak és oszlopainak á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.

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

Az előadás célja

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

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

és tanulni:

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

Bevezetés

Az OLAP technológia nem egyetlen szoftver, Nem programozási nyelv. 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.

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

A központosítás és a kényelmes strukturálás nem minden, amire egy elemzőnek szüksége van. Szüksége van egy eszközre az információk megtekintéséhez és megjelenítéséhez. A hagyományos riportok, még az egyetlen adattárházra épülő riportok is, hiányoznak azonban bizonyos rugalmasságból. Nem lehet őket „csavarni”, „kibontani” vagy „összecsukni”, hogy az adatok kívánt nézetét kapják. Minél több adat „szeletét” és „szeletét” tud feltárni egy elemző, annál több ötlete van, amelyek viszont egyre több „szeletet” igényelnek az ellenőrzéshez. Az OLAP ilyen eszközként szolgál az elemzők által végzett adatelemzéshez.

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

Az üzemi adatokat különféle forrásokból gyűjtik, tisztítják, integrálják és adattárházban tárolják. Sőt, már elérhetőek a különféle jelentéskészítő eszközökkel történő elemzéshez. Ezután az adatok (részben vagy egészben) előkészítésre kerülnek az OLAP elemzéshez. Betölthetők egy speciális OLAP adatbázisba, vagy hagyhatók egy relációs adatbázisban. Az OLAP használatának legfontosabb eleme a metaadatok, azaz a szerkezetre, elhelyezésre és az elhelyezésre vonatkozó információk adatátalakítás. Ezeknek köszönhetően a különböző tárolóelemek hatékony interakciója biztosított.

És így, Az OLAP az adattárházban felhalmozott többdimenziós adatelemzés eszközkészleteként határozható meg. Elméletileg az OLAP eszközök közvetlenül alkalmazhatók működési adatokra vagy azok adataira pontos másolatok. Fennáll azonban annak a veszélye, hogy az adatokat olyan elemzésnek vetik alá, amely nem alkalmas erre az elemzésre.

OLAP a kliensen és a szerveren

Az OLAP többdimenziós adatelemzésen alapul. Különféle eszközökkel állítható elő, amelyek kliens és szerver OLAP eszközökre oszthatók.

Az OLAP klienseszközök olyan alkalmazások, amelyek összesített adatokat (összegeket, átlagokat, maximális vagy minimális értékeket) számítanak ki és jelenítenek meg, míg magát az összesített adatokat egy gyorsítótárban tárolják az ilyen OLAP-eszközök címterében.

Ha a forrásadatokat egy asztali DBMS tartalmazza, akkor az összesített adatok kiszámítását maga az OLAP eszköz végzi el. Ha a kiindulási adatok forrása egy szerver DBMS, akkor sok ügyfél OLAP-eszköz GROUP BY operátort tartalmazó SQL-lekérdezéseket küld a szervernek, és ennek eredményeként a kiszolgálón kiszámított összesített adatokat kap.

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

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

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

Sok (de nem az összes) OLAP-kliens eszköz lehetővé teszi a gyorsítótár tartalmának összesített adatokkal történő fájlként történő elmentését, ami viszont lehetővé teszi azok újraszámításának elkerülését. Vegye figyelembe, hogy ezt a lehetőséget gyakran használják fel az összesített adatok elidegenítésére más szervezeteknek való továbbítás vagy közzététel céljából. Az ilyen elidegeníthető aggregált adatok tipikus példája a különböző régiókban és különböző korcsoportokban előforduló morbiditási statisztikák. nyílt információ az egészségügyi minisztériumok által kiadott különböző országokbanés az Egészségügyi Világszervezet. Ugyanakkor maga az eredeti adat, amely konkrét megbetegedésekre vonatkozó információkat jelent, egészségügyi intézmények bizalmas adatai, és semmi esetre sem kerülhetnek biztosítótársaságok kezébe, még kevésbé válhatnak nyilvánossá.

Az aggregált adatok gyorsítótárának fájlban való tárolásának gondolatát a szerver OLAP eszközökben fejlesztették tovább, amelyekben az aggregált adatok mentését és módosítását, valamint az azokat tartalmazó tároló karbantartását egy külön alkalmazás vagy folyamat, az ún. OLAP szerver. Az ügyfélalkalmazások kérhetnek ilyen többdimenziós tárolást, és válaszként kaphatnak bizonyos adatokat. Egyes ügyfélalkalmazások is létrehozhatnak ilyen tárolókat, vagy frissíthetik azokat a megváltozott forrásadatok alapján.

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

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

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

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

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

A nyers és az összesített adatok egyaránt tárolhatók relációs vagy többdimenziós struktúrákban. Ezért jelenleg három adattárolási módot alkalmaznak.

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

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

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

OLAP alapfogalmak

FAMSI teszt

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

• Gyors(Gyors) - elfogadható időn belül (általában legfeljebb 5 s) a felhasználó rendelkezésére bocsátani az elemzési eredményeket, még kevésbé részletes elemzés árán is;
• Elemzés(Elemzés) - 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 lehetősége;
• Megosztva(Megosztott) - többfelhasználós hozzáférés az adatokhoz megfelelő zárszerkezetek és engedélyezett hozzáférési eszközök támogatásával;
• Többdimenziós(Többdimenziós) - az adatok többdimenziós fogalmi megjelenítése, beleértve a hierarchiák és a többszörös hierarchiák teljes támogatását (ez az OLAP kulcskövetelménye);
• Információ(Információ) - az alkalmazásnak hozzá kell férnie minden szükséges információhoz, függetlenül annak mennyiségétől és tárolási helyétől.

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

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

kockákra

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

ábrán látható háromdimenziós kockában mérve. 26.1, eladási mennyiségek, méretként pedig idő, termék és üzlet használatos. A mérések a következőben vannak feltüntetve bizonyos szinteket csoportosítások: a termékek kategóriánként, az üzletek országonként, a tranzakciók időpontjára vonatkozó adatok pedig hónaponként vannak csoportosítva. Kicsit később részletesebben megvizsgáljuk a csoportosítás (hierarchia) szintjeit.

Rizs. 26.1.

Kocka "vágása".

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

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

Az OLAP alkalmazások architektúrája

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

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

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

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

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

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

/ 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 segédprogram, jelentős segítséget nyújthatnak egy vállalat elemző munkájának megszervezésében. SQL szerver Az Analysis Services (SSAS) és fő funkciója az OLAP kocka.

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.

BAN BEN Utóbbi időbenÚjabb káros tendencia alakult ki. 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 (a fejlesztési és hibakeresési szakaszok figyelembevételével) olyan összetett vezérlési feladatok megoldását, amelyek egyébként fel sem merültek 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 többel növelheti egy vállalat gazdálkodását. magas szint. 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ületekkel (dokumentumok bevitele és szerkesztése stb.) és relációs adatbázissal (DB) rendelkeznek a ma bemutatott információk tárolására és visszakeresésére. szoftver termékekírja be: MS SQL Server (SS).

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 alkalmazotti munkaállomásokon a Windows XP operációs rendszer, a szervereken pedig a Windows Server 2008 van telepítve, ezenkívül használjuk az MS SQL Server 2005-öt SQL Serverként, és az Enterprise Edition (EE) telepítését. a szerveren az OLAP kockával ) vagy a Developer Edition (DE). 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 funkcióját, de az MS Excel verziószámának növekedésével ez a lefedettség egyre szélesebb (például az MS Excel 2007-ben megjelenik a KPI grafikus ábrázolása, ami az MS Excel 2003-ban nem volt így, 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ára. 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

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

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

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

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

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

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

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

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

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

OLAP - kényelmes elemző eszköz

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

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

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

Rizs. 1. Adattárház szerkezete

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

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

Az OLAP definíciója és alapfogalmai

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

FASMI teszt

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

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

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

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

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

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

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

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

Rizs. 2. Kocka példa

Kocka "vágása".

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

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

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

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

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

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

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

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

Címkék

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

Hierarchiák és szintek

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

Ország

Állapot

Város

Bolt.

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

Az OLAP alkalmazások architektúrája

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 egy adatstruktúra egyszerűen "felrobban" - 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.