Flerdimensionell representation av data. Det allmänna schemat för organisationen av datalagret. Egenskaper, typer och huvudsakliga skillnader mellan OLAP- och OLTP-tekniker. System stjärna och snöflinga. Aggregation. OLAP-system olap-verktyg är utformade för att

Förutsättningarna för hög konkurrens och den växande dynamiken i den yttre miljön dikterar ökade krav på företagsledningssystem. Utvecklingen av teorin och praktiken för förvaltning åtföljdes av uppkomsten av nya metoder, teknologier och modeller som syftar till att förbättra effektiviteten i aktiviteter. Metoder och modeller bidrog i sin tur till framväxten av analytiska system. Efterfrågan på analytiska system i Ryssland är stor. Ur tillämpningssynpunkt är dessa system mest intressanta inom finanssektorn: banker, försäkringsföretag, investeringsbolag. Resultaten av arbetet med analytiska system är först och främst nödvändiga för personer vars beslut företagets utveckling beror på: chefer, experter, analytiker. Analytiska system låter dig lösa problemen med konsolidering, rapportering, optimering och prognoser. Hittills har det inte gjorts någon slutlig klassificering av analytiska system, precis som det inte finns något generellt system av definitioner i termer som används i denna riktning. Ett företags informationsstruktur kan representeras av en sekvens av nivåer, som var och en kännetecknas av sitt eget sätt att bearbeta och hantera information och har sin egen funktion i förvaltningsprocessen. Således kommer analytiska system att ordnas hierarkiskt på olika nivåer denna infrastruktur.

Transaktionssystemnivå

Datalagringslager

Data Mart Layer

OLAP-systemnivå

Analytiskt applikationsskikt

OLAP - system - (OnLine Analytical Processing, analytisk bearbetning i realtid) - är en teknik för komplex multidimensionell dataanalys. OLAP - system är tillämpliga där det finns en uppgift att analysera multifaktoriell data. De är ett effektivt verktyg för att analysera och generera rapporter. Datalager, datamarts och OLAP-system som diskuterats ovan är relaterade till business intelligence-system (Business Intelligence, BI).

Mycket ofta visar sig informations- och analyssystem som skapats för direkt användning av beslutsfattare vara extremt enkla att använda, men kraftigt begränsade i funktionalitet. Sådana statiska system kallas i litteraturen Executive Information Systems (ISR), eller Executive Information Systems (EIS). De innehåller fördefinierade uppsättningar av frågor och, även om de är tillräckliga för en daglig överblick, kan de inte svara på alla frågor om tillgänglig data som kan uppstå vid beslutsfattande. Resultatet av ett sådant system är som regel flersidiga rapporter, efter noggrann studie av vilka analytikern har en ny serie frågor. Emellertid måste varje ny begäran, som inte förutses när ett sådant system utformas, först formellt beskrivas, kodas av programmeraren och först därefter exekveras. Väntetiden kan i detta fall vara timmar och dagar, vilket inte alltid är acceptabelt. Således förvandlas den externa enkelheten hos statisk DSS, för vilken de flesta kunder av informations- och analyssystem aktivt kämpar, till en katastrofal förlust av flexibilitet.

Dynamisk DSS, å andra sidan, är fokuserade på att behandla oreglerade (ad hoc) analytikers dataförfrågningar. De mest djupgående kraven för sådana system övervägdes av E. F. Codd i artikeln som lade grunden för begreppet OLAP. Analytikers arbete med dessa system består i en interaktiv sekvens av att generera förfrågningar och studera deras resultat.

Men dynamisk DSS kan fungera inte bara inom området för online analytisk bearbetning (OLAP); Stöd för att fatta ledningsbeslut baserat på ackumulerad data kan utföras inom tre grundområden.

Detaljerad datasfär. Detta är omfattningen av de flesta system för informationshämtning. I de flesta fall gör relations-DBMS ett bra jobb med att hantera de utmaningar som uppstår här. Den allmänt accepterade standarden för språk för relationsdatamanipulation är SQL. Informationshämtningssystem som tillhandahåller ett slutanvändargränssnitt i uppgifterna att söka efter detaljerad information kan användas som tillägg både på separata databaser av transaktionssystem och på ett gemensamt datalager.

Sfär av aggregerade indikatorer. En heltäckande bild av informationen som samlas in i datalagret, dess generalisering och aggregering, hyperkubisk representation och multidimensionell analys är uppgifterna för online analytiska databehandlingssystem (OLAP). Här kan du antingen fokusera på speciella flerdimensionella DBMS, eller hålla dig inom ramen för relationsteknologier. I det andra fallet kan föraggregerade data samlas in i en stjärnformad databas, eller så kan information aggregeras i farten i processen att skanna detaljerade tabeller i en relationsdatabas.

Lagarnas sfär. Intelligent bearbetning utförs med metoder intellektuell analys data (IAD, Data Mining), vars huvuduppgifter är att söka efter funktionella och logiska mönster i den ackumulerade informationen, bygga modeller och regler som förklarar de hittade anomalierna och/eller förutsäger utvecklingen av vissa processer.

Online analytisk databehandling

Konceptet med OLAP bygger på principen om flerdimensionell datarepresentation. I en artikel från 1993 tog E. F. Codd upp bristerna i relationsmodellen, och pekade i första hand på omöjligheten att "kombinera, titta på och analysera data i termer av multidimensionalitet, det vill säga på det mest förståeliga sättet för företagsanalytiker", och definierade allmänna krav. för OLAP-system som utökar funktionaliteten hos relations-DBMS och inkluderar multidimensionell analys 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 tillhandahåller OLAP-funktionalitet i en eller annan grad. Cirka 30 av de mest kända finns listade i översiktswebbservern http://www.olapreport.com/. Genom att tillhandahålla en flerdimensionell konceptuell vy från användargränssnittet till källdatabasen är alla OLAP-produkter indelade i tre klasser beroende på typen av källdatabas.

De tidigaste online analytiska bearbetningssystemen (till exempel Arbor Softwares Essbase, Oracles Oracle Express Server) var MOLAP, vilket innebär att de bara kunde arbeta med sina egna flerdimensionella databaser. De är baserade på egenutvecklade teknologier för flerdimensionell DBMS och är de dyraste. Dessa system tillhandahåller en fullständig cykel av OLAP-bearbetning. De inkluderar antingen, förutom serverkomponenten, sitt eget integrerade klientgränssnitt eller används 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 generera datarepresentationer för slutanvändare.

Online Relational Data Analytical Processing (ROLAP)-system låter dig representera data som lagras i en relationsdatabas i en flerdimensionell form, vilket ger informationsomvandling till en flerdimensionell modell genom ett mellanliggande metadatalager. ROLAP-system är väl anpassade för att fungera med stora förråd. Liksom MOLAP-system kräver de betydande underhållskostnader av IT-specialister och ger ett driftsätt för flera användare.

Slutligen är hybridsystem (Hybrid OLAP, HOLAP) utformade för att kombinera fördelarna och minimera nackdelarna med de tidigare klasserna. Speedwares Media/MR tillhör denna klass. Enligt utvecklarna kombinerar den den analytiska flexibiliteten och svarshastigheten hos MOLAP med den ständiga tillgången till riktig data som är inneboende i ROLAP.

Flerdimensionell OLAP (MOLAP)

I specialiserade DBMS baserade på multidimensionell datarepresentation organiseras data inte i form av relationstabeller, utan i form av ordnade flerdimensionella arrayer:

1) hyperkuber (alla celler som lagras i databasen måste ha samma dimension, det vill säga vara i den mest kompletta basen av mätningar) eller

2) polykuber (varje variabel lagras med sin egen uppsättning mätningar, och alla bearbetningssvårigheter förknippade med detta flyttas till systemets interna mekanismer).

Användningen av flerdimensionella databaser i online analytiska bearbetningssystem har följande fördelar.

Vid användning av flerdimensionell DBMS är sökning och hämtning av data mycket snabbare än med en multidimensionell konceptuell vy av en relationsdatabas, eftersom en multidimensionell databas är denormaliserad, innehåller föraggregerade mått och ger optimerad åtkomst till de begärda cellerna.

Flerdimensionell DBMS klarar enkelt av uppgifterna att inkluderas i informationsmodell olika inbyggda funktioner, medan de objektivt existerande begränsningarna för SQL-språket gör implementeringen av dessa uppgifter baserade på relations-DBMS ganska svår, och ibland omöjlig.

Å andra sidan finns det betydande begränsningar.

Flerdimensionell DBMS tillåter dig inte att arbeta med stora databaser. Dessutom, på grund av denormalisering och förutförd aggregering, motsvarar volymen av data i en flerdimensionell databas som regel (enligt Codds uppskattning) 2,5-100 gånger mindre än volymen av den ursprungliga detaljerade datan.

Flerdimensionella DBMS:er är mycket ineffektiva i sin användning av externt minne jämfört med relationella DBMS:er. I de allra flesta fall är informationshyperkuben mycket sparsam, och eftersom data lagras i en ordnad form kan nollvärden endast tas bort genom att välja den optimala sorteringsordningen, vilket gör det möjligt att organisera data i största möjliga kontinuerliga grupper. Men även i detta fall är problemet bara delvis löst. Dessutom är den optimala sorteringsordningen när det gäller lagring av glesa data sannolikt inte den ordning som oftast används i frågor. Därför måste man i verkliga system hitta en kompromiss mellan hastighet och redundans för det diskutrymme som upptas av databasen.

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

Mängden initial data för analys är inte för stor (inte mer än några få gigabyte), det vill säga nivån på dataaggregering ä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 omstrukturering av hyperkuben).

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

