Riis. 2. OLAP-i kuubiku viil

Pöörlemine(Joonis 3) - aruandes või kuvatud lehel esitatud mõõtmiste asukoha muutmise toiming. Näiteks võib pööramisoperatsioon hõlmata tabeli ridade ja veergude vahetamist. Lisaks sellele liigub andmekuubiku pööramine mittetabeli mõõtmed kuvatud lehel olevate dimensioonide asukohta ja vastupidi.

OLAP ei ole üksik tarkvaratoode, programmeerimiskeel ega isegi mitte konkreetne tehnoloogia. Kui proovite katta OLAP-i kõigis selle ilmingutes, on see kontseptsioonide, põhimõtete ja nõuete kogum, mis on aluseks tarkvaratoodetele, mis hõlbustavad analüütikutel andmetele juurdepääsu. Uurime välja Milleks analüütikud vajavad midagi erilist hõlbustada juurdepääs andmetele.

Fakt on see, et analüütikud on ettevõtte teabe erilised tarbijad. Analüütiku ülesanne on leida suurtes andmemassiivides mustreid. Seetõttu ei pööra analüütik tähelepanu asjaolule, et neljapäeval, neljandal päeval müüdi vastaspoolele Tšernovile partii musta tinti - ta vajab teavet. umbes sadu ja tuhandeid sarnased sündmused. Üksikud faktid andmebaasis võivad huvi pakkuda näiteks raamatupidajale või müügiosakonna juhile, kelle pädevuses tehing asub. Ühest rekordist analüütikule ei piisa – näiteks võib tal vaja minna kuu või aasta jooksul kõiki antud filiaali või esinduse tehinguid. Samal ajal analüütik ära viskab ebavajalikud üksikasjad, nagu ostja TIN, tema täpne aadress ja telefoninumber, lepinguindeks jms. Samal ajal sisaldavad andmed, mida analüütik peab töötama, tingimata arvväärtusi - see on tingitud tema tegevuse olemusest.

Seega vajab analüütik palju andmeid, need andmed on selektiivsed ja neil on ka olemus " atribuutide komplekt - number". Viimane tähendab, et analüütik töötab järgmist tüüpi tabelitega:

siin" Riik", "Toode", "aasta" on atribuudid või mõõdud, A" Müügimaht" - seega arvväärtus või mõõta. Analüütiku ülesanne, kordame, on tuvastada püsivad seosed atribuutide ja numbriliste parameetrite vahel.. Tabelit vaadates näete, et seda saab hõlpsasti tõlkida kolme mõõtmesse: ühele teljele paneme riigid, teisele - kaubad, kolmandale - aastad. Ja selle kolmemõõtmelise massiivi väärtused on vastavad müügimahud.

Tabeli 3D esitus. Hall segment näitab, et 1988. aasta Argentina kohta puuduvad andmed

Just sellist kolmemõõtmelist massiivi OLAP-i mõttes nimetatakse kuubiks. Tegelikult ei ole range matemaatika seisukohalt selline massiiv alati kuubik: päris kuubi jaoks peab elementide arv kõigis mõõtmetes olema sama, samas kui OLAP-kuubikutel sellist piirangut pole. Vaatamata nendele üksikasjadele on termin "OLAP-kuubikud" oma lühiduse ja kujundlikkuse tõttu muutunud üldtunnustatud. OLAP-kuubik ei pea üldse 3D-kujuline olema. See võib olla nii kahe- kui ka mitmemõõtmeline, olenevalt lahendatavast probleemist. Eriti kogenud analüütikud võivad vajada umbes 20 mõõtmist – ja tõsised OLAP-tooted on mõeldud just sellise arvu jaoks. Lihtsamad töölauarakendused toetavad umbes 6 mõõdet.

mõõdud OLAP-kuubikud koosnevad nn märgid või liikmed. Näiteks dimensioon "Riik" koosneb siltidest "Argentina", "Brasiilia", "Venezuela" ja nii edasi.

Kõiki kuubi elemente ei tasu täita: kui 1988. aastal Argentinas kummitoodete müügi kohta info puudub, siis lihtsalt ei määrata väärtust vastavas lahtris. Samuti pole vaja, et OLAP-rakendus salvestaks andmeid tingimata mitmemõõtmelises struktuuris – peaasi, et kasutaja jaoks need andmed täpselt sellised välja näeksid. Muide, just mitmemõõtmeliste andmete kompaktse salvestamise spetsiaalsetel viisidel ei too "vaakum" (täitmata elemendid) kuubikutes kaasa mälu raiskamist.

Kuubik ise aga analüüsiks ei sobi. Kui kolmemõõtmelist kuubikut on veel võimalik adekvaatselt kujutada või kujutada, siis kuue-üheksateistkümne mõõtmega on olukord palju hullem. Sellepärast enne kasutamist tavalised kuubikud ekstraheeritakse mitmemõõtmelisest kuubist kahemõõtmelised tabelid. Seda toimingut nimetatakse kuubi "lõikamiseks". Jällegi on see termin kujundlik. Analüütik justkui võtab ja "lõikab" kuubi mõõtmed vastavalt teda huvitavatele märkidele. Nii saab analüütik kuubist kahemõõtmelise lõigu ja töötab sellega. Umbes samamoodi loevad metsamehed saelõikel aastarõngaid.

Sellest lähtuvalt jääb "lõikamata" reeglina ainult kaks mõõdet - vastavalt tabeli mõõtmete arvule. Juhtub, et "lõikamata" jääb ainult mõõde - kui kuubis on mitut tüüpi arvväärtusi, saab need joonistada ühe tabeli mõõtme järgi.

Kui vaatate lähemalt tabelit, mida me kõigepealt kujutasime, näete, et selles olevad andmed ei ole tõenäoliselt esmased, vaid on saadud summeerimine väiksemate esemete jaoks. Näiteks aasta jaguneb kvartaliteks, kvartalid kuudeks, kuud nädalateks, nädalad päevadeks. Riik koosneb piirkondadest ja piirkonnad paikkondadest. Lõpuks võib linnades endis eristada linnaosasid ja konkreetseid jaemüügipunkte. Tooteid saab kombineerida tooterühmadeks jne. OLAP-i mõttes nimetatakse selliseid mitmetasandilisi liitumisi üsna loogiliselt hierarhiad. OLAP-i tööriistad võimaldavad igal ajal liikuda soovitud hierarhia tasemele. Lisaks toetatakse reeglina samade elementide jaoks mitut tüüpi hierarhiat: näiteks päev-nädal-kuu või päev-kümnend-kvartal. Lähteandmed võetakse hierarhiate madalamatelt tasanditelt ja võetakse seejärel kokku, et saada kõrgemate tasemete väärtused. Üleminekuprotsessi kiirendamiseks salvestatakse erinevate tasemete summeeritud väärtused kuubis. Seega see, mis kasutaja poolelt näeb välja nagu üks kuubik, koosneb jämedalt öeldes paljudest primitiivsematest kuubikutest.

Hierarhia näide

See on üks olulisi punkte, mis viis OLAP-i tekkeni – tootlikkus ja tõhusus. Kujutagem ette, mis juhtub siis, kui analüütikul on vaja teavet hankida ja OLAP-i tööriistad pole ettevõttes saadaval. Analüütik teeb iseseisvalt (mis on ebatõenäoline) või programmeerija abiga vastava SQL-päringu ja saab huvipakkuvad andmed aruande kujul või ekspordib need tabelisse. Sellega on palju probleeme. Esiteks on analüütik sunnitud tegema midagi muud peale oma töö (SQL programmeerimine) või ootama, kuni programmeerijad ülesande tema eest ära teevad – kõik see mõjutab negatiivselt tööviljakust, rünnak, infarkti ja insuldi tase tõuseb jne. Teiseks ei päästa üksainus aruanne või tabel reeglina mõttehiiglasi ja vene analüüsi isasid – ja kogu protseduuri tuleb ikka ja jälle korrata. Kolmandaks, nagu oleme juba teada saanud, ei küsi analüütikud pisiasju - nad vajavad kõike korraga. See tähendab (ehkki tehnoloogia areneb hüppeliselt), et ettevõtte relatsiooniline andmebaasiserver, millele analüütik pääseb juurde, võib sügavalt ja pikalt mõelda, blokeerides ülejäänud tehingud.

OLAPi kontseptsioon näis just selliste probleemide lahendamiseks. OLAP-kuubikud on sisuliselt metaaruanded. Lõigates metaaruandeid (see tähendab kuubikuid) dimensioonide kaupa, saab analüütik tegelikult kätte neid "tavalisi" kahemõõtmelisi aruandeid, mis teda huvitavad (need pole ilmtingimata aruanded selle mõiste tavapärases tähenduses – me räägime samade funktsioonidega andmestruktuuridest). Kuubikute eelised on ilmsed – andmeid tuleb relatsioonilisest DBMS-ist küsida vaid üks kord – kuubi ehitamisel. Kuna analüütikud reeglina ei tööta käigupealt täiendatava ja muudetava teabega, on loodud kuubik asjakohane üsna pikka aega. Tänu sellele ei välistata mitte ainult katkestusi relatsioonilise DBMS-i serveri töös (puuduvad tuhandete ja miljonite vastuseridadega päringud), vaid ka analüütiku enda andmetele juurdepääsu kiirus suureneb hüppeliselt. Lisaks, nagu juba märgitud, parandab jõudlust ka hierarhiate ja muude koondväärtuste alamsummade arvutamine kuubi ehitamise ajal. See tähendab, et kui algselt sisaldasid meie andmed teavet konkreetse toote päevase tulu kohta ühes poes, siis kuubi moodustamisel arvutab OLAP-i rakendus erinevate hierarhiate tasemete (nädalad ja kuud, linnad ja riigid) kogusummad.

Loomulikult tuleb sel viisil tootlikkuse tõstmise eest maksta. Mõnikord öeldakse, et andmestruktuur lihtsalt "plahvatab" – OLAP-i kuup võib võtta kümneid või isegi sadu kordi rohkem ruumi kui algandmed.

Vasta küsimustele:

Mis on juhtunud kuubik OLAP?

Mis on juhtunud sildid konkreetne mõõde? Too näiteid.

Kas nad saavad meetmed OLAP-kuubis, sisaldavad mittenumbrilisi väärtusi.

Mis on andmeladu?

Mõnikord on laol ka teine ​​eesmärk - kõigi ettevõtteandmete integreerimine, et säilitada teabe terviklikkus ja asjakohasus kõigis infosüsteemides. See. hoidla ei kogune mitte ainult analüütilist, vaid peaaegu kogu teavet ja võib selle kataloogide kujul teistele süsteemidele tagasi väljastada.

Tüüpiline andmeladu erineb tavaliselt tüüpilisest relatsiooniandmebaasist. Esiteks on tavapärased andmebaasid loodud selleks, et aidata kasutajatel igapäevatööd teha, andmelaod aga otsuste tegemiseks. Näiteks toote müümisel ja arve väljastamisel kasutatakse tehingute töötlemiseks loodud andmebaasi ning mitme aasta müügi dünaamikat analüüsides, mis võimaldab planeerida tööd tarnijatega, kasutades andmeladu.

Teiseks on tavaandmebaasid kasutajate töö käigus pidevas muutumises ning andmeladu on suhteliselt stabiilne: seal olevaid andmeid uuendatakse enamasti graafiku alusel (olenevalt vajadusest näiteks nädala-, päeva- või tunnipõhiselt). Ideaalis on täiendamise protsess lihtsalt uute andmete lisamine teatud aja jooksul, muutmata juba salvestatud vana teavet.

Ja kolmandaks on tavapärased andmebaasid enamasti hoidlasse sisenevate andmete allikaks. Lisaks saab hoidlat täiendada välistest allikatest, näiteks statistilistest aruannetest.

Kuidas ladustamine on ehitatud?

• Väljavõte - andmete ekstraheerimine välistest allikatest arusaadavas vormingus;
• Transformatsioon - lähteandmete struktuuri muutmine struktuurideks, mis on mugavad analüütilise süsteemi ehitamiseks;

Tuleme tagasi analüüsi juurde.

Mis on analüüs ja miks seda vaja on?

Siinkohal tasub välja tuua erinevus DSS-iga töötamise ja lihtsa reguleeritud ja reguleerimata aruannete komplekti vahel. DSS-i analüüs on peaaegu alati interaktiivne ja iteratiivne. Need. analüütik süveneb andmetesse, koostab ja parandab analüütilisi päringuid ning saab aruandeid, mille struktuur ei pruugi olla ette teada. Tuleme selle juurde üksikasjalikumalt tagasi allpool, kui arutame päringukeelt. MDX.

OLAP

Kompleksse mitmemõõtmelise andmeanalüüsi tehnoloogiat nimetatakse OLAP-iks (On-Line Analytical Processing). OLAP on traditsioonilise andmehoidla põhikomponent. OLAP-i kontseptsiooni kirjeldas 1993. aastal tunnustatud andmebaaside uurija ja relatsiooniandmete mudeli autor Edgar Codd. 1995. aastal koostati Coddi poolt välja toodud nõuetest lähtuvalt nn FASMI test (Fast Analysis of Shared Multidimensional Information – jagatud mitmemõõtmelise teabe kiire analüüs), mis sisaldab järgmisi nõudeid mitmedimensioonilise analüüsi rakendustele:

• kasutajale analüüsi tulemuste esitamine vastuvõetava aja jooksul (tavaliselt mitte rohkem kui 5 s) isegi vähem detailse analüüsi hinnaga;
• võimalus teostada selle rakenduse jaoks spetsiifilist loogilist ja statistilist analüüsi ning salvestada see lõppkasutajale kättesaadaval kujul;
• mitme kasutaja juurdepääs andmetele koos sobivate lukustusmehhanismide ja volitatud juurdepääsutööriistade toega;
• andmete mitmemõõtmeline kontseptuaalne esitus, sealhulgas hierarhiate ja mitmete hierarhiate täielik tugi (see on OLAP-i põhinõue);
• võimalus pääseda juurde mis tahes vajalikule teabele, olenemata selle mahust ja salvestuskohast.

Enne kui räägime OLAP-i erinevatest rakendustest, vaatame loogilisest vaatenurgast lähemalt, millised on kuubikud.

Mitmemõõtmelised mõisted

Kuubik

• Tellimuse kuupäev
• Riik
• Linn
• Kliendi nimi
• Tarnefirma
• tootenimi
• Kauba kogus
• Tellimuse hind

• Kui suur on konkreetsest riigist pärit klientide tellimuste koguväärtus?
• Kui suur on teatud riigist pärit klientide tehtud ja kindla ettevõtte tarnitud tellimuste kogumaksumus?
• Kui suur on konkreetse riigi klientide poolt antud aastal tehtud ja konkreetse ettevõtte tarnitud tellimuste koguväärtus?

Selle päringu tulemuseks on alati numbrite veerg ja seda kirjeldavate atribuutide loend (näiteks riik) – see on ühemõõtmeline andmekogum või matemaatilises mõttes vektor.

Kujutage ette, et meil on vaja saada infot kõikide riikide tellimuste kogumaksumuse ja nende jaotuse kohta vedajafirmade lõikes – saame juba numbrite tabeli (maatriksi), kus veergude päistes on kirjas vedajad, ridade päistes riigid ja lahtrites tellimuste summa. See on kahemõõtmeline andmemassiv. Sellist andmekogumit nimetatakse pöördetabeliks ( pöördetabel) või risttabel.

