Designa datakuber. Skapa en OLAP-kub med Microsoft Query

Ris. 2. OLAP kub skiva

Rotation(Figur 3) - funktionen för att ändra platsen för mätningar som presenteras i en rapport eller på den visade sidan. En rotationsoperation kan till exempel innebära omarrangering av rader och kolumner i en tabell. Om du roterar en datakub flyttas dessutom dimensioner utanför tabell på plats med dimensioner som finns på den visade sidan och vice versa.

Anteckning: Den här föreläsningen tar upp grunderna för att designa datakuber för OLAPs datalager. Exemplet visar metoden för att konstruera en datakub med CASE-verktyget.

Syftet med föreläsningen

Efter att ha studerat materialet i denna föreläsning kommer du att veta:

• vad är en datakub i OLAP datalager ;
• hur man designar en datakub för OLAP datalager ;
• vad är en datakubdimension;
• hur ett faktum är relaterat till en datakub;
• vad är dimensionsattribut;
• vad är hierarki;
• vad är ett datakubmått;

och lär:

• bygga flerdimensionella diagram ;
• design enkel flerdimensionella diagram.

Introduktion

OLAP-teknik är inte en singel programvara, Inte programmeringsspråk. Om vi ​​försöker täcka in OLAP i alla dess yttringar, så är det en uppsättning koncept, principer och krav som ligger till grund för mjukvaruprodukter som gör det lättare för analytiker att komma åt data.

Analytiker är de största konsumenterna av företagsinformation. Analytikerns uppgift är att hitta mönster i stora mängder data. Därför kommer analytikern inte att uppmärksamma det individuella faktum att en viss dag såldes ett parti kulspetspennor till köparen Ivanov - han behöver information om hundratals och tusentals liknande händelser. Enstaka fakta i datalagret kan vara av intresse för till exempel en revisor eller chefen för försäljningsavdelningen, vars kompetens är stöd för ett visst kontrakt. För en analytiker räcker det inte med en post - han kan till exempel behöva information om alla kontrakt på ett försäljningsställe för en månad, kvartal eller år. Analytikern kanske inte är intresserad av köparens TIN eller hans telefonnummer - han arbetar med specifika numeriska data, vilket är kärnan i hans yrkesverksamhet.

Centralisering och bekväm strukturering är inte allt som en analytiker behöver. Han behöver ett verktyg för att se och visualisera information. Traditionella rapporter, även de som bygger på ett enda datalager, saknar dock en viss flexibilitet. De kan inte "tvinnas", "expanderas" eller "komprimeras" för att få önskad bild av data. Ju fler "skivor" och "sektioner" av data en analytiker kan utforska, desto fler idéer har han, som i sin tur kräver fler och fler "skivor" för verifiering. OLAP fungerar som ett sådant verktyg för dataanalys av en analytiker.

Även om OLAP inte är ett nödvändigt attribut för ett datalager, används det allt oftare för att analysera informationen som samlas i detta datalager.

Driftsdata samlas in från olika källor, rensas, integreras och lagras i ett datalager. Dessutom är de redan tillgängliga för analys med hjälp av olika rapporteringsverktyg. Därefter förbereds data (helt eller delvis) för OLAP-analys. De kan laddas in i en speciell OLAP-databas eller lämnas i en relationsdatabas. Den viktigaste delen av att använda OLAP är metadata, det vill säga information om struktur, placering och datatransformation. Tack vare dem säkerställs effektiv interaktion mellan olika lagringskomponenter.

Således, OLAP kan definieras som en uppsättning verktyg för multidimensionell dataanalys ackumulerad i ett datalager. Teoretiskt kan OLAP-verktyg appliceras direkt på operativa data eller deras exakta kopior. Det finns dock en risk att utsätta data för analys som inte är lämplig för denna analys.

OLAP på klient och server

OLAP bygger på multidimensionell dataanalys. Den kan produceras med olika verktyg, som kan delas in i klient- och server-OLAP-verktyg.

OLAP-klientverktyg är applikationer som beräknar aggregerade data (summor, medelvärden, högsta eller lägsta värden) och visar dem, medan själva aggregerade data finns i en cache i adressutrymmet för ett sådant OLAP-verktyg.

Om källdata finns i en stationär DBMS, utförs beräkningen av aggregerad data av själva OLAP-verktyget. Om källan till den initiala datan är en server-DBMS, skickar många av klientens OLAP-verktyg SQL-förfrågningar som innehåller GROUP BY-operatören till servern och som ett resultat tar emot aggregerad data beräknad på servern.

Som regel implementeras OLAP-funktionalitet i verktyg för statistisk databehandling (från produkter av denna klass till ryska marknaden produkter från Stat Soft och SPSS används ofta) och i vissa kalkylblad. I synnerhet har den bra multidimensionella analysverktyg Microsoft excel 2000. Med den här produkten kan du skapa och spara som en fil en liten lokal flerdimensionell OLAP-kub och visa dess två- eller tredimensionella sektioner.

Många utvecklings verktyg innehåller bibliotek med klasser eller komponenter som låter dig skapa applikationer som implementerar enkel OLAP-funktionalitet (som till exempel Decision Cube-komponenter i Borland Delphi och Borland C++Builder). Dessutom erbjuder många företag kontroller ActiveX och andra bibliotek som implementerar liknande funktionalitet.

Observera att klient-OLAP-verktyg som regel används med ett litet antal dimensioner (vanligtvis rekommenderas inte fler än sex) och en liten mängd värden för dessa parametrar - trots allt måste den resulterande aggregerade informationen passa in i adressutrymmet för ett sådant verktyg, och deras antal växer exponentiellt när antalet ökar mätningarna Därför tillåter även de mest primitiva klient-OLAP-verktygen som regel en preliminär beräkning av mängden RAM som krävs för att skapa en flerdimensionell kub i den.

Många (men inte alla) OLAP-klientverktyg låter dig spara innehållet i cachen med aggregerade data som en fil, vilket i sin tur låter dig undvika att räkna om dem. Observera att denna möjlighet ofta används för att alienera aggregerad data i syfte att överföra den till andra organisationer eller för publicering. Ett typiskt exempel på sådana överlåtbara aggregerade data är sjuklighetsstatistik i olika regioner och i olika åldersgrupper, vilket är öppen information publiceras av hälsoministerierna olika länder och Världshälsoorganisationen. Samtidigt är själva de ursprungliga uppgifterna, som representerar information om specifika sjukdomsfall, konfidentiella uppgifter från medicinska institutioner och bör inte i något fall falla i händerna på försäkringsbolag, än mindre bli offentliga.

Idén att lagra en cache med aggregerad data i en fil utvecklades vidare i serverns OLAP-verktyg, där sparande och ändring av aggregerad data, samt underhåll av lagringen som innehåller dem, utförs av en separat applikation eller process som kallas en OLAP-server. Klientapplikationer kan begära sådan flerdimensionell lagring och ta emot viss data som svar. Vissa klientapplikationer kan också skapa sådana butiker eller uppdatera dem baserat på ändrade källdata.

Fördelarna med att använda server-OLAP-verktyg jämfört med klient-OLAP-verktyg liknar fördelarna med att använda server-DBMS jämfört med stationära: när man använder serververktyg, sker beräkningen och lagringen av aggregerad data på servern och klientapplikationen tar bara emot resultaten av förfrågningar mot dem, vilket i allmänhet tillåter minska nätverkstrafiken, ledtid förfrågningar och resurskrav som förbrukas av klientapplikationen. Observera att dataanalys- och bearbetningsverktyg i företagsskala, som regel, är baserade på server-OLAP-verktyg, till exempel Oracle Express Server, Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, produkter från Crystal Decisions, Business Objects, Cognos, SAS Inleda. Eftersom alla de ledande tillverkarna av server-DBMS producerar (eller har licensierat från andra företag) ett eller annat server-OLAP-verktyg är urvalet ganska brett, och i nästan alla fall kan du köpa en OLAP-server från samma tillverkare som själva databasservern .

Observera att många OLAP-klientverktyg (särskilt Microsoft Excel 2003, Seagate Analysis, etc.) låter dig komma åt serverns OLAP-lagringar, och fungerar i det här fallet som klientprogram som utför sådana frågor. Dessutom finns det många produkter som är klientapplikationer för OLAP-verktyg från olika tillverkare.

Tekniska aspekter av multidimensionell datalagring

Flerdimensionella datalager innehåller aggregerade data med varierande detaljeringsgrad, till exempel försäljningsvolymer per dag, månad, år, per produktkategori, etc. Syftet med att lagra aggregerad data är att minska ledtid begär, eftersom det i de flesta fall för analyser och prognoser inte är detaljerade, utan sammanfattande data som är av intresse. Därför, när du skapar en flerdimensionell databas, beräknas och lagras alltid viss aggregerad data.

Observera att det inte alltid är motiverat att spara all samlad data. Faktum är att när nya dimensioner läggs till växer datavolymen som utgör kuben exponentiellt (ibland talar man om "explosiv tillväxt" av datavolymen). Mer exakt beror graden av tillväxt i volymen av aggregerad data på antalet dimensioner av kuben och medlemmarna av dimensionerna på olika nivåer i hierarkierna för dessa dimensioner. För att lösa problemet med "explosiv tillväxt" används olika scheman, som gör det möjligt att uppnå en acceptabel hastighet för utförande av förfrågningar när man inte beräknar alla möjliga aggregerade data.

Både rådata och aggregerade data kan lagras i antingen relationella eller flerdimensionella strukturer. Därför används för närvarande tre metoder för datalagring.

