Grundläggande begrepp som används av olap-teknik. OLAP-teknik

Villkoren för hög konkurrens och den växande dynamiken i den yttre miljön dikterar ökade krav på företagsledningssystem. Utvecklingen av ledningsteori och praktik åtföljdes av framväxten av nya metoder, teknologier och modeller som syftar till att förbättra effektiviteten i aktiviteterna. Metoder och modeller i sin tur bidrog till framväxten av analytiska system. Efterfrågan på analytiska system i Ryssland är hög. Dessa system är mest intressanta ur tillämpningssynpunkt i den finansiella sektorn: banker, försäkringsverksamhet, investeringsföretag. Resultaten av arbetet med analytiska system är främst nödvändiga för människor, på vars beslut företagets utveckling är beroende: chefer, experter, analytiker. Analytiska system gör det möjligt att lösa problem med konsolidering, rapportering, optimering och prognoser. Hittills har den slutliga klassificeringen av analytiska system inte utvecklats, eftersom det inte finns någon gemensamt system definitioner i termer som används i denna riktning. Informationsstrukturen för ett företag kan representeras av en sekvens av nivåer, som alla kännetecknas av sitt eget sätt att behandla och hantera information, och har sin egen funktion i hanteringsprocessen. Således kommer analytiska system att placeras hierarkiskt på olika nivåer av denna infrastruktur.

Transaktionella systemlager

Datalagernivå

Data mart lager

OLAP-nivå - system

Analytiskt applikationsskikt

OLAP - system - (OnLine Analytical Processing, analytisk bearbetning i realtid) - är en teknik för komplex flerdimensionell dataanalys. OLAP-system är tillämpliga där det finns en uppgift att analysera multifaktordata. De är ett effektivt verktyg för analys och generering av rapporter. Datalager, datamärken och OLAP-system som diskuterats ovan klassificeras som business intelligence-system (Business Intelligence, BI).

Mycket ofta är informations- och analyssystem som skapats med förväntningar om direkt användning av beslutsfattare extremt enkla att använda, men allvarligt begränsade i funktionalitet. Sådana statiska system kallas i litteraturen Executive Information Systems (EIS) eller Executive Information Systems (EIS). De innehåller fördefinierade frågor och är inte tillräckliga för den dagliga granskningen och kan inte svara på alla frågor om tillgänglig data som kan uppstå när du fattar beslut. Resultatet av arbetet med ett sådant system är som regel rapporter på flera sidor, efter en noggrann undersökning av vilken analytikern verkar nytt avsnitt frågor. Emellertid måste varje ny begäran, som inte förutses i utformningen av ett sådant system, först beskrivas formellt, kodas av programmeraren och först sedan köras. Väntetiden i detta fall kan vara timmar och dagar, vilket inte alltid är acceptabelt. Således blir den externa enkelheten hos statiska DSS: er, för vilka de flesta kunder inom informationsanalyssystem aktivt kämpar, till en katastrofal förlust av flexibilitet.

Dynamic DSS, å andra sidan, är inriktad på att bearbeta ad hoc-analytikerförfrågningar om data. Kraven på sådana system ansågs djupast av E. F. Codd i artikeln som lade grunden för begreppet OLAP. Analytiker arbetar med dessa system i en interaktiv sekvens för att generera frågor och studera deras resultat.

Men dynamiska DSS: er kan fungera i mer än bara området för online analytisk bearbetning (OLAP); stöd för att fatta ledningsbeslut baserat på ackumulerade data kan genomföras inom tre grundläggande områden.

Detaljerad datasfär. Detta är domänen för de flesta informationshämtningssystem. I de flesta fall gör relationella DBMS ett utmärkt jobb med de uppgifter som uppstår här. Den allmänt accepterade standarden för språket för relationsdatamanipulation är SQL. Informationssökningssystem som tillhandahåller ett slutanvändargränssnitt i uppgifterna för att söka efter detaljerad information kan användas som tillägg både över separata databaser för transaktionssystem och över ett gemensamt datalager.

Aggregatets sfär. En omfattande titt på informationen som samlats in i datalagret, dess generalisering och aggregering, hyperkubrepresentation och flerdimensionell analys är uppgifterna för OLAP-system för online analytisk databehandling. Här kan du antingen fokusera på speciell flerdimensionell DBMS eller hålla dig inom ramen för relationsteknologi. I det andra fallet kan föraggregerade data samlas in i en stjärnformad databas, eller så kan informationen samlas i farten under genomsökning av detaljerade tabeller i en relationsdatabas.

Regularitetssfären. Intellektuell bearbetning utförs med metoder för data mining (IAD, Data Mining), vars huvudsakliga uppgifter är sökandet efter funktionella och logiska mönster i den ackumulerade informationen, konstruktion av modeller och regler som förklarar de avvikelser som hittats och / eller förutsäger utvecklingen av vissa processer.

Snabb analytisk databehandling

OLAP-konceptet bygger på principen om flerdimensionell datapresentation. I en artikel från EF Codd från 1993 undersökte han bristerna i relationsmodellen och först och främst påpekade omöjligheten "att kombinera, se och analysera data i termer av flera dimensioner, det vill säga på det mest förståeliga sättet för företagsanalytiker". , och identifierade de allmänna kraven för OLAP-system som utökar funktionaliteten i relationell DBMS och inkluderar multivariatanalys som en av dess egenskaper.

Klassificering av OLAP-produkter enligt hur data presenteras.

För närvarande finns det ett stort antal produkter på marknaden som i en eller annan grad tillhandahåller OLAP-funktionalitet. Cirka 30 av de mest kända listas på översikten Webbserver http://www.olapreport.com/. Ger en flerdimensionell konceptvy från utsidan användargränssnitt till källdatabasen är alla OLAP-produkter uppdelade i tre klasser beroende på typen av källdatabas.

De tidigaste analysanalyssystemen på nätet (till exempel Essbase från Arbor Software, Oracle Express Server från Oracle) tillhörde MOLAP-klassen, det vill säga de kunde bara arbeta med sina egna flerdimensionella databaser. De är baserade på egenutvecklad flerdimensionell DBMS-teknik och är de dyraste. Dessa system ger en fullständig cykel av OLAP-bearbetning. De innehåller antingen, förutom serverkomponenten, sitt eget integrerade klientgränssnitt, eller så använder de för att kommunicera med användaren externa program arbeta med kalkylblad. För att underhålla sådana system krävs en speciell personal för att installera, underhålla systemet och bilda datarepresentationer för slutanvändare.

Relational online analytisk bearbetning (ROLAP) -system gör att du kan representera data som lagras i en relationsdatabas i en flerdimensionell form, vilket ger informationstransformation till en flerdimensionell modell genom ett mellanliggande metadatalager. ROLAP-system är väl lämpade för att arbeta med stora förvaringsanläggningar. Precis som MOLAP-system kräver de betydande IT-underhåll och är fleranvändare.

Slutligen är hybridsystem (Hybrid OLAP, HOLAP) utformade för att kombinera fördelarna och minimera de nackdelar som finns i tidigare klasser. Denna klass inkluderar Speedwares Media / MR. Enligt utvecklarna kombinerar den den analytiska flexibiliteten och lyhördheten hos MOLAP med den konstanta tillgången till verklig data som är inneboende i ROLAP.

Flerdimensionell OLAP (MOLAP)

I specialiserade DBMS baserade på flerdimensionell datarepresentation organiseras data inte i form av relationstabeller utan i form av ordnade flerdimensionella matriser:

1) hyperkuber (alla celler som lagras i databasen måste ha samma dimension, det vill säga vara i den mest fullständiga mätbasen) eller

2) polykuber (varje variabel lagras med sin egen uppsättning mätningar och alla tillhörande behandlingssvårigheter flyttas till systemets interna mekanismer).

Användningen av flerdimensionella databaser i onlineanalysbearbetningssystem har följande fördelar.

Vid användning av ett flerdimensionellt DBMS är sökningen och valet av data mycket snabbare än med en flerdimensionell konceptvy av en relationsdatabas, eftersom den flerdimensionella databasen är denormaliserad, innehåller föraggregerade indikatorer och ger optimerad åtkomst till de begärda cellerna.

Flerdimensionellt DBMS hanterar enkelt uppgifterna för inkludering i informationsmodell olika inbyggda funktioner, medan objektivt existerande begränsningar sQL-språk göra det svårt och ibland omöjligt att utföra dessa uppgifter på grundval av relationella DBMS.

Å andra sidan finns det betydande begränsningar.

Flerdimensionella DBMS tillåter inte arbete med stora databaser. Dessutom, på grund av denormalisering och tidigare utförd aggregering, motsvarar mängden data i en flerdimensionell databas som regel (enligt Codd) 2,5-100 gånger mindre än volymen för de ursprungliga detaljerade uppgifterna.

Flerdimensionella DBMS är mycket ineffektiva jämfört med relationella. externt minne... I den överväldigande majoriteten av fallen är informationshyperkuben mycket gles, och eftersom data lagras i ordnad form kan odefinierade värden endast tas bort genom att välja den optimala sorteringsordningen som gör det möjligt att organisera data i de största sammanhängande grupperna. Trots det är problemet bara delvis löst. Dessutom kommer den sorteringsordning som är optimal för lagring av glesa data sannolikt att skilja sig från den ordning som oftast används i frågor. Därför i verkliga system du måste hitta en kompromiss mellan prestanda och redundans på diskutrymme som upptas av databasen.

Därför är användningen av flerdimensionell DBMS motiverad endast under följande förhållanden.

Volymen initial data för analys är inte för stor (högst flera gigabyte), det vill säga nivån på dataggregation är ganska hög.

Uppsättningen av informationsdimensioner är stabil (eftersom varje förändring i deras struktur nästan alltid kräver en fullständig rekonstruktion av hyperkuben).

Systemets svarstid på ad hoc-förfrågningar är den mest kritiska parametern.

Omfattande användning av komplexa inbyggda funktioner krävs för att utföra tvärdimensionella beräkningar på celler i en hyperkub, inklusive möjligheten att skriva anpassade funktioner.

Relational OLAP (ROLAP)

Den direkta användningen av relationsdatabaser i online-analysbearbetningssystem har följande fördelar.

I de flesta fall implementeras datalager för företag med relationell DBMS, och med ROLAP-verktyg kan du analysera direkt på dem. Samtidigt är lagringsstorleken inte en så kritisk parameter som i fallet med MOLAP.