Det kräver omfattande användning av komplexa inbyggda funktioner för att utföra tvärdimensionella beräkningar på hyperkubceller, inklusive möjligheten att skriva anpassade funktioner.

Relationell OLAP (ROLAP)

Den direkta användningen av relationsdatabaser i online analytiska bearbetningssystem har följande fördelar.

I de flesta fall implementeras företagsdatalager med relationell DBMS, och ROLAP-verktyg låter dig utföra analyser 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 ändringar i dimensionsstrukturen måste göras ganska ofta, är ROLAP-system med en dynamisk dimensionsrepresentation den optimala lösningen, eftersom sådana modifieringar i dem inte kräver fysisk omorganisation av databasen.

Relationella DBMS ger en mycket högre nivå av dataskydd och goda åtkomstkontrollmöjligheter.

Den största nackdelen med ROLAP jämfört med flerdimensionell DBMS är lägre prestanda. För att uppnå prestanda jämförbar med MOLAP kräver relationssystem noggrann design av databasschemat och justering av index, vilket är mycket ansträngning från DBA:s sida. Det är bara när man använder stjärnscheman som prestandan för välinställda relationssystem kan approximeras till den för system baserade på flerdimensionella databaser.

Den största skillnaden mellan fakta och information är att vi tar emot och tar del av uppgifterna, men vi kan använda informationen till vår fördel. Grovt sett är information analyserad och systematiserad data. Tack vare den aktuella informationen som mottagits lyckas många företag överleva både under finanskrisen och i hård konkurrens. Det räcker inte att samla in fakta och ha all nödvändig information. Du måste fortfarande kunna analysera dem. För att underlätta arbetet för personer som uppmanas att fatta viktiga affärsbeslut har olika stödsystem tagits fram. Det är för detta ändamål som olika komplexa system har utvecklats som gör det möjligt att analysera stora mängder heterogena data och omvandla dem till information användbar för en affärsanvändare. Det framväxande området business intelligence syftar till att förbättra processkontrollen av affärssystem, genom användning av datalagring och teknologi.

Marknaden för företagsinformationssystem erbjuder idag ett brett utbud av lösningar som hjälper ett företag att organisera förvaltningsredovisning, säkerställa operativ ledning av produktion och försäljning och effektivt interagera med kunder och leverantörer.

En separat nisch på marknaden för affärssystem upptas av analytiska mjukvaruprodukter utformade för att stödja beslutsfattande på strategisk nivå för företagsledning. Den största skillnaden mellan sådana verktyg och operativa ledningssystem är att de senare tillhandahåller företagsledning i "fungerande läge", det vill säga implementeringen av ett väldefinierat produktionsprogram, medan analytiska system på strategisk nivå hjälper företagsledningen att utveckla beslut i "utvecklingsläget".

Omfattningen av de förändringar som genomförs kan variera från djupgående omstruktureringar till partiell förnyelse av teknologier vid enskilda produktionsanläggningar, men i vilket fall som helst överväger beslutsfattare utvecklingsalternativ som avgör företagets öde på lång sikt.

Oavsett hur kraftfullt och utvecklat ett företags informationssystem är, kan det inte hjälpa till att lösa dessa problem, dels eftersom det är inställt på stationära, etablerade affärsprocesser, dels har det inte och kan inte ha information för att fatta beslut om nya affärsområden, ny teknik, nya organisatoriska beslut.

Tack vare OLAP (On-Line Analytical Processing) databehandlings- och analysteknik kan vilken organisation som helst nästan omedelbart (inom fem sekunder) få de data som behövs för arbetet. OLAP kan definieras kort med fem nyckelord.

FAST (Snabb) - detta betyder att tiden för att söka och utfärda den nödvändiga informationen inte tar mer än fem sekunder. De enklaste förfrågningarna behandlas på en sekund, och endast ett fåtal komplexa förfrågningar har en handläggningstid på mer än tjugo sekunder. Olika metoder används för att uppnå detta resultat, från speciella former av datalagring till omfattande förberäkningar. Således kan du få en rapport på en minut, som tidigare tagit dagar att förbereda.

ANALYS (Analytisk) säger att systemet kan utföra vilken analys som helst, både statistisk och logisk, och sedan sparar den i en tillgänglig form.

DELAD (Delad) innebär att systemet ger den nödvändiga integriteten, ner till cellnivå

MULTIDIMENSIONAL (Multidimensional) - är den huvudsakliga egenskapen hos OLAP. Systemet måste fullt ut stödja hierarkier och flera hierarkier, eftersom detta är det mest logiska sättet att analysera både verksamheten och aktiviteterna i organisationer.

INFORMATION (Information). Nödvändig information måste levereras dit det behövs.

En organisations arbete samlar alltid data relaterade till omfattningen av dess verksamhet, som ibland lagras på helt olika platser, och att sammanföra dem är både svårt och tidskrävande. Det var för att påskynda insamlingen av data för att testa nya affärshypoteser som teknologin för interaktiv analytisk databehandling, eller OLAP, utvecklades. Huvudsyftet med sådana OLAP-system är att snabbt svara på godtyckliga användarförfrågningar. Ett sådant behov uppstår ofta under utvecklingen av något viktigt affärsprojekt, när utvecklaren behöver en arbetshypotes som har uppstått. Oftast ska informationen som användaren behöver presenteras i form av någon form av beroende – till exempel hur försäljningsvolymen beror på produktkategori, på försäljningsregion, på säsong och så vidare. Tack vare OLAP kan han omedelbart få nödvändiga data i önskad layout för den valda perioden.

Interaktiv OLAP-teknik låter dig omvandla enorma högar med rapporter och massor av data till användbar och korrekt information som hjälper en anställd att fatta ett välgrundat affärs- eller finansiellt beslut vid rätt tidpunkt.

Dessutom, tack vare OLAP, ökas bearbetningseffektiviteten, och användaren kan ta emot stora mängder sorterad (aggregerad) information nästan omedelbart. Tack vare OLAP kan användaren tydligt se hur effektivt hans organisation fungerar, har förmågan att reagera snabbt och flexibelt på externa förändringar och har förmågan att minimera de ekonomiska förlusterna för sin organisation. OLAP tillhandahåller korrekt information som förbättrar beslutsfattandet.

Den enda nackdelen med business intelligence-system är deras höga kostnad. Att skapa ett personligt informationslager kräver både tid och mycket pengar.

Användningen av OLAP - teknik i affärer gör att du snabbt kan få den nödvändiga informationen, som på användarens begäran kan presenteras i den vanliga formen - rapporter, grafer eller tabeller.

Rutiner för systemintegration av affärsstrukturer baseras på användning av gemensamma lösningar av ERP, CRM och SCM. I många fall levereras system av olika tillverkare och importerad data måste genomgå en process av dataavstämning och presentation som heterogen data. I en affärsmiljö antas ett entydigt krav - en fullständig analys av data, vilket innebär att man ser konsoliderade rapporter från olika synvinklar.

Olika tillverkare har olika datarepresentationsmekanismer. Den heterogena presentationsproceduren involverar extrahering, transformation och laddning (ETL). Till exempel i Microsoft SQL Server 2005 Analysis Services problemet med datakonsolidering implementeras med hjälp av Data Source Views - typer av datakällor som beskriver analytiska vymodeller.

Affärsapplikationer baserade på OLAP-teknologier, exempel på produkter. De vanligaste tillämpningarna av OLAP-tekniker är:

Dataanalys.

Den uppgift som OLAP-verktyg ursprungligen användes för och fortfarande är den mest populära. En multidimensionell datamodell, förmågan att analysera stora mängder data och snabba svar på förfrågningar gör sådana system oumbärliga för att analysera försäljning, marknadsföringsaktiviteter, distribution och andra uppgifter med en stor mängd initial data.

Produktexempel: Microsoft excel Pivottabeller, Microsoft Analysis Services, SAP BW, Oracle Essbase, Oracle OLAP, Cognos PowerPlay, MicroStrategy, Business Objects.

Ekonomisk planering-budgetering.

En multidimensionell modell gör att du samtidigt kan mata in data och enkelt analysera dem (till exempel planera faktaanalys). Därför serien moderna produkter CPM-klasser (Corporate Performance Management) använder OLAP%-modeller. En viktig uppgift är flerdimensionell back-beräkning (backsolve, breakback, writeback), som låter dig beräkna de nödvändiga ändringarna i detaljerade celler när det aggregerade värdet ändras. Det är ett verktyg för vad-om-analys (vad-om), d.v.s. att spela olika varianter av evenemang vid planering.

Produktexempel: Microsoft PerformancePint, Oracle EPB, Oracle OFA, Oracle Hyperion Planning, SAP SEM, Cognos Enterprise Planning, Geac.

finansiell konsolidering.

Konsolidering av data i enlighet med internationella redovisningsstandarder, med hänsyn tagen till ägarandelar, olika valutor och interna omsättningar, är en angelägen uppgift på grund av de skärpta kraven från kontrollorgan (SOX, Basel II) och företags börsintroduktioner. OLAP-tekniker gör det möjligt att påskynda beräkningen av konsoliderade rapporter och öka transparensen i hela processen.

Produktexempel: Oracle FCH, Oracle Hyperion FM, Cognos Controller.

Teknik för datalagring och on-line analytisk bearbetning (OLAP).
är viktiga delar av affärsbeslutsstöd, som alltmer blir en integrerad del av alla branscher. Användningen av OLAP-teknologier som ett verktyg för business intelligence ger mer kontroll och snabb tillgång till strategiska
information som bidrar till effektivt beslutsfattande.
Detta ger en möjlighet att modellera realistiska prognoser och effektivare resursanvändning. OLAP gör det möjligt för en organisation att reagera snabbare på marknadens krav.