• MOLAP(Multidimensional OLAP) - källdata och aggregerade data lagras i en flerdimensionell databas. Genom att lagra data i flerdimensionella strukturer kan du manipulera data som en flerdimensionell matris, på grund av vilken hastigheten för beräkning av aggregerade värden är densamma för alla dimensioner. Men i detta fall är den flerdimensionella databasen redundant, eftersom den flerdimensionella datan helt innehåller den ursprungliga relationsdatan.
• ROLAP(Relationell OLAP) - originaldata finns kvar i samma relationsdatabas där den ursprungligen fanns. Aggregat data placeras i servicetabeller speciellt skapade för att lagra dem i samma databas.
• HOLAP(Hybrid OLAP) - originaldata finns kvar i samma relationsdatabas där de ursprungligen fanns, och den aggregerade data lagras i en flerdimensionell databas.

Vissa OLAP-verktyg stöder lagring av data endast i relationsstrukturer, vissa endast i flerdimensionella. De flesta moderna server-OLAP-verktyg stöder dock alla tre metoderna för datalagring. Valet av lagringsmetod beror på volymen och strukturen för källdata, krav på hastigheten för exekvering av frågor och frekvensen för uppdatering av OLAP-kuber.

Observera också att de allra flesta moderna OLAP-verktyg inte lagrar "tomma" värden (ett exempel på ett "tomt" värde skulle vara frånvaron av försäljning av en säsongsbetonad produkt under lågsäsong).

Grundläggande OLAP-koncept

FAMSI test

Tekniken för komplex multidimensionell dataanalys kallas OLAP (On-Line Analytical Processing). OLAP är en nyckelkomponent i en datalagerorganisation. Begreppet OLAP beskrevs 1993 av Edgar Codd, en berömd databasforskare och författare till den relationella datamodellen. År 1995, utifrån de krav som Codd ställde, den s.k FASMI test(Snabb analys av delad flerdimensionell information) - snabb analys av delad flerdimensionell information, inklusive följande krav för applikationer för flerdimensionell analys:

• Snabb(Snabb) - förse användaren med analysresultat inom en acceptabel tid (vanligtvis inte mer än 5 s), även till priset av en mindre detaljerad analys;
• Analys(Analys) - förmågan att utföra logisk och statistisk analys som är specifik för en given applikation och spara den i en form som är tillgänglig för slutanvändaren;
• Delad(Delad) - åtkomst för flera användare till data med stöd för lämpliga låsmekanismer och auktoriserade åtkomstmedel;
• Flerdimensionell(Multidimensionell) - multidimensionell konceptuell representation av data, inklusive fullt stöd för hierarkier och flera hierarkier (detta är ett nyckelkrav för OLAP);
• Information(Information) - applikationen måste kunna komma åt all nödvändig information, oavsett dess volym och lagringsplats.

Det bör noteras att OLAP-funktionalitet kan implementeras olika sätt, som börjar med de enklaste dataanalysverktygen i kontorsapplikationer och slutar med distribuerade analyssystem baserade på serverprodukter.

Flerdimensionell representation av information

kuber

OLAP erbjuder bekväma, snabba sätt att komma åt, visa och analysera affärsinformation. Användaren får en naturlig, intuitiv datamodell, organisera dem i form av flerdimensionella kuber (kuber). Axlarna i det flerdimensionella koordinatsystemet är huvudattributen för den analyserade affärsprocessen. För försäljning kan det till exempel vara produkt, region, typ av köpare. Tid används som en av dimensionerna. I skärningspunkterna mellan mätaxlarna (Dimensioner) finns data som kvantitativt karakteriserar processen - mått (Measures). Detta kan vara försäljningsvolymer i bitar eller i monetära termer, lagersaldon, kostnader etc. En användare som analyserar information kan "klippa" kuben i olika riktningar, få en sammanfattning (till exempel efter år) eller omvänt detaljerad (per vecka) ) information och utföra andra manipulationer som kommer till honom under analysprocessen.

Som mått i den tredimensionella kuben som visas i fig. 26.1 används försäljningsbelopp och tid, produkt och butik används som dimensioner. Måtten visas i vissa nivåer grupperingar: produkterna grupperas efter kategori, butiker - efter land och data om transaktionstidpunkten - per månad. Lite senare kommer vi att titta på grupperingsnivåerna (hierarki) mer i detalj.

Ris. 26.1.

"Skär" en kub

Även en tredimensionell kub är svår att visa på en datorskärm så att värdena för de intressanta måtten är synliga. Vad kan vi säga om kuber med mer än tre dimensioner? För att visualisera data lagrad i en kub används som regel välbekanta tvådimensionella, det vill säga tabellvyer med komplexa hierarkiska rad- och kolumnrubriker.

En tvådimensionell representation av en kub kan erhållas genom att "klippa" den korsvis längs en eller flera axlar (dimensioner): vi fixar värdena för alla dimensioner utom två, och vi får en vanlig tvådimensionell tabell. Tabellens horisontella axel (kolumnrubriker) representerar en dimension, den vertikala axeln (radrubriker) representerar en annan, och tabellcellerna representerar måttens värden. I det här fallet betraktas en uppsättning mått faktiskt som en av dimensionerna: vi väljer antingen ett mått att visa (och sedan kan vi placera två dimensioner i rad- och kolumnrubrikerna), eller visar flera mått (och sedan en av tabellaxlar kommer att upptas av namnen på mått och den andra av värden för den enda "oklippta" dimensionen).

Arkitektur av OLAP-applikationer

Allt som sades ovan om OLAP hänförde sig huvudsakligen till multidimensionell presentation av data. Hur datan lagras berör, grovt sett, varken slutanvändaren eller utvecklarna av verktyget klienten använder.

Flerdimensionalitet i OLAP-applikationer kan delas in i tre nivåer.

• Multidimensionell datarepresentation - slutanvändarverktyg som tillhandahåller multidimensionell visualisering och manipulering av data; Det flerdimensionella representationsskiktet abstraherar från den fysiska strukturen av datan och behandlar datan som flerdimensionell.
• Flerdimensionell bearbetning är ett medel (språk) för att formulera flerdimensionella frågor (det traditionella relationsspråket SQL är olämpligt här) och en processor som kan bearbeta och exekvera en sådan fråga.
• Flerdimensionell lagring är ett sätt att fysiskt organisera data som säkerställer effektiv exekvering av flerdimensionella frågor.

De två första nivåerna är obligatoriska i alla OLAP-verktyg. Den tredje nivån, även om den är utbredd, är inte nödvändig, eftersom data för en multidimensionell representation kan extraheras från vanliga relationsstrukturer; Den flerdimensionella frågeprocessorn översätter i detta fall flerdimensionella frågor till SQL-frågor som exekveras av den relationella DBMS.

Specifika OLAP-produkter är som regel antingen ett multidimensionellt datapresentationsverktyg (OLAP-klient - till exempel pivottabeller i Excel 2000 från Microsoft eller ProClarity från Knosys) eller en flerdimensionell server-DBMS (OLAP-server - till exempel Oracle Express Server eller Microsoft OLAP-tjänster).

Det flerdimensionella bearbetningsskiktet är vanligtvis inbyggt i OLAP-klienten och/eller OLAP-servern, men kan isoleras i sin rena form, såsom Microsofts Pivot Table Service-komponent.

/ På ett kubistiskt sätt. Tillämpning av OLAP-kuber i förvaltningspraxis för stora företag

I kontakt med

Klasskamrater

Konstantin Tokmachev, systemarkitekt

I kubistisk stil.
Tillämpning av OLAP-kuber i förvaltningspraxis för stora företag

Kanske har tiden gått när ett företags datorresurser endast användes på att registrera information och redovisningsrapporter. Samtidigt togs ledningsbeslut "med ögonen" på kontor, vid möten och möten. Kanske är det dags att i Ryssland återställa företagens datorsystem till sin huvudsakliga resurs - att lösa hanteringsproblem baserat på data registrerade i datorn

Om fördelarna med affärsanalys

I företagsledningsslingan, mellan "rå" data och "spakarna" för att påverka det hanterade objektet, finns det "prestandaindikatorer" - KPI:er. De bildar ett slags "dashboard", som återspeglar tillståndet för olika delsystem av det kontrollerade objektet. Att utrusta företaget med informativa resultatindikatorer och övervaka deras beräkningar och erhållna värden är en affärsanalytikers arbete. Automatiserade analystjänster, såsom MS-verktyget, kan ge betydande hjälp med att organisera ett företags analytiska arbete. SQL Server Analysis Services (SSAS) och dess huvudfunktion är OLAP-kuben.

Ytterligare en poäng måste göras här. Låt oss säga att i amerikansk tradition kallas en specialitet fokuserad på att arbeta med OLAP-kuber BI (Business Intelligence). Det bör inte finnas några illusioner om att den amerikanska BI motsvarar den ryska "affärsanalytikern". No offense, men ofta är vår affärsanalytiker en "under-revisor" och "under-programmerare", en specialist med vag kunskap och en liten lön, som verkligen inte har några egna verktyg och metodik.

En BI-specialist är i själva verket en tillämpad matematiker, en högt kvalificerad specialist som sätter in moderna matematiska metoder i företagets arsenal (det som kallades Operations Research - metoder för operationsforskning). BI är mer överensstämmande med specialiteten "systemanalytiker" som en gång var i Sovjetunionen, tog examen från fakulteten för beräkningsmatematik och matematik vid Moscow State University. M.V. Lomonosov. OLAP-kuben och analystjänsterna kan bli en lovande grund för en rysk affärsanalytikers arbetsplats, kanske efter lite avancerad utbildning i riktning mot amerikansk BI.

I Nyligen En annan skadlig trend har dykt upp. Tack vare specialisering har den ömsesidiga förståelsen mellan olika kategorier av företagsanställda gått förlorad. En revisor, chef och programmerare, som "en svan, en kräfta och en gädda" i I.A.s fabel. Krylov, drar företaget åt olika håll.

Revisorn är upptagen med rapportering, hans belopp, både i betydelse och i dynamik, är inte direkt relaterade till företagets affärsprocess.