I fallet med en variabel dimension av problemet, när förändringar i mätstrukturen måste göras ganska ofta, R OLAP-system dimensioner med dynamisk representation är den optimala lösningen, eftersom sådana modifieringar i dem inte kräver fysisk omorganisation av databasen.

Relationella DBMS ger en betydligt högre nivå av dataskydd och bra möjligheter differentiering av tillgångsrättigheter.

Den största nackdelen med ROLAP jämfört med flerdimensionell DBMS är lägre prestanda. Relationssystem kräver noggrant databasschema och indexjustering för att uppnå prestanda som är jämförbara med MOLAP, vilket innebär mycket ansträngning från DBA: s sida. Endast genom att använda stjärnscheman kan prestanda för väl avstämda relationssystem vara nära prestanda för flerdimensionella databassystem.

Begreppet OLAP-teknik formulerades av Edgar Codd 1993.

Denna teknik är baserad på konstruktionen av flerdimensionella datamängder - de så kallade OLAP-kuberna (inte nödvändigtvis tredimensionella, som man kan dra slutsatsen från definitionen). Syftet med att använda OLAP-teknik är att analysera data och presentera denna analys i en form som är bekväm för ledningspersonalen att uppfatta och fatta beslut baserat på dem.

Viktiga krav för multivariata analysapplikationer:

• - förse användaren med analysresultaten på en rimlig tid (högst 5 s.);
• - tillgång till flera användare till data;
• - flerdimensionell datapresentation;
• - förmågan att komma åt all information oavsett lagringsplats och volym.

OLAP-systemverktyg ger möjlighet att sortera och välja data enligt angivna förhållanden. Olika kvalitativa och kvantitativa villkor kan specificeras.

Huvuddatamodellen som används i många verktygah skapande och underhåll av databaser - DBMS, är relationsmodellen. Data i den presenteras i form av en uppsättning tvådimensionella relationstabeller länkade av nyckelfält. För att eliminera duplicering, inkonsekvens och minska arbetskraftskostnader för att underhålla databaser används en formell apparat för att normalisera enhetstabeller. Användningen är dock associerad med ytterligare tid på att generera svar på frågor till databaser, även om minnesresurser sparas.

En flerdimensionell datamodell representerar objektet som studeras i form av en flerdimensionell kub, oftare används en tredimensionell modell. Mått eller attributattribut ritas längs kubens axlar eller ytor. Basattributen är fyllningen av kubcellerna. En flerdimensionell kub kan representeras av en kombination av tredimensionella kuber för att underlätta uppfattning och presentation i bildandet av rapporterings- och analysdokument och multimediepresentationer baserade på analysmaterialets beslut i stödsystemet.

Inom ramen för OLAP-teknik, baserat på det faktum att den flerdimensionella presentationen av data kan organiseras både med relationella DBMS och multidimensionella specialverktyg, finns det tre typer av flerdimensionella OLAP-system:

• - flerdimensionell OLAP-MOLAP;
• - relationell (Relation) OLAP-ROLAP;
• - blandad eller hybrid (Hibrid) OLAP-HOLAP.

I flerdimensionella DBMS organiseras data inte i form av relationstabeller utan i form av ordnade flerdimensionella matriser i form av hyperkubbar, när all lagrad data måste ha samma dimension, vilket innebär behovet av att bilda den mest fullständiga mätningar. Data kan organiseras i form av polycubes, i den här versionen lagras värdena för varje indikator med sin egen mätuppsättning, databearbetningen utförs av systemets eget verktyg. Lagringsstrukturen är förenklad i detta fall eftersom det finns inget behov av ett flerdimensionellt eller objektorienterat lagringsområde. De enorma arbetskraftskostnaderna för att skapa modeller och system för att omvandla data från en relationsmodell till en objektmodell reduceras.

Fördelarna med MOLAP är:

• - snabbare än med ROLAP, mottagande av svar på förfrågningar - tiden är en till två storleksordningar mindre;
• - Många inbyggda funktioner är svåra att implementera på grund av SQL-begränsningar.

MOLAP-begränsningar inkluderar:

• - relativt liten storlek på databaser;
• - på grund av denormalisering och preliminär aggregering använder flerdimensionella matriser 2,5-100 gånger mer minne än originaldata (minneskonsumtion växer exponentiellt med ökat antal mätningar);
• - det finns inga standarder för gränssnittet och dataanvändningsverktygen;
• - det finns begränsningar vid laddning av data.

Ansträngningen som krävs för att skapa flerdimensionell data ökar dramatiskt. i denna situation finns det praktiskt taget inga specialiserade medel för att objektivisera den relationsdata-modellen som finns i informationslagringen. Svarstiden på frågor kan ofta inte uppfylla kraven för OLAP-system.

Fördelarna med ROLAP-system är:

• - förmågan att snabbt analysera data direkt i datalagret, eftersom de flesta källdatabaser är relationella;
• - med en variabel dimension av problemet, vinner RO-LAP, för ingen fysisk omorganisation av databasen krävs;
• - ROLAP-system kan använda mindre kraftfulla klientstationer och servrar, och servrarna bär den största belastningen för bearbetning av komplexa SQL-frågor;
• - Nivån på informationsskydd och differentiering av åtkomsträttigheter i relationella DBMS är ojämförligt högre än i flerdimensionella.

Nackdelarna med ROLAP-system är lägre prestanda, behovet av noggrann utarbetande av databasscheman, specialjustering av index, analys av frågestatistik och övervägande av analysresultat vid uppdatering av databasscheman, vilket leder till betydande ytterligare arbetskraftskostnader.

Uppfyllelse av dessa villkor gör det möjligt att, när man använder ROLAP-system, uppnå indikatorer som liknar MOLAP-system när det gäller åtkomsttid, samt överträffa minnesbesparingar.

Hybrid OLAP-system är en kombination av verktyg som implementerar en relations- och flerdimensionell datamodell. Detta gör att du dramatiskt kan minska resurskostnaderna för att skapa och underhålla en sådan modell, svarstiden på förfrågningar.

Detta tillvägagångssätt utnyttjar fördelarna med de två första metoderna och kompenserar för deras nackdelar. Denna princip implementeras i de mest utvecklade mjukvaruprodukterna för detta ändamål.

Användningen av hybridarkitektur i OLAP-system är det lämpligaste sättet att lösa problemen i samband med användning av programvaruverktyg i multivariatanalys.

Mönsterdetekteringsläget är baserat på intelligent databehandling. Huvuduppgiften här är att identifiera mönster i de processer som studeras, inbördes förhållanden och interaktioner mellan olika faktorer, söka efter stora "ovanliga" avvikelser, förutsäga förloppet för olika väsentliga processer. Detta område tillhör datautvinning.

Skicka ditt bra arbete i kunskapsbasen är enkelt. Använd formuläret nedan

Studenter, doktorander, unga forskare som använder kunskapsbasen i sina studier och arbete kommer att vara dig mycket tacksam.

Publicerat den http://www.allbest.ru/

Kursarbete

efter disciplin: databaser

Ämne: TeknologiOLAP

Avslutad:

Chizhikov Alexander Alexandrovich

Introduktion

1. Klassificering av OLAP-produkter

2. OLAP-klient - OLAP-server: fördelar och nackdelar

3. Kärnan i OLAP-systemet

3.1 Konstruktionsprinciper

Slutsats

Lista över använda källor

Applikationer

Idirigera

Det är svårt att hitta en person i datorvärlden som åtminstone på en intuitiv nivå inte förstod vad databaser är och varför de behövs. Till skillnad från traditionella relationella DBMS är begreppet OLAP inte så känt, även om nästan alla har hört den mystiska termen "OLAP-kuber". Vad är OnLine Analytical Processing?

OLAP är inte en enda programvaruprodukt, inte ett programmeringsspråk eller ens en specifik teknik. Om du försöker täcka OLAP i alla dess manifestationer är det en uppsättning begrepp, principer och krav som ligger till grund för programvaruprodukter som gör det lättare för analytiker att få tillgång till data. Trots att knappast någon skulle vara oense med en sådan definition är det tveksamt att det kommer att föra icke-specialister till och med en iota närmare förståelsen av ämnet. Därför är det bättre att gå åt andra håll i din strävan efter kunskap om OLAP. Först måste du ta reda på varför analytiker på något sätt specifikt behöver underlätta åtkomst till data.

Poängen är att analytiker är speciella konsumenter av företagsinformation. Analytikerns jobb är att hitta mönster i stora datamängder. Därför kommer analytikern inte att uppmärksamma ett enda faktum, han behöver information om hundratusentals händelser. Förresten, en av de viktigaste punkterna som ledde till framväxten av OLAP är prestanda och effektivitet. Föreställ dig vad som händer när en analytiker behöver information och det inte finns någon OLAP i företaget. Analytikern gör oberoende (vilket är osannolikt) eller med hjälp av en programmerare lämplig SQL-fråga och tar emot data av intresse i form av en rapport eller exporterar dem till ett kalkylark. I det här fallet uppstår många problem. För det första tvingas analytikern att göra något annat än sitt eget arbete (SQL-programmering) eller vänta på att programmerarna ska slutföra uppgiften åt honom - allt detta har en negativ inverkan på arbetsproduktiviteten, hjärtinfarkt och stroke ökar, så vidare. För det andra räddar en enda rapport eller tabell som regel inte tankens jättar och fäderna till den ryska analysen - och hela proceduren måste upprepas om och om igen. För det tredje, som vi redan har upptäckt, 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 servern för den företagsrelationella DBMS, som analytikern vänder sig till, kan tänka djupt och länge och blockera resten av transaktionerna.

Konceptet med OLAP föddes just för att lösa sådana problem. OLAP-kuber är i huvudsak metarapporter. Genom att skära metarapporter (kuber, det vill säga) efter dimensioner får analytikern faktiskt de "vanliga" tvådimensionella rapporterna som intresserar honom (det här är inte nödvändigtvis rapporter i den vanliga betydelsen av termen - vi pratar om datastrukturer med samma funktioner). Fördelarna med kuber är uppenbara - data måste begäras från relationsdatabasen endast en gång - när kuben byggs. 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 utesluts inte bara avbrott i driften av den relationsbaserade DBMS-servern (det finns inga frågor med tusentals och miljontals svarslinjer), utan också snabbheten att få tillgång till data för analytikern ökar kraftigt. Dessutom förbättras, som noterat, också prestanda genom att räkna hierarkiernas delsummor och andra aggregerade värden när kuben byggs.