Bibliografi:

1. Erik Thomsen. OLAP-lösningar: Bygga flerdimensionella informationssystem andra upplagan. Wiley Computer Publishing John Wiley & Sons, Inc., 2002.

2. OLAP Council White paper, http://www.olapcouncil.org/research/whtpaply.htm

3. Gerd Stumme och Bernhard Ganter. Formell konceptanalys _ Matematiska grunder.

Skicka ditt goda 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 er mycket tacksamma.

Postat på 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ör- och nackdelar

3. Kärnan i OLAP-systemet

3.1 Konstruktionsprinciper

Slutsats

Lista över använda källor

Ansökningar

PÅledning

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

OLAP är inte en enda mjukvaruprodukt, inte ett programmeringsspråk och inte ens en specifik teknik. Om du försöker täcka OLAP i alla dess manifestationer, så är detta 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. Även om knappast någon kommer att hålla med om en sådan definition, är det tveksamt att det kommer att föra icke-specialister ett jota närmare att förstå ämnet. Därför, i din önskan om kunskap om OLAP, är det bättre att gå åt andra hållet. Först måste du ta reda på varför analytiker behöver på något sätt specifikt underlätta åtkomst till data.

Faktum är att analytiker är speciella konsumenter av företagsinformation. En analytikers uppgift ä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 hundratals och tusentals händelser. Förresten, en av de väsentliga punkterna som ledde till uppkomsten av OLAP är produktivitet och effektivitet. Låt oss föreställa oss vad som händer när en analytiker behöver få information och OLAP-verktyg inte är tillgängliga i företaget. Analytikern gör självständigt (vilket är osannolikt) eller med hjälp av en programmerare en lämplig SQL-fråga och tar emot informationen av intresse i form av en rapport eller exporterar den till ett kalkylblad. Det finns många problem med detta. 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 göra uppgiften åt honom - allt detta påverkar arbetsproduktiviteten negativt, ökar hjärtinfarkten och strokefrekvensen 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å, ber 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 relationella databasservern för företag som analytikern kommer åt kan tänka djupt och under lång tid och blockera resten av transaktionerna.

Begreppet OLAP dök upp just för upplösning liknande problem. OLAP-kuber är i huvudsak metarapporter. Genom att skära metarapporter (dvs. kuber) efter dimensioner, får analytikern faktiskt de "vanliga" tvådimensionella rapporterna av intresse för honom (detta är inte nödvändigtvis rapporter i ordets vanliga mening - vi pratar 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 frågor med tusentals och miljoner svarsrader), utan dataåtkomsthastigheten för analytikern själv ökar också dramatiskt. 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.

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

Nu när vi har listat ut lite om hur OLAP fungerar och vad det tjänar till, är det ändå värt att formalisera vår kunskap något och ge OLAP-kriterier utan samtidig översättning till vanligt mänskligt språk. Dessa kriterier (totalt totalt) formulerades 1993 av E.F. Codd - 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 definierar 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ändarförfrågan på i genomsnitt fem sekunder; De flesta förfrågningar behandlas dock inom en sekund, och de mest komplexa förfrågningarna bör behandlas inom tjugo sekunder. Nyligen genomförda studier har visat att användaren börjar tvivla på framgången för begäran om det tar mer än trettio sekunder.

Analys (analytisk). Systemet måste kunna hantera alla logiska och statistiska analyser som är specifika för affärsapplikationer och säkerställa att resultaten lagras i en form som är tillgänglig för slutanvändaren. Analysverktyg kan innefatta procedurer för tidsserieanalys, kostnadsallokering, valutaomvandling, modellering av förändringar i organisationsstrukturer och några andra.

Delad (delad). Systemet bör ge stora möjligheter att begränsa tillgången till data och många användares samtidiga arbete.

Flerdimensionell (flerdimensionell). Systemet bör tillhandahålla en begreppsmässigt flerdimensionell representation av data, inklusive fullt stöd flera hierarkier.

Information (information). Kraften hos olika mjukvaruprodukter kännetecknas av mängden indata som behandlas. Olika OLAP-system har olika kapacitet: avancerade OLAP-lösningar kan hantera minst tusen gånger mer data än de minsta. När du väljer ett OLAP-verktyg finns det ett antal faktorer att ta hänsyn till, inklusive dataduplicering, erforderligt RAM-minne, diskutrymmesanvändning, prestanda, integration med informationslager och så vidare.

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 det är möjligt att godtyckligt manipulera den och få de nödvändiga informationssektionerna - rapporter. Samtidigt ser slutanvändaren kuben som en multidimensionell dynamisk tabell som automatiskt sammanfattar data (fakta) i olika sektioner (dimensioner), och låter dig interaktivt hantera beräkningar och rapportens form. Dessa operationer tillhandahålls av OLAP-motorn (eller OLAP-beräkningsmotorn).

Hittills har många produkter utvecklats i världen som implementerar OLAP-teknologier. För att göra det enklare att navigera bland dem använder de klassificeringar av OLAP-produkter: genom metoden att lagra data för analys och genom platsen för OLAP-maskinen. Låt oss ta en närmare titt på varje kategori av OLAP-produkter.

Jag börjar med en klassificering av hur data lagras. Låt mig påminna dig om att flerdimensionella kuber är byggda på basis av källdata och aggregerade data. Både källdata och aggregerade data för kuber kan lagras i både relationella och flerdimensionella databaser. Därför används för närvarande tre datalagringsmetoder: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) och HOLAP (Hybrid OLAP). Följaktligen är OLAP-produkter indelade i tre liknande kategorier enligt metoden för datalagring:

1. När det gäller MOLAP lagras källdata 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. Aggregat data kan placeras i tjänstetabeller i samma databas. Omvandlingen av data från en relationsdatabas till flerdimensionella kuber sker på begäran av ett OLAP-verktyg.

3. Vid användning av HOLAP-arkitekturen finns källdata kvar i relationsdatabasen, medan 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å OLAP-maskinens placering. På grundval av detta är OLAP-produkter uppdelade i OLAP-servrar och OLAP-klienter:

I serverns OLAP-verktyg utförs beräkningar och lagring av aggregerade data av en separat process - servern. Klientapplikationen tar bara emot resultaten av frågor mot flerdimensionella kuber som är lagrade på servern. Vissa OLAP-servrar stöder bara relationsdatabaser, andra bara multidimensionella databaser. Många moderna OLAP-servrar stöder alla tre datalagringsmetoderna: MOLAP, ROLAP och HOLAP.

OLAP-klienten är utformad annorlunda. Flerdimensionell kubbyggnad och OLAP-beräkningar utförs i klientdatorns minne. OLAP-klienter är också uppdelade i ROLAP och MOLAP. Och vissa kan stödja båda alternativen för dataåtkomst.

Var och en av dessa tillvägagångssätt har sina för- och nackdelar. I motsats till vad många tror om fördelarna med serververktyg jämfört med klientverktyg, kan det i ett antal fall vara effektivare och mer lönsamt att använda en OLAP-klient för användare än att använda en OLAP-server.

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

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

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

Klientprogram vid tidpunkten för utförandet av OLAP-operationer exekverar frågor på det på ett SQL-liknande språk, och tar emot inte hela kuben, utan dess visade fragment. OLAP-klient vid tidpunkten för arbetet måste ha random access minne hela kuben. När det gäller ROLAP-arkitekturen måste hela datamatrisen som används för att beräkna kuben först laddas in i minnet. Dessutom, när antalet dimensioner, fakta eller dimensionsmedlemmar ökar, växer antalet aggregationer exponentiellt. Mängden data som behandlas av OLAP-klienten är alltså direkt beroende av mängden RAM på användarens PC.

Observera dock att de flesta OLAP-klienter tillhandahåller distribuerad datoranvändning. Därför förstås antalet bearbetade poster, vilket begränsar arbetet med klientens OLAP-verktyg, inte som volymen primärdata i företagsdatabasen, utan som 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 poster och returnerar ett kompakt urval för ytterligare OLAP-beräkningar. Storleken på detta urval kan vara tiotals och hundratals gånger mindre än volymen av primära, icke-aggregerade poster. Följaktligen minskar behovet av en sådan OLAP-klient i PC-resurser avsevärt.

Dessutom begränsas antalet dimensioner av den mänskliga perceptionens möjligheter. Det är känt att en genomsnittlig person samtidigt kan använda 3-4, max 8 dimensioner. Med ett större antal dimensioner i den dynamiska tabellen är uppfattningen av information betydligt svårare. Denna faktor bör beaktas vid förberäkning av RAM-minnet som en OLAP-klient kan behöva.

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

Denna egenskap bestäms av de två faktorerna som diskuterats ovan: mängden data som bearbetas och datorernas kraft. Med en ökning av antalet till exempel dimensioner minskar prestandan för alla OLAP-verktyg på grund av en betydande ökning av antalet aggregat, men samtidigt är minskningstakten annorlunda. Låt oss visa detta beroende av grafen.

Diagram 1. Beroende av prestanda för klient- och server-OLAP-verktyg på datatillväxt

Prestandaegenskaperna hos en OLAP-server är mindre känsliga för datatillväxt. Detta beror på olika tekniker för att behandla användarförfrågningar från OLAP-servern och OLAP-klienten. Till exempel, under en borroperation, kommer OLAP-servern åt de lagrade data och "drar" data från denna "gren". OLAP-klienten, å andra sidan, beräknar hela uppsättningen av aggregat vid tidpunkten för laddning. Men upp till en viss mängd data är prestanda för server- och klientverktyg jämförbar. För OLAP-klienter som stöder distribuerad databehandling kan området för prestandajämförbarhet sträcka sig till datavolymer som täcker OLAP-analysbehoven för ett stort antal användare. Detta bekräftas av resultaten av intern testning av MS OLAP Server och OLAP-klienten "Contour Standard". Testet utfördes på en 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. Kubladdningstiden i båda fallen överstiger inte 1 sekund, och utförandet av olika OLAP-operationer (borra upp, borra ner, flytta, filtrera, etc.) utförs på hundradelar av en sekund.