Chefen är upptagen med sin del av affärsprocessen, men kan inte globalt, på företagets nivå, utvärdera resultaten och utsikterna för sina handlingar.

Slutligen har programmeraren, som en gång (tack vare sin utbildning) var en ledare för avancerade tekniska idéer från vetenskapssfären till affärssfären, förvandlats till en passiv utförare av revisorns och chefens fantasier, så det är ingen längre ovanligt att företagens IT-avdelningar drivs av revisorer och i allmänhet alla som inte är lata. Brist på initiativ, analfabeter, men relativt högbetalda 1C-programmerare är ett verkligt gissel för ryska företag. (Nästan som en inhemsk fotbollsspelare.) Jag pratar inte ens om de så kallade "ekonomerna och advokaterna", allt har sagts om dem för länge sedan.

Så positionen för en affärsanalytiker, utrustad med en kunskapsintensiv SSAS-apparat, skicklig i grunderna i programmering och redovisning, är kapabel att konsolidera företagets arbete i förhållande till analysen och prognosen för affärsprocessen.

Fördelar med OLAP-kuber

OLAP-kub är modernt botemedel analys av företagets databas, vilket gör det möjligt att förse anställda på alla nivåer i hierarkin med den erforderliga uppsättningen av indikatorer som kännetecknar företagets produktionsprocess. Poängen är inte bara att det bekväma gränssnittet och det flexibla frågespråket för MDX-kuben (MultiDimensional eXpressions) låter dig formulera och beräkna de nödvändiga analytiska indikatorerna, utan även den anmärkningsvärda hastigheten och lättheten med vilken OLAP-kuben gör detta. Dessutom beror denna hastighet och lätthet, inom vissa gränser, inte på komplexiteten i beräkningarna och storleken på databasen.

Lite introduktion till OLAP-
kub kan ges av en "pivottabell" i MS Excel. Dessa objekt har liknande logik och liknande gränssnitt. Men, som kommer att framgå av artikeln, är OLAP-funktionaliteten ojämförligt rikare, och prestandan är ojämförligt högre, så "pivottabellen" förblir en lokal skrivbordsprodukt, medan OLAP är en produkt på företagsnivå.

Varför är OLAP-kuben så väl lämpad för att lösa analytiska problem? OLAP-kuben är utformad på ett sådant sätt att alla indikatorer i alla möjliga sektioner är förberäknade (helt eller delvis), och användaren kan bara "dra ut" de nödvändiga indikatorerna (måtten) och dimensionerna (måtten) med mus, och programmet kan rita om tabellerna.

All möjlig analys i alla sektioner bildar ett enormt fält, eller snarare, inte ett fält, utan bara en flerdimensionell OLAP-kub. Oavsett vilken begäran användaren (chef, affärsanalytiker, chef) vänder sig till analystjänsten förklaras svarshastigheten av två saker: för det första kan den nödvändiga analysen enkelt formuleras (antingen väljas från en lista med namn eller specificeras av en formeln på MDX-språket ), för det andra har den som regel redan beräknats.

Formuleringen av analys är möjlig i tre alternativ: det är antingen ett databasfält (eller snarare ett lagerfält), eller ett beräkningsfält definierat på kubdesignnivå, eller ett MDX-språkuttryck när man arbetar interaktivt med kuben.

Detta innebär flera attraktiva funktioner hos OLAP-kuber. I huvudsak försvinner barriären mellan användaren och data. Barriären är i form av en applikationsprogrammerare, som först måste förklara problemet (ställa in en uppgift). För det andra måste du vänta på att applikationsprogrammeraren ska skapa en algoritm, skriva och felsöka programmet och sedan eventuellt ändra det. Om det är många anställda och deras krav är varierande och föränderliga, så behövs ett helt team av applikationsprogrammerare. I den meningen ersätter en OLAP-kub (och en kvalificerad affärsanalytiker) ett helt team av applikationsprogrammerare när det gäller analytiskt arbete, precis som en kraftfull grävmaskin med en grävmaskinist ersätter ett helt team migrantarbetare med spadar när de gräver ett dike!

Samtidigt uppnås en annan mycket viktig kvalitet hos den erhållna analysdatan. Eftersom det bara finns en OLAP-kub för hela företaget, d.v.s. Detta är samma fält med analytiker för alla, vilket eliminerar irriterande avvikelser i data. När en chef måste ställa samma uppgift till flera oberoende medarbetare för att eliminera subjektivitetsfaktorn, men de ändå kommer med olika svar, som alla åtar sig att förklara på något sätt osv. OLAP-kuben säkerställer enhetlighet för analytisk data på olika nivåer i företagshierarkin, dvs. om en chef vill specificera en viss indikator som är intressant för honom, kommer han säkert att komma till de data på lägre nivå som hans underordnade arbetar med, och detta kommer att vara exakt de data på grundval av vilka indikatorn på högre nivå beräknades , och inte någon annan data, mottagen på något annat sätt, vid någon annan tidpunkt osv. Det vill säga att hela företaget ser samma analys, men på olika nivåer av aggregering.

Låt oss ge ett exempel. Låt oss säga att en chef kontrollerar kundfordringar. Så länge som KPI:n för förfallna fordringar är grön betyder det att allt är normalt och inga hanteringsåtgärder krävs. Om färgen har ändrats till gul eller röd är något fel: vi skär KPI:erna av försäljningsavdelningarna och ser omedelbart avdelningarna "i rött". Nästa avsnitt av chefer - och säljaren vars kunder ligger efter med betalningar identifieras. (Vidare kan det förfallna beloppet delas upp efter kunder, efter villkor etc.) Chefen för företaget kan direkt kontakta överträdarna på vilken nivå som helst. Men generellt sett ses samma KPI (på deras hierarkinivåer) av både avdelningschefer och försäljningschefer. Därför, för att korrigera situationen, behöver de inte ens vänta på ett "samtal på mattan"... Självklart behöver KPI:et i sig inte nödvändigtvis vara mängden försenade betalningar - det kan vara vägd genomsnittlig tid för försenade betalningar eller, i allmänhet, omsättningshastigheten för fordringar.

Låt oss notera att komplexiteten och flexibiliteten hos MDX-språket, tillsammans med de snabba (ibland omedelbara) resultaten, gör det möjligt för oss att lösa (med hänsyn till utvecklingsstadierna och felsökning) komplexa kontrolluppgifter som annars kanske inte hade ställts alls. på grund av komplexiteten för applikationsprogrammerare och initial osäkerhet i formuleringen. (Långa deadlines för applikationsprogrammerare att lösa analytiska problem på grund av dåligt förstådda formuleringar och långa modifieringar av program när villkoren förändras uppstår ofta i praktiken.)

Låt oss också vara uppmärksamma på det faktum att varje anställd i företaget kan samla in en OLAP-analytiker från det allmänna fältet exakt skörden som han behöver för sitt arbete, och inte nöja oss med "remsan" som är utskuren för honom i gemensamt "standardrapporter".

Fleranvändargränssnittet för att arbeta med en OLAP-kub i klient-server-läge tillåter varje anställd, oberoende av andra, att ha sina egna (även självgjorda med vissa färdigheter) analysblock (rapporter), som, när de väl har definierats, automatiskt uppdaterade - med andra ord, de är alltid uppdaterade skick.

Det vill säga, OLAP-kuben låter dig göra analytiskt arbete (som faktiskt utförs inte bara av receptionsanalytiker, utan faktiskt av nästan alla anställda på företaget, även logistiker och chefer som kontrollerar saldon och transporter) mer selektivt, ”inte generellt” , vilket skapar förutsättningar för att förbättra arbetet och öka produktiviteten.

För att sammanfatta vår introduktion noterar vi att användningen av OLAP-kuber kan höja ledningen av ett företag med mer hög nivå. Likformigheten hos analytiska data på alla nivåer i hierarkin, deras tillförlitlighet, komplexitet, lätthet att skapa och modifiera indikatorer, individuella inställningar, hög databehandlingshastighet och slutligen spara pengar och tid på att stödja alternativa analytiska vägar (applikationsprogrammerare, anställdas oberoende beräkningar) öppnar möjligheter för användningen av OLAP-kuber i praktiken av stora ryska företag.

OLTP + OLAP: återkopplingsslinga i företagsledningskedjan

Låt oss nu titta på den allmänna idén om OLAP-kuber och deras tillämpningspunkt i företagsledningskedjan. Termen OLAP (OnLine Analytical Processing) introducerades av den brittiske matematikern Edgar Codd utöver hans tidigare introducerade term OLTP (OnLine Transactions Processing). Detta kommer att diskuteras senare, men E. Codd föreslog naturligtvis inte bara termerna utan också de matematiska teorierna för OLTP och OLAP. Utan att gå in på detaljer, i den moderna tolkningen, är OLTP en relationsdatabas, betraktad som en mekanism för att registrera, lagra och hämta information.

Lösningsmetodik

ERP-system (Enterprice Resource Planning), som 1C7, 1C8, MS Dynamics AX, har användarorienterade mjukvarugränssnitt (inmatning och redigering av dokument etc.) och en relationsdatabas (DB) för lagring och hämtning av information som presenteras idag mjukvaruprodukter typ MS SQL Server (SS).

Observera att informationen som registreras i affärssystemets databas verkligen är en mycket värdefull resurs. Poängen är inte bara att den registrerade informationen säkerställer företagets aktuella dokumentflöde (utdrag av dokument, korrigering av dem, möjligheten att skriva ut och stämma av etc.) och inte bara möjligheten till beräkning bokslut(skatter, revision etc.). Ur ledningssynpunkt är det mycket viktigare att OLTP-systemet (relationsdatabasen) i själva verket är en verklig digital modell i naturlig storlek av företagets verksamhet.