Kui tahame saada samu andmeid, aga aastate kontekstis, siis tuleb üks muudatus veel, s.o. andmestik muutub kolmemõõtmeliseks (3. järku tingimustensor või 3-mõõtmeline "kuubik").

Ilmselgelt on maksimaalne mõõtmete arv kõigi atribuutide arv (Kuupäev, Riik, Klient jne), mis kirjeldavad meie koondandmeid (tellimuste kogus, kauba kogus jne).

Niisiis jõuame mitmemõõtmelisuse kontseptsiooni ja selle kehastuseni - mitmemõõtmeline kuup. Sellist tabelit nimetatakse " faktitabel". Mõõtmed või kuubiku teljed ( mõõtmed) on atribuudid, mille koordinaadid on väljendatud faktitabelis olevate atribuutide individuaalsete väärtustega. Need. näiteks kui tellimuste infot hoiti süsteemis aastatel 2003-2010, siis see aastate telg koosneb 8 vastavast punktist. Kui tellimused tulevad kolmest riigist, siis riigi teljel on 3 punkti jne. Olenemata sellest, kui palju riike on riikide kataloogis. Telje punkte nimetatakse selle "liikmeteks" ( liikmed).

Koondandmeid nimetatakse sel juhul "meetmeteks" ( mõõta). Segiajamise vältimiseks "mõõtmetega" on eelistatav viidata viimastele kui "telgedele". Mõõtmete komplekt moodustab teise "Mõõtmete" telje ( Meetmed). Sellel on sama palju liikmeid (punkte), kui on faktitabelis mõõdikuid (koondveergusid).

Mõõtmete või telgede liikmed saab rühmitada ühte või mitmesse hierarhiasse ( hierarhia). Selgitame näite varal, mis on hierarhia: linnad tellimuste alusel saab ühendada piirkondadeks, piirkondadeks piirkondadeks, riigi piirkondadeks, riigid mandriteks või muudeks üksusteks. Need. on hierarhiline struktuur – kontinent riik-piirkond-rajoon-linn- 5 taset ( Tase). Linnaosa kohta on andmed koondatud kõigi selles sisalduvate linnade kohta. Kõigi linnaosade piirkonna jaoks, mis sisaldab kõiki linnu jne. Miks me vajame mitut hierarhiat? Näiteks võiksime tellimuse kuupäeva teljel punktid (st päevad) hierarhiasse rühmitada. Aasta-kuu-päev või poolt Aasta-nädal-päev: mõlemal juhul kolm taset. Ilmselgelt rühmitavad nädala ja kuu päevad erinevalt. Samuti on olemas hierarhiad, mille tasemete arv ei ole deterministlik ja sõltub andmetest. Näiteks arvutikettal olevad kaustad.

Andmete koondamine võib toimuda mitme standardfunktsiooni abil: summa, miinimum, maksimum, keskmine, arv.

MDX

Vaatleme seda üksikasjalikult, kuna see on ainus keel, mis on saanud standardi staatuse üldise XMLA protokolli standardi raames, ja teiseks, kuna ettevõtte Mondriani projekti näol on olemas selle avatud lähtekoodiga rakendus. Pentaho. Teised OLAP-i analüüsisüsteemid (näiteks Oracle OLAP Option) kasutavad tavaliselt oma SQL-i süntaksilaiendeid, kuid deklareerivad ka MDX-i toetust.

Analüütiliste andmemassiividega töötamine eeldab ainult nende lugemist, mitte kirjutamist. See. MDX keeles pole andmete muutmise klausleid, vaid on ainult üks valikuklausel - select.

OLAP-is saate teha mitmemõõtmelistest kuubikutest viilud– st. kui andmeid filtreeritakse mööda ühte või mitut telge või prognoosid- kui kuup "variseb" mööda ühte või mitut telge, koondab andmed. Näiteks meie esimene näide riikide tellimuste summaga - seal on kuubiku projektsioon Riigi teljel. Selle juhtumi MDX-päring näeks välja järgmine:

Valige ...Lapsed ridadel alates
Mis siin on?

Valige– märksõna ja süntaks on lisatud ainult ilu pärast.
on telje nimi. Kõik MDX-i pärisnimed kirjutatakse nurksulgudesse.
on hierarhia nimi. Meie puhul on selleks maa-linn hierarhia.
on hierarhia esimesel tasemel oleva teljeliikme nimi (st riik) All on metaliige, mis ühendab kõik telje liikmed. Igal teljel on selline metaliige. Näiteks aastate teljel on “Kõik aastad” jne.
Lapsed on liikme funktsioon. Igal liikmel on mitu saadaolevat funktsiooni. nagu vanem. Tase, Hierarhia, tagastades vastavalt esivanema, taseme hierarhias ja hierarhia enda, kuhu liige antud juhul kuulub. Lapsed – tagastab selle liikme alamliikmete komplekti. Need. meie puhul riigid.
ridadel– Määrab, kuidas neid andmeid koondtabelis korraldada. Sel juhul rea päises. Siin on võimalikud väärtused: veergudel, lehtedel, lõikudel jne. Samuti on võimalik määrata lihtsalt indeksite järgi, alates 0-st.
alates on märge kuubi kohta, millest valik tehakse.

Mis siis, kui meil pole vaja kõiki riike, vaid ainult paari konkreetset? Selleks saate taotluses selgesõnaliselt märkida riigid, mida me vajame, ja mitte kõiki funktsiooniga Lapsed valida.

Valige ( ..., ... ) ridadelt alates
Sel juhul on lokkis sulgudeks määratud deklaratsioon ( seatud). Komplekt on nimekiri, liikmete loend ühelt teljelt.

Nüüd kirjutame päringu meie teise näite jaoks - väljund edastaja kontekstis:

Valige ...Lapsed ridadel .Liikmed veergudel alates
Lisatud siia:
- telg;
.Liikmed on teljefunktsioon, mis tagastab kõik sellel olevad liikmed. Sama funktsioon on saadaval hierarhia ja taseme jaoks. Sest sellel teljel on ainult üks hierarhia, siis võib selle näitamise ära jätta, sest tase ja hierarhia on samuti samad, siis saate kuvada kõik liikmed ühes loendis.

Ma arvan, et on juba ilmne, kuidas saame jätkata seda oma kolmanda näitega, esitades üksikasjalikud andmed aastate kaupa. Aga ärme parem aasta lõikes detailiseeri, vaid filtreerime – st. lõiku ehitama. Selleks kirjutage järgmine päring:

Valige ..Lapsed ridadel .Liikmed veergudel, kust (.)
Kus on filtreerimine?

kus- märksõna
on üks hierarhia liige . Täisnimi, sealhulgas kõik terminid, oleks: .. , aga sest selle liikme nimi on telje piires ainulaadne, siis võib kõik vahepealsed nimetähed ära jätta.

Miks on kuupäeva liige sulgudes? Sulud on korteež ( mitmekordne). Korteel on üks või mitu koordinaati mitmesugused teljed. Näiteks kahe telje korraga filtreerimiseks sulgudes loetleme kaks terminit alates erinev komadega eraldatud mõõdud. See tähendab, et korteež määratleb kuubi "lõigu" (või "filtreerimise", kui selline terminoloogia on lähemal).

Korpust kasutatakse enamaks kui lihtsalt filtreerimiseks. Kordad võivad olla ka rea/veeru/lehe päistes jne.

See on vajalik näiteks kolmemõõtmelise päringu tulemuse kuvamiseks kahemõõtmelises tabelis.

Valige ridadel ristliitmine (...lapsed, ..lapsed) .liikmed veergudel, kust (.)
Ristühendus on funktsioon. Tagastab korteežikomplekti (jah, hulk võib sisaldada kortereid!), mis tuleneb kahe hulga Descartes'i korrutisest. Need. tulemuste komplekt sisaldab kõiki võimalikke riikide ja aastate kombinatsioone. Rea päised sisaldavad seega paari väärtust: Riigi aasta.

Küsimus on selles, et kus on märge selle kohta, milliseid arvulisi karakteristikuid tuleks kuvada? Sel juhul kasutatakse selle kuubi jaoks määratud vaikemõõtu, s.o. Tellimuse hind. Kui tahame kuvada mõnd teist mõõtu, siis peame meeles, et mõõdud on dimensiooni liikmed Meetmed. Ja me käitume samamoodi nagu ülejäänud telgedega. Need. päringu filtreerimisel ühe mõõdiku järgi kuvatakse lahtrites täpselt see mõõt.

Küsimus: kuidas erineb sisse filtreerimine filtreerimisest, mis määrab telgede liikmed ridadel. Vastus: praktiliselt mitte midagi. See on lihtsalt see, kus viil on näidatud nende telgede jaoks, mis ei osale pealkirjade moodustamises. Need. sama telg ei saa samal ajal kohal olla ridadel, ja sisse kus.

Arvutatud liikmed

Koos liikmega. kui '.CurrentMember / ..', FORMAT_STRING='0,00%' valige ...Lapsed ridadel, kust .
Arvutamine toimub lahtri kontekstis, mille kõik koordinaatide atribuudid on teada. Vastavad koordinaadid (liikmed) saab iga kuubi telje jaoks saada funktsiooni CurrentMember abil. Siin tuleb mõista, et väljend .Praegune liige / ..' ei jaga üht terminit teisega, vaid jagab asjakohased koondandmed kuubiku viilud! Need. praeguse territooriumi viil jagatakse kõigi territooriumide viiludeks, st. kõigi tellimuste koguväärtus. FORMAT_STRING – määrab väärtuste väljastamise vormingu, st. %.

Veel üks näide arvutuslikust liikmest, kuid juba aastate teljel:

Koos liikmega. nagu'. - .'
On ilmne, et aruandes ei tule mitte ühik, vaid vastavate viilude erinevus, s.o. tellimuste hulga erinevus nende kahe aasta jooksul.

Kuva ROLAPis

Navigeerimine

Puurida- see on aruande täpsustamine, vähendades andmete koondamise astet, koos filtreerimisega mööda mõnda teist telge (või mitut telge). Puurimist on mitut tüüpi:

• puurimine– filtreerimine ühe aruande algse telje järgi koos üksikasjaliku teabe väljundiga valitud filtreerimisliikme hierarhias olevate järeltulijate kohta. Näiteks kui on tellimuste jaotuse aruanne riikide ja aastate lõikes, siis 2007. aastale klikkides kuvatakse aruanne samade 2007. aasta riikide ja kuude kontekstis.
• puurida kõrvale– filtreerimine ühe või mitme valitud telje all ja koondamise eemaldamine mööda ühte või mitut muud telge. Näiteks kui on olemas aruanne tellimuste jaotuse kohta riikide ja aastate lõikes, siis 2007. aastal klikkides kuvatakse veel üks aruanne näiteks 2007. aasta järgi filtreeritud Riigid ja tarnijad kontekstis.
• läbi puurida– agregatsiooni eemaldamine kõigil telgedel ja samaaegne filtreerimine nendel – võimaldab näha faktitabelist algandmeid, millest saadi aruandes olev väärtus. Need. kui klõpsate lahtri väärtusel, kuvatakse aruanne kõigi tellimustega, mis selle summa andsid. Omamoodi kohene puurimine kuubiku päris "sisikonda".

Sildid: lisa sildid

Avaleht Tingimused Artiklid Kursused Ettevõtete kogemused Blogi Nõuanded Allalaadimine Partneritele Kontaktid Pakkumised

Artiklid > Eelarvestamise ja juhtimisarvestuse automatiseerimine >

Aleksandr Karpov, projekti bud-tech.ru juht, raamatusarja "100% praktiline eelarvestamine" ja raamatu "Juhtimisarvestuse seadistamine ja automatiseerimine" autor

www.budtech.ru

Võib-olla tundub mõne jaoks OLAP-tehnoloogia (On-line Analytic Processing) kasutamine aruandluse koostamisel mingi eksootiline, nii et OLAP-CUBE kasutamine nende jaoks ei ole eelarve koostamise ja juhtimisarvestuse automatiseerimise üks olulisemaid nõudeid.

Tegelikult on juhtimisaruandlusega töötamisel väga mugav kasutada mitmemõõtmelist KUUBIT. Eelarvevormingute väljatöötamisel võib kokku puutuda mitme muutujaga vormide probleemiga (sellest leiab lähemalt 8. raamatust "Eelarve koostamise tehnoloogia ettevõttes" ja raamatust "Juhtimisarvestuse seadistamine ja automatiseerimine").

Selle põhjuseks on asjaolu, et ettevõtte efektiivne juhtimine nõuab järjest detailsemat juhtimisaruandlust. See tähendab, et süsteem kasutab üha rohkem erinevaid analüütilisi sektsioone (infosüsteemides määrab analüütika kataloogide komplekti).

Loomulikult viib see selleni, et juhid soovivad saada aruandeid kõigis neid huvitavates analüütilistes osades. Ja see tähendab, et aruanded tuleb kuidagi "hingama" sundida. Ehk siis võib öelda, et antud juhul räägime sellest, et tähenduse poolest peaks sama aruanne andma infot erinevates analüütilistes osades. Seetõttu ei sobi staatilised aruanded enam paljudele kaasaegsetele juhtidele. Nad vajavad dünaamikat, mida mitmemõõtmeline KUUBIK suudab pakkuda.

Seega on OLAP-tehnoloogiast saanud tänapäevaste ja paljutõotavate infosüsteemide asendamatu element. Seetõttu peate tarkvaratoote valimisel pöörama tähelepanu sellele, kas see kasutab OLAP-tehnoloogiat.

Ja peate suutma eristada tõelisi KUUBID imitatsioonidest. MS Exceli pivot-tabelid on üks selline imitatsioon. Jah, see tööriist näeb välja nagu CUBE, kuid tegelikult pole see nii, kuna need on staatilised, mitte dünaamilised tabelid. Lisaks on neil hierarhiliste kataloogide elemente kasutavate aruannete koostamise võimalus palju halvem.

Et kinnitada CUBE kasutamise asjakohasust ehitamisel juhtkonna aruandlus Lihtsaim näide on müügieelarve. Selles näites on ettevõtte jaoks asjakohased järgmised analüütilised lõigud: tooted, filiaalid ja turustuskanalid. Kui need kolm analüütikat on ettevõtte jaoks olulised, siis müügieelarvet (või aruannet) saab kuvada mitmel viisil.

Tuleb märkida, et kui loote eelarveread kolme analüütilise lõigu põhjal (nagu vaadeldavas näites), võimaldab see KUB-i abil luua üsna keerukaid eelarvemudeleid ja koostada üksikasjalikke aruandeid.

Näiteks müügieelarvet saab koostada kasutades ainult ühte analüütikat (teatmeraamatut). Näide müügieelarvest, mis põhineb üksikul "Tooted" analüüsil, on näidatud Joonis 1.

Riis. 1. Näide müügieelarvest, mis on üles ehitatud ühe analüütika "Tooted" alusel tarkvarapaketi OLAP-CUBE'is.