När provstorleken överstiger mängden RAM-minne börjar bytet med disken och OLAP-klientens prestanda sjunker kraftigt. Först från denna tidpunkt kan vi prata om fördelen med OLAP-servern.

Man bör komma ihåg att "brytpunkten" definierar gränsen för en kraftig ökning av kostnaden för en OLAP-lösning. För varje specifik användares uppgifter bestäms denna punkt enkelt av prestandatester av OLAP-klienten. Sådana tester kan erhållas från utvecklarföretaget.

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

Att använda en OLAP-server i den "klassiska" ideologin innebär att ladda upp data från relationella DBMS:er till en flerdimensionell databas. Uppladdningen utförs under en viss period, så OLAP-serverdatan återspeglar inte tillståndet för närvarande. Endast de OLAP-servrar som stöder ROLAP-driftsläget berövas denna brist.

På samma sätt tillåter ett antal OLAP-klienter ROLAP- och Desktop-arkitekturer med direkt databasåtkomst. Detta ger on-line analys av initiala data.

OLAP-servern ställer minimikrav på klientterminalernas kapacitet. Objektivt sett är kraven för OLAP-klienten högre, eftersom den utför beräkningar i RAM-minnet på användarens PC. Tillståndet för en viss organisations maskinvaruflotta är en kritisk faktor att ta hänsyn till när du väljer ett OLAP-verktyg. Men det har också sina för- och nackdelar. En OLAP-server använder inte den enorma processorkraften som dagens persondatorer har. Om en organisation redan har en flotta av moderna datorer är det ineffektivt att bara använda dem som displayterminaler och samtidigt dra på sig extra kostnader för en central server.

Om kraften i användarnas datorer "lämnar mycket att önska", kommer OLAP-klienten att köras långsamt eller inte fungera alls. Att köpa en kraftfull server kan vara billigare än att uppgradera alla datorer.

Här är det användbart att ta hänsyn till trender inom hårdvaruutveckling. Eftersom mängden data för analys är praktiskt taget konstant, kommer den stadiga tillväxten av PC-kraft att leda till att OLAP-klienternas kapacitet utökas och OLAP-servrar flyttas till segmentet med mycket stora databaser.

När du använder en OLAP-server skickas endast visningsdata över nätverket till klientdatorn, medan OLAP-klienten tar emot alla primära exempeldata.

Därför, när en OLAP-klient används, nätverkstrafik kommer att vara högre.

Men när du använder en OLAP-server kan användaroperationer, till exempel, drill down, generera nya frågor till en flerdimensionell databas och därför en ny dataöverföring. Exekveringen av OLAP-operationer av OLAP-klienten utförs i RAM och orsakar följaktligen inte nya dataflöden i nätverket.

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

Därför, i den överväldigande majoriteten av fallen, kommer analysen av en databas med "medelstora" storlekar med en OLAP-klient inte att sakta ner användarens arbete.

Kostnaden för en OLAP-server är ganska hög. Detta bör även inkludera kostnaden för en dedikerad dator och de fasta kostnaderna för att administrera en flerdimensionell databas. Dessutom kräver implementering och underhåll av en OLAP-server tillräckligt höga kvalifikationer från personalen.

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. Det finns inga höga krav på personalens kvalifikationer vid implementering av en OLAP-klient. En OLAP-klient kan distribueras mycket snabbare än en OLAP-server.

Utveckling av analytiska applikationer med hjälp av klient-OLAP-verktyg är en snabb process som inte kräver särskild utbildning av utföraren. En användare som kan den fysiska implementeringen av databasen kan utveckla en analytisk applikation på egen hand, utan inblandning av en IT-specialist. När du använder en OLAP-server måste du lära dig 2 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 enda visuellt gränssnitt för att beskriva kuber och anpassa användargränssnitt för dem.

Överväg processen att skapa en OLAP-applikation med hjälp av klientverktyget.

Diagram 2: Skapa en OLAP-applikation med ROLAP-klientverktyget

Funktionsprincipen för ROLAP-klienter är en preliminär beskrivning av det semantiska skiktet bakom vilket den fysiska strukturen för källdata döljs. I det här fallet kan datakällor vara: lokala tabeller, RDBMS. Listan över datakällor som stöds bestäms av den specifika programvaruprodukten. Därefter kan användaren självständigt manipulera de objekt som han förstår vad gäller ämnesområdet för att skapa kuber och analytiska gränssnitt.

Funktionsprincipen för OLAP-serverklienten är annorlunda. På OLAP-servern, när användaren skapar kuber, manipulerar användaren de fysiska beskrivningarna av databasen.

Detta skapar anpassade beskrivningar i själva kuben. OLAP Server-klienten är endast konfigurerad för kub.

Låt oss förklara hur ROLAP-klienten fungerar med exemplet att skapa en dynamisk försäljningsrapport (se figur 2). Låt initialdata för analys lagras i två tabeller: Försäljning och Affär.

När man skapar ett semantiskt lager beskrivs datakällorna - Försäljnings- och Deal-tabellerna - i termer som är begripliga för slutanvändaren och blir till "Produkter" och "Deals". Fältet "ID" från tabellen "Produkter" byter namn till "Kod" och "Namn" till "Produkt" och så vidare.

Sedan skapas ett affärsobjekt för försäljning. Ett affärsobjekt är ett platt bord på grundval av vilket en flerdimensionell kub bildas. När du skapar ett affärsobjekt kombineras tabellerna "Produkter" och "Affärer" av fältet "Kod" för produkten. Eftersom rapporten inte behöver visa alla fält i tabellerna använder affärsobjektet bara fälten Artikel, Datum och Belopp.

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

När man arbetar med en interaktiv rapport kan användaren ställa in filtrerings- och grupperingsvillkor med samma enkla musrörelser. Vid denna tidpunkt kommer ROLAP-klienten åt data i cachen. OLAP-serverns klient genererar en ny fråga till den flerdimensionella databasen. Genom att till exempel använda ett produktfilter i försäljningsrapporten kan du få en rapport om försäljningen av produkter av intresse för oss.

Alla inställningar för en OLAP-applikation kan lagras i ett dedikerat metadatalager, i ett program eller i ett flerdimensionellt databassystem. Implementeringen beror på den specifika mjukvaruprodukten.

Så, i vilka fall kan användningen av en OLAP-klient för användare vara mer effektiv och fördelaktig än att använda en OLAP-server?

Den ekonomiska genomförbarheten av att använda en OLAP-server uppstår när mängden data ä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ög prestanda och låg kostnad.

Kraftfulla analytikers datorer är ett annat argument för OLAP-klienter. När du använder en OLAP-server används inte dessa kapaciteter. Andra fördelar med OLAP-klienter inkluderar:

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

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

Att konfigurera ROLAP-klienter förenklas genom att eliminera mellanlänken - skapa en flerdimensionell databas.

3. Kärnan i OLAP-systemet

3.1 Konstruktionsprinciper

applikationsklients kärndata

Av det som redan har sagts är det tydligt att OLAP-mekanismen är en av de mest populära dataanalysmetoderna idag. Det finns två huvudsakliga metoder för att lösa detta problem. Den första av dem kallas Multidimensional OLAP (MOLAP) - implementeringen av mekanismen med hjälp av en multidimensionell databas på serversidan, och den andra Relational OLAP (ROLAP) - bygger kuber i farten baserat på SQL-frågor till ett relationellt DBMS. Var och en av dessa tillvägagångssätt har sina för- och nackdelar. Deras jämförande analys ligger utanför ramen för detta arbete. Endast kärnimplementeringen av ROLAP-modulen för skrivbordet kommer att beskrivas här.

En sådan uppgift uppstod efter att ha använt ROLAP-systemet, byggt på basis av Decision Cube-komponenterna som är en del av Borland Delphi. Tyvärr visade användningen av denna uppsättning komponenter dålig prestanda på stora mängder data. Detta problem kan minskas genom att försöka skära bort så mycket data som möjligt innan du skickar in den till byggkuber. Men detta räcker inte alltid.

På Internet och i pressen kan man hitta mycket information om OLAP-system, men nästan ingenstans står det om hur det fungerar inuti.

Arbetsschema:

Det allmänna schemat för skrivbordets OLAP-system kan representeras enligt följande:

Schema 3. Arbetet med ett stationärt OLAP-system

Algoritmen för arbetet är följande:

1. Inhämta data i form av en platt tabell eller resultat SQL-exekvering begäran.

2. Cacha data och konvertera dem till en flerdimensionell kub.

3. Visning av den konstruerade kuben med hjälp av en korstabell eller diagram, etc. I allmänhet kan ett godtyckligt antal mappningar kopplas till en kub.

Fundera på hur ett sådant system kan ordnas internt. Låt oss börja från den sida som du kan se och känna, det vill säga från mappningarna. Displayer 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 är markerade i ljusgrått och celler som innehåller dimensionsdata är markerade 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 måste vi gå tillväga enligt följande:

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

Bestäm koordinaterna för kolumnerna och raderna för totalsummorna som påverkas av elementet som läggs till.

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