Men för att hantera processen räcker det inte att registrera information om den. Processen bör presenteras i form av ett system av numeriska indikatorer (KPI) som kännetecknar dess framsteg. Dessutom måste acceptabla värdeintervall definieras för indikatorer. Och endast om värdet på indikatorn faller utanför det tillåtna intervallet, bör en kontrollåtgärd följa.

När det gäller en sådan logik (eller mytologi) av kontroll ("kontroll genom avvikelse"), båda forntida grekisk filosof Platon, som skapade bilden av rorsmannen (cybernosen), som lutar sig mot åran när båten avviker från kursen, och den amerikanske matematikern Norbert Wiener, som skapade vetenskapen om cybernetik på tröskeln till dataepoken.

Utöver det vanliga systemet för att registrera information med OLTP-metoden behövs ett annat system - ett system för att analysera den insamlade informationen. Detta tillägg, som i styrslingan spelar rollen som återkoppling mellan ledning och styrobjekt, är ett OLAP-system eller kort och gott en OLAP-kub.

Som en mjukvaruimplementering av OLAP kommer vi att överväga verktyget MS Analysis Services, som är en del av standardleveransen av MS SQL Server, förkortat SSAS. Observera att, enligt E. Codds plan, bör OLAP-kuben i analys ge samma omfattande handlingsfrihet som OLTP-systemet och relationsdatabasen (SQL Server) ger vid lagring och hämtning av information.

OLAP Logistik

Låt oss nu titta på den specifika konfigurationen av externa enheter, applikationsprogram och tekniska operationer som den automatiserade driften av OLAP-kuben är baserad på.

Vi antar att företaget använder ett affärssystem, till exempel 1C7 eller 1C8, i vilket information registreras som vanligt. Databasen för detta affärssystem finns på en viss server och stöds av MS SQL Server.

Vi kommer också att anta att en annan server har programvara installerad, inklusive MS SQL Server med verktyget MS Analysis Services (SSAS), samt MS SQL Server Management Studio, MS C#, MS Excel och MS Visual Studio. Dessa program bildar tillsammans det nödvändiga sammanhanget: verktygen och nödvändiga gränssnitten för utvecklaren av OLAP-kuber.

SSAS-servern har ett fritt distribuerat program som heter blat, anropat (med parametrar) från kommandorad och tillhandahåller posttjänster.

På anställdas arbetsstationer, inom lokalt nätverk, bland annat MS Excel-program (versioner inte mindre än 2003) installeras, samt eventuellt en speciell drivrutin för att säkerställa att MS Excel fungerar med MS Analysis Services (såvida inte motsvarande drivrutin redan ingår i MS Excel).

För tydlighetens skull kommer vi att anta att operativsystemet Windows XP är installerat på anställdas arbetsstationer och Windows Server 2008 på servrarna. Låt oss dessutom använda MS SQL Server 2005 som SQL Server och låta Enterprise Edition (EE) installeras på servern med OLAP-kuben ) eller Developer Edition (DE). I dessa utgåvor är det möjligt att använda den sk. ”semi-additiva åtgärder”, dvs. ytterligare aggregerade funktioner (statistik) andra än vanliga summor (till exempel extremum eller medelvärde).

OLAP-kubdesign (OLAP-kubism)

Låt oss säga några ord om designen av själva OLAP-kuben. På statistikspråket är en OLAP-kub en uppsättning prestationsindikatorer som beräknas i alla nödvändiga avsnitt, till exempel leveransindikatorn i sektioner av kunder, efter varor, efter datum, etc. På grund av direkt översättning från engelska i rysk litteratur om OLAP-kuber kallas indikatorer för "mått", och sektioner kallas "dimensioner". Detta är en matematiskt korrekt, men syntaktisk och semantiskt inte särskilt lyckad översättning. De ryska orden "mått", "dimension", "dimension" är nästan lika i betydelse och stavning, medan de engelska "mått" och "dimension" är olika i både stavning och betydelse. Därför ger vi företräde åt de traditionella ryska statistiska termerna "indikator" och "cut", som har liknande betydelse.

Det finns flera alternativ för mjukvaruimplementering av en OLAP-kub i förhållande till OLTP-systemet där data registreras. Vi kommer bara att överväga ett schema, det enklaste, mest pålitliga och snabbaste.

I den här designen delar OLAP och OLTP inte tabeller, och OLAP-analys beräknas så detaljerat som möjligt under kubuppdateringsstadiet (process), som föregår användningsstadiet. Detta schema kallas MOLAP (Multidimensional OLAP). Dess nackdelar är asynkron med ERP och höga minneskostnader.

Även om en OLAP-kub formellt sett kan byggas med alla (tusentals) relationsdatabastabeller för ERP-systemet som datakälla och alla (hundratals) deras fält som indikatorer eller sektioner, bör detta i själva verket inte göras. Vice versa. För att ladda in i en kub är det mer korrekt att förbereda en separat databas, kallad "showcase" eller "lager".

Flera skäl tvingar oss att göra detta.

• För det första, binda OLAP-kub till tabeller riktig bas data kommer säkerligen att skapa tekniska problem. Att ändra data i en tabell kan utlösa en uppdatering av kuben, och att uppdatera en kub är inte nödvändigtvis en snabb process, så kuben kommer att vara i ett tillstånd av konstant ombyggnad; Samtidigt kan kubuppdateringsproceduren blockera (vid läsning) data i databastabellerna, vilket saktar ner användarnas arbete med att registrera data i affärssystemet.
• För det andra, Att ha för många indikatorer och skärningar kommer att dramatiskt öka lagringsytan för kuben på servern. Låt oss inte glömma att OLAP-kuben lagrar inte bara källdata, som i OLTP-systemet, utan också alla indikatorer sammanfattade över alla möjliga sektioner (och till och med alla kombinationer av alla sektioner). Dessutom kommer hastigheten för att uppdatera kuben och i slutändan hastigheten för att bygga och uppdatera analyser och användarrapporter baserade på dem sakta ner i enlighet med detta.
• Tredje, för många fält (indikatorer och sektioner) kommer att skapa problem i OLAP-utvecklargränssnittet, eftersom listorna över element kommer att bli enorma.
• För det fjärde, OLAP-kuben är mycket känslig för dataintegritetsöverträdelser. Kuben kan inte byggas om nyckeldata inte finns på länken som anges i strukturen för kubfältsanslutningarna. Tillfälliga eller permanenta integritetsbrott, tomma fält är vanliga i en ERP-systemdatabas, men detta är absolut inte lämpligt för OLAP.

Du kan också lägga till att ERP-systemet och OLAP-kuben ska finnas på olika servrar för att dela belastningen. Men sedan, om det finns gemensamma tabeller för OLAP och OLTP, uppstår också problemet med nätverkstrafik. Praktiskt taget olösliga problem uppstår i detta fall när det är nödvändigt att konsolidera flera olika ERP-system (1C7, 1C8, MS Dynamics AX) till en OLAP-kub.

Förmodligen kan vi fortsätta att lägga upp tekniska problem. Men viktigast av allt, kom ihåg att, till skillnad från OLTP, är OLAP inte ett sätt att registrera och lagra data, utan ett analysverktyg. Detta innebär att det inte finns något behov av att ladda upp och ladda ner "smutsig" data från ERP till OLAP "för säkerhets skull." Tvärtom måste du först utveckla ett koncept för att hantera företaget, åtminstone på nivån för KPI-systemet, och sedan designa ett applikationsdatalager (lager), som ligger på samma server som OLAP-kuben och innehåller en liten , förfinad mängd data från ERP som behövs för hanteringen .

Utan att främja dåliga vanor, OLAP-kuben i förhållande till OLTP kan liknas vid den välkända "still-kuben", genom vilken den "rena produkten" extraheras från den "fermenterade massan" av den verkliga registreringen.

Så vi fick att datakällan för OLAP är en speciell databas (lager), som ligger på samma server som OLAP. Generellt betyder detta två saker. För det första måste det finnas speciella procedurer som skapar ett lager från ERP-databaser. För det andra är OLAP-kuben asynkron med sina ERP-system.

Med hänsyn till ovanstående föreslår vi följande version av datorprocessarkitekturen.

Lösningsarkitektur

Anta att det finns många affärssystem för ett visst företag (innehav) på olika servrar, de analytiska data som vi skulle vilja se konsoliderade inom en OLAP-kub. Vi betonar att vi i den beskrivna tekniken kombinerar data från affärssystem på lagernivå, vilket lämnar designen av OLAP-kuben oförändrad.

På OLAP-servern skapar vi bilder (tomma kopior) av databaserna för alla dessa affärssystem. Vi utför periodvis (natt) partiell replikering av motsvarande aktiva ERP-databaser på dessa tomma kopior.

Därefter lanseras SP (lagrad procedur), som på samma OLAP-server utan nätverkstrafik, baserat på partiella repliker av ERP-systemdatabaser, skapar (eller fyller på) ett lager (lager) - datakällan för OLAP-kuben.

Därefter lanseras standardproceduren för att uppdatera/bygga en kub baserad på lagerdata (Processoperation i SSAS-gränssnittet).

Låt oss kommentera några aspekter av tekniken. Vilken typ av arbete gör SP:er?

Som ett resultat av partiell replikering visas aktuella data i bilden av något ERP-system på OLAP-servern. Förresten, partiell replikering kan utföras på två sätt.

För det första, från alla tabeller i ERP-systemdatabasen, under partiell replikering, kopieras endast de som behövs för att bygga ett lager. Detta styrs av en fast lista med tabellnamn.

För det andra kan partiell replikering också innebära att inte alla fält i tabellen kopieras, utan bara de som är involverade i att bygga lagret. Listan över fält som ska kopieras är antingen specificerad eller dynamiskt skapad i SP i bilden av kopian (om inte alla fält initialt finns i kopian av tabellen).