Naturligtvis måste du betala för att öka produktiviteten på detta sätt. Ibland sägs det att datastrukturen helt enkelt "exploderar" - en OLAP-kub kan ta tiotals eller till och med hundratals gånger mer utrymme än originaldata.

Nu när vi har räknat ut lite om hur OLAP fungerar och vad det är för är det ändå värt att formalisera vår kunskap något och ge OLAP-kriterier redan utan samtidig översättning till vanligt mänskligt språk. Dessa kriterier (totalt 12) formulerades 1993 av E.F. Coddom är skaparen av begreppet relationell DBMS och samtidigt OLAP. Vi kommer inte att överväga dem direkt, eftersom de senare omarbetades till det så kallade FASMI-testet, som bestämmer kraven för OLAP-produkter. FASMI är en förkortning för namnet på varje testobjekt:

Snabbt snabbt). Den här egenskapen innebär att systemet ska svara på en användares begäran på i genomsnitt fem sekunder. de flesta förfrågningar behandlas dock inom en sekund och de mest komplexa förfrågningarna ska behandlas inom tjugo sekunder. Ny forskning har visat att en användare börjar tvivla på att en begäran lyckas om det tar mer än trettio sekunder.

Analys (analytisk). Systemet måste klara alla logiska och statistiska analyser som är specifika för affärsapplikationer och se till att resultaten sparas i en form som är tillgänglig för slutanvändaren. Analysverktyg kan inkludera procedurer för tidsserieanalys, kostnadsallokering, valutakonvertering, modelleringsändringar i organisationsstrukturer och några andra.

Delad (delad). Systemet bör ge gott om möjligheter att skilja åtkomst till data och samtidig användning av många användare.

Flerdimensionellt Systemet bör ge en konceptuell flerdimensionell representation av data, inklusive fullt stöd flera hierarkier.

Information Kraften hos olika programvaruprodukter kännetecknas av mängden ingångsdata som bearbetas. Olika OLAP-system har olika kapacitet: avancerade OLAP-lösningar kan hantera minst tusen gånger mer data än de minst kraftfulla. Det finns ett antal faktorer att tänka på när du väljer ett OLAP-verktyg, inklusive dataduplicering, RAM-minne, användning av diskutrymme, prestanda, datalagerintegration och mer.

1. Klassificering av OLAP-produkter

Så, kärnan i OLAP ligger i det faktum att den initiala informationen för analys presenteras i form av en flerdimensionell kub, och möjligheten att godtyckligt manipulera den och erhålla nödvändiga informationsavsnitt - rapporter - tillhandahålls. Samtidigt ser slutanvändaren kuben som en flerdimensionell dynamisk tabell som automatiskt sammanfattar data (fakta) i olika avsnitt (dimensioner) och låter dig interaktivt styra beräkningar och rapportformuläret. Dessa operationer utförs av en OLAP-maskin (eller en OLAP-dator).

Hittills har många produkter utvecklats i världen som implementerar OLAP-teknik. För att göra det lättare att navigera bland dem används klassificeringar av OLAP-produkter: förresten data lagras för analys och av platsen för OLAP-maskinen. Låt oss titta närmare på varje kategori av OLAP-produkter.

Jag börjar med att klassificera det enligt hur data lagras. Låt mig påminna dig om att flerdimensionella kuber är byggda på grundval av initiala och aggregerade data. Både rå och aggregerad data för kuber kan lagras i både relations- och flerdimensionella databaser. Därför finns det för närvarande tre metoder för lagring av data: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) och HOLAP (Hybrid OLAP). Följaktligen är OLAP-produkter uppdelade i tre liknande kategorier när det gäller datalagringsmetod:

1.I fallet med MOLAP lagras källan och aggregerade data i en flerdimensionell databas eller i en flerdimensionell lokal kub.

2. I ROLAP-produkter lagras källdata i relationsdatabaser eller i platta lokala tabeller på en filserver. Samlade data kan placeras i servicetabeller i samma databas. Omvandling av data från en relationsdatabas till flerdimensionella kuber sker på begäran av OLAP-verktyget.

3. Vid användning av HOLAP-arkitekturen förblir originaldata i relationsdatabasen och aggregaten placeras i den flerdimensionella. En OLAP-kub byggs på begäran av ett OLAP-verktyg baserat på relations- och flerdimensionell data.

Nästa klassificering baseras på platsen för OLAP-maskinen. På grundval av detta är OLAP-produkter uppdelade i OLAP-servrar och OLAP-klienter:

I serverbaserade OLAP-verktyg utförs beräkningar och lagring av aggregerad data genom en separat process - servern. Klientapplikationen får endast resultat från frågor mot flerdimensionella kuber som lagras på servern. Vissa OLAP-servrar stöder lagring av data endast i relationsdatabaser, andra endast i flerdimensionella databaser. Många moderna OLAP-servrar stöder alla tre lagringsmetoderna: MOLAP, ROLAP och HOLAP.

OLAP-klienten fungerar annorlunda. Flerdimensionell kubbyggnad och OLAP-beräkningar utförs i minnet på klientdatorn. OLAP-klienter är också uppdelade i ROLAP och MOLAP. Och vissa kan stödja båda typerna av datatillgång.

Var och en av dessa tillvägagångssätt har sina egna fördelar och nackdelar. I motsats till vad många tror om fördelarna med verktygssidan på sidan av verktygen på klientsidan kan det i ett antal fall vara effektivare och lönsammare att använda en OLAP-klient för användare än att använda en OLAP-server.

2. OLAP-klient - OLAP-server: fördelar och nackdelar

När man bygger informationssystem OLAP-funktionalitet kan implementeras av både server- och klient-OLAP-verktyg. I praktiken är valet resultatet av en avvägning mellan prestanda och mjukvarukostnad.

Mängden data bestäms av en kombination av följande egenskaper: antalet poster, antalet dimensioner, antalet dimensionsposter, dimensionernas längd och antalet fakta. Det är känt att en OLAP-server kan hantera större datamängder än en OLAP-klient med samma datorkraft. Detta beror på att OLAP-servern lagras på hårddiskar en flerdimensionell databas som innehåller förberäknade kuber.

Klientprogram vid tidpunkten för körning av OLAP-operationer kör frågor till det på ett SQL-liknande språk och tar inte emot hela kuben utan dess fragment visas. OLAP-klienten vid arbetet måste ha en slumpminne hela kuben. När det gäller ROLAP-arkitekturen är det nödvändigt att förinstallera hela dataarrayen som används för att beräkna kuben i minnet. Dessutom ökar antalet aggregat exponentiellt när antalet dimensioner, fakta eller dimensionsposter ökar. Således står mängden data som behandlas av OLAP-klienten i direkt proportion till mängden RAM på användarens dator.

Observera dock att de flesta OLAP-klienter tillhandahåller distribuerad databehandling. Därför betyder inte antalet bearbetade poster, som begränsar klientens OLAP-verktyg, volymen på företagsdatabasens primära data utan storleken på det aggregerade urvalet från den. OLAP-klienten genererar en fråga till DBMS, som beskriver filtreringsvillkoren och algoritmen för preliminär gruppering av primärdata. Servern hittar, grupperar posterna och returnerar ett kompakt urval för ytterligare OLAP-beräkningar. Storleken på detta prov kan vara tiotals eller hundratals gånger mindre än volymen av primära, icke-aggregerade poster. Följaktligen minskas behovet av en sådan OLAP-klient för PC-resurser avsevärt.

Dessutom sätter antalet dimensioner begränsningar på människans förmåga. Det är känt att den genomsnittliga personen samtidigt kan använda 3-4, maximalt 8 dimensioner. Med ett större antal dimensioner i den dynamiska tabellen blir uppfattningen av information mycket svårare. Denna faktor bör tas med i beräkningen av RAM-minnet som OLAP-klienten kan behöva.

Längden på mått påverkar också storleken på OLAP-verktygets adressutrymme som används vid beräkning av OLAP-kuben. Ju längre dimensioner desto fler resurser krävs för att försortera den flerdimensionella matrisen och vice versa. Endast korta dimensioner i källdata är ett annat argument till förmån för OLAP-klienten.

Denna egenskap bestäms av två faktorer som diskuterats ovan: volymen av bearbetade data och kraften hos datorer. Med en ökning av till exempel dimensioner minskar prestanda för alla OLAP-verktyg på grund av en betydande ökning av antalet aggregat, men nedgångstakten är annorlunda. Låt oss demonstrera detta beroende av diagrammet.

Figur 1. Beroende på prestanda hos klient- och server OLAP-verktyg på ökningen av datavolym

Hastighetsegenskaperna för OLAP-servern är mindre känsliga för datatillväxt. Detta beror på de olika tekniker som används av OLAP-servern och OLAP-klienten för att behandla användarförfrågningar. Till exempel, under en borroperation, kommer OLAP-servern åt de lagrade data och hämtar data från denna "gren". OLAP-klienten beräknar hela uppsättningen aggregat vid laddningstillfället. Men upp till en viss mängd data är prestandan för servern och klientverktygen jämförbar. För OLAP-klienter som stöder Grid Computing kan omfattningen av prestandas jämförbarhet sträcka sig till mängden data som täcker OLAP-analysbehov stor mängd användare. Detta bekräftas av resultaten av intern testning av MS OLAP Server och OLAP-klienten "Kontur Standard". Testet utfördes på en PC IBM PC Pentium Celeron 400 MHz, 256 Mb för ett urval av 1 miljon unika (dvs aggregerade) poster med 7 dimensioner innehållande från 10 till 70 medlemmar. Kubens laddningstid överstiger i båda fallen inte 1 sekund, och utförandet av olika OLAP-operationer (borra upp, borra ner, flytta, filtrera etc.) utförs på hundradels sekund.

När provstorleken överstiger RAM-mängden börjar byte med skivan och OLAP-klientens prestanda sjunker kraftigt. Först från det här ögonblicket kan vi prata om fördelen med OLAP-servern.

Man bör komma ihåg att "böjpunkten" definierar gränsen för en kraftig ökning av kostnaden för en OLAP-lösning. För allas uppgifter specifik användare denna punkt kan lätt identifieras från OLAP-klientprestanda. Sådana tester kan erhållas från utvecklarföretaget.