Samtidigt bör det noteras att den resulterande matrisen kommer att vara mycket gles, varför dess organisation i form tvådimensionell array(en variant som ligger på ytan) är inte bara irrationell, utan sannolikt omöjlig på grund av den stora dimensionen av denna matris, för vilken ingen mängd RAM räcker att lagra. Till exempel, om vår kub innehåller försäljningsinformation för ett år, och om den bara har 3 dimensioner - kunder (250), produkter (500) och datum (365), så får vi en matris med fakta av följande dimensioner: antal av element = 250 x 500 x 365 = 45 625 000. Och detta trots att det bara kan finnas några tusen fyllda element i matrisen. Dessutom, ju fler dimensioner, desto glesare blir matrisen.

Därför, för att arbeta med denna matris, måste du tillämpa speciella mekanismer för att arbeta med glesa matriser. Olika alternativ för att organisera en gles matris är möjliga. De är ganska väl dokumenterade i programmeringslitteraturen, som till exempel första volymen av Donald Knuths klassiker The Art of Programming.

Låt oss nu överväga hur vi kan bestämma koordinaterna för ett faktum, med kunskap om dimensionerna som motsvarar det. För att göra detta, låt oss titta närmare på rubrikstrukturen:

I det här fallet kan du enkelt hitta ett sätt att bestämma numren för motsvarande cell och totalsummorna som den faller i. Flera tillvägagångssätt kan föreslås här. En är att använda trädet för att hitta matchande celler. Detta träd kan byggas genom att passera genom provet. Dessutom kan en analytisk rekursiv formel enkelt definieras för att beräkna den nödvändiga koordinaten.

Data som lagras i tabellen måste konverteras för att kunna användas. Så, för att förbättra prestandan när du bygger en hyperkub, är det önskvärt att hitta unika element lagrade i kolumner som är dimensioner för kuben. Dessutom kan du föraggregera fakta för poster som har samma dimensionsvärden. Som nämnts ovan är de unika värdena som finns tillgängliga i dimensionsfälten viktiga för oss. Sedan kan följande struktur föreslås för att lagra dem:

Schema 4. Struktur för att lagra unika värden

Genom att använda denna struktur minskar vi behovet av minne avsevärt. Vilket är ganska relevant, eftersom. För att öka hastigheten på arbetet är det önskvärt att lagra data i RAM. Dessutom kan du bara lagra en rad element och ladda upp deras värden till disken, eftersom vi bara behöver dem när vi visar korstabellen.

De idéer som beskrivs ovan låg till grund för att skapa CubeBase-komponentbiblioteket.

Schema 5. Strukturen för CubeBase-komponentbiblioteket

TСubeSource utför cachning och datakonvertering till ett internt format, såväl som preliminär dataaggregering. TСubeEngine-komponenten beräknar hyperkuben och utför operationer med den. I själva verket är det en OLAP-maskin som omvandlar en platt tabell till en flerdimensionell datamängd. TCubeGrid-komponenten visar korstabellen och styr visningen av hyperkuben. TСubeChart låter dig se hyperkuben i form av grafer, och TСubePivote-komponenten styr driften av kubkärnan.

Så jag har övervägt 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 är att ladda data och konvertera dem till ett internt format. Frågan kommer att vara logisk - varför är detta nödvändigt, eftersom du helt enkelt kan använda data från en platt tabell och titta på den när du bygger en kubskiva. För att besvara denna fråga, låt oss överväga tabellstrukturen från en OLAP-maskins synvinkel. För ett OLAP-system kan tabellkolumner vara antingen fakta eller dimensioner. I det här fallet kommer logiken att arbeta med dessa kolumner att vara annorlunda. I en hyperkub är dimensionerna faktiskt axlarna, och värdena för dimensionerna är koordinaterna på dessa axlar. I det här fallet kommer kuben att fyllas väldigt ojämnt - det kommer att finnas kombinationer av koordinater som inte kommer att motsvara några poster och det kommer att finnas kombinationer som motsvarar flera poster i källtabellen, och den första situationen är vanligare, dvs. , kommer kuben att se ut som universum - tom utrymme, på separata platser där kluster av punkter (fakta) uppstår. Alltså, om vi är det bootstrap data kommer vi att pre-aggregera data, det vill säga vi kommer att kombinera poster som har samma mätvärden, samtidigt som vi beräknar de preliminära aggregerade faktavärdena, sedan kommer vi i framtiden att behöva arbeta med färre poster, vilket kommer att öka hastigheten arbete och minska kraven på RAM.

För att bygga delar av en hyperkub behöver vi följande funktioner - att bestämma koordinaterna (i själva verket mätvärden) för tabellposter, samt att bestämma poster som har specifika koordinater (mätvärden). Låt oss se hur dessa möjligheter kan förverkligas. Det enklaste sättet att lagra en hyperkub är att använda en databas med sitt eget interna format.

Schematiskt kan transformationerna representeras enligt följande:

Diagram 6. Konvertering av en intern formatdatabas till en normaliserad databas

Det vill säga, istället för en tabell fick vi en normaliserad databas. Faktum är att normalisering minskar systemets hastighet, kan databasexperter säga, och i detta kommer de säkert att ha rätt när vi behöver få värden för element i ordböcker (i vårt fall dimensionsvärden). Men grejen är att vi inte behöver dessa värden alls när vi konstruerar en skiva. 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 vore att numrera om elementens värden. För att numreringen ska vara entydig inom en dimension sorterar vi först listorna med mätvärden (ordböcker, uttryckta i termer av databasen) i alfabetisk ordning. Dessutom numrerar vi om fakta, och fakta är föraggregerade. Vi får följande diagram:

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 relationsdatabasteori görs detta med hjälp av speciella mellantabeller. Det räcker för oss att tilldela varje post i dimensionstabellerna en lista vars element kommer att vara antalet fakta i vars form dessa dimensioner användes (det vill säga att bestämma alla fakta som har samma värde för koordinaten beskrivs av denna dimension). För fakta, respektive för varje post, lägger vi i korrespondens värdena för koordinaterna längs vilka den ligger i hyperkuben. I det följande menar vi överallt under koordinaterna för en post i hyperkuben numren på motsvarande poster i tabellerna med mätvärden. Sedan för vårt hypotetiska exempel får vi följande uppsättning som definierar den interna representationen av hyperkuben:

Schema 8. Intern representation av en hyperkub

Detta kommer att vara vår interna representation av hyperkuben. Eftersom vi inte gör det för en relationsdatabas, används bara fält med variabel längd som fält för att länka mätvärden (vi kunde inte göra detta i RDB, eftersom antalet tabellkolumner är förutbestämt där).

Man skulle kunna försöka använda en uppsättning temporära tabeller för att implementera en hyperkub, men den här metoden ger för låg prestanda (ett exempel är en uppsättning Decision Cube-komponenter), så vi kommer att använda våra egna datalagringsstrukturer.

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

kontrollera förekomsten av ett element i ordboken;

lägga till ett element i ordboken;

söka efter postnummer som har ett specifikt koordinatvärde;

söka efter koordinater efter mätvärde;

söka efter ett mätvärde med dess koordinater.

För att uppfylla dessa krav kan du använda olika typer och datastrukturer. Du kan till exempel använda arrayer av strukturer. I det verkliga fallet kräver dessa arrayer ytterligare indexeringsmekanismer som kommer att öka hastigheten för att ladda data och erhålla information.

För att optimera driften av hyperkuben är det nödvändigt att bestämma vilka uppgifter som måste prioriteras och med vilka kriterier vi behöver för att uppnå en ökning av kvaliteten på arbetet. Det viktigaste för oss är att öka hastigheten på programmet, medan det är önskvärt att inte en mycket stor mängd RAM krävs. En ökning av prestandan är möjlig tack vare introduktionen ytterligare mekanismer tillgång till data, till exempel införandet av indexering. Tyvärr ökar detta RAM-minnet. Därför bestämmer vi vilka operationer vi behöver utföra med störst hastighet. För att göra detta, överväg de individuella komponenterna som implementerar hyperkuben. 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 genom värdet av mätningen;

bestämning av värdet genom 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 inte lägg 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 att snabbt hitta närvaron av det önskade elementet (dessutom uppstår ett sådant problem också när man bestämmer koordinaten genom elementets värde). För detta kommer hashningen att vara optimal. I det här fallet kommer den optimala strukturen att vara användningen av hashträd, där vi kommer att lagra länkar till element. I det här fallet kommer elementen att vara strängarna i dimensionslexikonet. Då kan dimensionsvärdets struktur representeras enligt följande:

PFactLink = ^TFactLink;

TFactLink = rekord

FactNo: heltal; // faktaindex i tabellen

TDimensionRecord = rekord

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

index: heltal; // koordinatvärde

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

Och i hashträdet kommer vi att lagra länkar till unika element. Dessutom måste vi lösa problemet med den inversa transformationen - för att bestämma värdet på mätningen med koordinaten. Att förse maximal prestanda du måste använda direktadressering. Därför kan du använda en annan array, där indexet är koordinaten för mätningen, och värdet är en länk till motsvarande post i ordboken. Du kan dock göra det enklare (och spara på minnet samtidigt) om du ordnar arrayen av element på lämpligt sätt så att elementets index är dess koordinat.

Organiseringen av en array som implementerar en lista med fakta ger inga särskilda problem på grund av dess enkla struktur. Den enda anmärkningen kommer att vara att det är önskvärt att beräkna alla aggregeringsmetoder som kan behövas och som kan beräknas inkrementellt (till exempel summan).

Så vi har beskrivit ett sätt att lagra data i form av en hyperkub. Det låter dig generera 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 att behandla. Samtidigt används en pivottabell och grafer som huvudtyper av datapresentation. Dessutom är båda dessa metoder faktiskt projektioner av hyperkuben. För att säkerställa maximal effektivitet i att konstruera representationer kommer vi att utgå från vad dessa projektioner representerar. Låt oss börja med pivottabellen, som den viktigaste för dataanalys.