Naturligtvis är det möjligt att inte kopiera hela tabellrader, utan bara att lägga till nya poster. Detta skapar dock allvarliga olägenheter när man bokför ERP-revisioner "retroaktivt", vilket ofta är fallet i verkliga system. Så det är lättare, utan vidare, att kopiera alla poster (eller uppdatera "svansen" från ett visst datum).

Därefter är SP:s huvuduppgift att konvertera ERP-systemdata till lagerformat. Om det bara finns ett ERP-system, så handlar uppgiften att konvertera huvudsakligen om att kopiera och eventuellt formatera om nödvändig data. Men om du behöver konsolidera flera affärssystem i samma OLAP-kub olika strukturer, då blir omvandlingarna mer komplicerade.

Uppgiften att konsolidera flera olika affärssystem i en kub är särskilt svår om uppsättningarna av deras objekt (varukataloger, entreprenörer, lager etc.) delvis överlappar varandra, objekten har samma betydelse, men beskrivs naturligtvis olika i katalogerna olika system(i betydelsen koder, identifierare, namn etc.).

I verkligheten uppstår en sådan bild i ett stort holdingbolag, när flera av dess ingående autonoma bolag av samma typ bedriver ungefär samma typ av verksamhet på ungefär samma territorium, men använder sina egna och icke överenskomna registreringssystem. I det här fallet, när du konsoliderar data på lagernivå, kan du inte klara dig utan extra mappningstabeller.

Låt oss ägna lite uppmärksamhet åt lagerarkitekturen. Vanligtvis representeras ett OLAP-kubschema i form av en "stjärna", dvs. som en datatabell omgiven av "strålar" av kataloger - tabeller med sekundära nyckelvärden. En tabell är ett block av "indikatorer", referensböcker är deras avsnitt. I det här fallet kan katalogen i sin tur vara ett godtyckligt obalanserat träd eller en balanserad hierarki, till exempel en flernivåklassificering av varor eller entreprenörer. I en OLAP-kub blir de numeriska fälten i en datatabell från ett lager automatiskt "indikatorer" (eller mått), och sektioner (eller dimensioner) kan definieras med hjälp av sekundära nyckeltabeller.

Detta är en visuell "pedagogisk" beskrivning. Faktum är att arkitekturen för en OLAP-kub kan vara mycket mer komplex.

För det första kan ett lager bestå av flera "stjärnor", eventuellt sammankopplade genom gemensamma kataloger. I det här fallet kommer OLAP-kuben att vara en förening av flera kuber (flera datablock).

För det andra kan "strålen" av en asterisk inte bara vara en katalog, utan ett helt (hierarkiskt) filsystem.

För det tredje, på basis av befintliga dimensionssektioner, kan nya hierarkiska sektioner definieras med hjälp av OLAP-utvecklargränssnittsverktygen (t.ex. med färre nivåer, med en annan nivåordning, etc.)

För det fjärde, baserat på befintliga indikatorer och avsnitt, med hjälp av MDX-språkuttryck, kan nya indikatorer (beräkningar) definieras. Det är viktigt att notera att nya kuber, nya indikatorer, nya sektioner automatiskt är helt integrerade med de ursprungliga elementen. Det bör också noteras att dåligt formulerade beräkningar och hierarkiska sektioner avsevärt kan bromsa driften av en OLAP-kub.

MS Excel som gränssnitt med OLAP

Av särskilt intresse är användargränssnittet med OLAP-kuber. Det mest kompletta gränssnittet tillhandahålls naturligtvis av själva SSAS-verktyget. Detta inkluderar en verktygssats för OLAP-kubutvecklare, en interaktiv rapportdesigner och ett fönster för interaktivt arbete med en OLAP-kub som använder frågor på MDX-språket.

Utöver själva SSAS finns det många program som tillhandahåller ett gränssnitt till OLAP, som täcker deras funktionalitet i större eller mindre utsträckning. Men bland dem finns det en, som enligt vår mening har obestridliga fördelar. Detta är MS Excel.

Gränssnittet med MS Excel tillhandahålls av en speciell drivrutin, nedladdningsbar separat eller ingår i Excel-distributionen. Den täcker inte all funktionalitet hos OLAP, men med tillväxten av MS Excel versionsnummer blir denna täckning bredare (till exempel visas en grafisk representation av KPI i MS Excel 2007, vilket inte var fallet i MS Excel 2003, etc.).

Naturligtvis, förutom dess ganska kompletta funktionalitet, är den största fördelen med MS Excel den utbredda spridningen av detta program och den nära förtrogenhet med det för det överväldigande antalet kontorsanvändare. I denna mening, till skillnad från andra gränssnittsprogram, behöver företaget inte köpa något extra och behöver inte utbilda någon ytterligare.

Den stora fördelen med MS Excel som gränssnitt med OLAP är möjligheten att ytterligare självständigt bearbeta data som erhålls i OLAP-rapporten (dvs. fortsätta att studera data som erhållits från OLAP på andra ark i samma Excel, inte längre med OLAP-verktyg, men med vanliga Excel-verktyg).

Facubi nattlig behandlingscykel

Nu kommer vi att beskriva den dagliga (nattliga) beräkningscykeln för OLAP-drift. Beräkningen utförs under kontroll av facubi-programmet, skrivet i C# 2005 och lanserat via Task Scheduler på en server med lager och SSAS. I början går facubi till Internet och läser aktuella växelkurser (används för att representera ett antal indikatorer i en valuta). Utför sedan följande steg.

Först lanserar facubi SPs som utför partiell replikering av databaserna för olika ERP-system (hållelement) tillgängliga på det lokala nätverket. Replikering utförs, som vi sa, till förberedda "bakgrunder" - bilder av fjärranslutna ERP-system som finns på SSAS-servern.

För det andra, genom SP, utförs en mappning från ERP-repliker till lagerlagringen - en speciell DB, som är källan till OLAP-kubdata och ligger på SSAS-servern. I det här fallet löses tre huvuduppgifter:

• ERP-data justeras till de nödvändiga kubformaten; Vi pratar om både tabeller och tabellfält. (Ibland måste den obligatoriska tabellen "formas", t.ex. från flera MS Excel-ark.) Liknande data kan ha olika format i olika affärssystem, till exempel har nyckel-ID-fält i 1C7-kataloger en 36-siffrig teckenkod med längden 8 , och _idrref-fält i kataloger 1С8 – hexadecimala tal med längden 32;
• under bearbetningen logisk datakontroll utförs (inklusive att skriva ”defaults” i stället för saknade data, där så är möjligt) och integritetskontroll, d.v.s. kontrollera närvaron av primära och sekundära nycklar i motsvarande klassificerare;
• kodkonsolidering objekt som har samma betydelse i olika affärssystem. Till exempel kan motsvarande delar av kataloger för olika affärssystem ha samma innebörd, säg att de är samma motpart. Problemet med att konsolidera koder löses genom att konstruera mappningstabeller, där olika koder för samma objekt sammanförs.

För det tredje lanserar facubi standardproceduren för uppdatering av processkubdata (från procedurerna för SSAS-verktyget).

Baserat på checklistorna skickar facubi mejl om hur bearbetningsstegen fortskrider.

Efter att ha kört facubi lanserar Task Scheduler flera excel-filer i tur och ordning, där rapporter är förskapade baserat på OLAP-kubindikatorer. Som vi sa har MS Excel ett speciellt mjukvarugränssnitt (separat nedladdningsbar eller inbyggd drivrutin) för att arbeta med OLAP-kuber (med SSAS). När du startar MS Excel aktiveras MS VBA-program (som makron), som säkerställer att data i rapporter uppdateras; rapporter modifieras vid behov och skickas per post (blat-program) till användarna enligt checklistor.

Lokala nätverksanvändare med åtkomst till SSAS-servern kommer att få "live"-rapporter konfigurerade för OLAP-kuben. (I princip kan de själva, utan någon post, uppdatera OLAP-rapporter i MS Excel som finns på sina lokala datorer.) Användare utanför det lokala nätverket kommer antingen att få de ursprungliga rapporterna, men med begränsad funktionalitet, eller för dem (efter uppdatering av OLAP:n) rapporter i MS Excel) kommer speciella "döda" rapporter som inte kommer åt SSAS-servern att beräknas.

Utvärdering av resultat

Vi pratade ovan om asynkroniseringen av OLTP och OLAP. I den aktuella teknikvarianten utförs uppdateringscykeln för OLAP-kuben på natten (säg att den börjar kl. 01.00). Det betyder att användare under den aktuella arbetsdagen arbetar med gårdagens data. Eftersom OLAP inte är ett inspelningsverktyg (titta på den senaste versionen av dokumentet), utan ett hanteringsverktyg (förstå trenden i processen), är en sådan fördröjning vanligtvis inte kritisk. Men vid behov, även i den beskrivna versionen av kubarkitekturen (MOLAP), kan uppdateringen utföras flera gånger om dagen.

Exekveringstiden för uppdateringsprocedurer beror på designfunktionerna hos OLAP-kuben (mer eller mindre komplexitet, mer eller mindre framgångsrika definitioner av indikatorer och sektioner) och på volymen av databaser för externa OLTP-system. Enligt erfarenhet tar lagerbyggnadsproceduren från flera minuter till två timmar, kubuppdateringsproceduren (Process) tar från 1 till 20 minuter. Vi talar om komplexa OLAP-kuber som förenar dussintals strukturer av stjärntyp, dussintals vanliga "strålar" (referenssektioner) för dem och hundratals indikatorer. Genom att uppskatta volymen av databaser för externa affärssystem baserade på fraktdokument talar vi om hundratusentals dokument och följaktligen miljontals produktlinjer per år. Det historiska bearbetningsdjupet av intresse för användaren var tre till fem år.