Dessutom ökar kostnaden för en OLAP-serverlösning när antalet användare ökar. Faktum är att OLAP-servern utför beräkningar för alla användare på en dator. Följaktligen, ju större antal användare desto mer RAM och processorkraft. Således, om volymerna av bearbetade data ligger inom området för jämförbara prestanda för server- och klientsystem, kommer användningen av en OLAP-klient, om allt annat är lika, att vara mer lönsam.

Användningen av en OLAP-server i den "klassiska" ideologin möjliggör nedladdning av data från relations-DBMS till en flerdimensionell databas. Nedladdningen utförs under en viss period, så OLAP-serverns data återspeglar inte det aktuella tillståndet. Endast de OLAP-servrar som stöder ROLAP-driftsättet saknar denna nackdel.

På samma sätt möjliggör en mängd olika OLAP-klienter ROLAP och Desktop-arkitekturer med direkt databasåtkomst. Detta ger on-line analys av rådata.

OLAP Server har minimala krav på klientterminalernas kraft. Objektivt är kraven för OLAP-klienten högre sedan den utför beräkningar i RAM på användarens dator. Tillståndet för maskinvaruflottan för en viss organisation är den viktigaste indikatorn som bör beaktas när man väljer ett OLAP-verktyg. Men också här finns plus och minus. OLAP-servern använder inte den moderna processorkraften personliga datorer... Om en organisation redan har en flotta moderna datorer är det ineffektivt att endast använda dem som displayterminaler och samtidigt göra extra kostnader för en central server.

Om användarnas dators kraft är "dålig" kommer OLAP-klienten att vara långsam eller inte fungera alls. Att köpa en kraftfull server kan vara billigare än att uppgradera alla datorer.

Det är användbart här att ta hänsyn till trender inom hårdvaruutveckling. Eftersom mängden data för analys är praktiskt taget konstant kommer den stabila tillväxten av PC-kraft att leda till en utvidgning av funktionerna hos OLAP-klienter och deras förskjutning av OLAP-servrar till segmentet av mycket stora databaser.

När du använder en OLAP-server överförs endast data för visning till klientdatorn via nätverket, medan OLAP-klienten tar emot hela datamängden från det primära exemplet.

Där där OLAP-klienten används kommer nätverkstrafiken att vara högre.

Men när du använder en OLAP-server, användaroperationer, till exempel, ner, generera nya frågor till den flerdimensionella databasen, och därför en ny dataöverföring. Körningen av OLAP-operationer av en OLAP-klient utförs i RAM och orsakar följaktligen inte nya dataströmmar i nätverket.

Det bör också noteras att modernt nätverk hårdvara ger en hög genomströmningsnivå.

I den överväldigande majoriteten av fallen kommer analysen av en "medium" databas med OLAP-klienten därför inte att sakta ner användarens arbete.

Kostnaden för en OLAP-server är ganska hög. Detta bör också läggas till kostnaden för en dedikerad dator och de konstanta kostnaderna för att administrera en flerdimensionell databas. Dessutom kräver implementering och underhåll av en OLAP-server högkvalificerad personal.

Kostnaden för en OLAP-klient är en storleksordning lägre än kostnaden för en OLAP-server. Administration och ytterligare teknisk utrustning för servern krävs inte. När du implementerar en OLAP-klient finns det inga höga krav på personalens kvalifikationer. En OLAP-klient kan distribueras mycket snabbare än en OLAP-server.

Utveckling av analytiska applikationer med OLAP-klientverktyg är en snabb process och kräver ingen speciell utbildning för entreprenören. En användare som känner till den fysiska implementeringen av databasen kan utveckla en analytisk applikation på egen hand utan inblandning av en IT-specialist. Lär dig 2 när du använder OLAP Server olika system, ibland från olika leverantörer, för att skapa kuber på servern och för att utveckla en klientapplikation. OLAP-klienten tillhandahåller ett enhetligt visuellt gränssnitt för att beskriva kuber och anpassa deras användargränssnitt.

Låt oss titta på processen för att skapa en OLAP-applikation med ett klientverktyg.

Figur 2. Skapa ett OLAP-program med hjälp av ROLAP-klientverktyget

Principen för drift av ROLAP-klienter är en preliminär beskrivning av det semantiska skiktet bakom vilket den ursprungliga datans fysiska struktur är dold. I detta fall kan datakällor vara: lokala tabeller, RDBMS. Listan över datakällor som stöds är produktspecifik. Därefter kan användaren självständigt manipulera objekt som han förstår när det gäller ämnesområdet för att skapa kuber och analytiska gränssnitt.

OLAP-serverklienten fungerar annorlunda. När OLAP-servern skapar kuber manipulerar användaren de fysiska beskrivningarna av databasen.

Detta skapar anpassade beskrivningar i själva kuben. OLAP-serverklienten är endast konfigurerad per kub.

Låt oss förklara principen för ROLAP-klienten med hjälp av exemplet att skapa en dynamisk försäljningsrapport (se diagram 2). Låt initialdata för analys lagras i två tabeller: Försäljning och Deal.

När du skapar ett semantiskt lager beskrivs datakällorna - tabellerna försäljning och affär - i termer som är förståliga för slutanvändaren och förvandlas till "produkter" och "erbjudanden". Fältet "ID" från tabellen "Produkter" har bytt namn till "Kod" och "Namn" till "Produkt" och så vidare.

Sedan skapas affärsobjektet Försäljning. Ett affärsobjekt är ett platt bord från vilket en flerdimensionell kub bildas. När ett affärsobjekt skapas kombineras tabellerna "Produkter" och "Erbjudanden" med fältet "Kod" för artikeln. Eftersom alla tabellfält inte behöver visas i rapporten använder affärsobjektet bara fälten "Artikel", "Datum" och "Belopp".

Därefter skapas en OLAP-rapport baserad på affärsobjektet. Användaren väljer ett affärsobjekt och drar dess attribut till kolumnen eller radområdet i rapporttabellen. I vårt exempel, baserat på affärsobjektet Försäljning, har vi skapat en rapport om försäljning av varor per månad.

När du arbetar med en interaktiv rapport kan användaren ställa in filter- och grupperingsförhållanden med samma enkla musrörelser. Vid denna tidpunkt får ROLAP-klienten åtkomst till data i cachen. Å andra sidan genererar OLAP-serverklienten en ny fråga mot den flerdimensionella databasen. Genom att till exempel tillämpa ett filter efter produkter i försäljningsrapporten kan du få en rapport om försäljningen av de produkter som är intressanta för oss.

Alla OLAP-applikationsinställningar kan lagras i ett dedikerat metadataförvaring, i ett program eller i ett flerdimensionellt databassystemförvar. Implementeringen beror på den specifika programvaruprodukten.

Så, i vilka fall kan användningen av OLAP-klienten för användare vara mer effektiv och lönsam än användningen av OLAP-servern?

Den ekonomiska genomförbarheten med att använda en OLAP-server uppstår när datamängden är mycket stor och outhärdlig för en OLAP-klient, annars är användningen av den senare mer motiverad. I det här fallet kombinerar OLAP-klienten höga prestandaegenskaper med låga kostnader.

Kraftfulla analytiker-datorer är en annan anledning till att använda OLAP-klienter. När du använder en OLAP-server används inte dessa kapaciteter. Bland fördelarna med OLAP-klienter är följande:

Kostnaderna för att implementera och underhålla en OLAP-klient är betydligt lägre än kostnaderna för en OLAP-server.

När du använder en OLAP-klient med en inbäddad maskin överförs data över nätverket en gång. När du utför OLAP-operationer genereras inga nya dataströmmar.

Konfigurera ROLAP-klienter förenklas genom att eliminera en mellanlänk - skapa en flerdimensionell databas.

3. Kärnan i OLAP-systemet

3.1 Designprinciper

applikationsklientens kärndata

Av vad som har sagts är det tydligt att OLAP-motorn är en av de mest populära metoderna för dataanalys idag. Det finns två huvudmetoder för att lösa detta problem. Den första heter Multidimensional OLAP (MOLAP), som implementerar mekanismen med hjälp av en flerdimensionell databas på serversidan, och den andra, Relational OLAP (ROLAP), bygger kuber i farten baserat på SQL-frågor till en relationell DBMS. Var och en av dessa tillvägagångssätt har sina egna fördelar och nackdelar. Deras jämförande analys ligger utanför ramen för detta arbete. Endast implementeringen av kärnan i skrivbordet ROLAP-modulen kommer att beskrivas här.

Detta problem uppstod efter tillämpningen av ROLAP-systemet, byggt på grundval av de beslutskubkomponenter som ingår i Borland Delphi. Tyvärr visade användningen av denna uppsättning komponenter dålig prestanda på stora datamängder. Detta problem kan mildras genom att försöka skära av så mycket data som möjligt innan du matar in det i kuberna. Men det räcker inte alltid.

På Internet och i pressen kan du hitta mycket information om OLAP-system, men nästan ingenstans sägs det om hur det fungerar internt.

Arbetsschema:

Det allmänna arbetsschemat för ett stationärt OLAP-system kan visas på följande sätt:

Diagram 3. Drift av OLAP-systemet på skrivbordet

Arbetsalgoritmen är som följer:

1. Få data i form av en platt tabell eller resultatet av en SQL-fråga.

2. Caching av data och omvandling till en flerdimensionell kub.

3. Visa den konstruerade kuben med hjälp av en korstab eller diagram etc. I allmänhet kan ett godtyckligt antal skärmar anslutas till en kub.

Tänk på hur liknande system kan ordnas inuti. Vi börjar detta från den sida som kan ses och beröras, det vill säga från mappningarna. De skärmar som används i OLAP-system är oftast av två typer - korstabeller och diagram. Tänk på en korstabell, som är det primära och vanligaste sättet att visa en kub.

I figuren nedan visas rader och kolumner som innehåller aggregerade resultat i gult, celler som innehåller fakta visas i ljusgrå och celler som innehåller måttdata markeras i mörkgrå.

Således kan tabellen delas in i följande element, som vi kommer att arbeta med i framtiden:

När vi fyller i matrisen med fakta ska vi göra så här:

Basera på mätdata och bestäm koordinaterna för det tillagda elementet i matrisen.

Bestäm koordinaterna för kolumnerna och raderna med totalsummor som påverkas av det tillagda objektet.

Lägg till ett element i matrisen och motsvarande kolumner och rader med totalt.