Låt oss hitta sätt att implementera en sådan struktur. Det finns tre delar som utgör en pivottabell: radrubriker, kolumnrubriker och den faktiska aggregerade faktatabellen. av de flesta på ett enkelt sätt faktatabellvyer kommer att använda en tvådimensionell array, vars dimension kan bestämmas genom att bygga rubrikerna. Tyvärr kommer det enklaste sättet att vara det mest ineffektiva, eftersom tabellen kommer att vara mycket gles och minnet kommer att vara extremt ineffektivt, vilket resulterar i att endast mycket små kuber kan byggas, annars kanske det inte finns tillräckligt med minne. Därför måste vi välja en datastruktur för att lagra information som kommer att tillhandahålla toppfart söka / lägga till ett nytt element och samtidigt minimiförbrukningen av RAM. Denna struktur kommer att vara de så kallade glesa matriserna som du kan läsa mer om Knuth om. Möjlig olika sätt matrisorganisation. För att välja det alternativ som passar oss överväger vi först strukturen på tabellrubrikerna.

Rubriker har en tydlig hierarkisk struktur, så det skulle vara naturligt att använda ett träd för att lagra dem. I det här fallet kan trädnodens struktur schematiskt avbildas enligt följande:

Bilaga C

Samtidigt är det logiskt att lagra en referens till motsvarande element i mättabellen för en flerdimensionell kub som ett dimensionsvärde. Detta kommer att minska minnesförbrukningen för att lagra skivan och påskynda arbetet. Länkar används också som överordnade och underordnade noder.

För att lägga till ett element i trädet är det nödvändigt att ha information om dess placering i hyperkuben. Som sådan information är det nödvändigt att använda dess koordinat, som lagras i Dictionary of Dimension Values. Låt oss överväga schemat för att lägga till ett element till rubrikträdet i en pivottabell. I det här fallet använder vi värdena för mätkoordinater som initial information. Ordningen som dessa dimensioner listas i bestäms av den önskade aggregeringsmetoden och matchar hierarkinivåerna i rubrikträdet. Som ett resultat av arbetet måste du få en lista med kolumner eller rader i pivottabellen där du vill lägga till ett element.

AnsökanD

Vi använder mätkoordinaterna som initialdata för att bestämma denna struktur. Dessutom antar vi för tydlighetens skull att vi definierar kolumnen av intresse för oss i matrisen (vi kommer att överväga hur vi kommer att bestämma raden lite senare, eftersom det är bekvämare att använda andra datastrukturer där, se anledningen till detta val även nedan). Som koordinater tar vi heltal - antalet mätvärden som kan bestämmas enligt beskrivningen ovan.

Så efter att ha utfört denna procedur får vi en rad länkar till kolumnerna i den glesa matrisen. Nu behöver du bara göra nödvändiga åtgärder med strängar. För att göra detta, inuti varje kolumn, måste du hitta det önskade elementet och lägga till det motsvarande värde. För var och en av dimensionerna i samlingen måste du känna till antalet unika värden och den faktiska uppsättningen av dessa värden.

Låt oss nu titta på hur man representerar värdena inuti kolumnerna - det vill säga hur man bestämmer den önskade raden. För att göra detta kan flera tillvägagångssätt användas. Det enklaste vore att representera varje kolumn som en vektor, men eftersom det kommer att vara väldigt sparsamt blir minnet extremt ineffektivt. För att undvika detta använder vi datastrukturer som ger mer effektiv representation av glesa endimensionella arrayer (vektorer). Den enklaste av dessa skulle vara en normal lista, enbart eller dubbelt länkad, men inte ekonomisk när det gäller tillgång till element. Därför kommer vi att använda ett träd, vilket kommer att ge snabbare tillgång 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 leda till betydande overhead i minne och bearbetningstid. Låt oss göra lite mer knepigt - låt oss starta ett träd för att lagra alla kombinationer av mått som används i rader, som kommer att vara identiska med den som beskrivs ovan, men dess element kommer inte att vara pekare till rader (som inte existerar som sådana), men deras index och själva indexvärdena är inte av intresse för oss och används endast som unika nycklar. Sedan kommer vi att använda dessa nycklar för att hitta det önskade elementet i kolumnen. Kolumnerna i sig är lättast att representera som ett vanligt binärt träd. Grafiskt kan den resulterande strukturen representeras enligt följande:

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

För att bestämma motsvarande radnummer kan du använda samma procedur som proceduren som beskrivs ovan för att bestämma kolumnerna i pivottabellen. I det här fallet är radnumren unika inom en pivottabell och identifierar element i vektorer som är kolumner i pivottabellen. Det enklaste sättet att generera dessa siffror skulle vara att behålla en räknare och öka den med ett när ett nytt element läggs till i radhuvudträdet. Dessa kolumnvektorer lagras enklast som binära träd, där värdet på radnumret 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 uppehålla oss vid detta och överväga det allmänna schemat för att lägga till ett element i en kolumn.

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

1. Bestäm radnumren där element läggs till

2.Definiera uppsättningen kolumner där objekt läggs till

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

Efter att ha kö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 du bygger en skiva. Det enklaste sättet att implementera det är bara vid konstruktionen av matrisen, eftersom det i detta skede finns tillgång till alla nödvändiga fält, och dessutom utförs aggregeringen av värden. Samtidigt, när en post tas emot från cachen, kontrolleras dess överensstämmelse med filtreringsvillkoren, och i händelse av att den inte uppfyller kraven, kasseras posten.

Eftersom strukturen som beskrivs ovan fullständigt beskriver pivottabellen, kommer uppgiften att visualisera den att vara trivial. I det här fallet kan du använda standardtabellkomponenter som är tillgängliga i nästan alla Windows-programmeringsverktyg.

Den första produkten som utförde OLAP-frågor var Express (ett IRI-företag). Själva termen OLAP myntades dock av Edgar Codd, "relationsdatabasernas fader". Och Codds arbete finansierades av Arbor, företaget som lanserade sin egen OLAP-produkt, Essbase (senare köpt av Hyperion, som togs över av Oracle 2007) ett år tidigare. Andra välkända OLAP-produkter inkluderar Microsoft Analysis Services (tidigare kallade OLAP Services, en del av SQL Server), Oracle OLAP Option, IBM:s DB2 OLAP Server (egentligen EssBase med IBM-tillägg), 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 som ger snabb hämtning. 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 den analytiska programvarans cache. Exempel på sådana produkter är SAP BW, BusinessObjects, Microstrategy. System baserade på "fysisk OLAP" ger stabil lämpligast tid svar på frågor än "virtuella OLAP"-system. Virtuella OLAP-leverantörer hävdar att deras produkter är mer skalbara när det gäller att stödja mycket stora datamängder.

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

Deductor är en analytisk plattform, d.v.s. grunden för att skapa kompletta applikationslösningar. Teknikerna som implementeras i Deductor gör det möjligt att, på basis av en enda arkitektur, gå igenom alla stadier av att bygga ett analytiskt system: från att skapa ett datalager till att automatiskt välja modeller och visualisera resultaten.

Systemsammansättning:

Deductor Studio är den analytiska kärnan i Deductor-plattformen. Deductor Studio innehåller en komplett uppsättning mekanismer som låter dig få information från en godtycklig datakälla, utföra hela bearbetningscykeln (rengöring, datatransformation, bygga modeller), visa resultaten på det mest bekväma sättet (OLAP, tabeller, diagram). , beslutsträd ...) och exportresultat.

Deductor Viewer är slutanvändarens arbetsplats. Programmet låter dig minimera kraven på personal, eftersom alla nödvändiga operationer utförs automatiskt med tidigare förberedda bearbetningsskript, det finns inget behov av att tänka på metoden för att erhålla data och mekanismerna för att bearbeta dem. Användaren av Deductor Viewer behöver bara välja intresserapporten.

Deductor Warehouse är ett multidimensionellt plattformsoberoende datalager som samlar all information som behövs för analys av ämnesområdet. Användningen av ett enda förråd möjliggör bekväm åtkomst, hög hastighet bearbetning, konsistens av information, centraliserad lagring och automatiskt stöd för hela processen med dataanalys.

4. Klientserver

Deductor Server är designad för analytisk bearbetning på distans. Det ger möjlighet att både automatiskt "köra" data genom befintliga skript på servern, och träna om befintliga modeller. Genom att använda Deductor Server kan du implementera en fullfjädrad treskiktsarkitektur där den fungerar som en applikationsserver. Åtkomst till servern tillhandahålls av Deductor Client.

Arbetsprinciper:

1. Dataimport

Analys av all information i Deductor börjar med dataimport. Som ett resultat av importen reduceras data till en form som lämpar sig för efterföljande analys med hjälp av alla mekanismer som finns i programmet. Typen av data, format, DBMS, etc. spelar ingen roll, eftersom mekanismer för arbete med alla är enhetliga.

2. Dataexport

Närvaron av exportmekanismer gör att du kan skicka resultaten till tredje parts applikationer, till exempel överföra en försäljningsprognos till systemet för att generera en inköpsorder eller lägga upp en förberedd rapport på en företagswebbplats.

3. Databehandling

Bearbetning i Deductor betyder varje åtgärd som är kopplad till någon form av datatransformation, till exempel filtrering, bygga en modell, städning och så vidare. I det här blocket utförs faktiskt de viktigaste åtgärderna ur analyssynpunkt. Den viktigaste egenskapen hos de bearbetningsmekanismer som implementeras i Deductor är att data som erhålls som ett resultat av bearbetning kan bearbetas igen med någon av de metoder som är tillgängliga för systemet. Således är det möjligt att bygga godtyckligt komplexa bearbetningsscenarier.