Den beskrivna tekniken har använts i ett antal stora företag: sedan 2008 i Russian Fish Company (RRK) och Russian Sea Company (RM), sedan 2012 i Santa Bremor Company (SB). Vissa företag är främst handels- och inköpsföretag (PPC), andra är produktionsföretag (anläggningar för bearbetning av fisk och skaldjur i Moldavien och Republiken Vitryssland). Alla företag är stora innehav, som förenar flera företag med oberoende och olika datorredovisningssystem - allt från vanliga affärssystem som 1C7 och 1C8 till "relic" redovisningssystem baserade på DBF och Excel. Jag kommer att tillägga att den beskrivna tekniken för att driva OLAP-kuber (utan att ta hänsyn till utvecklingsstadiet) antingen inte kräver speciella anställda alls, eller är ansvaret för en heltidsanställd affärsanalytiker. Uppgiften har körts automatiskt i flera år, vilket ger olika kategorier av företagsanställda uppdaterad rapportering på daglig basis.

För- och nackdelar med lösningen

Erfarenheten visar att den föreslagna lösningen är ganska tillförlitlig och lätt att använda. Det är lätt att modifiera (anslutning/bortkoppling av nya affärssystem, skapande av nya indikatorer och sektioner, skapande och modifiering av Excel-rapporter och deras e-postlistor) med invariansen av facubi-kontrollprogrammet.

MS Excel som gränssnitt med OLAP ger tillräcklig uttrycksförmåga och gör att olika kategorier av kontorsanställda snabbt kan bli bekanta med OLAP-teknik. Användaren får dagliga "standard" OLAP-rapporter; genom att använda MS Excel-gränssnittet med OLAP, kan du självständigt skapa OLAP-rapporter i MS Excel. Dessutom kan användaren självständigt fortsätta att studera informationen i OLAP-rapporter med hjälp av de vanliga funktionerna i hans MS Excel.

Den "förfinade" lagerdatabasen, i vilken flera heterogena ERP-system konsolideras (under kubens konstruktion), även utan någon OLAP, låter dig lösa (på en SSAS-server, med frågemetoden i Transact SQL eller SP-metoden , etc.) många tillämpade förvaltningsproblem. Låt oss komma ihåg att lagerets databasstruktur är enhetlig och mycket enklare (när det gäller antalet tabeller och antalet tabellfält) än databasstrukturerna i den ursprungliga ERP:n.

Vi noterar särskilt att i vår föreslagna lösning finns möjligheten att konsolidera olika affärssystem i en OLAP-kub. Detta gör att du kan få analyser för hela innehavet och upprätthålla en långsiktig kontinuitet i analysen när ett företag flyttar till ett annat redovisnings-ERP-system, till exempel när du går från 1C7 till 1C8.

Vi använde MOLAP-kubmodellen. Fördelarna med denna modell är tillförlitlighet i drift och hög hastighet att behandla användarförfrågningar. Nackdelar: OLAP och OLTP är asynkrona, liksom stora mängder minne för lagring av OLAP.

Sammanfattningsvis, här är ytterligare ett argument till förmån för OLAP som kunde ha varit mer lämpligt under medeltiden. Eftersom dess beviskraft vilar på auktoritet. En blygsam, klart underskattad brittisk matematiker E. Codd utvecklade teorin om relationsdatabaser i slutet av 60-talet. Kraften i denna teori var sådan att det nu, efter 50 år, redan är svårt att hitta en icke-relationell databas och ett annat databasfrågespråk än SQL.

OLTP-teknik, baserad på teorin om relationsdatabaser, var E. Codds första idé. Faktum är att begreppet OLAP-kuber är hans andra idé, uttryckt av honom i början av 90-talet. Även utan att vara matematiker kan du förvänta dig att den andra idén kommer att vara lika effektiv som den första. Det vill säga när det gäller datoranalys kommer OLAP-idéer snart att ta över världen och ersätta alla andra. Helt enkelt för att ämnet analys hittar sin heltäckande matematiska lösning i OLAP, och denna lösning är "tillräcklig" (B. Spinozas term) för det praktiska problemet med analys. "Adekvat" betyder i Spinoza att Gud själv inte kunde ha tänkt på något bättre...

1. Larson B. Utveckling av affärsanalys i Microsoft SQL Server 2005. – St. Petersburg: "Peter", 2008.
2. Codd E. Relational Completeness of Data Base Sublanguages, Data Base Systems, Courant Computer Science Sumposia Series 1972, v. 6, Englwood cliffs, N.Y., Prentice – Hall.

I kontakt med

I allmänhet vet varje specialist vad OLAP är idag. Åtminstone är begreppen "OLAP" och "flerdimensionell data" fast förbundna i våra sinnen. Jag hoppas dock att det faktum att detta ämne tas upp igen kommer att godkännas av majoriteten av läsarna, för för att idén om något inte ska bli föråldrad med tiden måste du regelbundet kommunicera med smarta människor eller läs artiklar i en bra publikation...

Datalager (platsen för OLAP i företagets informationsstruktur)

Termen "OLAP" är oupplösligt kopplad till termen "data warehouse" (Data Warehouse).

Här är definitionen formulerad av "grundläggaren" av datalager, Bill Inmon: "Ett datalager är en domänspecifik, tidsbunden, oföränderlig samling av data för att stödja ledningens beslutsfattande."

Datan i lagret kommer från operativa system (OLTP-system), som är designade för att automatisera affärsprocesser. Dessutom kan förvaret fyllas på från externa källor, såsom statistiska rapporter.

Varför bygga datalager - trots allt innehåller de uppenbart överflödig information som redan "bor" i databaser eller operativsystemfiler? Svaret kan vara kort: det är omöjligt eller mycket svårt att direkt analysera data från operativsystem. Detta beror på olika anledningar, inklusive fragmentering av data, dess lagring i olika DBMS-format och i olika "hörn" av företagsnätverket. Men även om ett företag lagrar all sin data på en central databasserver (vilket är extremt sällsynt), kommer en analytiker nästan säkert inte att förstå deras komplexa, ibland förvirrande strukturer. Författaren har en ganska sorglig erfarenhet av att försöka "mata" hungriga analytiker med "rå" data från operativa system - det visade sig vara "för mycket för dem".

Syftet med förvaret är alltså att tillhandahålla ”råvarorna” för analys på ett ställe och i en enkel, begriplig struktur. Ralph Kimball, i förordet till sin bok "The Data Warehouse Toolkit", skriver att om läsaren efter att ha läst hela boken bara förstår en sak - nämligen att strukturen på lagret ska vara enkel - kommer författaren att överväga sin uppgift avslutad.

Det finns ytterligare ett skäl som motiverar uppkomsten av en separat lagringsanläggning - komplexa analytiska frågor för operativ information saktar ner företagets nuvarande arbete, blockerar tabeller under lång tid och lägger beslag på serverresurser.

Enligt min mening behöver ett förvar inte nödvändigtvis innebära en gigantisk ansamling av data – huvudsaken är att det är bekvämt för analys. Generellt sett finns det en separat term för små lagringsanläggningar - Data Marts (datakiosker), men i vår ryska praxis hör du det inte ofta.

OLAP - ett bekvämt analysverktyg

Centralisering och bekväm strukturering är inte allt som en analytiker behöver. Han behöver fortfarande ett verktyg för att se och visualisera information. Traditionella rapporter, även de som bygger på ett enda förråd, saknar en sak - flexibilitet. De kan inte "tvinnas", "expanderas" eller "komprimeras" för att få önskad bild av data. Naturligtvis kan du ringa en programmerare (om han vill komma), och han (om han inte är upptagen) kommer att göra en ny rapport snabbt nog - säg inom en timme (jag skriver det här och jag tror inte på det själv - det går inte så snabbt i livet, låt oss ge honom tre timmar). Det visar sig att en analytiker inte kan testa mer än två idéer per dag. Och han (om han är en bra analytiker) kan komma på flera sådana idéer per timme. Och ju fler "skivor" och "sektioner" av data analytikern ser, desto fler idéer har han, som i sin tur kräver fler och fler "skivor" för verifiering. Om han bara hade ett verktyg som skulle tillåta honom att expandera och kollapsa data enkelt och bekvämt! OLAP fungerar som ett sådant verktyg.

Även om OLAP inte är ett nödvändigt attribut för ett datalager, används det allt oftare för att analysera informationen som samlas i lagret.

Komponenterna som ingår i ett typiskt förvar visas i fig. 1.

Ris. 1. Datalagerstruktur

Verksamhetsdata samlas in från olika källor, rensas, integreras och lagras i ett relationslager. Dessutom är de redan tillgängliga för analys med hjälp av olika rapporteringsverktyg. Därefter förbereds data (helt eller delvis) för OLAP-analys. De kan laddas in i en speciell OLAP-databas eller lagras i relationslagring. Dess viktigaste element är metadata, det vill säga information om struktur, placering och transformation av data. Tack vare dem säkerställs effektiv interaktion mellan olika lagringskomponenter.

För att sammanfatta kan vi definiera OLAP som en uppsättning verktyg för multidimensionell analys av data som ackumuleras i ett lager. Teoretiskt kan OLAP-verktyg appliceras direkt på operativa data eller deras exakta kopior (för att inte störa operativa användare). Men vi riskerar därmed att trampa på den rake som redan beskrivits ovan, d.v.s. börja analysera operativa data som inte är direkt lämpliga för analys.

Definition och grundläggande begrepp för OLAP

Först, låt oss dechiffrera: OLAP är Online Analytical Processing, det vill säga operationell dataanalys. De 12 definierande principerna för OLAP formulerades 1993 av E. F. Codd, "uppfinnaren" av relationsdatabaser. Senare omarbetades dess definition till det så kallade FASMI-testet, vilket kräver att OLAP-applikationen ger möjlighet att snabbt analysera delad flerdimensionell information ().

FASMI test

Snabb(Snabb) - analys bör utföras lika snabbt på alla aspekter av informationen. Acceptabel svarstid är 5 sekunder eller mindre.