Sama müügieelarve saab koostada kasutades kahte analüütikat (teatmeraamatut). Näide müügieelarvest, mis on üles ehitatud kahe analüütika "Tooted" ja "Sidusettevõtted" põhjal, on esitatud joonis 2.

Riis. 2. Näide müügieelarvest, mis on üles ehitatud kahe analüütika "Tooted" ja "Sidusettevõtted" alusel tarkvarapaketi OLAP-CUBE'is.

.

Kui tekib vajadus koostada detailsemaid aruandeid, siis saab sama müügieelarve koostada kolme analüütika (teatmikud) abil. Näide kolme analüütika "Tooted", "Sidusettevõtted" ja "Turustuskanalid" põhjal üles ehitatud müügieelarvest on toodud aastal. joonis 3.

Riis. 3. Näide müügieelarvest, mis on üles ehitatud kolme analüütika "Tooted", "Osad" ja "Turustuskanalid" alusel tarkvarapaketi OLAP-CUBE'is.

Tuleb meeles pidada, et aruannete koostamiseks kasutatav KUB võimaldab kuvada andmeid erinevas järjestuses. Peal joonis 3 müügieelarve "kasutatakse" esmalt toote, seejärel haru ja seejärel turustuskanali järgi.

Samu andmeid saab esitada erinevas järjestuses. Peal joonis 4 sama müügieelarve "rullitakse välja" esmalt toodete, seejärel turustuskanalite ja seejärel harude kaupa.

Riis. 4. Näide müügieelarvest, mis on üles ehitatud kolme analüütika "Tooted", "Turustuskanalid" ja "Sidusettevõtted" alusel tarkvarapaketi OLAP-CUBE'is.

Peal joonis 5 sama müügieelarve "rullitakse välja" esmalt harude, seejärel toodete ja seejärel turustuskanalite kaupa.

Riis. 5. Näide müügieelarvest, mis on üles ehitatud kolme analüütika "filiaalid", "tooted" ja "levituskanalid" alusel tarkvarakompleksi OLAP-CUBE'is.

Tegelikult pole need kõik võimalikud võimalused müügieelarve tuletamiseks.

Lisaks peate pöörama tähelepanu asjaolule, et KUB võimaldab teil töötada kataloogide hierarhilise struktuuriga. Esitatud näidetes on hierarhilised kataloogid "Tooted" ja "Turustuskanalid".

Kasutaja seisukohast on ta see näide saab mitu juhtimisaruannet (vt Riis. 1-5), kuid tarkvaratoote sätete seisukohalt on see üks aruanne. Lihtsalt CUBE abil saab seda vaadata mitmel viisil.

Loomulikult on praktikas võimalik väga suur hulk väljundvõimalusi erinevate juhtimisaruannete jaoks, kui nende artiklid põhinevad ühel või mitmel analüütikul. Ja analüüsikomplekt ise sõltub kasutajate vajadustest detailide osas. Tõsi, ei tasu unustada, et ühest küljest, mida rohkem analüütikuid, seda detailsemaid aruandeid saab koostada. Kuid teisest küljest tähendab see, et eelarve koostamise finantsmudel muutub keerulisemaks. Igal juhul on KUB olemasolul ettevõttel võimalik vaadata vajalikku aruandlust erinevates versioonides, vastavalt huvipakkuvatele analüütilistele osadele.

On vaja mainida veel mõnda OLAP-CUBE funktsiooni.

Mitmemõõtmelises hierarhilises OLAP-KUUBIS on mitu dimensiooni: rea tüüp, kuupäev, read, otsing 1, otsing 2 ja otsing 3 (vt joonis 1). Riis. 6). Loomulikult kuvatakse aruandes nii palju kataloogidega nuppe, kui on maksimaalset kataloogide arvu sisaldaval eelarvereal. Kui ühelgi eelarvereal pole ühte kataloogi, siis aruanne ei sisalda kataloogidega nuppe.

Riis. 6. INTEGRAL tarkvarapaketi OLAP-CUBE mõõtmised

Esialgu on OLAP-CUBE üles ehitatud kõikidele mõõtmetele. Vaikimisi paiknevad aruande algsel koostamisel mõõtmed täpselt nendes piirkondades, nagu näidatud joonis 6. See tähendab, et selline mõõde nagu "Kuupäev" asub vertikaalsete mõõtmete piirkonnas (mõõtmed veerualal), mõõtmed "Read", "Otsing 1", "Otsing 2" ja "Otsing 3" asuvad horisontaalmõõtmete piirkonnas (mõõtmed rea piirkonnas) ja dimensioon "Rea tüüp" on mõõtmete laiendamata piirkonnas (ja dimensiooni tüübi ala). Kui dimensioon asub viimases piirkonnas, siis aruande andmeid selle dimensiooni võrra ei "laiendata".

Kõiki neid mõõtmeid saab paigutada ükskõik millisesse kolmest piirkonnast. Pärast mõõtmiste edastamist koostatakse aruanne koheselt uue mõõtmiskonfiguratsiooni järgi. Näiteks saate kuupäeva ja stringe kataloogidega vahetada. Või võite ühe teatmeraamatu vertikaalsele mõõtmisalale üle kanda (vt joonis 1). Riis. 7). Teisisõnu saab OLAP-CUBE'is olevat aruannet "keerutada" ja valida aruande väljundi versiooni, mis on kasutajale kõige mugavam.

Riis. 7. Näide aruande ümberehitamisest pärast INTEGRAL tarkvarapaketi mõõtmiskonfiguratsiooni muutmist

Mõõtmiskonfiguratsiooni saab muuta kas KUB-i põhivormil või muudatuste kaardi redaktoris (vt. Riis. 8). Selles redaktoris saate ka mõõtmisi hiirega ühest piirkonnast teise lohistada. Lisaks saate samas piirkonnas mõõte vahetada.

Lisaks saate samal kujul konfigureerida mõningaid mõõteparameetreid. Iga dimensiooni jaoks saate kohandada kogusummade asukohta, elementide sortimisjärjekorda ja elementide nimesid (vt. Riis. 8). Samuti saate määrata, millist nime elemendid aruandes kuvada: lühendatult (Name) või täisnimega (FullName).

Riis. 8. Tarkvarakompleksi "INTEGRAL" mõõtmiste kaardi toimetaja

Mõõteparameetreid saab redigeerida otse igas neist (vt. Riis. 9). Selleks klõpsake mõõtmise nimetuse kõrval asuval nupul asuvat ikooni.

Riis. 9. Kataloogi redigeerimise näide 1 Tooted ja teenused tarkvarapaketis INTEGRAL

Selle redaktori abil saate valida elemendid, mida soovite aruandes kuvada. Vaikimisi kuvatakse aruandes kõik üksused, kuid vajadusel saab mõned üksused või kaustad välja jätta. Näiteks kui teil on vaja aruandes kuvada ainult üks tooterühm, siis tuleb dimensiooniredaktoris kõik ülejäänud märgid eemaldada. Pärast seda sisaldab aruanne ainult ühte tooterühma (vt joon. Riis. 10).

Selles redaktoris saate ka üksusi sortida. Lisaks saab elemente mitmel viisil ümber paigutada. Pärast sellist ümberrühmitamist koostatakse aruanne koheselt uuesti.

Riis. 10. Näide ainult ühe tooterühma (kausta) kuvamisest aruandes INTEGRAL tarkvarapaketis

Dimensiooniredaktoris saab kiiresti luua oma gruppe, lohistada sinna elemente kataloogidest jne. Vaikimisi luuakse automaatselt ainult rühm Muu, kuid saate luua ka teisi rühmi. Seega saab dimensiooniredaktorit kasutades seadistada, milliseid teatmeteoste elemente ja millises järjekorras aruandes kuvada.

Tuleb märkida, et kõiki selliseid ümberkorraldusi ei registreerita. See tähendab, et pärast aruande sulgemist või ümberarvutamist kuvatakse aruandes kõik kataloogid vastavalt konfigureeritud metoodikale.

Tegelikult oleks võinud kõik sellised muudatused teha algselt stringide seadistamisel.

Näiteks saab piirangute abil määrata ka, milliseid elemente või kataloogide rühmi aruandes kuvada ja milliseid mitte.

Märge: selle artikli teemat käsitletakse üksikasjalikumalt töötubades "Ettevõtte eelarve juhtimine" Ja "Juhtimisarvestuse seadistamine ja automatiseerimine" viis läbi selle artikli autor - Aleksander Karpov.

Kui kasutajal on peaaegu regulaarselt vaja kuvada aruandes ainult teatud elemendid või kataloogide kaustad, siis on parem aruanderidade loomisel sellised seadistused eelnevalt teha. Kui kasutajale on olulised erinevad viiteelementide kombinatsioonid aruannetes, siis metoodika seadistamisel piiranguid seada ei pea. Kõiki selliseid piiranguid saab dimensiooniredaktoriga kiiresti konfigureerida.

Üldine informatsioon

Microsoft Excel võimaldab luua PivotTable-liigendtabeli aruandeid, mis põhinevad võrguanalüütilise töötlemise (OLAP) lähteandmetel. Kui töötate PivotTable-liigendtabeli aruannetega, mis põhinevad OLAP-i lähteandmetel, ja aruannetega, mis põhinevad mitte-OLAP-i lähteandmetel, võite märgata erinevusi tööriista võimalustes ja käitumises. Selles artiklis käsitletakse mõningaid peamisi erinevusi OLAP-i lähteandmetel põhinevate PivotTable-liigendtabeli aruannete ja mitte-OLAP-i lähteandmetel põhinevate PivotTable-liigendtabeli aruannete vahel.

Hankige andmeid ja värskendage erinevusi

OLAP-i andmebaasid on korraldatud selleks, et hõlbustada suurte andmemahtude eraldamist ja analüüsimist. Enne kui Excel kuvab kokkuvõtlikud andmed PivotTable-liigendtabelis, teostab OLAP-server arvutused andmete kokkuvõtmiseks. Vajadusel tagastatakse Excelisse ainult vajalikud kokkuvõtlikud andmed.

Väliste mitte-OLAP-andmebaaside puhul tagastatakse kõik üksikud kirjed ja Excel teeb kokkuvõtte. Seetõttu annavad OLAP-i andmebaasid Excelile võimaluse analüüsida palju suuremaid välisandmeid.

OLAP-server saadab Excelisse uued andmed alati, kui PivotTable-liigendtabeli või PivotCharti aruande või vaate paigutus muutub. Mitte-OLAP-i lähteandmete kasutamisel värskendatakse andmeid erinevalt ja dialoogiboksis PivotTable-liigendtabeli suvandid on saadaval erinevad värskendussuvandid.

Mitte-OLAP-andmeid saab Microsoft Excelisse tagastada välise andmevahemiku või PivotTable-liigendtabeli aruande või PivotChartina. OLAP-i andmeid saab Excelisse tagastada ainult PivotTable-liigendtabeli aruande või PivotChartina.

Taustataotlus

Kui PivotTable-liigendtabeli aruanne põhineb OLAP-i andmeallikal, ei saa dialoogiboksis PivotTable-liigendtabeli suvandid taustapäringu suvandit lubada.

Taotlused parameetritega

OLAP-i andmeallikal põhinevad PivotTable-liigendtabeli aruanded ei toeta parameetritega päringuid.

Mälu optimeerimine

Kui PivotTable-liigendtabeli aruanne põhineb OLAP-i andmeallikal, pole dialoogiboksi PivotTable-liigendtabeli suvandid märkeruut Mälu optimeerimine saadaval.

Lehekülje veerise valikud

Mitte-OLAP-i lähteandmetel põhinevates PivotTable-liigendtabeli aruannetes saate kasutada lehe veerise suvandeid, et hankida andmeid iga üksuse kohta eraldi või kõigi üksuste kohta korraga. Need lehe veerise valikud pole OLAP-i lähteandmetel põhinevates aruannetes saadaval. OLAP-i lähteandmed hangitakse alati iga üksuse kohta vastavalt vajadusele, võimaldades aruannetel kuvada teavet suurtest OLAP-andmebaasidest.

Arvutamise erinevused

Lehekülje veerise valikud

Te ei saa muuta funktsiooni OLAP-i lähteandmete põhjal PivotTable-liigendtabeli aruande andmeväljade kokkuvõtmiseks. See piirang ilmneb seetõttu, et kogusummad arvutatakse OLAP-serveris. Lõplikud funktsioonid

OLAP-i andmeallika põhjal ei saa PivotTable-liigendtabelis arvutatud välja või arvutatud üksust luua.

Arvutatud väljad ja arvutatud liikmed

OLAP-i lähteandmetel põhinevas PivotTable-liigendtabeli aruandes vahesummadega töötamisel kehtivad järgmised piirangud.

PivotTable-liigendtabeli aruande vahesummade kogufunktsiooni ei saa muuta.

OLAP-CUBE (dünaamiline juhtimisaruandlus)

PivotTable-liigendtabeli aruande sisemiste või sisemiste veeruväljade vahesummasid ei saa kuvada.

Kuna kogusummad arvutatakse OLAP-serveris, ei saa te dialoogiboksis PivotTable-liigendtabeli suvandid suvandit Vahepealsed peidetud leheüksused muuta.

Vahesummad

Dialoogiboksi PivotTable-i suvandid suvandit Märgista kogusumma * saab kasutada ainult OLAP-i lähteandmetel põhinevates PivotTable-liigendtabeli aruannetes. See valik tähistab kõik vahesummad ja lõppsummad tärniga (*), mis näitab, et need väärtused sisaldavad nii peidetud kui ka kuvatavaid üksusi.

Paigutus ja kujunduse erinevused

Mõõdud ja mõõdud

OLAP-i lähteandmetel põhineva PivotTable-liigendtabeli aruandega töötamisel saab dimensiooni kasutada ainult rea, veeru või leheväljana. Mõõtmeid saab kasutada ainult andmeväljadena. Kui lohistate dimensiooni välja andmealale või dimensiooni rea, veeru või lehe veerise alale, kuvatakse järgmine tõrketeade.

Teisaldatavat välja ei saa sellesse PivotTable-liigendtabeli alasse paigutada.

Kui OLAP-i lähteandmetel põhinev PivotTable-liigendtabeli aruanne on aktiivne, kuvab PivotTable-liigendtabeli tööriistariba iga väljarea kõrval ikooni. Ikoon näitab, kuhu Excel võimaldab teil PivotTable-liigendtabeli aruandes välja paigutada. Kui ikoon asub vasakus ülanurgas, on väli dimensioon, mille saab lohistada rea, veeru või ala leheväljale. Kui ikoon on paremas alanurgas, on väljal mõõdud, mida saab lohistada andmeväljade alale.

Mõõdud ja mõõdud

Microsoft Excel võimaldab teil PivotTable-liigendtabelisse lisatud välju ümber nimetada. Kui PivotTable-liigendtabeli aruanne põhineb OLAP-i lähteandmetel, kaob teie kohandatud nimi, kui väli PivotTable-liigendtabelist eemaldatakse.

Elementide rühmitamine ja lahti rühmitamine

Excel 2000-s ei saa te OLAP-i lähteandmetel põhinevas PivotTable-liigendtabeli aruandes üksusi rühmitada.

Väljade ümbernimetamine

OLAP-i lähteandmetel põhinevad PivotTable-liigendtabeli aruanded kuvavad OLAP-serveris saadaolevate andmete madalaima taseme.