4. Visualisering

Du kan visualisera data i Deductor Studio (Viewer) när som helst under behandlingen. Systemet bestämmer självständigt hur det kan göra detta, till exempel om det är utbildat neuralt nätverk, då kan du förutom tabeller och diagram se grafen för det neurala nätverket. Användaren måste välja önskat alternativ från listan och konfigurera flera parametrar.

5. Integrationsmekanismer

Deductor tillhandahåller inga verktyg för datainmatning - plattformen är uteslutande fokuserad på analytisk bearbetning. För att använda information som lagras i heterogena system tillhandahålls flexibla import-exportmekanismer. Interaktion kan organiseras med batchkörning, arbete i OLE-serverläge och åtkomst till Deductor Server.

6. Replikering av kunskap

Deductor låter dig implementera en av de viktigaste funktionerna i alla analytiska system - stöd för kunskapsreplikeringsprocessen, d.v.s. ger en möjlighet för anställda som inte är insatta i analysmetoder och sätt att få ett visst resultat, att få ett svar baserat på modeller som utarbetats av en expert.

Wslutsats

I detta dokument övervägdes ett sådant område av modern informationsteknik som dataanalyssystem. Analyserade huvudverktyget för analytisk bearbetning av information - OLAP - teknologi. Kärnan i begreppet OLAP och betydelsen av OLAP-system i den moderna affärsprocessen avslöjas i detalj. ROLAP-serverns struktur och funktion beskrivs i detalj. Som ett exempel på implementering av OLAP data - teknologier ges den analytiska plattformen Deductor. Den presenterade dokumentationen är utvecklad och uppfyller kraven.

OLAP-teknologier är ett kraftfullt verktyg för databehandling i realtid. En OLAP-server låter dig organisera och presentera data över olika analyser och förvandlar data till värdefull information som 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, vilket stöder gigabytestora datavolymer som kan nås av tusentals användare. Med hjälp av OLAP-tekniker genomförs tillgång till information i realtid, d.v.s. frågebehandling saktar inte längre ner analysprocessen, vilket säkerställer dess effektivitet och effektivitet. Med visuella administrationsverktyg kan du utveckla och implementera även de mest komplexa analytiska applikationer, vilket gör denna process enkel och snabb.

Liknande dokument

Grunden för konceptet OLAP (On-Line Analytical Processing) - online analytisk databehandling, funktionerna i 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-12-10


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

terminsuppsats, tillagd 2013-12-25


Evig datalagring. Entiteten och värdet för OLAP-verktyget ( Online analytisk bearbetning). Databaser och datalagringar, deras egenskaper. Struktur, arkitektur för datalagring, deras leverantörer. Några tips för att förbättra prestandan 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 inbyggda pivottabellen. OLAP-teknik för multidimensionell dataanalys. Förse användare med information för att fatta ledningsbeslut.

terminsuppsats, tillagd 2008-09-19


Grundläggande information om OLAP. Operationell analytisk databehandling. Klassificering av OLAP-produkter. Krav på medlen för operationsanalytisk bearbetning. Användningen av flerdimensionella databaser i online analytiska bearbetningssystem, deras fördelar.

terminsuppsats, tillagd 2011-10-06


Utveckling av delsystem för webbanalys med hjälp från Microsoft Access- och Olap-teknologier. Teoretiska aspekter av utvecklingen av ett dataanalysdelsystem i informationssystemet för en musikportal. Olap-teknologier i forskningsobjektets analysdelsystem.

terminsuppsats, tillagd 2009-11-06


Övervägande av OLAP-verktyg: klassificering av skyltfönster och informationslagringar, konceptet med en datakub. Systemarkitektur för beslutsstöd. Mjukvaruimplementering Abitura system. Skapa en webbrapport med hjälp av Reporting Services-tekniker.

terminsuppsats, tillagd 2012-05-12


Datalager, organisationsprinciper. Dataprocesser. OLAP-struktur, tekniska aspekter av multidimensionell datalagring. Integrationstjänster, fyllning av lager och datamarts. Förmåga hos system som använder Microsoft-teknik.

terminsuppsats, tillagd 2012-05-12


Konstruktion av ett datalagersystem för ett handelsföretag. Beskrivningar av scheman för lagringsrelationer. Visa information om produkten. Skapande av en OLAP-kub för ytterligare informationsanalys. Utveckla frågor för att utvärdera effektiviteten i snabbköpet.

kontrollarbete, tillagt 2015-12-19


Syftet med datalager. SAP BW-arkitektur. Bygger analytisk rapportering baserad på OLAP-kuber i SAP BW-systemet. Huvudsakliga skillnader mellan datalager och OLTP-system. En översikt över funktionsområdena för BEx. Skapa en fråga i BEx Query Designer.

1993 publicerade grundaren av den relationella strategin för att bygga databaser, Edgar Codd och partners (Edgar Codd, matematiker och IBM-stipendiat), en artikel initierad av företaget "Arbor Software" (idag är det det berömda företaget "Hyperion Solutions") , med titeln "Providing OLAP (operational analytical processing) for analytic users", som formulerade 12 funktioner i OLAP-tekniken, som sedan kompletterades med sex till. Dessa bestämmelser har blivit huvudinnehållet i en ny och mycket lovande teknik.

Huvuddragen i tekniken OLAP (grundläggande):

• multidimensionell konceptuell representation av data;
• intuitiv datamanipulation;
• tillgänglighet och detaljerad information;
• omgång dataextraktion mot tolkning;
• OLAP analysmodeller;
• klient-server-arkitektur (OLAP är tillgänglig från skrivbordet);
• transparens (transparent åtkomst till externa data);
• stöd för flera användare.

Specialfunktioner(särskild):

• behandling av icke-formaliserad data;
• spara OLAP-resultat: lagra dem separat från originaldata;
• uteslutning av saknade värden;
• hantering av saknade värden.

Funktioner i rapportering( Rapportera ):

• flexibilitet i rapportering;
• standardrapporteringsprestanda;
• automatisk konfiguration av det fysiska lagret av dataextraktion.

Mäthantering( Dimension ):

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

Historiskt sett innebär idag termen "OLAP" 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 framväxten som självständiga termer hänger ihop. "Relationell OLAP"(ROLAP) och "Multidimensional 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, erhålla godtyckliga datasegment och utföra analytiska operationer med detaljering, faltning, distribution från slut till ände, jämförelse över tid i många parametrar samtidigt. Allt arbete med OLAP-systemet sker ämnesmässigt och låter dig bygga statistiskt giltiga modeller av affärssituationen.

OLAP programvara - är ett onlinedataanalysverktyg som finns i förvaret. Huvud funktionär att dessa verktyg inte är avsedda att användas av en specialist inom informationsteknologi, inte av en expertstatistiker, utan av en professionell inom det tillämpade förvaltningsområdet - en chef för en avdelning, avdelning, ledning och slutligen, en direktör. Verktyg utformade för att kommunicera analytiker med ett problem, inte med en dator. På 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 låter dig analysera data av vilken komplexitet som helst vid alla tidsintervall.

Ris. 6.14.

Med flexibla mekanismer för datamanipulation och visuell visning till sitt förfogande (Fig. Fig. 6.15, Fig. 6.16), överväger chefen först data från olika vinklar, som kan (eller kanske inte) är relaterade till problemet som ska lösas.

Därefter jämför han olika affärsindikatorer med varandra och försöker identifiera dolda relationer; kan ta en närmare titt på data, granulera den, till exempel genom att dela upp den efter tid, region eller kund, eller, omvänt, ytterligare generalisera presentationen av information för att ta bort distraherande detaljer. Därefter använder du modulen statistisk uppskattning och simulering flera scenarier för utveckling av händelser byggs, och det mest acceptabla alternativet väljs från dem.

En företagsledare kan till exempel komma med en hypotes att spridningen av tillgångstillväxten 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 begära från lagret och visa på diagrammet räntan för honom för de filialer vars tillgångstillväxt för innevarande kvartal minskade med mer än 10% jämfört med förra året, och för de vars tillgångar ökade med mer än 25 %. Han bör kunna använda ett enkelt urval från menyn som tillhandahålls. Om de erhållna resultaten faller märkbart in i två motsvarande grupper, bör detta bli en stimulans för ytterligare verifiering av hypotesen som lagts fram.

För närvarande ringde riktningen dynamisk simulering(Dynamisk simulering), som fullt ut implementerar ovanstående FASMI-princip.

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

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

Nästan alltid är uppgiften att bygga ett analytiskt system för multivariat dataanalys uppgiften att bygga ett enda, samordnat informationssystem baserat på heterogena mjukvaruverktyg och lösningar. 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 den ömsesidiga kompatibiliteten mellan olika mjukvarukomponenter, enkel utveckling, användning och integration, effektivitet i funktion, stabilitet och även former, nivå och potentiella utsikter för relationer mellan olika tillverkare.

OLAP är tillämpligt överallt där det finns en uppgift att analysera multifaktoriell data. I allmänhet, om det finns en tabell med data som har minst en beskrivande kolumn och en kolumn med siffror, kommer OLAP-verktyget att vara ett effektivt verktyg för att analysera och generera rapporter. Som ett exempel på användningen av OLAP-teknik, överväg studiet av resultaten av försäljningsprocessen.

Nyckelfrågor "Hur mycket såldes?", "Hur mycket såldes?" expandera när verksamheten blir mer komplex och historiska data ackumuleras till en viss uppsättning faktorer, eller nedskärningar: ".. i St. Petersburg, i Moskva, i Ural, i Sibirien ...", ".. under det sista kvartalet , jämfört med den nuvarande", "..från leverantör A kontra leverantör B..." osv.

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