Det bör noteras att den resulterande matrisen kommer att vara mycket gles, varför dess organisation i form av en tvådimensionell matris (en variant som ligger på ytan) inte bara är irrationell, men sannolikt omöjlig på grund av den stora dimensionen av denna matris, för vilken ingen mängd RAM kommer att räcka. Till exempel, om vår kub innehåller information om försäljning under ett år, och om det bara finns 3 dimensioner i det - Kunder (250), Produkter (500) och Datum (365), kommer vi att få en faktmatris med följande dimensioner : antal element \u003d 250 x 500 x 365 \u003d 45 625 000. Och detta trots att de fyllda elementen i matrisen bara kan vara några tusen. Dessutom, ju större antal mätningar, desto mer gles matrisen blir.

För att arbeta med denna matris måste du därför använda speciella mekanismer för att arbeta med glesa matriser. Olika alternativ för att organisera en gles matris är möjliga. De beskrivs ganska väl i programmeringslitteraturen, till exempel i första volymen av den klassiska boken The Art of Programming av Donald Knuth.

Låt oss nu överväga hur du kan bestämma koordinaterna för ett faktum, med vetskap om motsvarande mätningar. För att göra detta, låt oss titta närmare på rubrikstrukturen:

Samtidigt kan du enkelt hitta ett sätt att bestämma numren på motsvarande cell och de totala som den faller i. Flera tillvägagångssätt kan föreslås här. En använder ett träd för att hitta matchande celler. Detta träd kan byggas genom att det går igenom urvalet. Dessutom kan du enkelt definiera en analytisk återkommande formel för att beräkna den önskade koordinaten.

De data som lagras i tabellen måste konverteras för att kunna användas. Så för att förbättra prestanda när man bygger en hyperkub är det önskvärt att hitta unika element som lagras i kolumner som är kubens dimensioner. Dessutom kan du utföra preliminär aggregering av fakta för poster som har samma dimensionsvärden. Som nämnts ovan är de unika värdena som är tillgängliga i mätfälten viktiga för oss. Sedan kan följande struktur föreslås för lagring av dem:

Schema 4. Lagring av unika värden

Genom att använda denna struktur minskar vi minnesbehovet avsevärt. Vilket är ganska relevant, sedan för att öka arbetshastigheten är det önskvärt att lagra data i RAM. Dessutom kan endast en rad element lagras och deras värden kan dumpas till disk, eftersom vi bara behöver dem när vi visar en korstabell.

Idéerna som beskrivs ovan låg till grund för att skapa CubeBase-komponentbiblioteket.

Schema 5. Strukturen i CubeBase-komponentbiblioteket

TСubeSource utför cachning och omvandling av data till ett internt format, liksom preliminär dataggregation. Komponenten TСubeEngine beräknar hyperkuben och fungerar med den. I själva verket är det en OLAP-maskin som förvandlar en platt tabell till en flerdimensionell dataset. TCubeGrid-komponenten hanterar visningen av korstabellen och styr visningen av hyperkuben. TCubeChart låter dig se hyperkuben i form av grafer, och TCubePivote-komponenten styr kubkärnans arbete.

Så jag undersökte arkitekturen och interaktionen mellan komponenter som kan användas för att bygga en OLAP-maskin. Låt oss nu titta närmare på komponenternas interna struktur.

Det första steget i systemet blir att ladda ner data och konvertera det till ett internt format. En logisk fråga kommer att vara - varför är detta nödvändigt, för du kan helt enkelt använda data från en platt tabell och visa den när du bygger en kubskiva. För att svara på denna fråga, överväg strukturen på tabellen ur OLAP-maskinens synvinkel. För OLAP-system kan tabellkolumner vara antingen fakta eller dimensioner. I detta fall kommer logiken att arbeta med dessa kolumner vara annorlunda. I en hyperkub är dimensioner faktiskt axlar och måttvärden är koordinater på dessa axlar. I det här fallet kommer kuben att fyllas mycket ojämnt - det kommer att finnas kombinationer av koordinater som inte motsvarar några poster och det kommer att finnas kombinationer som motsvarar flera poster i originaltabellen, och den första situationen är vanligare, det vill säga kommer kuben att se ut som universum - tomt utrymme, på vissa ställen där det finns kluster av punkter (fakta). Således, om vi pre-aggregerar data under den initiala datainladdningen, det vill säga, vi kombinerar poster som har samma dimensionsvärden, medan vi beräknar de preliminära aggregerade faktavärdena, så i framtiden måste vi arbeta med färre poster, vilket ökar arbetshastigheten och minskar kraven till mängden RAM.

För att konstruera skivor av en hyperkub behöver vi följande funktioner - definiera koordinater (i själva verket mätvärden) för tabellposter, samt definiera poster som har specifika koordinater (mätvärden). Låt oss överväga hur du kan implementera dessa funktioner. Det enklaste sättet att lagra en hyperkub är att använda en databas i sitt eget interna format.

Transformationerna kan schematiskt representeras enligt följande:

Schema 6. Konvertera en internformatdatabas till en normaliserad databas

Istället för en tabell fick vi en normaliserad databas. Generellt sänker normaliseringen systemets prestanda, kan databasspecialister säga, och i detta kommer de att vara helt rätt, i fallet när vi behöver få värden för elementen i ordböckerna (i vårt fall värdena av mått). Men poängen är att vi inte alls behöver dessa värden i det skede vi bygger. Som nämnts ovan är vi bara intresserade av koordinaterna i vår hyperkub, så vi kommer att definiera koordinaterna för mätvärdena. Det enklaste är att ändra numret på elementens värden. För att numreringen ska vara entydig inom en dimension sorterar vi först listorna över mätvärden (ordböcker, i termer av en databas) i alfabetisk ordning. Låt oss dessutom numera om fakta, och fakta är förgrupperade. Vi får följande schema:

Schema 7. Omnumrering av den normaliserade databasen för att bestämma koordinaterna för mätvärden

Nu återstår bara att länka elementen i olika tabeller till varandra. I relationell databasteori görs detta med hjälp av speciella mellanliggande tabeller. Det räcker för oss att sätta varje post i dimensionstabellerna i överensstämmelse med en lista, vars element kommer att vara antalet fakta, i vilken form dessa dimensioner användes (det vill säga för att bestämma alla fakta som har samma värde för de koordinater som beskrivs av denna dimension). För fakta, respektive för varje post, kommer vi att sätta i korrespondens värdena på koordinaterna längs den ligger i hyperkuben. I det följande kommer koordinaterna för en post i en hyperkub att förstås som antalet motsvarande poster i tabellerna med måttvärden. Sedan, för vårt hypotetiska exempel, får vi följande uppsättning som definierar den interna representationen av hypercube:

Schema 8. Intern representation av en hyperkub

Detta kommer att vara vår interna representation av hypercube. Eftersom vi inte gör det för en relationsdatabas använder vi helt enkelt fält med variabel längd som kommunikationsfält med måttvärden (vi kunde inte göra detta i en RDB, eftersom antalet tabellkolumner är fördefinierat).

Vi kan försöka använda en uppsättning tillfälliga tabeller för att implementera en hypercube, men den här metoden ger för låg prestanda (till exempel en uppsättning Decision Cube-komponenter), så vi använder våra egna datalagringsstrukturer.

För att implementera en hyperkub måste vi använda datastrukturer som ger maximal prestanda och minsta minnesförbrukning. Uppenbarligen kommer vi att ha de viktigaste strukturerna för lagring av ordböcker och en faktatabell. Tänk på de uppgifter som ordboken ska utföra med maximal hastighet:

kontrollera om ett element finns i ordboken;

lägga till ett objekt i ordboken;

söka efter postnummer med ett specifikt koordinatvärde;

koordinera sökning efter mätvärde;

sök efter ett mätvärde med dess koordinat.

För att genomföra dessa krav kan du använda olika typer och datastrukturer. Du kan till exempel använda matriser av strukturer. I ett verkligt fall behövs ytterligare indexeringsmekanismer för dessa matriser, vilket ökar hastigheten för datainläsning och informationshämtning.

För att optimera hypercubens arbete är det nödvändigt att avgöra vilka uppgifter som måste lösas som en prioriteringsfråga, och genom vilka kriterier vi behöver för att förbättra kvaliteten på arbetet. Det viktigaste för oss är att öka hastigheten på programmet, medan det är önskvärt att inte mycket RAM krävs. Förbättrad prestanda är möjlig tack vare införandet av ytterligare datatillgångsmekanismer, till exempel införandet av indexering. Tyvärr ökar detta RAM-omkostnaderna. Därför kommer vi att avgöra vilka operationer vi behöver utföra med högsta hastighet. För att göra detta, överväga de enskilda komponenterna som implementerar hypercube. Dessa komponenter är av två huvudtyper - dimension och faktatabell. För mätning skulle en typisk uppgift vara:

lägga till ett nytt värde;

bestämning av koordinaten med mätvärdet;

bestämning av värde med koordinat.

När vi lägger till ett nytt elementvärde måste vi kontrollera om vi redan har ett sådant värde, och i så fall lägg inte till ett nytt utan använd den befintliga koordinaten, annars måste vi lägga till ett nytt element och bestämma dess koordinat. Detta kräver ett sätt snabbsökning närvaron av det nödvändiga elementet (dessutom uppstår ett sådant problem när koordinaten bestäms av elementets värde). För detta är det bästa sättet att använda hashing. I detta fall är den optimala strukturen användningen av hashträd, där vi lagrar referenser till element. I det här fallet kommer elementen att vara linjerna i dimensionens ordlista. Då kan dimensionsvärdets struktur representeras enligt följande:

PFactLink \u003d ^ TFactLink;

TFactLink \u003d post

Fakta nr: heltal; // index för faktum i tabellen

TDimensionRecord \u003d post

Värde: sträng; // mätvärde

Index: heltal; // koordinatvärde

FactLink: PFactLink; // pekare till början av listan med element i faktatabellen

Och vi kommer att lagra länkar till unika element i hashträdet. Dessutom måste vi lösa det omvända transformationsproblemet - för att bestämma mätvärdet med koordinaten. Att förse maximal prestanda du måste använda direkt adressering. Därför kan du använda en annan matris där index är koordinaten för dimensionen och värdet är en referens till motsvarande post i ordboken. Det är dock lättare att göra (och spara på minnet) om du ordnar ordningen med elementen så att elementets index är dess koordinat.

Organisationen av matrisen som implementerar faktalistan ger inga speciella problem på grund av dess enkla struktur. Den enda anmärkningen är att det är önskvärt att beräkna alla aggregeringsmetoder som kan behövas och som kan beräknas stegvis (till exempel summan).