Elementide rühmitamine ja lahti rühmitamine

Mitte-OLAP-i lähteandmete puhul kuvatakse uue PivotTable-liigendtabeli aruande üksused esmalt üksuse nime järgi kasvavas järjekorras.

Üksikasjad

Käsk Kuva leheküljed pole OLAP-i lähteandmetel põhinevates PivotTable-liigendtabeli aruannetes saadaval.

Kuva üksused ilma andmeteta

Dialoogiboksi PivotTable-liigendtabeli väli suvand Kuva üksused ilma andmeteta pole saadaval OLAP-i lähteandmetel põhinevates PivotTable-liigendtabeli aruannetes.

Allpool on nimekiri küsimustest infotehnoloogia teemal MFPU / MFPA "Synergy" haldamisel

… on interaktiivne automatiseeritud süsteem, mis aitab…

OLAP-i selle sõna kitsas tähenduses tõlgendatakse kui ...

OLAP-süsteemid (online analüütiline töötlemine) on...

OLTP-süsteemidest oli vähe kasu, sest ...

Automatiseeritud juhtimissüsteem (automaatne teave…

MS projektis...

OLTP-süsteemis toimuvad andmete värskendused ...

Diagramm, mille eesmärk on analüüsida tööplaani kasutades meetodit ...

Infosüsteem on omavahel ühendatud elementide kogum ...

Infotehnoloogia on...

Infoturve on...

Infotehnoloogiat ühiskonna arengut mõjutavad järgmised umbes ...

Teabevahetus organisatsiooni juhtorganite struktuuris ...

Juhtide infosüsteemid (Executive Information Sys…

"Väikeste" infosüsteemide tunnused hõlmavad ...

"Keskmise" mastaabiga infosüsteemide tunnused hõlmavad ...

Infotöötlusmeetodid on...

Raamatupidamise infosüsteemide ehitamise modulaarne põhimõte ...

Joonisel on fragment ... tüüpi diagrammist, mis on tehtud pro ...

MS Projecti võrguskeemil on välise projekti ülesanne…

MS Projecti võrguskeemil on ülesanne, mis ei ole seotud ...

MS Projecti võrguskeemil on ülesanne, mis on ...

Võrguskeemil MS Projectis kokkuvõtlik ülesanne, kombineeritud

Automatiseeritud tööde koosseis ja arv hõlmas ...

Teadus infotegevusest, infoprotsessidest ja ...

Infosüsteemi korraldamine, milles kaugserveris ...

OLAP-süsteemi peamine eesmärk on...

ERP-süsteemide põhieesmärk on automatiseerida...

MPS-i metoodika põhieesmärk on…

OLAP-süsteemide peamised omadused on ...

Tehnilise toe alamsüsteem sisaldab ...

Tehnoloogiliste etappide jada esmase ...

Personaalarvutite võrku ühendamisel intrapro vormis…

Rakendatud tarkvara Arvuti on loodud...

Ainete infotehnoloogia näide on tehnoloogia ...

Otsuste toetamise protsess hõlmab…

Enterprise-Scale Network või Corporate Network on teave…

Tehisintellekti süsteem on…

Tehingute töötlemise süsteemid on süsteemid, mis on loodud…

Tehingute töötlemise süsteemid vastavad…

Otsuste tugisüsteemid (DS…

Kaasaegsed meetodid ja tööriistad protsesside analüüsimiseks ja planeerimiseks…

Integreeritud automatiseeritud infosüsteemide loomine…

Loodud infosüsteemid muutuvad kasutuskõlbmatuks ...

Juhtimistoetuste infosüsteemi eripära avaldub ...

Traditsiooniliste OLTP-süsteemide abil saate ...

Ettevõtte infosüsteemide struktuur on ...

Et kiirendada ja lihtsustada personalijuhtide tööd ettevõttes..

Personalijuhtide töö kiirendamiseks ja lihtsustamiseks ettevõttes helista…

Meid ümbritseva maailma fikseeritud tajutavad faktid esindavad ...

Toimingute ahel, mis peegeldab kõige täpsemalt…

Dialoogirežiimis lahendatud majandusülesanded iseloomustavad ...

Ekspertsüsteemid on loodud töötlema...

Kas rikub turvalisust või on turvaalas…

OLAP on lihtne

Hämmastav lähedal...

Töö käigus tuli sageli koostada keerulisi aruandeid, kogu aeg püüdsin leida neis midagi ühist, et muuta need lihtsamaks ja universaalsemaks, kirjutasin ja avaldasin sel teemal isegi artikli “Osipovi puu”. Kuid nad kritiseerisid minu artiklit ja ütlesid, et kõik minu tõstatatud probleemid on OLAP-is (www.molap.rgtu.ru) juba ammu lahendatud ja soovitasid vaadata EXCELi pivot-tabeleid.
See osutus nii lihtsaks, et rakendades oma geniaalseid käsi, sain väga lihtsa skeemi andmete üleslaadimiseks 1C7 või mõnest muust andmebaasist (edaspidi tähendab 1C mis tahes andmebaasi) ja analüüsi OLAP-is.
Arvan, et paljud OLAP-i üleslaadimisskeemid on liiga keerulised, valin lihtsuse.

Omadused :

1. Töötamiseks on vaja ainult EXCEL 2000.
2. Kasutaja saab ise koostada aruandeid ilma programmeerimata.
3. Üleslaadimine 1C7-st lihtsas tekstifailivormingus.
4. Sest raamatupidamiskanded mahalaadimiseks on juba olemas universaalne töötlemine, mis töötab mis tahes konfiguratsioonis. Muude andmete mahalaadimiseks on näidistöötlus.
5. Saate aruandevormid eelnevalt kujundada ja seejärel rakendada neid erinevatele andmetele ilma neid ümber kujundamata.
6. Päris hea esitus. Esimesel pikemal etapil imporditakse esmalt tekstifailist andmed EXCELi ja ehitatakse OLAP-kuubik ning seejärel saab selle kuubi põhjal üsna kiiresti valmis mistahes aruande. Näiteks 3 kuu kaupade müügi andmed kaupluses, mille sortiment on 6000 kaupa, laaditakse EXCELi Cel600-128M 8 minutiga, hinnang kaupade ja gruppide kaupa (OLAP aruanne) arvutatakse ümber 1 minutiga.
7. Andmed laaditakse 1C7-st täielikult alla määratud perioodi kohta (kõik liikumised, kõigi ladude, ettevõtete, kontode kohta). EXCELi importimisel on võimalik kasutada filtreid, mis laadivad ainult analüüsiks vajalikud andmed (näiteks kõikidest liikumistest, ainult müügist).
8. Praegu on välja töötatud meetodid liikumiste või jääkide analüüsimiseks, kuid mitte liigutuste ja jääkide koos analüüsimiseks, kuigi see on põhimõtteliselt võimalik.

Mis on OLAP : (www.molap.rgtu.ru)

Oletame, et teil on kauplemisvõrk. Laske kauplemistoimingute andmed üles laadida tekstifaili või tabelisse kujul:

Kuupäev – toimimise kuupäev
Kuu - tegevuskuu
Nädal - töönädal
Tüüp - ost, müük, tagastamine, mahakandmine
Vastaspool – operatsioonis osalev väline organisatsioon
Autor – arve väljastanud isik

Näiteks 1C-s vastab selle tabeli üks rida ühele arve reale, mõned väljad (Töövõtja, Kuupäev) võetakse arve päisest.

Analüüsimiseks mõeldud andmed laetakse OLAP-süsteemi tavaliselt üles teatud perioodiks, millest saab laadimisfiltreid kasutades põhimõtteliselt eristada teist perioodi.

See tabel on OLAP-analüüsi allikas.

Kasutaja määrab ise, millised tabeli väljad on Dimensioonid, milliseid andmeid ja milliseid filtreid rakendada. Süsteem ise koostab aruande visuaalse tabeli kujul. Mõõtmed saab paigutada aruandetabeli rea- või veerupealkirjadesse.
Nagu näete, saate ühest lihtsast tabelist saada palju andmeid erinevate aruannete kujul.

Kuidas iseseisvalt kasutada :

Pakkige andmed jaotuspaketist lahti täpselt c:\fixin kataloogi (kauplemissüsteemi jaoks on võimalik c:\reports). Lugege faili readme.txt ja järgige kõiki selles sisalduvaid juhiseid.

Kõigepealt peate kirjutama töötluse, mis laadib andmed 1C-st tekstifaili (tabelisse). Peate määratlema üleslaaditavate väljade koostise.
Näiteks valmis universaalne töötlemine, mis töötab mis tahes konfiguratsioonis ja laadib OLAP-analüüsi jaoks teatud perioodiks postitused maha, laadib analüüsi jaoks välja järgmised väljad:

Kuupäev|Nädalapäev|Nädal|Aasta|Kvartal|Kuu|Dokument|Ettevõte|Deebet|Dt-nomenklatuur
|DtGroupNomenclature|DtSectionNomenclature|Credit|Summa|Valusumma|Kogus
|Valuuta|DtTöövõtjad|DtGroupContractors|KtContractors|KtGroupContractors|
CTMiscellaneousObjects

Kui eesliidete Dt (Kt) all on deebet (kreedit) alamkontsid, on rühm selle alamkonto rühm (kui see on olemas), jaotis on rühma rühm, klass on jaotise rühm.

Kauplemissüsteemi puhul võivad väljad olla järgmised:

Suund|Liikumise liik|Raha eest|Toode|Kogus|Hind|Summa|Kuupäev|Ettevõte
|Ladu|Valuuta|Dokument|Nädalpäev|Nädal|Aasta|Kvartal|Kuu|Autor
|Tootekategooria|Liikumise kategooria|Osapoole kategooria|Tooterühm
|ValAmount|Oma hind|Töövõtja

Andmete analüüsiks kasutatakse tabeleid "Liikumiste analüüs.xls" ("Arvepidamise analüüs.xls"). Nende avamisel ärge blokeerige makrosid, vastasel juhul ei saa te aruandeid värskendada (need käivitavad makrod VBA keeles). Need failid võtavad algandmed failist C:\fixin\motions.txt (C:\fixin\buh.txt), muidu on need samad.

OLAP-i põhitõed

Seetõttu peate võib-olla kopeerima oma andmed ühte neist failidest.
Andmete EXCELi laadimiseks valige või kirjutage oma filter ja klõpsake lehel "Tingimused" nuppu "Genereeri".
Aruandelehed algavad eesliitega "Alates". Minge aruandelehele, klõpsake nuppu "Värskenda" ja aruande andmed muutuvad vastavalt viimastele laaditud andmetele.
Kui te pole standardaruannetega rahul, on olemas leht OtchTemplate. Kopeerige see uuele lehele ja kohandage aruandevaadet, töötades sellel lehel pivot-tabeliga (lisateavet pivot-tabelitega töötamise kohta leiate mis tahes EXEL 2000 raamatust). Soovitan seadistada aruanded väikese andmehulga jaoks ja seejärel käivitada need suures massiivis, kuna ei ole võimalik keelata tabeli ümberjoonistamist iga kord, kui aruande kujundus muutub.

Tehnilised märkused :

Andmete üleslaadimisel 1C-st valib kasutaja kausta, kuhu fail üles laadida. Tegin seda seetõttu, et tõenäoliselt laetakse lähiajal üles mitu faili (jäänused ja liikumised). Seejärel, vajutades Exploreris nuppu "Saada" —> "OLAP-analüüsiks EXCEL 2000-s", kopeeritakse andmed valitud kaustast kausta C:\fixin. (et see käsk ilmuks käsu "Saada" loendisse, tuleb kopeerida fail "For OLAP analysis in EXCEL 2000.bat" kataloogi C:\Windows\SendTo) Seetõttu laadige motions.txt või buh.txt failidele nimed andvad andmed kohe üles.

Tekstifaili formaat:
Tekstifaili esimene rida sisaldab veergude pealkirju, mis on eraldatud tähega "|", ülejäänud read sisaldavad nende veergude väärtusi, eraldatuna tähega "|".

Tekstifailide importimiseks Excelisse kasutatakse Microsoft Queryt (EXCEL-i osa), mille toimimiseks peab impordikataloogis (C:\fixin) olema fail shema.ini, mis sisaldab järgmist teavet:

ColNameHeader=Tõsi
Formaat=piiratud(|)
MaxScanRows=3
CharacterSet=ANSI
ColNameHeader=Tõsi
Formaat=piiratud(|)
MaxScanRows=3
CharacterSet=ANSI

Selgitus: motions.txt ja buh.txt on jaotise nimi, vastab imporditud faili nimele, kirjeldab tekstifaili importimist Excelisse. Ülejäänud parameetrid tähendavad, et esimene rida sisaldab veergude nimesid, veeru eraldaja on "|", märgistik on Windows ANSI (DOS-i jaoks - OEM).
Välja tüüp määratakse automaatselt, tuginedes veerus sisalduvatele andmetele (kuupäev, number, string).
Väljade loendit ei pea kuskil kirjeldama – EXCEL ja OLAP määravad ise, millised väljad failis sisalduvad esimesel real olevate päiste järgi.

Tähelepanu, kontrollige oma piirkondlikke seadeid "Juhtpaneel" -> "Piirkondlikud seaded". Minu töötlemisel laaditakse numbrid üles komaeraldajaga ja kuupäevad on vormingus "DD.MM.YYYY".

Kui klõpsate nuppu "Genereeri", laaditakse andmed lehe "Base" liigendtabelisse ja kõik lehtedel "Tagastus" olevad aruanded võtavad andmeid sellelt liigendtabelist.

Ma saan aru, et MS SQL Serveri ja võimsate andmebaaside austajad nurisevad, et minu jaoks on kõik liiga lihtsustatud, et minu töötlemine kõverdub iga-aastase näidise peale, kuid ennekõike tahan anda OLAP-analüüsi eelised keskmise suurusega organisatsioonidele. Positsioneeriksin selle toote hulgimüüjate iga-aastase analüüsivahendina, jaemüüjate kvartalianalüüsina ja mis tahes organisatsiooni tegevusanalüüsina.

Pidin VBA-ga nokitsema, et andmed võetaks mingist suvaliste väljade nimekirjaga failist ja oleks võimalik ette valmistada aruandevormid.

Töö kirjeldus EXCELIS (kasutajatele):

Juhised aruannete kasutamiseks:
1. Saatke allalaaditud andmed analüüsiks (kontrollige administraatorilt). Selleks paremklõpsake kaustal, kuhu olete 1C-st andmed üles laadinud, ja valige käsk "Esita", seejärel "OLAP-analüüsile EXCEL 2000-s".
2. Avage fail "Motion Analysis.xls".
3. Valige Filtri väärtus, vajalikud filtrid saate lisada vahekaardile "Väärtused".
4. Klõpsake nuppu "Genereeri" ja allalaaditud andmed laaditakse EXCELi.
5. Pärast andmete laadimist EXCELi saate vaadata erinevaid aruandeid. Selleks klõpsake lihtsalt valitud aruandes nuppu "Värskenda". Aruandelehed algavad sõnaga Rep.
Tähelepanu! Pärast filtri väärtuse muutmist peate uuesti klõpsama nuppu "Loo", et EXCELIS olevad andmed laaditaks üleslaaditavast failist uuesti vastavalt filtritele.

Töötlemine demost:

motionsbuh2011.ert töötlemine - Uusim versioon tehingute mahalaadimine raamatupidamisest 7.7 analüüsimiseks Excelis. Sellel on märkeruut "Lisa failile", mis võimaldab teil üles laadida andmeid osade kaupa perioodide kaupa, manustades need samale failile ja mitte uuesti samasse faili üles laadida:

Töötlemine motionswork.ert laadib müügiandmed Excelis analüüsimiseks üles.

Esitage näiteid :

Male postitamisega:

Operaatorite töökoormus arvetüüpide lõikes:

P.S. :

On selge, et sarnase skeemi järgi saate korraldada andmete mahalaadimist 1C8-st.
2011. aastal võttis minuga ühendust kasutaja, kellel oli vaja see töötlemine 1C7-s lõpule viia, et see saaks üles laadida suuri andmemahtusid, leidsin allhanke tellija ja tegin selle töö ära. Seega on areng üsna asjakohane.

Motionsbuh2011.ert töötlemist on täiustatud, et käsitleda suuri andmete üleslaadimisi.

Esimene selge määratlus OLAP(On-line Analytical Processing) pakkus 1993. aastal välja E.F. Codd artiklis, mis avaldati Arbor Software (praegu Hyperion Software) toel. Artikkel sisaldas 12 reeglit, mis on nüüdseks laialt tuntuks saanud ja mida kirjeldatakse mis tahes OLAP-i rakenduste tarnija veebisaidil. Hiljem, 1995. aastal, lisandus neile veel kuus vähemtuntud reeglit, kõik need jaotati nelja rühma ja nimetati "tunnusteks" (tunnusteks). Siin on reeglid, mis määratlevad OLAP-i rakenduse koos OLAP-i aruande saidi kaaslooja Nigel Pendse kommentaaridega.

OLAP-i põhifunktsioonid on järgmised:

1. Andmemudeli mitmemõõtmelisus. Vähesed vaidlevad selle väitega vastu ja seda peetakse OLAP-i peamiseks omaduseks. Üks osa sellest nõudest on võimalus ehitada mudelist erinevaid projektsioone ja sektsioone.

2. Intuitiivsed andmetega manipuleerimise mehhanismid. Codd usub, et andmetega manipuleerimine peaks toimuma otse tabelilahtris olevate toimingute kaudu, ilma menüüsid või keerukaid kasutamata. Võib eeldada, et see eeldab hiireoperatsioonide kasutamist, kuid Codd seda ei väida. Paljud tooted ei järgi seda reeglit. Meie seisukohast on sellel omadusel andmeanalüüsi protsessi kvaliteedile vähe mõju. Usume, et programm peaks pakkuma töömudeli valiku võimalust, sest kõigile kasutajatele ei meeldi sama asi.

3. Kättesaadavus. OLAP on vahendaja. Codd rõhutab konkreetselt, et OLAP-mootor on vahevara heterogeensete andmeallikate ja kasutajaliidese vahel. Enamik tooteid pakub neid funktsioone, kuid andmete juurdepääsetavus on sageli väiksem kui see, mida teised tarkvaramüüjad sooviksid.

4. Pakettandmete ekstraheerimine. See reegel nõuab, et tooted pakuksid nii oma andmebaase analüüsitud andmete salvestamiseks kui ka dünaamilist (reaalajas) juurdepääsu välistele andmetele. Oleme selles küsimuses Coddiga nõus ja kahetseme, et vähesed OLAP-tooted vastavad sellele. Isegi need programmid, mis selliseid funktsioone pakuvad, muudavad need harva piisavalt lihtsaks ja automatiseeritud. Selle tulemusel toetab Codd mitmemõõtmelist andmete esitust ja suurte mitmemõõtmeliste andmebaaside osalist eelarvutust koos läbipaistva ja täieliku juurdepääsuga üksikasjalikule teabele. Tänapäeval peetakse seda hübriid-OLAP-i määratluseks, mis on muutumas populaarseimaks arhitektuuriks, nii et Codd nägi selle valdkonna peamisi suundumusi väga täpselt.

5. Klient-server arhitektuur. Codd usub, et mitte ainult ei peaks iga toode olema klient/server, vaid et iga OLAP-toote serverikomponent peaks olema piisavalt nutikas, et erinevaid kliente saaks ühendada minimaalse vaeva ja programmeerimisega. See on palju keerulisem test kui lihtne klient-server arhitektuur ja suhteliselt vähesed tooted läbivad selle. Võime väita, et see test on võib-olla keerulisem, kui see peaks olema, ja ei tasu süsteemiarhitektuuri arendajatele ette dikteerida.

6. Läbipaistvus. See test on samuti raske, kuid vajalik. Täielik vastavus tähendab, et näiteks arvutustabeli kasutajal on täielik juurdepääs OLAP-mootori pakutavatele võimalustele ja ta ei pruugi isegi teada, kust andmed pärinevad. Selle saavutamiseks peavad tooted pakkuma dünaamilist juurdepääsu heterogeensetele andmeallikatele ja täisfunktsionaalset arvutustabelimoodulit. OLAP-server asetatakse arvutustabeli ja andmelao vahele.

7. Mitme mängijaga töö. Codd määratleb, et OLAP-i strateegiliseks tööriistaks käsitlemiseks peavad rakendused olema enamat kui lihtsalt andmete lugemine ja tõlgendamine ning sellisena peavad nad pakkuma samaaegset juurdepääsu (sealhulgas andmete otsimist ja värskendamist), terviklikkust ja turvalisust.

Eriomadused

8. Denormaliseeritud andmete käsitlemine. See tähendab, et OLAP-mootori ja normaliseerimata andmeallika vaheline integreerimine on võimalik. Codd rõhutab, et OLAP keskkonnas teostatud andmete uuendamisel peaks olema võimalik välissüsteemides denormaliseeritud andmeid muuta.

9. OLAP-i tulemuste salvestamine algandmetest eraldi. Tegelikult on see seotud toote rakendamisega, mitte selle võimalustega, kuid vähesed vaidlevad selle väitega. Sisuliselt toetab Cobb laialdaselt tunnustatud süsteemi, mille kohaselt OLAP-i rakendused peaksid analüüsima otse tehinguandmetele ja OLAP-i andmete muudatusi tuleks hoida tehinguandmetest eraldi.

10. Tõstke esile puuduvad andmed. See tähendab, et puuduvad andmed peavad erinema nullist. Reeglina toetavad seda funktsiooni kõik kaasaegsed OLAP-süsteemid.

11. Puuduvate väärtuste käsitlemine. Kõiki puuduvaid väärtusi tuleks analüüsis ignoreerida, olenemata nende allikast.

Aruandluse omadused

12. Paindlik aruandlus. Erinevad mõõtmed peaksid vastavalt kasutaja vajadustele igal viisil sobima. Enamik tooteid vastavad sellele nõudele spetsiaalsete aruannete toimetajate raames. Soovin, et samad funktsioonid oleksid saadaval ka interaktiivsetes vaatajates, kuid see on palju harvem. See on üks põhjusi, miks eelistame analüüsi ja aruandluse funktsionaalsust ühendada ühes moodulis.

1. Olapi kuubi mõiste

13. Järjepidev aruandlusjõudlus. See tähendab, et süsteemi jõudlus aruannete koostamisel ei tohiks andmebaasi mõõtmete või suuruse suurenemisega oluliselt langeda.

14. Füüsilise kihi automaatne reguleerimine. OLAP-süsteem peab automaatselt kohandama füüsilist struktuuri, et kohandada seda mudeli tüübi ja struktuuriga.

Mõõtmete kontroll

15. Üldine funktsionaalsus. Kõigi mõõtmete struktuur ja funktsionaalsus peavad olema samad.

16. Piiramatud mõõtmed ja koondamistase. Tegelikult tähendab piiramatu arvu all Codd 15-20, s.o. arv, mis teadaolevalt ületab analüütiku maksimaalsed vajadused.

17. Piiramatu arv toiminguid erinevate mõõtmiste andmete vahel. Codd usub, et selleks, et rakendust saaks nimetada mitmemõõtmeliseks, peab see toetama kõiki arvutusi, mis kasutavad kõigi mõõtmete andmeid.

Üksikasjad Hyperioni toodete kohta - saidil www.hyperion.ru

trükiversioon

tagasi

10.8 Pivot-tabelitega töötamine (liigendtabeli objekt)

Excel.PivotTable-objekt, töötage programmiliselt Exceli PivotTable-liigendtabelite ja OLAP-kuubikutega, kasutades VBA-d, PivotCache-objekti, looge liigendtabeli paigutus

Enamiku ettevõtete tegevuse käigus koguneb tegevuste kohta nn algandmeid. Näiteks kaubandusettevõtte jaoks saab koguda andmeid kaupade müügi kohta - iga ostu kohta eraldi, mobiilsideettevõtete jaoks - tugijaamade koormuse statistikat jne. Väga sageli vajab ettevõtte juhtkond analüütilist teavet, mis genereeritakse toorteabe põhjal - näiteks selleks, et arvutada iga tooteliigi panus ettevõtte tuludesse või teenuse kvaliteeti antud jaama piirkonnas. Toorteabest on sellist teavet väga raske välja võtta: peate täitma väga keerulisi SQL päringuid, mis võtavad kaua aega ja segavad sageli käimasolevat tööd. Seetõttu keritakse praegu üha enam toorandmeid esmalt andmelaosse ja seejärel OLAP-kuubikutesse, mis on interaktiivseks analüüsiks väga mugavad. Lihtsaim viis OLAP-i kuubikutest mõelda on mitmemõõtmeliste tabelitena, milles standardsete kahe mõõtme (veerud ja read, nagu tavalistes tabelites) asemel võib olla palju mõõtmeid. Mõistet "sektsioon" kasutatakse tavaliselt kuubi mõõtmete kirjeldamiseks. Näiteks võib turundusosakond vajada teavet aja, piirkonna, tootetüübi, müügikanali jne järgi. Kuubikuid kasutades (erinevalt tavapärastest SQL-päringutest) on väga lihtne saada vastuseid küsimustele, nagu “kui palju seda tüüpi tooteid müüdi eelmise aasta neljandas kvartalis Loode regioonis piirkondlike edasimüüjate kaudu.

Loomulikult ei saa selliseid kuupe luua tavalistes andmebaasides. OLAP-kuubikud nõuavad spetsiaalseid tarkvaratooteid. SQL Serveriga on kaasas Microsofti OLAP-andmebaas nimega Analysis Services. OLAP-lahendusi on Oracle'ilt, IBMilt, Sybase'ilt jne.

Selliste kuubikutega töötamiseks on Excelisse sisse ehitatud spetsiaalne klient.

Vene keeles nimetatakse seda pöördetabel(graafilisel ekraanil on see saadaval menüü kaudu Andmed -> pöördetabel) ja inglise keeles - pöördetabel. Sellest lähtuvalt nimetatakse objekti, mida see klient esindab, PivotTable-liigendtabeliks. Tuleb märkida, et see võib töötada mitte ainult OLAP-i kuubikutega, vaid ka tavaliste andmetega Exceli tabelites või andmebaasides, kuid paljud funktsioonid lähevad kaotsi.

PivotTable ja PivotTable-objekt on Panorama Software tarkvaratooted, mille Microsoft on omandanud ja Excelisse integreeritud.

Seetõttu erineb PivotTable-liigendtabeli objektiga töötamine mõnevõrra teiste Exceli objektidega töötamisest. Sageli on raske välja mõelda, mida teha. Seetõttu on soovitatav makrosalvestit aktiivselt kasutada vihjete saamiseks. Samal ajal peavad kasutajad pivot-tabelitega töötades sageli tegema samu korduvaid toiminguid, mistõttu on automatiseerimine vajalik paljudes olukordades.

Kuidas näeb välja programmiline liigendtabeliga töötamine?

Esimene asi, mida peame tegema, on luua PivotCache'i objekt, mis esindab OLAP-i allikast hangitud kirjete komplekti. Väga tinglikult saab seda PivotCache'i objekti võrrelda QueryTable'iga. PivotTable-liigendtabeli objekti kohta saab kasutada ainult ühte PivotCache'i objekti. PivotCache'i objekt luuakse kogu PivotCaches meetodi Add() abil:

Dim PC1 PivotCache'ina

Määra PC1 = ActiveWorkbook.PivotCaches.Add(xlExternal)

PivotCaches on standardkogu ja üksikasjalikku kaalumist väärivatest meetoditest saab selles nimetada ainult meetodit Add(). See meetod hõlmab kahte parameetrit:

• Allika tüüp- nõutav, määrab pivot-tabeli andmeallika tüübi. Saate luua PivotTable-liigendtabeli, mis põhineb Exceli vahemikul, andmebaasi andmetel, välisel andmeallikal, teisel PivotTable-liigendtabelil jne. Praktikas on OLAP-i tavaliselt mõttekas kasutada ainult siis, kui andmeid on palju - vastavalt on vaja spetsiaalset välist salvestusruumi (näiteks Microsoft Analysis Services). Sellises olukorras valitakse xlExternal.
• SourceData- nõutav kõigil juhtudel, välja arvatud juhul, kui esimese parameetri väärtus on xlExternal. Rangelt võttes määratleb see andmevahemiku, mille alusel PivotTable-liigendtabel luuakse. Tavaliselt võtab see Range objekti.

Järgmine ülesanne on konfigureerida PivotCache objekti parameetrid. Nagu juba mainitud, on see objekt väga sarnane QueryTable'iga ning selle atribuutide ja meetodite komplekt on väga sarnane. Mõned kõige olulisemad omadused ja meetodid on järgmised:

• ADOühendus- võimalus tagastada ADO ühenduse objekt, mis luuakse automaatselt välise andmeallikaga ühenduse loomiseks. Kasutatakse ühenduse omaduste edasiseks konfigureerimiseks.
• ühendus- töötab täpselt samamoodi nagu sama nimega objekti atribuut QueryTable. See võib aktsepteerida ühenduse stringi, ettevalmistatud kirjekomplekti objekti, tekstifaili, veebipäringut. Microsoft Query fail. Kõige sagedamini kirjutatakse OLAP-iga töötamisel ühendusstring otse (kuna näiteks andmete muutmiseks pole mõtet Recordset objekti vastu võtta - OLAP-i andmeallikad on peaaegu alati kirjutuskaitstud). Näiteks võib selle atribuudi seadistamine LONDONI serveris Foodmarti andmebaasiga (analüüsiteenuste näidisandmebaasiga) ühenduse loomiseks välja näha järgmine:

PC1.Ühendus = "OLEDB;Pakkuja=MSOLAP.2;Andmeallikas=LONDON1;Esialgne kataloog = FoodMart 2000"

• omadused CommandType Ja käsu tekst kirjeldada samamoodi andmebaasiserverisse saadetava käsu tüüpi ja käsu teksti. Näiteks müügikuubikule juurdepääsu saamiseks ja selle kliendi vahemällu salvestamiseks võite kasutada sellist koodi nagu

PC1.CommandType = xlCmdCube

PC1.CommandText = Massiiv("Müük")

• vara Kohalik ühendus võimaldab luua ühenduse Exceli loodud kohaliku kuubikuga (*.cub-fail). Loomulikult on selliste failide kasutamine "tootmismahtudega" töötamiseks äärmiselt ebasoovitav - ainult paigutuse jms loomise eesmärgil.
• vara Kasutatud mälu tagastab PivotCache'i kasutatud RAM-i hulga. Kui sellel PivotCache'il põhinevat PivotTable-liigendtabelit pole veel loodud ja avatud, tagastab 0. Seda saab kasutada kontrollimaks, kas teie rakendus töötab nõrkade klientidega.
• vara OLAP tagastab väärtuse Tõene, kui PivotCache on ühendatud OLAP-serveriga.
• OptimizeCache- vahemälu struktuuri optimeerimise võimalus. Andmete esialgne laadimine võtab kauem aega, kuid siis võib töö kiirus suureneda. OLE DB allikate puhul ei tööta.

Objekti PivotCache ülejäänud omadused on samad, mis QueryTable objektil ja seetõttu neid siin ei käsitleta.

PivotCache objekti põhimeetod on CreatePivotTable() meetod. Selle meetodi abil viiakse läbi järgmine etapp - pivot tabeli (PivotTable objekti) loomine. See meetod hõlmab nelja parameetrit:

• TabelSihtkoht on ainus nõutav parameeter.

  Aktsepteerib vahemiku objekti, mille vasakusse ülanurka asetatakse pivot tabel.

• tabeli nimi- Pivot-tabeli nimi. Kui pole määratud, genereeritakse automaatselt vormi nimi "PivotTable1".
• lugeda andmeid- kui selle väärtuseks on määratud Tõene, salvestatakse kogu kuubi sisu automaatselt vahemällu. Selle parameetriga peate olema väga ettevaatlik, kuna selle vale kasutamine võib oluliselt suurendada kliendi koormust.
• Vaikeversioon- Seda omadust tavaliselt ei täpsustata. Võimaldab määrata loodava PivotTable-liigendtabeli versiooni. Vaikimisi kasutatakse uusimat versiooni.

Pöördtabeli loomine töövihiku esimese lehe esimesse lahtrisse võib välja näha järgmine:

PC1.CreatePivotTable Range("A1")

Pivot-tabel on loodud, kuid kohe pärast loomist on see tühi. See pakub nelja ala, kuhu saab allikast välju paigutada (graafilisel ekraanil saab seda kõike seadistada kas akna abil Pivot tabeli väljade loend- see avaneb automaatselt või nupuga Paigutus PivotTable-liigendtabeli viisardi viimasel kuval):

• veeru ala- sisaldab neid dimensioone (“jaotis”, milles andmeid analüüsitakse), mille liikmeid on vähem;
• joonepiirkond- need mõõtmed, mille liikmeid on rohkem;
• lehe ala- need mõõtmised, mille järgi on vaja ainult filtreerida (näiteks näidata andmeid ainult sellise ja sellise piirkonna kohta või ainult sellise ja sellise aasta kohta);
• andmeala- tegelikult tabeli keskosa. Need arvulised andmed (näiteks müügimaht), mida analüüsime.

Raske on usaldada, et kasutaja paigutab elemendid kõigisse nelja piirkonda õigesti.

Lisaks võib see veidi aega võtta. Seetõttu on sageli vaja PivotTable-liigendtabelis andmeid programmiliselt korraldada. See toiming tehakse CubeField objekti abil. Selle objekti peamine omadus on Orientatsioon, see määrab, kus see või teine ​​väli asub. Näiteks paneme veeru alale dimensiooni Kliendid:

PT1.CubeFields(""). Orientatsioon = xlColumnField

Seejärel - stringide ala dimensioon Aeg:

PT1.CubeFields(""). Orientatsioon = xlRowField

Seejärel – toote dimensioon lehe alale:

PT1.CubeFields(""). Orientatsioon = xlPageField

Ja lõpuks indikaator (arvulised andmed analüüsiks) Ühiku müük:

PT1.CubeFields("."). Orientatsioon = xlDataField

Nüüd on pivot-tabel loodud ja sellega on täiesti võimalik töötada. Sageli on aga vaja teha veel üks toiming – laiendada dimensioonihierarhia soovitud taset. Näiteks kui oleme huvitatud kvartalianalüüsist, siis peame laiendama dimensiooni Aeg taset Kvartal (vaikimisi näidatakse ainult ülemist taset). Muidugi saab kasutaja seda ise teha, kuid alati ei saa loota, et ta arvab ära, kus hiirega klõpsata. Laiendage programmiliselt näiteks dimensiooni Aeg hierarhiat 1997. aasta kvartalite tasemele, kasutades PivotField ja PivotItem objekte:

PT1.PivotFields(“.”).PivotItems(“.”).DrilledDown = Tõene

/ Kubistlikul moel. OLAP-kuubikute kasutamine suurettevõtete juhtimispraktikas

Kokkupuutel

Klassikaaslased

Konstantin Tokmachev, süsteemiarhitekt

kubistlikul moel.
OLAP-kuubikute kasutamine suurettevõtete juhtimispraktikas

Võib-olla on juba möödas aeg, mil ettevõtte arvutusressursse kulutati ainult teabe ja raamatupidamisaruannete registreerimisele. Samas tehti juhtimisotsuseid “silma järgi” kontorites, koosolekutel ja istungitel. Võib-olla on Venemaal aeg naasta ettevõtete arvutisüsteemide juurde nende peamine ressurss - juhtimisprobleemide lahendamine arvutis registreeritud andmete põhjal.

Ärianalüüsi eelistest

Ettevõtte juhtimisahelas on "toorete" andmete ja hallatava objekti mõjutamise "hoobade" vahel "jõudlusnäitajad" - KPI-d. Need moodustavad justkui "armatuurlaua", mis peegeldab kontrollitava objekti erinevate alamsüsteemide olekut. Ettevõtte varustamine informatiivsete tulemusnäitajatega ning nende arvutamise ja saadud väärtuste kontrollimine on ärianalüütiku töö. Automaatanalüüsiteenused, nagu MS SQL Server Analysis Services (SSAS) utiliit ja selle põhidisposiit, OLAP-kuubik, võivad ettevõtte analüütilise töö korraldamisel oluliselt aidata.

Siin tuleb teha veel üks märkus. Näiteks Ameerika traditsioonis nimetatakse OLAP-kuubikutega töötamisele keskendunud eriala BI-ks (Business Intelligence). Ei tohiks olla illusioone, et Ameerika BI vastab Vene "ärianalüütikule". Pole pahaks, aga sageli on meie ärianalüütik “alaraamatupidaja” ja “alaprogrammeerija”, hägusate teadmiste ja väikese palgaga spetsialist, kellel tõesti pole oma tööriistu ja metoodikat.

BI-spetsialist on tegelikult rakendusmatemaatik, kõrgetasemeline spetsialist, kes rakendab ettevõtetes kaasaegseid matemaatilisi meetodeid (mida nimetati operatsioonide uurimiseks - operatsioonide uurimise meetodid). BI haakub rohkem NSV Liidus olnud erialale “süsteemianalüütik”, mille valmistas Moskva Riikliku Ülikooli VMK teaduskond. M.V. Lomonossov. OLAP-i kuubik ja analüüsiteenused võivad saada paljulubavaks aluseks Venemaa ärianalüütiku töökohal, võib-olla pärast tema kvalifikatsiooni mõningast paranemist Ameerika BI suunas.

Viimasel ajal on ilmnenud veel üks kahjulik trend. Tänu spetsialiseerumisele on kadunud vastastikune mõistmine ettevõtte erinevate kategooriate töötajate vahel. Raamatupidaja, juht ja programmeerija, nagu "luik, vähk ja haug" muinasjutus I.A. Krylov, tõmmates korporatsiooni erinevatesse suundadesse.

Raamatupidaja on hõivatud aruandlusega, selle summad nii tähenduselt kui ka dünaamiliselt ei ole otseselt seotud ettevõtte äriprotsessiga.

Juht on hõivatud oma äriprotsessi segmendiga, kuid ei suuda globaalselt, ettevõtte kui terviku tasandil hinnata oma tegevuse tulemusi ja väljavaateid.

Lõpuks on programmeerija, kes oli kunagi (tänu haridusele) arenenud tehniliste ideede dirigeerija teaduse ja ärivaldkonnani, muutunud raamatupidaja ja juhi fantaasiate passiivseks teostajaks, mistõttu pole enam haruldane, kui raamatupidajad ja üldiselt kõik, kes pole laisad, sõidavad ettevõtete IT-osakondi. Asjatundmatu, kirjaoskamatu, kuid suhteliselt kõrgelt tasustatud 1C programmeerija on Venemaa korporatsioonide tõeline nuhtlus. (Peaaegu nagu kodumaine jalgpallur.) Ma ei räägi nn "majandusteadlastest ja juristidest", nende kohta on kõik ammu öeldud.

Seega on programmeerimise ja raamatupidamise põhitõdesid tundva kõrgtehnoloogilise SSAS-aparaadiga varustatud ärianalüütiku ametikoht võimeline koondama ettevõtte tööd seoses äriprotsessi analüüsi ja prognoosiga.

OLAP-kuubikute eelised

OLAP-kuubik on kaasaegne rajatis ettevõtte arvutisüsteemi andmebaasi analüüs, mis võimaldab anda hierarhia kõikide tasandite töötajatele vajalikke näitajaid, mis iseloomustavad ettevõtte tootmisprotsessi. Asi pole mitte ainult selles, et MDX (MultiDimensional eXpressions) kuubiku kasutajasõbralik liides ja paindlik päringukeel võimaldavad formuleerida ja arvutada vajalikke analüütilisi näitajaid, vaid ka selle OLAP-i kuubi märkimisväärses kiiruses ja lihtsuses. Pealegi ei sõltu see kiirus ja lihtsus teatud piirides arvutuste keerukusest ja andmebaasi mahust.

Teatud arusaam OLAP-ist
kuubik võib anda MS Exceli "liigendtabeli". Nendel objektidel on sarnane loogika ja sarnased liidesed. Kuid nagu artiklist näha, on OLAP-i funktsionaalsus võrreldamatult rikkalikum ja jõudlus võrreldamatult kõrgem, nii et "liigendtabel" jääb kohalikuks töölauatooteks, OLAP aga ettevõtte tasemel toode.

Miks sobib OLAP-kuubik nii hästi analüütiliste probleemide lahendamiseks? OLAP-kuubik on konstrueeritud selliselt, et kõik indikaatorid kõikides võimalikes sektsioonides on eelnevalt välja arvutatud (täielikult või osaliselt) ning kasutajal jääb vaid hiirega “välja tõmmata” vajalikud indikaatorid (mõõdab mõõdud) ja sektsioonid (mõõtmed mõõdud) ning programm joonistab plaadid ümber.

Kõik võimalikud analüütikad kõigis sektsioonides moodustavad ühe tohutu välja või õigemini mitte välja, vaid lihtsalt mitmemõõtmelise OLAP-i kuubi. Ükskõik, millise taotluse kasutaja (juht, ärianalüütik, juht) analüütikateenusele esitab, on reageerimiskiirus tingitud kahest asjast: esiteks on vajalik analüütika hõlpsasti formuleeritav (kas nimekirjast nime järgi valitud või MDX-keeles valemiga antud), teiseks on see reeglina juba välja arvutatud.

Analüütika formuleerimine on võimalik kolmes versioonis: see on kas andmebaasiväli (täpsemalt laoväli) või kuubikujunduse tasemel defineeritud arvutusväli või kuubikuga interaktiivsel töötamisel MDX keele avaldis.

See tähendab OLAP-i kuubikute mitut atraktiivset funktsiooni korraga. Tegelikult kaob barjäär kasutaja ja andmete vahel. Barjäär rakendusprogrammeerija näol, kes kõigepealt peab probleemi selgitama (ülesande püstitama). Teiseks peate ootama, kuni rakenduse programmeerija loob algoritmi, kirjutab ja silub programmi, seejärel võidakse seda muuta. Kui töötajaid on palju ja nende nõudmised on mitmekesised ja muutlikud, siis on vaja tervet meeskonda rakendusprogrammeerijaid. Selles mõttes asendab OLAP-kuubik (ja kvalifitseeritud ärianalüütik) analüütilise töö poolest tervet meeskonda rakendusprogrammeerijaid, nagu võimas ekskavaator koos ekskavaatoriga kraavi kaevamisel asendab terve brigaadi külalistöölisi labidatega!

Sel juhul saavutatakse saadud analüütiliste andmete teine ​​väga oluline kvaliteet. Kuna OLAP-kuubik on terve ettevõtte jaoks üks, st. Kuna see on sama valdkond, kus on analüütikud kõigile, on andmete tüütu ebakõla välistatud. Kui juht peab subjektiivsusfaktori kõrvaldamiseks sama ülesande seadma mitmele sõltumatule töötajale, kuid nad toovad ikkagi erinevaid vastuseid, mida igaüks kohustub kuidagi selgitama jne. OLAP-kuubik tagab analüütiliste andmete ühtsuse ettevõtte hierarhia erinevatel tasanditel, s.t. kui juht soovib täpsustada mõnda teda huvitavat näitajat, siis jõuab ta kindlasti madalama taseme andmeteni, millega tema alluv töötab, ja just nende põhjal arvutatakse kõrgema taseme näitaja, mitte aga mingid muud mingil muul viisil, mingil muul ajal jne saadud andmed. See tähendab, et kogu ettevõte näeb sama analüüsi, kuid erinevatel konsolideerimistasanditel.

Võtame näite. Oletame, et haldur kontrollib saadaolevaid arveid. Kuni tähtaja ületanud nõuete KPI on roheline, on kõik normaalne, juhtimistoiminguid pole vaja. Kui värv on muutunud kollaseks või punaseks, on midagi valesti: lõikame KPI müügiosakonna kaupa ja näeme kohe jaotusi “punasega”. Määratletakse järgmine jaotis juhtide - ja müüja kohta, kelle kliendid hilinevad maksetega. (Edaspidi saab viivituse suurust jaotada ostjate, tingimuste jms järgi.) Ettevõtte juht võib otse pöörduda mis tahes tasandi rikkujate poole. Kuid üldiselt näevad sama KPI-d (oma hierarhia tasemel) nii osakonnajuhatajad kui müügijuhid. Seetõttu ei pea nad olukorra parandamiseks isegi “vaibale kõnet” ootama... Muidugi ei pea KPI ise olema ilmtingimata võlgnevuse summa – selleks võib olla kaalutud keskmine viivisperiood või üldiselt nõuete käibe määr.

Pange tähele, et MDX-keele keerukus ja paindlikkus koos kiirete (mõnikord hetkeliste) tulemustega võimaldavad lahendada (arvestades arenduse ja silumise etappe) keerulisi juhtimisprobleeme, mis muudel tingimustel ei pruugi rakendusprogrammeerijate keerukuse ja sõnastuse esialgse ebakindluse tõttu üldse tekkida. (Pikad ajaraamid rakendusprogrammeerijatel analüütiliste probleemide lahendamiseks halvasti mõistetava sõnastuse ja pikkade programmimuudatuste tõttu, kui tingimused muutuvad praktikas sageli.)

Pöörakem tähelepanu ka sellele, et iga ettevõtte töötaja saab OLAP-i analüütikule üldpõllult koguda täpselt selle saagi, mida ta tööks vajab, ja mitte rahulduda "ribaga", mille ta on ühistes "standardaruannetes" maha lõiganud.

Mitme kasutajaga liides OLAP-kuubikuga töötamiseks klient-serveri režiimis võimaldab igal töötajal teistest sõltumatult omada (teatud oskustega isegi oma tootmist) analüüsiplokke (aruandeid), mida pärast defineerimist automaatselt värskendatakse – teisisõnu on need alati ajakohased.

See tähendab, et OLAP-kuubik võimaldab teil muuta analüütilise töö (mida tegelikult ei tee mitte ainult märkmeanalüütikud, vaid tegelikult teevad peaaegu kõik ettevõtte töötajad, isegi saldosid ja saadetisi kontrollivad logistikud ja juhid) selektiivsemaks, "näost, mitte üldises väljenduses", mis loob tingimused töö parandamiseks ja tööviljakuse suurendamiseks.

Sissejuhatust kokku võttes märgime, et OLAP-kuubikute kasutamine võib tõsta ettevõtte juhtimise kõrgemale tasemele. Analüütiliste andmete ühtsus hierarhia kõigil tasanditel, nende usaldusväärsus, keerukus, indikaatorite loomise ja muutmise lihtsus, individuaalsed sätted, andmetöötluse kiirus ning lõpuks alternatiivsete analüüsiteede (rakenduse programmeerijad, töötaja sõltumatud arvutused) toetamiseks kuluva raha ja aja kokkuhoid avavad väljavaated OLAP-i kuubikute kasutamiseks Venemaa suurettevõtete praktikas.

OLTP + OLAP: tagasiside ahel ettevõtte juhtimisahelas

Nüüd kaaluge OLAP-kuubikute üldist ideed ja nende rakenduspunkti ettevõtte juhtimisahelas. Mõiste OLAP (OnLine Analytical Processing) võttis Briti matemaatik Edgar Codd kasutusele lisaks varasemale terminile OLTP (OnLine Transactions Processing). Sellest tuleb juttu hiljem, kuid E. Codd pakkus loomulikult välja mitte ainult terminid, vaid ka OLTP ja OLAP matemaatilised teooriad. Üksikasjadesse laskumata on OLTP tänapäevases tõlgenduses relatsiooniline andmebaas, mida peetakse teabe registreerimise, salvestamise ja hankimise mehhanismiks.

Lahenduse metoodika

Sellistel ERP-süsteemidel (Enterprice Resource Planning), nagu 1С7, 1С8, MS Dynamics AX, on kasutajale orienteeritud programmeerimisliidesed (dokumentide sisestamine ja parandamine jne) ning relatsiooniline andmebaas (DB) teabe salvestamiseks ja hankimiseks, mida tänapäeval pakuvad tarkvaratooted nagu MS SQL Server (SS).

Pange tähele, et ERP-süsteemi andmebaasis registreeritud teave on tõepoolest väga väärtuslik ressurss. Asi pole mitte ainult selles, et registreeritud teave tagab ettevõtte jooksva töövoo (dokumentide väljastamine, nende parandamine, printimise ja vastavusse viimise võimalus jne), mitte ainult arvutamise võimaluse. finantsaruanded(maksud, audit jne). Juhtimise seisukohalt on palju olulisem, et OLTP-süsteem (relatsiooniandmebaas) on tegelikult ettevõtte tegevuse tegelik digitaalmudel täissuuruses.

Kuid protsessi juhtimiseks ei piisa selle teabe registreerimisest. Protsessi tuleks esitada selle kulgu iseloomustavate arvnäitajate süsteemina (KPI). Lisaks tuleb indikaatorite jaoks määratleda lubatud väärtuste vahemikud. Ja ainult siis, kui indikaatori väärtus ületab lubatud intervalli, peaks järgnema kontrolltoiming.

Mis puudutab sellist juhtimisloogikat (või mütoloogiat) (“juhtimine kõrvalekalde järgi”), lähenevad ja Vana-Kreeka filosoof Platon, kes lõi tüürimehe (kübernina) kuvandi, kes toetub aerule, kui paat kaldub kursilt kõrvale, ja Ameerika matemaatik Norbert Wiener, kes lõi arvutite ajastu eelõhtul küberneetikateaduse.

Lisaks tavapärasele OLTP-meetodil teabe salvestamise süsteemile on vaja veel ühte süsteemi - kogutud teabe analüüsimise süsteemi. See lisandmoodul, mis juhtimisahelas mängib tagasiside rolli juhtimise ja juhtobjekti vahel, on OLAP-süsteem või lühidalt OLAP-kuubik.

OLAP-i tarkvararakendusena käsitleme utiliiti MS Analysis Services, mis on osa MS SQL Serveri standardtarnetest (lühendatult SSAS). Pange tähele, et E. Coddi plaani kohaselt peaks OLAP-kuubik analüütikas andma samasuguse ammendava tegevusvabaduse, mille annavad OLTP-süsteem ja relatsiooniandmebaas (SQL Server) teabe salvestamisel ja hankimisel.

OLAP logistika

Vaatleme nüüd välisseadmete, rakenduste ja tehnoloogiliste toimingute spetsiifilist konfiguratsiooni, millel põhineb OLAP-kuubi automatiseeritud töö.

Eeldame, et ettevõte kasutab ERP-süsteemi, näiteks 1C7 või 1C8, mille sees teave registreeritakse tavapärasel viisil. Selle ERP-süsteemi andmebaas asub kindlas serveris ja seda haldab MS SQL Server.

Samuti eeldame, et tarkvara on installitud teise serverisse, sealhulgas MS Analysis Services (SSAS) utiliidiga MS SQL Server, samuti MS SQL Server Management Studio, MS C#, MS Excel ja MS Visual Studio programmid. Need programmid koos moodustavad vajaliku konteksti: tööriistad ja vajalikud liidesed OLAP-kuubi arendajale.

SSAS-serverisse on installitud vabavara blat, mida kutsutakse (koos parameetritega) from käsurida ja postiteenuste osutamine.

Töötajate töökohtades, sees kohalik võrk, muuhulgas on installitud MS Exceli programmid (versioon 2003 või uuem) ning võimalik, et ka spetsiaalne draiver, mis võimaldab MS Excelil töötada MS Analysis Services'iga (v.a juhul, kui vastav draiver on MS Excelis juba sees).

Kindluse mõttes eeldame, et töötajate töökohtadel on operatsioonisüsteem Windows XP ja serverites - Windows Server 2008. Samuti oletame, et SQL Serverina kasutatakse MS SQL Server 2005 ja serverisse on installitud Enterprise Edition (EE) või Developer Edition (DE) koos OLAP-kuubikuga. Nendes väljaannetes on võimalik kasutada nn. "poollisandiga meetmed", s.o. täiendavad koondfunktsioonid (statistika), mis ei ole tavalised summad (nt ekstreemum või keskmine väärtus).

OLAP-i kuubiku kujundus (OLAP-kubism)

Ütleme paar sõna OLAP-kuubi enda disainist. Statistika keeles on OLAP-kuubik tulemusnäitajate kogum, mis on arvutatud kõigis vajalikes jaotistes, näiteks saadetise indikaator jaotiste kaupa ostjate, kaupade, kuupäevade jne järgi. Tänu otsetõlkele inglise keelest vene kirjanduses OLAP-kuubikute kohta nimetatakse indikaatoreid "meetmeteks" ja kärpeid "mõõtmeteks". See on matemaatiliselt õige, kuid süntaktiliselt ja semantiliselt mitte eriti õnnestunud tõlge. Venekeelsed sõnad "measure", "measurement", "dimension" peaaegu ei erine tähenduse ja kirjapildi poolest, samas kui ingliskeelsed "measure" ja "dimension" on erinevad nii kirjapildi kui ka tähenduse poolest. Seetõttu eelistame "indikaatorile" ja "lõikusele" traditsioonilisi venekeelseid statistikatermineid, mis on tähenduselt sarnased.

Seoses OLTP-süsteemiga, kus andmeid logitakse, on OLAP-kuubi tarkvaraliseks juurutamiseks mitu võimalust. Vaatleme ainult ühte skeemi, mis on kõige lihtsam, usaldusväärsem ja kiireim.

Selles skeemis ei ole OLAP-il ja OLTP-l ühiseid tabeleid ning OLAP-i analüüs arvutatakse võimalikult üksikasjalikult kuubiku värskendamise (protsessi) etapis enne kasutusetappi. Seda skeemi nimetatakse MOLAP-iks (Multidimensional OLAP). Selle puudused on asünkroonsus ERP-ga ja suured mälukulud.

Kuigi formaalselt saab OLAP-i kuubi ehitada, kasutades andmeallikana kõiki (tuhandeid) ERP-süsteemi relatsiooniandmebaasi tabeleid ja indikaatoritena või sektsioonidena nende kõiki (sadu) välju, siis tegelikkuses seda teha ei tohiks. Vastupidi. Kuubikusse laadimiseks on õigem koostada eraldi andmebaas, mida nimetatakse "vitriiniks" või "laoks" (ladu).

Sellel on mitu põhjust.

• Esiteks, OLAP-kuubi ühendamine tabelitega tõeline alus andmed tekitavad kindlasti tehnilisi probleeme. Tabelis olevate andmete muutmine võib käivitada kuubi värskendamise ja kuubi värskendamine ei pruugi olla kiire protsess, nii et kuubik on püsiva ümberehitamise olekus. samas võib kuubi uuendamise protseduur blokeerida (lugemise ajal) andmebaasi tabelite andmed, aeglustades kasutajate tööd andmete registreerimisel ERP süsteemis.
• Teiseks, liiga paljude indikaatorite ja kärbete olemasolu suurendab järsult kuubiku salvestusala serveris. Ärgem unustagem, et OLAP-kuubik ei salvesta mitte ainult algandmeid, nagu OLTP-süsteemis, vaid ka kõiki indikaatoreid, mis on summeeritud kõigi võimalike sektsioonide (ja isegi kõigi jaotiste kombinatsioonide) lõikes. Lisaks aeglustub vastavalt ka kuubi uuendamise kiirus ning lõpuks ka analüütika ja nendel põhinevate kasutajaaruannete koostamise ja uuendamise kiirus.
• Kolmandaks, liiga palju välju (meetmed ja aspektid) tekitab probleeme OLAP-i arendajaliideses, kuna elementide loendid muutuvad lõputuks.
• Neljandaks OLAP-kuubik on andmete terviklikkuse rikkumiste suhtes väga tundlik. Kuupi ei saa ehitada, kui võtmeandmed ei asu kuubiväljade lingistruktuuris määratud lingi juures. Ajutine või püsiv terviklikkuse rikkumine, tühjad väljad on ERP-süsteemi andmebaasis tavalised, kuid OLAP-ile see kategooriliselt ei sobi.

Samuti võid lisada, et koormuse jagamiseks peaksid ERP-süsteem ja OLAP-kuubik asuma erinevates serverites. Kuid kui OLAP-i ja OLTP-i jaoks on ühised tabelid, on probleem ka võrguliikluses. Praktiliselt lahendamatud probleemid ilmnevad sel juhul, kui on vaja koondada mitu heterogeenset ERP-süsteemi (1C7, 1C8, MS Dynamics AX) ühte OLAP-kuubi.

Tõenäoliselt on võimalik tehnilisi probleeme veelgi kuhjata. Kuid mis kõige tähtsam, pidage meeles, et erinevalt OLTP-st ei ole OLAP andmete registreerimise ja salvestamise vahend, vaid analüüsitööriist. See tähendab, et pole vaja "igaks juhuks" ERP-st OLAP-i "määrdunud" andmeid laadida ja laadida. Vastupidi, esmalt tuleb välja töötada ettevõtte juhtimise kontseptsioon, vähemalt KPI-süsteemi tasemel, ning seejärel kujundada rakenduste andmeladu (ladu), mis asub OLAP-kuubikuga samas serveris ja sisaldab väikest viimistletud hulka haldamiseks vajalikke ERP-andmeid.

Ei reklaami halvad harjumused OLAP-kuubikut OLTP-ga seoses võib võrrelda tuntud "alembilise kuubikuga", mille abil saadakse "puhas toode" tegeliku registreeringu "käärinud massist".

Nii saime aru, et OLAP-i andmeallikaks on spetsiaalne andmebaas (ladu), mis asub OLAP-iga samas serveris. Põhimõtteliselt tähendab see kahte asja. Esiteks peavad olema spetsiaalsed protseduurid, mis loovad ERP andmebaasidest lao. Teiseks on OLAP-kuubik oma ERP-süsteemidega asünkroonne.

Eelnevat arvesse võttes pakume välja arvutusprotsessi arhitektuuri järgmise versiooni.

Lahenduse arhitektuur

Olgu erinevatel serveritel palju teatud ettevõtte (ettevõtte) ERP-süsteeme, mille analüütilised andmed oleksid koondatud ühte OLAP-kuubi. Rõhutame, et kirjeldatud tehnoloogias kombineerime ERP süsteemide andmed lao tasemel, jättes OLAP kuubi kujunduse muutmata.

OLAP-serveris loome kõigi nende ERP-süsteemide andmebaasidest pildid (tühjad koopiad). Nendele tühjadele koopiatele teostame perioodiliselt (iga öö) vastavate aktiivselt töötavate ERP-de andmebaaside osalist replikatsiooni.

Järgmisena käivitatakse SP (salvestatud protseduur), mis samas OLAP-serveris ilma võrguliikluseta ERP-süsteemide andmebaaside osaliste koopiate alusel loob (või täiendab) salvestusruumi (ladu) - OLAP-kuubi andmeallika.

Seejärel käivitatakse standardne protseduur kuubiku värskendamiseks / ehitamiseks vastavalt laoandmetele (Protsessi toiming SSAS-i liideses).

Kommenteerime mõningaid tehnoloogia aspekte. Millist tööd SP-d teevad?

Osalise replikatsiooni tulemusena ilmuvad tegelikud andmed mõne ERP-süsteemi pildile OLAP-serveris. Muide, osalist replikatsiooni saab teha kahel viisil.

Esiteks kopeeritakse osalise replikatsiooni käigus kõigist ERP-süsteemi andmebaasis olevatest tabelitest ainult need, mida on vaja lao ehitamiseks. Seda juhib fikseeritud tabelinimede loend.

Teiseks võib osaline replikatsioon tähendada ka seda, et ei kopeerita kõiki tabeli välju, vaid ainult neid, mis on seotud lao ehitamisega. Kopeeritavate väljade loend määratakse SP-s kas määratud või luuakse dünaamiliselt kopeerimispildist (kui tabeli koopia ei sisalda algselt kõiki välju).

Loomulikult on võimalik mitte kopeerida terveid tabeli ridu, vaid ainult lisada uusi kirjeid. See aga tekitab tõsiseid ebamugavusi ERP versioonide "tagasikuupäeva" arvestamisel, mida reaalses elus sageli leidub. Nii on lihtsam ilma pikema jututa kõik kirjed kopeerida (või "saba" mõnest kuupäevast alates värskendada).

Lisaks on SP põhiülesanne ERP-süsteemidest andmete teisendamine laovormingusse. Kui on ainult üks ERP-süsteem, taandub transformatsiooni ülesanne peamiselt vajalike andmete kopeerimisele ja võimalusel ümbervormindamisele. Aga kui teil on vaja koondada mitu ERP-süsteemi samasse OLAP-i kuubi erinev struktuur, siis muutuvad teisendused keerulisemaks.

Eriti keeruline on mitme erineva ERP-süsteemi koondamine kuubi, kui nende objektide komplektid (kaubakataloogid, töövõtjad, laod jne) osaliselt ristuvad, on objektidel sama tähendus, kuid loomulikult kirjeldatakse neid kataloogides erinevalt. erinevad süsteemid(koodide, identifikaatorite, nimede jne tähenduses).

Tegelikkuses tekib selline pilt suures valdusettevõttes, kui mitu sama tüüpi autonoomset ettevõtet, mis seda moodustavad, teostavad ligikaudu samal territooriumil ligikaudu sama tüüpi tegevusi, kuid kasutavad oma ja koordineerimata registreerimissüsteeme. Sel juhul ei saa lao tasemel andmete koondamisel hakkama ilma abivastendusetabeliteta.

Pöörame veidi tähelepanu lao ladustamise arhitektuurile. Tavaliselt on OLAP-i kuubiskeemi kujutatud "tärnina", st. kataloogide "kiirtega" ümbritsetud andmetabelina – teisese võtme väärtuste tabelid. Tabel on "näitajate" plokk, teatmeteosed on nende lõiked. Samal ajal võib kataloog omakorda olla suvaline tasakaalustamata puu või tasakaalustatud hierarhia, näiteks mitmetasandiline kaupade või vastaspoolte klassifikaator. OLAP-kuubis muutuvad laos oleva andmetabeli numbriväljad automaatselt "indikaatoriteks" (või mõõdikuteks) ja sektsioone (või mõõtmeid) saab määratleda sekundaarsete võtmete tabelite kaudu.

See on visuaalne "pedagoogiline" kirjeldus. Tegelikult võib OLAP-kuubi arhitektuur olla palju keerulisem.

Esiteks võib ladu koosneda mitmest "tärnist", mis võivad olla ühendatud ühiste kataloogide kaudu. Sel juhul on OLAP-kuubik mitme kuubi (mitme andmeploki) liit.

Teiseks ei pruugi tärni "kiir" olla üks kataloog, vaid terve (hierarhiline) failisüsteem.

Kolmandaks, olemasolevate dimensioonikärbete põhjal saab OLAP-i arendajaliidese abil defineerida uusi hierarhilisi kärpeid (näiteks vähemate tasemetega, erineva tasemete järjestusega jne).

Neljandaks saab olemasolevate näitajate ja lõikude põhjal defineerida uusi näitajaid (arvutusi), kasutades MDX keele väljendit. Oluline on märkida, et uued kuubikud, uued indikaatorid, uued sektsioonid integreeritakse automaatselt täielikult algsete elementidega. Samuti tuleb märkida, et halvasti formuleeritud arvutused ja hierarhilised kärped võivad OLAP-kuubiku tööd märgatavalt aeglustada.

MS Excel liidesena OLAP-iga

Eriti huvitav on OLAP-kuubikutega kasutajaliides. Loomulikult pakub SSAS-i utiliit ise kõige täiuslikumat liidest. See on OLAP-kuubiku arendaja tööriistakomplekt, interaktiivne aruannete kujundaja ja aken interaktiivseks tööks OLAP-kuubikuga, kasutades päringuid MDX-keeles.

Lisaks SSAS-ile endale on palju programme, mis pakuvad OLAP-ile liidest, kattes nende funktsionaalsust suuremal või vähemal määral. Kuid nende hulgas on üks, millel on meie arvates vaieldamatud eelised. See on MS Excel.

Liidese MS Exceliga pakub spetsiaalne draiver, mille saab alla laadida eraldi või lisada Excelisse. See ei kata kõiki OLAP-i funktsioone, kuid MS Exceli versiooninumbrite kasvuga muutub see katvus üha laiemaks (näiteks MS Excel 2007-s ilmub KPI-graafika, mida MS Excel 2003-s ei olnud jne).

Loomulikult on MS Exceli peamiseks eeliseks lisaks üsna täielikule funktsionaalsusele selle programmi laialt levinud levik ja valdava enamuse kontorikasutajate lähedane tutvus sellega. Selles mõttes ei pea ettevõte erinevalt teistest liideseprogrammidest midagi juurde hankima ega kedagi täiendavalt koolitama.

MS Exceli kui OLAP-i liidese suur eelis on OLAP-i aruandes saadud andmete edasise iseseisva töötlemise võimalus (st OLAP-ist saadud andmete uurimise jätkamine sama Exceli teistel lehtedel, mitte enam OLAP-i tööriistu kasutades, vaid tavalisi Exceli tööriistu).

Igaõhtune facubi ravitsükkel

Nüüd kirjeldame OLAP-i töö igapäevast (öist) arvutustsüklit. Arvutamine toimub facubi programmi juhtimisel, mis on kirjutatud C # 2005 ja käivitatud Task Scheduleri abil lao ja SSAS-iga serveris. Alguses pääseb facubi Internetti ja loeb kehtivaid vahetuskursse (kasutatakse mitmete näitajate esitamiseks valuutas). Järgmisena tehakse järgmised sammud.

Esiteks käivitab facubi SP-d, mis teostavad erinevate kohalikus võrgus saadaolevate ERP-süsteemide (hoidmiselementide) andmebaasi osalist replikatsiooni. Replikatsioon tehakse, nagu me ütlesime, eelnevalt ettevalmistatud "hoovides" - SSAS-serveris asuvate kaug-ERP-süsteemide piltidel.

Teiseks, SP kaudu toimub vastendamine ERP-replicatest laosalvestusele - spetsiaalsele DB-le, mis on OLAP-kuubiandmete allikas ja asub SSAS-serveris. See täidab kolm peamist ülesannet:

• ERP andmed on viidud nõutavate kuubivormingute alla; räägime tabelitest ja tabeliväljadest. (Mõnikord tuleb nõutav tabel näiteks mitmest MS Exceli lehelt “vormida”.) Sarnased andmed võivad erinevates ERP-des olla erineva vorminguga, näiteks 1C7 kataloogide võtme ID väljadel on 36-kohaline kood pikkusega 8 ja _idrref väljadel 1C8 kataloogides on kuueteistkümnendarvud pikkusega 32;
• töötlemise ajal teostatakse andmete loogilist kontrolli (sh võimalusel puuduvate andmete asemel vaikimisi vaikimisi ettekirjutamist) ja terviklikkuse kontrolli, s.o. primaar- ja sekundaarvõtmete olemasolu kontrollimine vastavates klassifikaatorites;
• koodide konsolideerimine objektid, millel on erinevates ERP-des sama tähendus. Näiteks võivad erinevate ERP-de kataloogide vastavad elemendid omada sama tähendust, näiteks, see on sama vastaspool. Koodide koondamise ülesanne lahendatakse kaardistamise tabelite konstrueerimisega, kus ühtsusse tuuakse samade objektide erinevad koodid.

Kolmandaks käivitab facubi standardse protsessi kuubiku andmete värskendamise protseduuri (SSAS-i utiliidi protseduuridest).

Vastavalt kontrollnimekirjadele saadab facubi välja e-kirjad töötlemisetappide edenemise kohta.

Pärast facubi käivitamist käivitab Task Scheduler kordamööda mitu exceli faili, milles OLAP kuubi indikaatorite põhjal koostatakse aruanded. Nagu me ütlesime, on MS Excelil spetsiaalne programmeerimisliides (eraldi allalaaditav või sisseehitatud draiver) OLAP-kuubikutega töötamiseks (SSAS-iga). MS Exceli käivitamisel kaasatakse MS VBA-s olevad programmid (nt makrod), mis pakuvad aruannete andmete värskendamist; aruandeid muudetakse vajadusel ja saadetakse kasutajatele posti teel (blat programm) vastavalt kontrollnimekirjadele.

Kohaliku võrgu kasutajad, kellel on juurdepääs SSAS-serverile, saavad OLAP-kuubi jaoks konfigureeritud "reaalajas" aruandeid. (Põhimõtteliselt saavad nad ise, ilma igasuguse postita, OLAP-i aruandeid uuendada MS Excelis, lamades oma kohalikes arvutites.) Väljaspool kohtvõrku olevad kasutajad saavad kas algsed, kuid piiratud funktsionaalsusega aruanded või arvutatakse nende jaoks (pärast OLAP-i aruannete värskendamist MS Excelis) spetsiaalsed "surnud" aruanded, mis ei pääse SSAS-i serverisse.

Tulemuste hindamine

Eespool rääkisime OLTP ja OLAP-i asünkroonsusest. Tehnoloogia vaadeldavas versioonis viiakse OLAP-i kuubi värskendustsükkel läbi öösel (näiteks algab see kell 1 öösel). See tähendab, et jooksval tööpäeval töötavad kasutajad eilsete andmetega. Kuna OLAP ei ole logimise tööriist (vt dokumendi uusimat versiooni), vaid haldustööriist (mõistke protsessi suundumust), pole see mahajäämus tavaliselt kriitiline. Vajadusel on aga isegi kirjeldatud kuubiarhitektuuri versioonis (MOLAP) võimalik uuendada mitu korda päevas.

Värskendusprotseduuride täitmise aeg sõltub OLAP-i kuubi disainifunktsioonidest (enam-vähem keerukus, enam-vähem edukad indikaatorite ja sektsioonide määratlused) ning väliste OLTP-süsteemide andmebaaside mahust. Lao ehitamise protseduurid kestavad kogemuste kohaselt mitmest minutist kahe tunnini, kuubi uuendamise protseduur (Protsess) 1 kuni 20 minutit. Jutt on keerulistest OLAP-kuubikutest, mis ühendavad kümneid tähestruktuure, nende jaoks kümneid tavalisi "kiiri" (referentslõikeid), umbes sadu indikaatoreid. Hinnates väliste ERP-süsteemide andmebaaside mahtu dokumentide saatmise järgi, räägime sadadest tuhandetest dokumentidest ja vastavalt miljonitest tootesarjadest aastas. Kasutajat huvitava töötlemise ajalooline sügavus oli kolm kuni viis aastat.

Kirjeldatud tehnoloogiat kasutatakse mitmetes suurkorporatsioonides: alates 2008. aastast Venemaa kalakompaniis (RRK) ja Vene merekompaniis (RM), alates 2012. aastast ettevõttes Santa Bremor (SB). Mõned ettevõtted on valdavalt kaubandus-ostmisettevõtted (RRK), teised on tootmisettevõtted (Moldova Vabariigi kala- ja mereandide töötlemisettevõtted ja Julgeolekunõukogu). Kõik ettevõtted on suured osalused, mis ühendavad mitut ettevõtet, millel on sõltumatud ja erinevad arvutipõhised raamatupidamissüsteemid – alates standardsetest ERP süsteemidest nagu 1C7 ja 1C8 kuni DBF-il ja Excelil põhinevate "reliikvia" raamatupidamissüsteemideni. Lisan, et kirjeldatud OLAP-kuubikute käitamise tehnoloogia (arendusetappi arvestamata) kas ei vaja üldse eritöötajaid või kuulub ühe täiskohaga ärianalüütiku kohustuste hulka. Ülesanne on keerlenud aastaid automaatrežiimis, varustades iga päev erinevate ettevõtete töötajate kategooriaid ajakohase aruandlusega.

Lahenduse plussid ja miinused

Nagu kogemus näitab, on pakutud lahenduse variant üsna usaldusväärne ja hõlpsasti kasutatav. Seda on lihtne muuta (uute ERP-de ühendamine / lahtiühendamine, uute indikaatorite ja jaotiste loomine, Exceli aruannete ja nende meililistide loomine ja muutmine) facubi juhtimisprogrammi muutumatuna.

MS Excel liidesena OLAP-iga pakub piisavat väljendusrikkust ja võimaldab erinevate kategooriate kontoritöötajatel kiiresti OLAP-tehnoloogiaga liituda. Kasutaja saab iga päev "standardseid" OLAP aruandeid; kasutades MS Exceli liidest OLAP-iga, saab iseseisvalt luua OLAP-i aruandeid MS Excelis. Lisaks saab kasutaja oma MS Exceli tavalisi võimalusi kasutades iseseisvalt jätkata OLAP-aruannete teabe uurimist.

“Täpsustatud” laoandmebaas, kuhu on koondatud (kuubiku ehitamise käigus) mitmed heterogeensed ERP-süsteemid ka ilma OLAP-ita, võimaldab lahendada (SSAS serveris, Transact SQL päringumeetodi või SP meetodiga jne) palju rakenduslikke haldusülesandeid. Tuletame meelde, et lao andmebaasi struktuur on ühtne ja palju lihtsam (tabelite arvu ja tabeliväljade arvu poolest) kui algse ERP andmebaasi struktuurid.

Eriliselt märgime ära, et meie pakutud lahenduses on võimalus koondada erinevad ERP-süsteemid ühte OLAP-kuubi. See võimaldab teil hankida kogu osaluse analüüsi ja säilitada analüütika pikaajaline järjepidevus, kui ettevõte liigub üle teisele ERP-arvestussüsteemile, näiteks 1C7-lt 1C8-le.

Kasutasime MOLAP kuubimudelit. Selle mudeli eelised on töökindlus ja kasutaja päringute töötlemise kiire. Miinused - asünkroonsed OLAP ja OLTP, samuti suured mälumahud OLAP-i salvestamiseks.

Toome lõpetuseks veel ühe argumendi OLAP-i kasuks, mis oleks ehk keskajal sobivam olnud. Sest selle tõendusjõud toetub autoriteedile. Tagasihoidlik, selgelt alahinnatud Briti matemaatik E. Codd töötas välja relatsiooniliste andmebaaside teooria 60ndate lõpus. Selle teooria tugevus oli selline, et nüüd, pärast 50 aastat, on juba raske leida mitterelatsioonilist andmebaasi ja andmebaasi päringukeelt peale SQL-i.

Relatsiooniliste andmebaaside teoorial põhinev OLTP-tehnoloogia oli E. Coddi esimene idee. Tegelikult on OLAP-kuubikute kontseptsioon tema teine ​​​​idee, mille ta väljendas 90ndate alguses. Isegi kui te pole matemaatik, võite eeldada, et teine ​​idee on sama tõhus kui esimene. See tähendab, et arvutianalüütika osas võtavad OLAP-i ideed peagi maailma üle ja tõrjuvad välja kõik teised. Lihtsalt sellepärast, et analüütika teema leiab oma ammendava matemaatilise lahenduse OLAP-is ja see lahendus on „adekvaatne“ (B. Spinoza termin) analüütika praktilise ülesande jaoks. "Adekvaatselt" tähendab Spinozas seda, et isegi jumal ise poleks saanud paremat ideed tulla ...

1. Larson B. Ärianalüüsi arendamine Microsoft SQL Server 2005-s. - Peterburi: "Piter", 2008.
2. Codd E. Andmebaasi allkeelte relatsiooniline täielikkus, andmebaasisüsteemid, Courant Computer Science Sumposia Series 1972, v. 6, Englwoodi kaljud, N.Y., Prentice–Hall.

Kokkupuutel