Om man försöker lyfta fram de huvudsiffror (fakta) och nedskärningar (mätargument) som analytikern manipulerar, försöker utöka eller optimera företagets verksamhet, får man en tabell lämplig för försäljningsanalys som en sorts mall som kräver lämplig justering för varje specifikt företag.

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

Produktkategori. Det kan finnas flera kategorier, de skiljer sig åt för varje typ av verksamhet: Klass, Modell, Typ av förpackning etc. Om bara en produkt säljs eller sortimentet är väldigt 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), kan den initiala analysen för alla typer av varor inte utföras, utan generaliseras till vissa överenskomna kategorier.

Område. Beroende på verksamhetens globala karaktär kan du mena kontinent, grupp av länder, land, territorium, stad, distrikt, gata, del av gatan. Naturligtvis, om det bara finns ett uttag, så saknas denna dimension.

Försäljare. Detta mått beror också på verksamhetens struktur och omfattning. Det kan vara: Filial, Butik, Återförsäljare, Försäljningschef. I vissa fall sker ingen mätning, till exempel när säljaren inte påverkar försäljningsvolymerna, det bara finns en butik osv.

Köpare. I vissa fall, till exempel detaljhandeln, är kunden opersonlig och det finns ingen mätning, i andra fall finns kundinformationen där och viktig för försäljningen. Denna dimension kan innehålla namnet på företagsköparen eller många grupperingar och egenskaper hos kunder: industri, företagsgrupp, ägare etc. Analys av försäljningsstrukturen för att identifiera de viktigaste komponenterna i intressesammanhang. För att göra detta är det bekvämt att till exempel använda ett diagram av typen "Pie" i komplexa fall när 3 dimensioner undersöks samtidigt - "Kolumner". Till exempel, i "Computer Technology"-butiken för kvartalet uppgick försäljningen av datorer till 100 000 $, fotografisk utrustning - 10 000 $, förbrukningsvaror - 4 500 $. Slutsats: butikens omsättning beror till stor del på försäljningen av datorer (faktiskt kanske förbrukningsmaterial nödvändigt för att sälja datorer, men detta är en analys av interna beroenden).

Dynamisk analys ( regressionsanalys- identifiera trender). Identifiering av trender, säsongsvariationer. Visuellt visas dynamiken med en graf av typen "Linje". Exempelvis minskade försäljningen av Intels produkter under året medan Microsofts försäljning växte. Kanske har den genomsnittliga kundens välbefinnande förbättrats, eller så har bilden av butiken förändrats och därmed även kundernas sammansättning. Räckvidden behöver justeras. Ett annat exempel: under 3 år på vintern minskar försäljningen av videokameror.

Beroendeanalys(korrelationsanalys). Jämförelse av försäljningsvolymer av olika varor över tid för att identifiera det nödvändiga sortimentet - "korgar". Det är också bekvämt att använda ett diagram av typen "Linje" för detta. Vid till exempel borttagning av skrivare från sortimentet under de första två månaderna konstaterades en nedgång i försäljningen av pulverpatroner.

OLAP (OnLine Analytical Processing) är inte namnet på en specifik produkt, utan på en hel online analytisk processteknik som involverar dataanalys och rapportering. Användaren förses med en flerdimensionell tabell som automatiskt sammanfattar data i olika sektioner och låter dig snabbt hantera beräkningarna och rapportens form.

Även om analytisk bearbetning i vissa publikationer kallas både online och interaktiv, återspeglar adjektivet "online" mest exakt innebörden av OLAP-teknik. Utvecklingen av ledningsbeslut faller inom kategorin områden som är mest falskt mottagliga för automatisering. Men idag finns det en möjlighet att hjälpa chefen att utveckla beslut och, viktigast av allt, att avsevärt påskynda processen för att utveckla beslut, deras urval och antagande.

Beslutsstödssystem har vanligtvis möjlighet att förse användaren med aggregerade data för olika prover från den initiala uppsättningen i en form som är bekväm för perception och analys. Som regel sådana aggregerade funktioner bilda en flerdimensionell datamängd, ofta kallad hyperkub eller metakub, vars axlar innehåller parametrar, och cellerna innehåller aggregerade data som är beroende av dem - och sådan data kan också lagras i relationstabeller, men i det här fallet talar vi om det logiska organisation av data och inte om den fysiska implementeringen av deras lagring.

Längs varje axel kan data organiseras i en hierarki som representerar olika detaljnivåer.

Enligt dimensionerna i den flerdimensionella modellen läggs faktorer som påverkar företagets aktiviteter åt sidan (till exempel: tid, produkter, företagsgrenar, etc.). Den resulterande OLAP-kuben fylls sedan med indikatorer för företagets aktivitet (priser, försäljning, plan, vinst, kassaflöde, etc.). Det bör noteras att, till skillnad från en geometrisk kub, måste ytorna på en OLAP-kub inte ha samma storlek. Denna fyllning kan utföras som med riktiga data operativsystem, och förutspått baserat på historiska data. Dimensionerna för en hyperkub kan vara komplexa, hierarkiska och relationer kan upprättas mellan dem. Under analysen kan användaren ändra synvinkeln på data (den så kallade operationen att ändra den logiska vyn), och därigenom se data i olika sektioner och lösa specifika problem. Olika operationer kan utföras på kuber, inklusive prognoser och villkorlig schemaläggning (vad-om-analys).

Tack vare denna datamodell kan användare formulera komplexa frågor, generera rapporter och ta emot delmängder av data. Operativ analytisk bearbetning kan avsevärt förenkla och påskynda processen för förberedelser och beslutsfattande av ledningspersonal. Online analytisk bearbetning tjänar syftet att omvandla data till information. Den skiljer sig i grunden från den traditionella beslutsstödsprocessen, som oftast bygger på övervägande av strukturerade rapporter.

OLAP-teknik hänvisar till typen av intellektuell analys och involverar 12 principer:

1. Konceptuell flerdimensionell representation. Användaranalytikern ser företagets värld som multidimensionell till sin natur, och OLAP-modellen måste vara multidimensionell i sin kärna.

2. Genomskinlighet. OLAP-systemets arkitektur bör vara öppen, så att användaren, var han än befinner sig, kan kommunicera med hjälp av ett analytiskt verktyg - klienten - med servern.

3. Tillgänglighet. En OLAP-analytikeranvändare måste kunna utföra analys baserat på ett gemensamt konceptuellt schema som innehåller företagsomfattande data i en relationsdatabas samt data från äldre äldre databaser, på vanliga åtkomstmetoder och på en gemensam analytisk modell. Ett OLAP-system ska bara komma åt data som verkligen behövs och inte tillämpa den allmänna "köketratt"-principen som innebär onödig input.

4. Konsekvent prestation i rapportutveckling. Med en ökning av antalet dimensioner eller storleken på databasen bör analytikeranvändaren inte uppleva en signifikant minskning av prestanda.

5. Klient-server-arkitektur. De flesta data som krävs för onlineanalys idag finns på stordatorer med åtkomst till användararbetsstationer över ett LAN. Detta innebär att OLAP-produkter måste kunna fungera i en klient-servermiljö.

6. Allmän multidimensionalitet. Varje dimension bör tillämpas oavsett dess struktur och operativa kapacitet. De underliggande datastrukturerna, formlerna och rapporteringsformaten bör inte vara partiska mot någon enskild dimension.

7. Dynamisk hantering av glesa matriser. Den fysiska designen av ett OLAP-verktyg måste vara fullt anpassningsbar till den specifika analysmodellen för att optimalt hantera glesa matriser. Sparsitet (mätt som andelen tomma celler till alla möjliga) är en av egenskaperna för datautbredning.

8. Fleranvändarsupport. Ett OLAP-verktyg måste ge möjligheten att dela frågor och utöka flera analytiker samtidigt som integriteten och säkerheten bibehålls.

9. Obegränsade korsoperationer. Olika operationer kan, på grund av sin hierarkiska karaktär, representera beroendeförhållanden i OLAP-modellen, det vill säga de är tvärfunktionella. Deras utförande bör inte kräva att analytikeranvändaren omdefinierar dessa beräkningar och operationer.

10. Intuitiv datamanipulation. Analytikeranvändarens syn på de dimensioner som definieras i analysmodellen måste innehålla all nödvändig information för att utföra åtgärder på OLAP-modellen, d.v.s. de bör inte kräva användning av ett menysystem eller andra funktioner för flera användargränssnitt.

11. Flexibla rapporteringsalternativ. Rapporteringsverktyg bör vara syntetiserade data eller information som härrör från datamodellen i alla möjliga riktningar. Detta innebär att raderna, kolumnerna eller sidorna i en rapport måste visa flera dimensioner av en OLAP-modell samtidigt, med möjlighet att visa vilken delmängd som helst av elementen (värdena) som finns i dimensionen, och i valfri ordning.

12. Obegränsad dimension och antal aggregeringsnivåer. En studie om det möjliga antalet nödvändiga mätningar som krävs i en analytisk modell visade att upp till 19 mätningar kan användas samtidigt av en analytiker. Detta leder till en rekommendation om antalet dimensioner som stöds av OLAP-systemet. Dessutom bör var och en av de vanliga dimensionerna inte begränsas av antalet aggregeringsnivåer som definieras av användaranalytikern.

Som specialiserade OLAP-system som för närvarande erbjuds på marknaden kan du specificera CalliGraph, Business Intelligence.

För att lösa enkla dataanalysuppgifter är det möjligt att använda en budgetlösning - Microsoft Excel och Access office-applikationer, som innehåller elementära OLAP-teknikverktyg som låter dig skapa pivottabeller och bygga olika rapporter utifrån dem.