Så vi har beskrivit ett sätt att lagra data i form av en hyperkub. Det låter dig skapa en uppsättning punkter i ett flerdimensionellt utrymme baserat på informationen i datalagret. För att en person ska kunna arbeta med dessa uppgifter måste de presenteras i en form som är bekväm för bearbetning. Samtidigt används en pivottabell och grafer som huvudtyper av datapresentation. Dessutom är båda dessa metoder faktiskt projektioner av en hyperkub. För att säkerställa maximal effektivitet vid framställning av representationer bygger vi på vad dessa prognoser representerar. Låt oss börja med pivottabellen som den viktigaste för dataanalysen.

Låt oss hitta sätt att implementera en sådan struktur. Det finns tre delar som utgör en pivottabell: dessa är radrubriker, kolumnrubriker och den faktiska aggregerade faktatabellen. Mest på ett enkelt sätt faktatabellvyn använder en tvådimensionell matris, vars dimension kan bestämmas genom att konstruera rubrikerna. Tyvärr kommer den enklaste metoden att vara den mest ineffektiva, eftersom tabellen kommer att vara mycket gles och minnet kommer att användas extremt ineffektivt, vilket gör det möjligt att bygga endast mycket små kuber, annars kanske det inte finns tillräckligt med minne . Således måste vi välja en datastruktur för lagring av information som ger maximal sökningshastighet / tillägg av ett nytt element och samtidigt den minimala förbrukningen av RAM. Denna struktur kommer att vara de så kallade glesa matriserna, som du kan läsa mer om i Knuth. Olika sätt att organisera matrisen är möjliga. För att välja det alternativ som passar oss, låt oss först överväga strukturen på bordsrubrikerna.

Rubriker har en tydlig hierarkisk struktur, så det vore naturligt att anta att du använder ett träd för att lagra dem. I detta fall kan strukturen för en trädnod visas schematiskt enligt följande:

Bilaga C

I detta fall är det logiskt att lagra en referens till motsvarande element i dimensionstabellen i en flerdimensionell kub som ett dimensionsvärde. Detta kommer att minska minnesutgifterna för lagring av skivan och påskynda ditt arbete. Länkar används också som noder för föräldrar och barn.

För att lägga till ett element i trädet måste du ha information om dess plats i hyperkuben. Som sådan information är det nödvändigt att använda dess koordinat, som lagras i ordlistan med måttvärden. Låt oss överväga schemat för att lägga till ett element i rubrikträdet i en pivottabell. I det här fallet använder vi värdena på mätkoordinaterna som initial information. Ordningen i vilken dessa dimensioner listas bestäms av den önskade aggregeringsmetoden och är densamma som hierarkinivåerna i rubrikträdet. Som ett resultat av arbetet måste du få en lista med kolumner eller rader i pivottabellen som du behöver lägga till ett element.

AnsökanD

Vi använder mätkoordinaterna som initialdata för att bestämma denna struktur. Dessutom, för bestämdhet, antar vi att vi definierar den intressanta kolumnen för oss i matrisen (vi kommer att överväga hur vi kommer att definiera en rad lite senare, eftersom det är bekvämare att använda andra datastrukturer där, se orsaken till detta val också nedan). Låt oss ta heltal som koordinater - antal mätvärden som kan bestämmas enligt beskrivningen ovan.

Så efter att ha utfört denna procedur får vi en rad referenser till kolumnerna i den glesa matrisen. Nu måste du utföra alla nödvändiga åtgärder med strängarna. För att göra detta måste du i varje kolumn hitta önskat element och lägga till motsvarande värde där. För varje dimension i samlingen måste du veta antalet unika värden och den faktiska uppsättningen av dessa värden.

Låt oss nu överväga i vilken form det är nödvändigt att representera värdena i kolumnerna - det vill säga hur man bestämmer den önskade raden. Flera tillvägagångssätt kan användas för detta. Det enklaste skulle vara att representera varje kolumn som en vektor, men eftersom den kommer att vara mycket gles, kommer minnet att vara extremt ineffektivt. För att undvika detta kommer vi att använda datastrukturer som ger en mer effektiv representation av glesa endimensionella matriser (vektorer). Den enklaste av dessa kommer att vara en vanlig lista, enstaka eller dubbelt länkade, men den är oekonomisk när det gäller åtkomstelement. Därför kommer vi att använda ett träd som ger mer snabb åtkomst till elementen.

Du kan till exempel använda exakt samma träd som för kolumner, men då måste du skapa ett eget träd för varje kolumn, vilket skulle resultera i betydande minne och bearbetningskostnader. Låt oss göra lite knepigare - vi får ett träd för att lagra alla kombinationer av dimensioner som används i strängar, som kommer att vara identiska med den som beskrivs ovan, men dess element kommer inte att vara pekare till strängar (som inte finns som sådana), men deras index och värdena på själva indexen är inte av intresse för oss och används bara som unika nycklar. Vi använder sedan dessa tangenter för att hitta önskat objekt i kolumnen. Kolumnerna själva representeras lättast i form av ett vanligt binärt träd. Den resulterande strukturen kan representeras enligt följande:

Bild 9. Bild av en pivottabell i form av ett binärt träd

Du kan använda samma procedur för att bestämma lämpliga radnummer som i proceduren för att bestämma kolumnerna i en pivottabell ovan. Radnumren är dock unika inom en enda pivottabell och identifierar elementen i vektorerna som är kolumnerna i pivottabellen. Det enklaste sättet att generera dessa nummer är att hålla en räknare och öka den med en när ett nytt element läggs till i radhuvudet. Dessa kolumnvektorer lagras lättast som binära träd, där radnummervärdet används som nyckel. Dessutom är det också möjligt att använda hashtabeller. Eftersom procedurerna för att arbeta med dessa träd diskuteras i detalj i andra källor, kommer vi inte att dröja vid detta och överväga allmänna systemet lägga till ett objekt i en kolumn.

I en generaliserad form kan åtgärdssekvensen för att lägga till ett element i matrisen beskrivas enligt följande:

1. Definiera radnumren till vilka artiklar läggs till

2. Definiera den uppsättning kolumner som objekt läggs till

3.För alla kolumner, hitta element med nödvändiga siffror rader och lägg till det aktuella elementet till dem (lägg till inkluderar att ansluta det erforderliga antalet faktavärden och beräkna aggregerade värden som kan bestämmas stegvis).

Efter att ha utfört denna algoritm får vi en matris som är en pivottabell som vi behövde bygga.

Nu ett par ord om filtrering när man bygger en skiva. Det är lättast att implementera det just i konstruktionsstadiet, eftersom det i detta skede finns tillgång till alla obligatoriska fält och dessutom aggregeras värdena. Samtidigt, under hämtning av en post från cachen, kontrolleras dess överensstämmelse med filtreringsvillkoren, och i händelse av bristande efterlevnad kastas posten.

Eftersom strukturen som beskrivs ovan fullständigt beskriver pivottabellen kommer uppgiften att visualisera den vara trivial. I det här fallet kan du använda de vanliga tabellkomponenterna som finns i nästan alla programmeringsverktyg för Windows.

Den första produkten som kör OLAP-frågor var Express (från IRI). Men termen OLAP myntades av Edgar Codd, "fadern till relationsdatabaser". Och Codds arbete finansierades av Arbor, företaget som släppte sin egen OLAP-produkt, Essbase (senare förvärvad av Hyperion, som förvärvades av Oracle 2007) - ett år tidigare. Andra välkända OLAP-produkter inkluderar Microsoft Analysis Services (tidigare OLAP Services, en del av SQL Server), Oracle OLAP Option, IBM: s DB2 OLAP Server (faktiskt EssBase med tillägg från IBM), SAP BW, Brio-produkter, BusinessObjects, Cognos, MicroStrategy och andra tillverkare.

Ur teknisk synvinkel är produkterna på marknaden uppdelade i "fysisk OLAP" och "virtuell". I det första fallet finns det ett program som utför en preliminär beräkning av aggregat, som sedan lagras i en speciell flerdimensionell databas, vilket säkerställer snabb utvinning. Exempel på sådana produkter är Microsoft Analysis Services, Oracle OLAP Option, Oracle / Hyperion EssBase, Cognos PowerPlay. I det andra fallet lagras data i relationell DBMS, och aggregaten kanske inte existerar alls eller skapas på den första begäran i DBMS eller analytisk programvaru-cache. Exempel på sådana produkter är SAP BW, BusinessObjects, Microstrategy. System baserade på "fysisk OLAP" ger stabila den bästa tiden svar på frågor än "virtuella OLAP" -system. Virtuella OLAP-leverantörer hävdar att de är mer skalbara för att stödja mycket stora mängder data.

I detta arbete vill jag titta närmare på produkten från BaseGroup Labs - Deductor.

Deductor är en analytisk plattform, dvs. grund för att skapa komplett tillämpade lösningar... De tekniker som implementeras i Deductor tillåter, på grundval av en enda arkitektur, att gå igenom alla steg i byggandet av ett analytiskt system: från att skapa ett datalager till att automatiskt välja modeller och visualisera de erhållna resultaten.

Systemets sammansättning:

Deductor Studio är den analytiska kärnan i Deductor-plattformen. Deductor Studio innehåller en komplett uppsättning mekanismer som gör att du kan få information från en godtycklig datakälla, genomföra hela bearbetningscykeln (rengöring, omvandling av data, byggnadsmodeller), vilket visar resultaten på det mest praktiska sättet (OLAP, tabeller, diagram , beslutsträd ...) och exportresultat.

Deductor Viewer är en slutanvändararbetsstation. Programmet låter dig minimera kraven på personal, eftersom alla nödvändiga operationer utförs automatiskt med de tidigare förberedda bearbetningsskripten, det finns inget behov av att tänka på metoden för att erhålla data och mekanismerna för deras bearbetning. Deduсtor Viewer-användaren behöver bara välja den intressanta rapporten.

Deductor Warehouse är ett flerdimensionellt datalager över flera plattformar som samlar all information som behövs för att analysera ämnesområdet. Användningen av ett enda arkiv möjliggör bekväm åtkomst, hög bearbetningshastighet, informationskonsistens, central lagring och automatiskt stöd för hela dataanalysprocessen.

4. Klient-server

Deductor Server är utformad för analytisk bearbetning på distans. Det ger möjlighet att både automatiskt "köra" data genom befintliga skript på servern och omskola befintliga modeller. Med hjälp av Deductor Server kan du implementera en fullständig tretrinnsarkitektur där den fungerar som en applikationsserver. Åtkomst till servern tillhandahålls med Deductor Client.