Analys(Analys) - det måste vara möjligt att utföra grundläggande typer av numerisk och statistisk analys, fördefinierad av applikationsutvecklaren eller fritt definierad av användaren.

Delad(Delad) – många användare måste ha tillgång till data, samtidigt som det är nödvändigt att kontrollera åtkomsten till konfidentiell information.

Flerdimensionell(Multidimensional) är den viktigaste, mest väsentliga egenskapen hos OLAP.

Information(Information) - applikationen måste kunna komma åt all nödvändig information, oavsett dess volym och lagringsplats.

OLAP = Flerdimensionell vy = Kub

OLAP erbjuder bekväma, snabba sätt att komma åt, visa och analysera affärsinformation. Användaren får en naturlig, intuitiv datamodell som organiserar dem i form av flerdimensionella kuber (kuber). Axlarna i det flerdimensionella koordinatsystemet är huvudattributen för den analyserade affärsprocessen. För försäljning kan det till exempel vara produkt, region, typ av köpare. Tid används som en av dimensionerna. I skärningspunkterna mellan axlarna - dimensioner (Dimensioner) - finns data som kvantitativt karakteriserar processen - mått (mått). Detta kan vara försäljningsvolymer i bitar eller i monetära termer, lagersaldon, kostnader etc. En användare som analyserar information kan "klippa" kuben i olika riktningar, få en sammanfattning (till exempel efter år) eller omvänt detaljerad (per vecka) ) information och utföra andra manipulationer som kommer till honom under analysprocessen.

Som mått i den tredimensionella kuben som visas i fig. 2 används försäljningsbelopp och tid, produkt och butik används som dimensioner. Mätningar presenteras på specifika grupperingsnivåer: produkter grupperas efter kategori, butiker efter land och transaktionstidsdata per månad. Lite senare kommer vi att titta på nivåerna för gruppering (hierarki) mer i detalj.

Ris. 2. Kubexempel

"Skär" en kub

Även en tredimensionell kub är svår att visa på en datorskärm så att värdena för de intressanta måtten är synliga. Vad kan vi säga om kuber med mer än tre dimensioner? För att visualisera data lagrad i en kub används som regel välbekanta tvådimensionella, det vill säga tabellvyer med komplexa hierarkiska rad- och kolumnrubriker.

En tvådimensionell representation av en kub kan erhållas genom att "skära" den över en eller flera axlar (dimensioner): vi fixar värdena för alla dimensioner utom två, och vi får en vanlig tvådimensionell tabell. Tabellens horisontella axel (kolumnrubriker) representerar en dimension, den vertikala axeln (radrubriker) representerar en annan, och tabellcellerna representerar måttens värden. I det här fallet betraktas en uppsättning mått faktiskt som en av dimensionerna - vi väljer antingen ett mått att visa (och sedan kan vi placera två dimensioner i rad- och kolumnrubrikerna), eller visar flera mått (och sedan en av tabellaxlar kommer att upptas av namnen på måtten och de andra - värden för den enda "oklippta" dimensionen).

Ta en titt på fig. 3 - här är en tvådimensionell del av kuben för ett mått - Enhetsförsäljning (sålda stycken) och två "oklippta" dimensioner - Butik (Butik) och Tid (Tid).

Ris. 3. 2D-kubskiva för ett mått

I fig. Figur 4 visar bara en "oskuren" dimension - Butik, men den visar värden för flera mått - Enhetsförsäljning (sålda enheter), Butiksförsäljning (försäljningsbelopp) och Butikskostnad (butikskostnader).

Ris. 4. 2D-kubskiva för flera mått

En tvådimensionell representation av en kub är också möjlig när fler än två dimensioner förblir "oskurna". I det här fallet kommer två eller flera dimensioner av den "skurna" kuben att placeras på skivaxlarna (rader och kolumner) - se fig. 5.

Ris. 5. 2D-kubskiva med flera dimensioner på en axel

Taggar

Värdena "lagda" längs dimensioner kallas medlemmar eller etiketter. Etiketter används både för att "klippa ut" kuben och för att begränsa (filtrera) vald data - när vi i en dimension som förblir "oklippt" inte är intresserade av alla värden, utan av en delmängd av dem, till exempel tre städer av flera dussin. Etikettvärden visas i 2D-kubvyn som rad- och kolumnrubriker.

Hierarkier och nivåer

Etiketter kan kombineras till hierarkier som består av en eller flera nivåer. Till exempel är etiketterna för dimensionen Butik naturligt grupperade i en hierarki med nivåer:

Land

stat

Stad

Lagra.

Aggregerade värden beräknas enligt hierarkinivåerna, till exempel försäljningsvolym för USA ("Lands"-nivå) eller för Kalifornien ("State"-nivå). Det är möjligt att implementera mer än en hierarki i en dimension - säg för tid: (År, Kvartal, Månad, Dag) och (År, Vecka, Dag).

Arkitektur av OLAP-applikationer

Allt som sades ovan om OLAP hänförde sig huvudsakligen till multidimensionell presentation av data. Hur datan lagras berör, grovt sett, varken slutanvändaren eller utvecklarna av verktyget klienten använder.

Flerdimensionalitet i OLAP-applikationer kan delas in i tre nivåer:

• Multidimensionell datarepresentation - slutanvändarverktyg som tillhandahåller multidimensionell visualisering och manipulering av data; Det flerdimensionella representationsskiktet abstraherar från den fysiska strukturen av datan och behandlar datan som flerdimensionell.
• Flerdimensionell bearbetning är ett medel (språk) för att formulera flerdimensionella frågor (det traditionella relationsspråket SQL är olämpligt här) och en processor som kan bearbeta och exekvera en sådan fråga.
• Flerdimensionell lagring är ett sätt att fysiskt organisera data som säkerställer effektiv exekvering av flerdimensionella frågor.

De två första nivåerna är obligatoriska i alla OLAP-verktyg. Den tredje nivån, även om den är utbredd, är inte nödvändig, eftersom data för en multidimensionell representation kan extraheras från vanliga relationsstrukturer; Den flerdimensionella frågeprocessorn översätter i detta fall flerdimensionella frågor till SQL-frågor som exekveras av den relationella DBMS.

Specifika OLAP-produkter är som regel antingen ett multidimensionellt datarepresentationsverktyg, en OLAP-klient (till exempel pivottabeller i Excel 2000 från Microsoft eller ProClarity från Knosys), eller en flerdimensionell server-DBMS, en OLAP-server (till exempel Oracle Express Server eller Microsoft OLAP Services).

Det flerdimensionella bearbetningsskiktet är vanligtvis inbyggt i OLAP-klienten och/eller OLAP-servern, men kan isoleras i sin rena form, såsom Microsofts Pivot Table Service-komponent.

Tekniska aspekter av multidimensionell datalagring

Som nämnts ovan kan OLAP-analysverktyg också extrahera data direkt från relationssystem. Detta tillvägagångssätt var mer attraktivt på den tiden då OLAP-servrar inte ingick i prislistorna för ledande DBMS-tillverkare. Men idag erbjuder Oracle, Informix och Microsoft fullfjädrade OLAP-servrar, och även de IT-chefer som inte gillar att skapa en "zoo" av mjukvara från olika tillverkare i sina nätverk kan köpa (eller snarare göra en motsvarande begäran till företagsledningen ) OLAP-server av samma märke som huvuddatabasservern.

OLAP-servrar, eller flerdimensionella databasservrar, kan lagra sina flerdimensionella data på olika sätt. Innan vi överväger dessa metoder måste vi prata om en så viktig aspekt som att lagra enheter. Faktum är att i vilket datalager som helst - både vanligt och flerdimensionellt - tillsammans med detaljerad data extraherad från operativa system, lagras även sammanfattningsindikatorer (aggregerade indikatorer, aggregationer), såsom summan av försäljningsvolymer per månad, per kategori varor, etc. Aggregat lagras uttryckligen i det enda syftet att påskynda utförandet av förfrågningar. När allt kommer omkring, å ena sidan, som regel, ackumuleras en mycket stor mängd data i lagret, och å andra sidan är analytiker i de flesta fall inte intresserade av detaljerade, utan av generaliserade indikatorer. Och om miljontals individuella försäljningar måste läggas ihop varje gång för att beräkna den totala försäljningen för året, skulle hastigheten med största sannolikhet vara oacceptabel. Därför, när data laddas in i en flerdimensionell databas, beräknas och sparas alla totala indikatorer eller delar av dem.

Men du måste som bekant betala för allt. Och för snabbheten att bearbeta förfrågningar om sammanfattningsdata måste du betala för en ökning av datamängder och tid för att ladda dem. Dessutom kan en ökning av volymen vara bokstavligt talat katastrofal - i ett av de publicerade standardtesterna krävde en fullständig beräkning av aggregat för 10 MB källdata 2,4 GB, d.v.s. data växte 240 gånger! Graden av data "svällning" vid beräkning av aggregat beror på antalet dimensioner av kuben och strukturen av dessa dimensioner, det vill säga förhållandet mellan antalet "fäder" och "barn" på olika mätnivåer. För att lösa problemet med att lagra enheter används de ibland komplexa kretsar, som gör det möjligt att uppnå en betydande ökning av frågeprestanda när man inte beräknar alla möjliga aggregat.

Nu om de olika alternativen för att lagra information. Både granulära data och aggregat kan lagras i antingen relationella eller flerdimensionella strukturer. Flerdimensionell lagring låter dig behandla data som en flerdimensionell array, vilket säkerställer lika snabba beräkningar av totala indikatorer och olika flerdimensionella transformationer längs någon av dimensionerna. För en tid sedan stödde OLAP-produkter antingen relationell eller multidimensionell lagring. Idag tillhandahåller som regel samma produkt båda dessa typer av lagring, såväl som en tredje typ - blandad. Följande villkor gäller:

• MOLAP(Multidimensional OLAP) - både detaljerad data och aggregat lagras i en flerdimensionell databas. I detta fall erhålls den största redundansen, eftersom flerdimensionell data helt innehåller relationsdata.
• ROLAP(Relational OLAP) - detaljerad data finns kvar där den ursprungligen "levde" - i relationsdatabasen; aggregat lagras i samma databas i speciellt skapade tjänstetabeller.
• HOLAP(Hybrid OLAP) - detaljerad data finns kvar (i en relationsdatabas), och aggregat lagras i en flerdimensionell databas.

Var och en av dessa metoder har sina egna fördelar och nackdelar och bör användas beroende på förhållandena - datavolymen, kraften i det relationella DBMS, etc.

Vid lagring av data i flerdimensionella strukturer finns det ett potentiellt problem med "bloat" på grund av lagring av tomma värden. När allt kommer omkring, om i en flerdimensionell array utrymme är reserverat för alla möjliga kombinationer av dimensionsetiketter, men bara en liten del faktiskt fylls (till exempel ett antal produkter säljs endast i ett litet antal regioner), då de flesta av kuben kommer att vara tom, även om utrymmet kommer att vara upptaget. Moderna OLAP-produkter kan hantera detta problem.

Fortsättning följer. I framtiden kommer vi att prata om specifika OLAP-produkter som produceras av ledande tillverkare.

OLAP är inte en separat mjukvaruprodukt, inte ett programmeringsspråk eller ens en specifik teknik. Om vi ​​försöker täcka in OLAP i alla dess yttringar, så är det en uppsättning koncept, principer och krav som ligger till grund för mjukvaruprodukter som gör det lättare för analytiker att komma åt data. Låt oss ta reda på För vad analytiker behöver något speciellt främja tillgång till data.

Faktum är att analytiker är speciella konsumenter av företagsinformation. Analytikerns uppgift är att hitta mönster i stora datamängder. Därför kommer analytikern inte att uppmärksamma det separata faktum att på torsdagen den fjärde såldes ett parti svart bläck till motparten Chernov - han behöver information om hundratals och tusentals liknande händelser. Enstaka fakta i databasen kan vara av intresse för till exempel en revisor eller chefen för försäljningsavdelningen, som är ansvarig för transaktionen. För en analytiker räcker det inte med en post - han kan till exempel behöva alla transaktioner från en viss filial eller representationskontor under en månad eller ett år. Samtidigt analytiker kasserar onödiga uppgifter som köparens TIN, hans exakta adress och telefonnummer, avtalsindex och liknande. Samtidigt innehåller de uppgifter som en analytiker kräver för sitt arbete nödvändigtvis numeriska värden - detta beror på själva kärnan i hans verksamhet.

Så analytikern behöver mycket data, denna data är selektiv och har också karaktären av " attributuppsättning - nummer". Det senare innebär att analytikern arbetar med tabeller av följande typ:

här" Ett land", "Produkt", "År" är attribut eller mätningar, A" Försäljningsvolym" - därigenom det numeriska värdet eller mäta. Analytikerns uppgift, vi upprepar, är att identifiera starka samband mellan attribut och numeriska parametrar. När du tittar på tabellen kommer du att märka att den lätt kan omvandlas till tre dimensioner: vi lägger länder på en av axlarna, varor på den andra och år på den tredje. Och värdena i denna tredimensionella array kommer att vara motsvarande försäljningsvolymer.

Tredimensionell representation av tabellen. Det grå segmentet visar att det inte finns några uppgifter för Argentina 1988

Det är just denna tredimensionella array som kallas en kub i OLAP-termer. Faktum är att från strikt matematiksynpunkt kommer en sådan array inte alltid att vara en kub: en riktig kub måste ha samma antal element i alla dimensioner, men OLAP-kuber har inte en sådan begränsning. Men trots dessa detaljer har termen "OLAP-kuber", på grund av dess korthet och figurativitet, blivit allmänt accepterad. En OLAP-kub behöver inte vara tredimensionell. Det kan vara både två- och flerdimensionellt, beroende på vilket problem som ska lösas. Särskilt rutinerade analytiker kan behöva ett 20-tal dimensioner – och seriösa OLAP-produkter är designade för exakt denna mängd. Enklare skrivbordsprogram stöder cirka 6 dimensioner.

Mått OLAP-kuber består av sk märken eller medlemmar. Dimensionen Land består till exempel av etiketterna Argentina, Brasilien, Venezuela och så vidare.

Inte alla delar av kuben måste fyllas i: om det inte finns någon information om försäljning av gummiprodukter i Argentina 1988, kommer värdet i motsvarande cell helt enkelt inte att fastställas. Det är inte heller nödvändigt att en OLAP-applikation nödvändigtvis lagrar data i en flerdimensionell struktur - huvudsaken är att denna data ser ut exakt så här för användaren. Förresten, det är just de speciella metoderna för kompakt lagring av flerdimensionell data som "vakuum" (ofyllda element) i kuber inte leder till slöseri med minne.

Själva kuben är dock inte lämplig för analys. Om det fortfarande är möjligt att adekvat föreställa sig eller avbilda en tredimensionell kub, så är situationen mycket värre med en sex- eller nittondimensionell kub. Det är därför innan användning vanliga utvinns från en flerdimensionell kub tvådimensionella tabeller. Denna operation kallas att "klippa" kuben. Denna term är återigen bildlig. Analytikern, som det var, tar och "klipper" dimensionerna på kuben enligt de märken som är intressanta för honom. På så sätt får analytikern en tvådimensionell skiva av kuben och arbetar med den. På ungefär samma sätt räknar skogshuggare årsringarna på ett hugget träd.

Följaktligen förblir som regel bara två dimensioner "oskurna" - enligt antalet dimensioner i tabellen. Det händer att endast en dimension förblir "oskuren" - om kuben innehåller flera typer av numeriska värden kan de ritas ut längs en av tabelldimensionerna.

Om du tittar ännu närmare på tabellen som vi avbildade först, kommer du att märka att uppgifterna i den sannolikt inte är primära, utan erhållna som ett resultat summering på mindre element. Till exempel är ett år uppdelat i kvartal, kvartal i månader, månader i veckor, veckor i dagar. Ett land består av regioner och regioner består av befolkade områden. Slutligen, i själva städerna kan distrikt och specifika butiker identifieras. Produkter kan kombineras till produktgrupper och så vidare. I OLAP-termer kallas sådana flernivåassociationer ganska logiskt hierarkier. OLAP-verktyg gör det möjligt att flytta till önskad hierarkinivå när som helst. Dessutom stöds som regel flera typer av hierarkier för samma element: till exempel dag-vecka-månad eller dag-decennium-kvartal. Källdata tas från lägre nivåer av hierarkier och summeras sedan för att erhålla värden på högre nivåer. För att påskynda övergångsprocessen lagras de summerade värdena för olika nivåer i en kub. Det som ser ut som en kub från användarens sida, grovt sett, består alltså av många fler primitiva kuber.

Hierarki exempel

Detta är en av de väsentliga punkterna som ledde till framväxten av OLAP - produktivitet och effektivitet. Låt oss föreställa oss vad som händer när en analytiker behöver få information, men det finns inga OLAP-verktyg i företaget. Analytikern gör självständigt (vilket är osannolikt) eller med hjälp av en programmerare lämplig SQL-fråga och tar emot informationen av intresse i form av en rapport eller exporterar den till ett kalkylblad. Många problem uppstår i detta fall. För det första tvingas analytikern att göra något annat än sitt jobb (SQL-programmering) eller vänta på att programmerare ska slutföra uppgiften åt honom - allt detta har en negativ inverkan på arbetsproduktiviteten, ökar antalet stormningar, hjärtinfarkt och stroke, och så vidare . För det andra räddar en enda rapport eller tabell som regel inte tankejättarna och den ryska analysens fäder - och hela proceduren kommer att behöva upprepas om och om igen. För det tredje, som vi redan har fått reda på, frågar analytiker inte om bagateller - de behöver allt på en gång. Detta innebär (även om tekniken går framåt med stormsteg) att den företagsrelationella DBMS-servern som analytikern kommer åt kan tänka djupt och under lång tid och blockera andra transaktioner.

Konceptet OLAP verkade just lösa sådana problem. OLAP-kuber är i huvudsak metarapporter. Genom att klippa metarapporter (dvs. kuber) längs dimensioner får analytikern faktiskt de "vanliga" tvådimensionella rapporterna som intresserar honom (detta är inte nödvändigtvis rapporter i ordets vanliga mening - vi talar om datastrukturer med samma funktioner). Fördelarna med kuber är uppenbara - data behöver bara begäras från ett relationellt DBMS en gång - när du bygger en kub. Eftersom analytiker som regel inte arbetar med information som kompletteras och ändras i farten är den genererade kuben relevant under ganska lång tid. Tack vare detta elimineras inte bara avbrott i driften av den relationella DBMS-servern (det finns inga förfrågningar med tusentals och miljoner svarsrader), utan hastigheten för åtkomst till data för analytikern själv ökar också kraftigt. Dessutom, som redan nämnts, förbättras prestanda också genom att beräkna subsummor av hierarkier och andra aggregerade värden vid den tidpunkt då kuben byggs. Det vill säga, om våra data från början innehöll information om dagliga intäkter för en specifik produkt i en enda butik, då när man bildar en kub, beräknar OLAP-applikationen summan för olika nivåer av hierarkier (veckor och månader, städer och länder).

Självklart måste man betala för att öka produktiviteten på detta sätt. Det sägs ibland att en datastruktur helt enkelt "exploderar" - OLAP kub kan ta upp tiotals eller till och med hundratals gånger mer utrymme än originaldata.

Svara på frågorna:

Vad har hänt kub OLAP?

Vad har hänt taggar specifik mätning? Ge exempel.

Kan de åtgärder i en OLAP-kub, innehålla icke-numeriska värden.