Arbetsprinciper:

1. Dataimport

Analys av all information i Deductor börjar med dataimport. Som ett resultat av importen fördes uppgifterna till ett formulär som är lämpligt för efterföljande analys med alla mekanismer som finns tillgängliga i programmet. Uppgifternas natur, format, DBMS etc. spelar ingen roll, eftersom mekanismer för att arbeta med alla är enhetliga.

2. Dataexport

Tillgängligheten av exportmekanismer gör att du kan skicka de erhållna resultaten till tredjepartsapplikationer, till exempel för att överföra en försäljningsprognos till systemet för att bilda en inköpsorder eller lägga upp en beredd rapport på en företagswebbplats.

3. Databehandling

Bearbetning i deduktor betyder alla åtgärder som är associerade med någon form av datatransformation, till exempel filtrering, byggande av en modell, rengöring och så vidare. I detta block utförs faktiskt de viktigaste åtgärderna ur analysens synvinkel. Det viktigaste kännetecknet för bearbetningsmekanismerna som implementeras i Deductor är att data som erhållits som ett resultat av bearbetning igen kan behandlas med någon av de metoder som är tillgängliga för systemet. Således kan du skapa godtyckligt komplexa bearbetningsscenarier.

4. Visualisering

Du kan visualisera data i Deductor Studio (Viewer) i alla skeden av behandlingen. Systemet bestämmer självständigt på vilket sätt det kan göra detta, till exempel om det tränas neuralt nätverk, sedan kan du förutom tabeller och diagram visa diagrammet för det neurala nätverket. Användaren måste välja önskat alternativ från listan och konfigurera flera parametrar.

5. Mekanismer för integration

Deductor tillhandahåller inte datainmatningsverktyg - plattformen fokuserar uteslutande på analytisk bearbetning. För att använda information lagrad i heterogena system tillhandahålls flexibla import-exportmekanismer. Interaktion kan organiseras med batchexekvering, arbete i OLE-serverläge och samtal till Deductor Server.

6. Kopiering av kunskap

Med Deductor kan du implementera en av de viktigaste funktionerna i alla analytiska system - stöd för kunskapsreplikationsprocessen, dvs. att ge anställda som inte känner till analysmetoderna och metoderna för att få ett visst resultat att få ett svar baserat på modeller som utarbetats av en expert.

Zavslutande

I det nuvarande arbetet, ett sådant modernt område informationstekniksom ett dataanalyssystem. Det viktigaste verktyget för analytisk informationsbehandling - OLAP - teknik analyseras. Kärnan i begreppet OLAP och innebörden av OLAP-system i den moderna affärsprocessen beskrivs i detalj. ROLAP-serverns struktur och funktion beskrivs i detalj. Deductors analytiska plattform ges som ett exempel på implementering av OLAP-data. Den inlämnade dokumentationen är utvecklad och uppfyller kraven.

OLAP-teknik är ett kraftfullt databehandlingsverktyg i realtid. OLAP-servern låter dig organisera och presentera data i samband med olika analytiska riktningar och förvandla data till värdefull informationsom hjälper företag att fatta bättre beslut.

Användningen av OLAP-system ger genomgående höga nivåer av prestanda och skalbarhet och stöder datavolymer på flera gigabyte, som kan nås av tusentals användare. Med hjälp av OLAP-teknologier nås information i realtid, dvs. bearbetningsförfrågningar saktar inte ner analysprocessen och säkerställer dess effektivitet och effektivitet. Med visuella administrationsverktyg kan du utveckla och implementera även de mest komplexa analytiska applikationerna, vilket gör processen enkel och snabb.

Liknande dokument

Grunden för begreppet OLAP (On-Line Analytical Processing) är den operativa analytiska bearbetningen av data, särdragen med dess användning på klienten och på servern. Allmänna egenskaper för de grundläggande kraven för OLAP-system samt sätt att lagra data i dem.

abstrakt, tillagt 2010-10-12


OLAP: generella egenskaper, syfte, mål, mål. Klassificering av OLAP-produkter. Principer för att bygga ett OLAP-system, CubeBase-komponentbibliotek. Beroendet av prestanda för klient- och server OLAP-verktyg av ökningen av datavolym.

term paper, lagt till 2013-12-25


Evig datalagring. Kärnan och betydelsen av OLAP-verktyget (On-line Analytical Processing). Databaser och datalager, deras egenskaper. Datalagringens struktur, arkitektur, deras leverantörer. Här är några tips för att förbättra prestanda för OLAP-kuber.

test, tillagt 2010-10-23


Bygga dataanalyssystem. Bygga algoritmer för att designa en OLAP-kub och skapa frågor till den konstruerade pivottabellen. OLAP-teknik för multivariat dataanalys. Förse användarna med information för att fatta ledningsbeslut.

term paper, added 09/19/2008


Grundläggande information om OLAP. Snabb analytisk databehandling. OLAP-produktklassificering. Krav på verktyg för onlineanalysbehandling. Användningen av flerdimensionella databaser i online analytiska bearbetningssystem, deras fördelar.

term paper, added 06/10/2011


Utveckling av undersystem för webbplatsanalys med hjälp från Microsoft Access- och Olap-teknik. Teoretiska aspekter av utvecklingen av ett dataanalysundersystem i informationssystemet för en musikportal. Olap-tekniker i undersystemet för analysen av forskningsobjekt.

term paper, added 11/06/2009


Hänsyn till OLAP-verktyg: klassificering av datamärken och informationsbutiker, begreppet datakub. Systemstruktur för beslutsstöd. Programvaruimplementering av "Abitura" -systemet. Skapande av en webbrapport med Reporting Services-teknik.

perioduppsats, tillagd 2012-12-12


Datalager, organisationsprinciper. Processer för databehandling. OLAP-struktur, tekniska aspekter av flerdimensionell datalagring. Integrationstjänster, fyllning av lagringar och datamärken. Möjligheter för system som använder Microsoft-teknik.

perioduppsats, tillagd 2012-12-12


Bygga ett schema för ett datalager för ett handelsföretag. Spara beskrivningar av butiksrelationsscheman. Visar produktinformation. Skapande av OLAP-kub för ytterligare informationsanalys. Utveckling av frågor för att bedöma stormarknadens effektivitet.

test, tillagt 2015-12-19


Syfte med datalagrar. SAP BW-arkitektur. Bygga analytisk rapportering baserad på OLAP-kuber i SAP BW-systemet. Viktiga skillnader mellan datalager och OLTP-system. Översikt över BEx funktionella områden. Skapa en fråga i BEx Query Designer.

Syftet terminspapper är studiet av OLAP-teknik, konceptet för dess implementering och struktur.

I modern värld dator nätverk och datorsystem möjliggör analys och bearbetning av stora mängder data.

En stor mängd information komplicerar i hög grad sökandet efter lösningar, men gör det möjligt att få mycket mer exakta beräkningar och analyser. För att lösa detta problem finns det en hel klass med informationssystem som utför analyser. Sådana system kallas beslutsstödsystem (DSS) (DSS, Decision Support System).

För att utföra analysen måste DSS samla in information med hjälp av dess inmatning och lagring. Totalt finns det tre huvuduppgifter som löses i DSS:

· dataingång;

· datalagring;

· dataanalys.

Datainmatning i DSS utförs automatiskt från sensorer som kännetecknar miljöns eller processens tillstånd eller av en mänsklig operatör.

Om datainmatningen utförs automatiskt från sensorer ackumuleras data av beredskapssignalen som visas när information visas eller genom cyklisk avfrågning. Om inmatningen utförs av en person, bör de ge användarna praktiska sätt att mata in data, kontrollera dem för korrekt inmatning och utföra nödvändiga beräkningar.

När du matar in data samtidigt av flera operatörer är det nödvändigt att lösa problemen med modifiering och parallell åtkomst av samma data.

DSS tillhandahåller analys med data i form av rapporter, tabeller, grafer för studier och analys, varför sådana system erbjuder beslutsstödfunktioner.

I datainmatningssubsystem som kallas OLTP (On-linetransactionprocessing) implementeras operativ databehandling. För deras implementering används konventionella databashanteringssystem (DBMS).

Analysundersystemet kan byggas utifrån:

· Delsystem för informationshämtningsanalys baserade på relationella DBMS och statiska frågor med hjälp av SQL-språket;

· Delsystem för operativ analys. För att implementera sådana delsystem används OLAP: s analytiska databehandlingsteknik online med begreppet flerdimensionell datapresentation;

· Delsystem för intellektuell analys. Detta delsystem implementerar DataMining-metoder och algoritmer.

Ur användarens synvinkel tillhandahåller OLAP-system ett sätt för flexibel visning av information i olika sektioner, automatiskt kvitto aggregerade data, utför analytiska operationer av faltning, detaljer, jämförelse i tid. Tack vare allt detta är OLAP-system en lösning med stora fördelar inom dataförberedelse för alla typer av affärsrapportering, där presentation av data presenteras i olika sektioner och olika nivåer av hierarki, såsom försäljningsrapporter, olika former av budgetar och andra. OLAP-system har stora fördelar med en sådan presentation i andra former av dataanalys, inklusive prognoser.

1.2 Definition OLAP-system

Tekniken för komplex multivariat dataanalys kallas OLAP. OLAP är en nyckelkomponent i en HD-organisation.

OLAP-funktionalitet kan implementeras på olika sätt, både det enklaste, såsom dataanalys i kontorsapplikationer, och mer komplexa - distribuerade analyssystem baserade på serverprodukter.

OLAP (On-LineAnalyticalProcessing) är en teknik för on-line analytisk databehandling med verktyg och metoder för att samla in, lagra och analysera flerdimensionell data och för att stödja beslutsprocesser.

Huvudsyftet med OLAP-system är att stödja analytiska aktiviteter, godtyckliga förfrågningar från analytikeranvändare. Syftet med OLAP-analys är att testa nya hypoteser.

1993 publicerade grundaren av den relationella metoden för att bygga databaser, Edgar Codd och partners (Edgar Codd, matematiker och IBM Fellow), en artikel initierad av Arbor Software (idag är det det berömda företaget Hyperion Solutions) med titeln "Providing OLAP ( operativ analytisk bearbetning) för användare-analytiker ", som formulerar 12 funktioner i OLAP-teknik, som sedan kompletterades med ytterligare sex. Dessa bestämmelser har blivit huvudinnehållet i en ny och mycket lovande teknik.

De viktigaste funktionerna i tekniken OLAP (Basic):

• flerdimensionell konceptuell representation av data;
• intuitiv databehandling;
• tillgänglighet och detaljerad information;
• omgång datautvinning mot tolkning;
• OLAP-analysmodeller;
• klient-server-arkitektur (OLAP är tillgänglig från skrivbordet);
• öppenhet (transparent tillgång till externa uppgifter);
• stöd för multiplayer.

Specialfunktioner (Särskild):

• bearbetning av opformerade uppgifter;
• spara OLAP-resultat: hålla dem åtskilda från originaldata;
• eliminering av saknade värden;
• hantering av saknade värden.

Funktioner i rapporteringen (Rapportera):

• flexibilitet i att generera rapporter;
• standardrapporteringsprestanda;
• automatisk konfiguration av det fysiska lagret för datautvinning.

Mäthantering (Dimensionera):

• måttens universalitet;
• obegränsat antal dimensioner och aggregeringsnivåer;
• obegränsat antal operationer mellan måtten.

Historiskt sett betyder termen "OLAP" idag inte bara en flerdimensionell vy av data från slutanvändaren, utan också en flerdimensionell representation av data i måldatabasen. Det är med detta som utseendet som oberoende termer är kopplat "Relational OLAP" (ROLAP) och "Flerdimensionell OLAP" (MOLAP).

OLAP-tjänsten är ett verktyg för att analysera stora mängder data i realtid. Genom att interagera med OLAP-systemet kommer användaren att kunna utföra flexibel visning av information, få godtyckliga dataskivor och utföra analytiska operationer för detaljering, faltning, end-to-end-distribution, jämförelse över tid i många parametrar samtidigt. Allt arbete med OLAP-systemet sker med avseende på ämnesområde och låter dig bygga statistiskt sunda modeller av affärssituationen.

OLAP-programvara - det är ett verktyg för online dataanalysi förvaret. Huvudfunktionen är att dessa verktyg är avsedda att inte användas av en specialist inom informationsteknik, inte av en expert-statistiker, utan av en professionell inom det tillämpade området management - en chef för en avdelning, avdelning, ledning och slutligen en regissör. Verktygen är avsedda för analytikerens kommunikation med ett problem, inte med en dator... I fig. 6.14 visar en elementär OLAP-kub som låter dig utvärdera data i tre dimensioner.

En flerdimensionell OLAP-kub och ett system med motsvarande matematiska algoritmer för statistisk bearbetning gör att du kan analysera data av vilken komplexitet som helst vid alla tidsintervall.

Fikon. 6.14.

Efter att ha till sitt förfogande flexibla mekanismer för att manipulera data och visuell visning (Fig. 6.15, Fig. 6.16) tittar chefen först på data från olika vinklar, vilket kanske eller inte är relaterat till problemet som löses.

Sedan jämför han olika affärsindikatorer med varandra och försöker avslöja dolda relationer; kan titta på informationen närmare, detaljera den, till exempel genom att sönderdela den i komponenter efter tid, per region eller efter klient, eller omvänt, generalisera presentationen av information ännu mer för att ta bort störande detaljer. Därefter använder du modulen statistisk uppskattning och simulering flera alternativ för utveckling av evenemang byggs, och det mest acceptabla alternativet väljs bland dem.

Fikon. 6.15.

En företagschef kan till exempel utveckla en hypotes om att spridningen av tillgångstillväxt i olika grenar av företaget beror på förhållandet mellan specialister med teknisk och ekonomisk utbildning i dem. För att testa denna hypotes kan chefen fråga från lagret och visa på diagrammet räntan för de filialer vars tillgångstillväxt minskade med mer än 10% jämfört med förra året och för dem vars tillgångar ökade med mer än 25%. Han borde kunna använda ett enkelt val från menyn som erbjuds. Om de erhållna resultaten märkbart faller i två motsvarande grupper, bör detta vara ett incitament för att ytterligare testa hypotesen.

För närvarande har den snabba utvecklingen fått en riktning dynamisk modellering (Dynamic Simulation), som helt implementerar ovanstående FASMI-princip.

Med hjälp av dynamisk modellering bygger analytikern en modell för en affärssituation som utvecklas över tiden, enligt ett visst scenario. Samtidigt kan resultatet av sådan modellering vara flera nya affärssituationer som genererar ett träd möjliga lösningar med en bedömning av sannolikheten och utsikterna för var och en.

Fikon. 6.16.

Tabell 6.3 visar jämförande egenskaper statisk och dynamisk analys.

Tabell 6.3.

Karakteristisk	Statisk analys	Dynamisk analys
Typer av frågor	WHO! Vad? Hur många? Hur? När? Var?	Varför är det så? Tänk om ...? Vad händer om ...?
Respons tid	Inte reglerad	Sekunder
Typiska datahantering	Reglerad rapport, diagram, tabell, figur	En sekvens av interaktiva rapporter, diagram, skärmformer. Dynamiskt förändrade aggregeringsnivåer och dataskärning
Analytiska kravnivå	Mitten	Lång
Skärmformstyp	I grunden förutbestämd, reglerad	Användardefinierad, anpassningsbar
Dataggregationsnivå	Detaljerad och sammanfattning	Användardefinierad
"Ålder" av data	Historisk och aktuell	Historisk, aktuell och projicerad
Typer av förfrågningar	Mestadels förutsägbart	Oförutsägbart - då och då
Utnämning	Reglerad analytisk bearbetning	Multi-pass analys, modellering och prognoser

Uppdraget att bygga ett analytiskt system för multivariat dataanalys är nästan alltid uppgiften att bygga ett enhetligt, konsekvent fungerande informationssystem baserat på heterogent programvaruverktyg och beslut... Och själva valet av medel för implementering av IP blir en extremt svår uppgift. Många faktorer måste beaktas här, inklusive ömsesidig kompatibilitet mellan olika programvarukomponenter , underlättar deras utveckling, användning och integration, effektivitet i funktion, stabilitet och till och med former, nivå och potentiella utsikter för relationer mellan olika tillverkningsföretag.

OLAP är tillämpligt överallt där det finns en multifaktordataanalysuppgift. I allmänhet, om det finns någon tabell med data där det finns minst en beskrivande kolumn och en kolumn med siffror, kommer OLAP-verktyget att effektivt botemedel analys och rapportgenerering. Som ett exempel på användning av OLAP-teknik, överväga studien av resultaten av försäljningsprocessen.

Nyckelfrågor "Hur mycket sålt?", "Hur mycket sålt?" expanderar när verksamheten blir mer komplex och historiska data ackumuleras till ett antal faktorer, eller avsnitt: ".. i St Petersburg, Moskva, Ural, Sibirien ...", ".. under det sista kvartalet, jämfört med nuvarande, ".. från leverantör A kontra leverantör B ..." etc.

Svar på sådana frågor är nödvändiga för att fatta ledningsbeslut: om att ändra sortiment, priser, stänga och öppna butiker, filialer, säga upp och underteckna avtal med återförsäljare, genomföra eller avsluta reklamkampanjer etc.

Om du försöker markera de viktigaste siffrorna (fakta) och avsnitten (mätargument) som analytikern manipulerar för att försöka expandera eller optimera företagets verksamhet, får du en tabell som är lämplig för att analysera försäljning som en typ av mall som kräver lämpliga justeringar för varje företag.

Tid... Som regel är det flera perioder: år, kvartal, månad, decennium, vecka, dag. Många OLAP-verktyg beräknar automatiskt större perioder från ett datum och beräknar totalen för dem.

Produktkategori... Det kan finnas flera kategorier, de skiljer sig åt för varje typ av verksamhet: Variation, modell, typ av förpackning etc. Om bara en produkt säljs eller sortimentet är mycket litet behövs inte kategorin.

Produkt... Ibland används namnet på produkten (eller tjänsten), dess kod eller artikel. I de fall där sortimentet är mycket stort (och vissa företag har tiotusentals artiklar i sin prislista), kanske den första analysen för alla typer av varor inte genomförs utan generaliseras till vissa överenskomna kategorier.

Område... Beroende på företagets globala karaktär kan man betyda kontinent, grupp av länder, land, territorium, stad, distrikt, gata, del av en gata. Naturligtvis, om det bara finns en försäljningsplats, saknas denna dimension.

Säljare... Denna dimension beror också på företagets struktur och storlek. Det kan vara: Branch, Store, Dealer, Sales Manager. I vissa fall finns det ingen dimension, till exempel när säljaren inte påverkar försäljningen finns det bara en butik och så vidare.

Kund... I vissa fall, till exempel i detaljhandeln, är kunden opersonlig och det finns ingen mätning, i andra fall finns det information om kunden och det är viktigt för försäljningen. Denna dimension kan innehålla namnet på det köpande företaget eller många grupper och egenskaper hos kunder: Bransch, företagsgrupp, ägare och så vidare .. Analys av försäljningsstrukturen för att identifiera de viktigaste komponenterna i intressekontext. För detta är det praktiskt att använda till exempel ett diagram av "Pie" -typ i svåra fall när 3 dimensioner undersöks samtidigt - "Kolumner". Till exempel i butiken "Datorutrustning" för kvartalet uppgick försäljningen av datorer till 100 000 dollar, fotografisk utrustning - 10 000 dollar och förbrukningsvaror - 4500 dollar. Slutsats: butiksomsättningen beror i stor utsträckning på försäljning av datorer (faktiskt behövs kanske förbrukningsvaror för att sälja datorer, men detta är en analys av interna beroenden).

Dynamisk analys ( regressionsanalys - identifiera trender). Identifiering av trender, säsongsvariationer. En graf av typen "Linje" visar tydligt dynamiken. Till exempel minskade försäljningen av Intel-produkter under året medan Microsoft ökade. Kanske har den genomsnittliga kundens välbefinnande förbättrats eller butikens image har förändrats och därmed kundernas sammansättning. En sortimentjustering krävs. Ett annat exempel: i tre år på vintern har försäljningen av videokameror minskat.

Beroendeanalys (korrelationsanalys). Jämförelse av försäljningsvolymer för olika varor över tid för att identifiera det önskade sortimentet - "korg". Det är också praktiskt att använda ett "Line" -tabell för detta. När exempelvis skrivare togs bort från produktsortimentet under de första två månaderna minskade försäljningen av pulverpatroner.