Olap-program. OLAP-system

4. Klassificering av OLAP-produkter.

5. Principer för OLAP-klienter.

7. Användningsområden för OLAP-teknik.

8. Ett exempel på att använda OLAP-tekniker för analys inom försäljningsområdet.

1. Platsen för OLAP i företagets informationsstruktur.

Termen "OLAP" är oupplösligt kopplad till termen "datalager".

Data i lagret kommer från operativa system (OLTP-system), som är utformade för att automatisera affärsprocesser. Dessutom kan lagret fyllas på med externa källor, till exempel statistiska rapporter.

Syftet med förvaret är att tillhandahålla "råvaran" för analys på ett ställe och i en enkel, begriplig struktur.

Det finns en annan anledning som motiverar uppkomsten av en separat lagring - komplexa analytiska frågor till operativ information saktar ner företagets nuvarande arbete, blockerar tabeller under lång tid och utnyttjar serverresurser.

En lagring är inte nödvändigtvis en gigantisk ansamling av data - det viktigaste är att det är bekvämt för analys.

Centralisering och bekväm strukturering är inte allt som en analytiker behöver. Han behöver fortfarande ett verktyg för att visa och visualisera information. Traditionella rapporter, till och med byggda på ett enda arkiv, saknar en sak - flexibilitet. De kan inte vridas, expanderas eller kollapsas för att få den önskade bilden. Jag önskar att han hade ett sådant verktyg som gör det möjligt att utöka och kollapsa data enkelt och bekvämt! OLAP fungerar som ett sådant verktyg.

Även om OLAP inte är ett nödvändigt attribut för ett datalager används det alltmer för att analysera informationen som samlats in i detta lager.

OLAP: s plats i företagets informationsstruktur (fig. 1).

Bild 1... En platsOLAP i företagets informationsstruktur

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

Sammanfattningsvis kan OLAP definieras som en samling flerdimensionella dataanalysverktyg som ackumulerats i lagret.

2. Operativ analytisk databehandling.

OLAP-konceptet bygger på principen om flerdimensionell datapresentation. 1993 adresserade EF Codd bristerna i relationsmodellen, först och främst och påpekade omöjligheten att "kombinera, visa 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 definierades de allmänna kraven för OLAP-system som utökar funktionell relationell DBMS och inkluderar multivariatanalys som en av dess egenskaper.

Enligt Codd är en flerdimensionell konceptvy ett multipelperspektiv bestående av flera oberoende dimensioner längs vilka specifika datamängder kan analyseras.

Samtidig analys över flera dimensioner definieras som multivariat analys. Varje dimension inkluderar riktningar för datakonsolidering, bestående av en serie successiva aggregeringsnivåer, där varje högre nivå motsvarar en större grad av dataggregation för motsvarande dimension.

Således kan entreprenörsdimensionen bestämmas av konsolideringsriktningen, som består av nivåerna av generalisering "företag - avdelning - avdelning - anställd". Tidsdimensionen kan till och med innehålla två konsolideringsriktningar - år - kvartal - månad - dag och veckodag, eftersom tidräkning efter månad och vecka är oförenlig. I detta fall blir det möjligt att godtyckligt välja önskad informationsnivå för var och en av mätningarna.

Nedborrningsoperationen motsvarar förflyttningen från de högre konsolideringsstadierna till de lägre; tvärtom innebär en upprullning att flytta från lägre nivåer till högre nivåer (fig. 2).

Figur 2. Mätningar och riktningar för datakonsolidering

3. Krav på verktyg för onlineanalysbehandling.

Det flerdimensionella tillvägagångssättet uppstod nästan samtidigt och parallellt med det relationella tillvägagångssättet. Men bara sedan mitten av nittiotalet, eller snarare sedan
1993, intresse för MSUBD började få en allmän karaktär. Det var i år som en ny programartikel av en av grundarna av den relationella metoden dök upp E. Codda, där han formulerade 12 grundläggande krav för implementeringsmedel OLAP (Bord 1).

Bord 1.

	Flerdimensionell datarepresentation	Verktygen måste stödja en flerdimensionell konceptuell syn på data.
	Genomskinlighet	Användaren ska inte vara medveten om vilka specifika medel som används för att lagra och bearbeta data, hur data är organiserade och varifrån de kommer.
	Tillgänglighet	Det är upp till verktygen att välja och kommunicera med den bästa datakällan för att svara på en given begäran. Verktygen ska kunna automatiskt kartlägga sin egen logik till olika heterogena datakällor.
	Konsekvent prestanda	Prestanda bör praktiskt taget inte bero på antalet dimensioner i begäran.
	Stöd för klient-serverarkitektur	Verktygen måste fungera i en klient-server-arkitektur.
	Jämställdhet av alla mätningar	Ingen av mätningarna ska vara grundläggande, de ska alla vara lika (symmetriska).
	Dynamisk bearbetning av glesa matriser	Odefinierade värden bör lagras och hanteras på det mest effektiva sättet.
	Stöd för fleranvändarläge för att arbeta med data	Verktygen måste ge möjlighet att arbeta för mer än en användare.
	Stöder operationer baserat på olika dimensioner	Alla flerdimensionella operationer (t.ex. aggregering) måste tillämpas enhetligt och konsekvent på valfritt antal av alla dimensioner.
	Enkel databehandling	Verktygen bör ha det mest bekväma, naturliga och bekväma användargränssnittet.
	Avancerade presentationsverktyg	Fonder måste stödja olika sätt visualisering (presentation) av data.
	Obegränsat antal dimensioner och nivåer av dataggregation	Det bör inte finnas någon gräns för antalet dimensioner som stöds.

Regler för utvärdering av mjukvaruprodukter i OLAP-klassen

Uppsättningen av dessa krav, som fungerade som de facto-definitionen av OLAP, bör betraktas som rådgivande, och specifika produkter bör bedömas utifrån vilken grad de är nära att uppfylla alla krav.

Senare reviderades Codds definition till det så kallade FASMI-testet, som kräver en OLAP-applikation för att snabbt kunna analysera delad flerdimensionell information.

Att komma ihåg Codds 12 regler är för betungande för de flesta. Det visade sig att du kan sammanfatta OLAP-definitionen med endast fem nyckelord: Snabb analys av delad flerdimensionell information - eller kort sagt - FASMI (översatt från engelska:F ast A nalys av S harad M ultimensionell Jag information).

Denna definition formulerades först i början av 1995 och har inte behövt revideras sedan dess.

FAST ( Snabb) - betyder att systemet ska kunna ge de flesta svar till användare inom cirka fem sekunder. Samtidigt behandlas de enklaste förfrågningarna inom en sekund och väldigt få - mer än 20 sekunder. Forskning har visat att slutanvändare uppfattar att processen misslyckas om inga resultat erhålls efter 30 sekunder.

Vid första anblicken kan det verka förvånande att när man tar emot en rapport på en minut, som inte så länge sedan tog dagar, blir användaren snabbt uttråkad i väntan, och projektet visar sig vara mycket mindre framgångsrikt än i fallet med en omedelbart svar, även till priset av mindre detaljerad analys.

ANALYS (analys) innebär att systemet kan hantera alla logiska och statistiska analyser som är specifika för av denna ansökanoch säkerställer att den sparas i ett formulär som är tillgängligt för slutanvändaren.

Det spelar ingen roll om denna analys görs i en leverantörs egen verktygslåda eller i en medföljande extern programvaruprodukt som ett kalkylark, det behöver bara tillhandahålla alla nödvändiga analysfunktioner på ett intuitivt sätt för slutanvändarna. Analysverktyg kan inkludera specifika procedurer som tidsserie-analys, kostnadsallokering, valutakursöverföringar, målsökning, flerdimensionell strukturförändring, icke-procedurell modellering, undantagsdetektering, datautvinning och andra applikationsberoende åtgärder. Sådana funktioner varierar mycket mellan produkterna, beroende på målinriktningen.

DELAD innebär att systemet uppfyller alla krav på sekretessskydd (eventuellt ner till cellnivå) och, om flera skrivåtkomst krävs, tillhandahåller modifieringsblockering på lämplig nivå. Inte alla applikationer behöver skriva tillbaka data. Antalet sådana applikationer växer dock och systemet måste kunna hantera flera modifieringar på ett säkert sätt i rätt tid.

MULTIDIMENSIONELL - detta är ett viktigt krav. Om du var tvungen att definiera OLAP i ett ord skulle du välja det. Systemet måste ge en flerdimensionell konceptuell bild av data, inklusive fullt stöd för hierarkier och flera hierarkier, eftersom detta definitivt är det mest logiska sättet att analysera företag och organisationer. Det finns inget minsta antal dimensioner som måste bearbetas eftersom det också beror på applikationen och de flesta OLAP-produkter har tillräckligt många dimensioner för de marknader de riktar sig till.

INFORMATION - det är allt. Den nödvändiga informationen bör erhållas där den behövs. Mycket beror dock på applikationen. Kraften hos olika produkter mäts i termer av hur mycket input de kan bearbeta, men inte hur många gigabyte de kan lagra. Produkternas kraft varierar kraftigt - de största OLAP-produkterna kan hantera minst tusen gånger mer data än de minsta. Det finns många faktorer att tänka på i detta avseende, inklusive dataduplicering, RAM-minne, diskutnyttjande, prestanda, datalagringsintegration etc.

FASMI-testet är en rimlig och förståelig definition av de mål som OLAP fokuserar på att uppnå.

4. KlassificeringOLAP-Produkter.

Så kärnan i OLAP består i det faktum att den ursprungliga informationen för analysen 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 möjliggör interaktiv kontroll av beräkningar och rapportformulär. Genomförandet av dessa operationer säkerställsOLAP -maskin (eller maskinOLAP-beräkningar).

Hittills har många produkter utvecklats i världen som implementerasOLAP -teknik. För att göra det lättare att navigera bland dem används klassificeringarOLAP -produkter: genom datalagring för analys och platsOLAP -bilar. Låt oss titta närmare på varje kategoriOLAP produkter.

Klassificering efter lagringsmetod

Flerdimensionella kuber bygger på käll- 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 sätt att lagra data:MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) och HOLAP (Hybrid OLAP) ). Respektive,OLAP -Produkter är indelade i tre liknande kategorier efter lagringsmetod:

1. I fallet med MOLAP , käll- och aggregerade data lagras 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. Konvertering av data från en relationsdatabas till flerdimensionella kuber sker på begäranOLAP-verktyg.

3. Vid användningHOLAP arkitektur, förblir originaldata i relationsdatabasen och aggregaten finns i den flerdimensionella. ByggnadOLAP -kub utförs på begäranOLAP -Medel baserat på relationella och flerdimensionella data.

Platsklassificering OLAP-bilar.

Utifrån dettaOLAP -produkter är indelade iOLAP-servrar och OLAP-klienter:

Server OLAP -medel för beräkning och lagring av aggregerade data utförs av en separat process - servern. Klientapplikationen får endast resultat från frågor mot flerdimensionella kuber som lagras på servern. VissaOLAP -servers stöder datalagring endast i relationsdatabaser, vissa - bara i flerdimensionella. Många modernaOLAP -servers stöder alla tre sätten att lagra data:MOLAP, ROLAP och HOLAP.

MOLAP.

MOLAP är Flerdimensionell on-line analytisk bearbetning,det vill säga flerdimensionell OLAP.Detta innebär att servern använder en multidimensionell databas (MDB) för att lagra data. Känslan av att använda MDB är uppenbar. Det kan effektivt lagra data som är flerdimensionella till sin karaktär, vilket ger ett sätt att snabbt underhålla databasfrågor. Data överförs från en datakälla till en flerdimensionell databas och sedan aggregeras databasen. Förberäkningen är det som gör OLAP-frågor snabbare eftersom sammanfattningsdata redan har beräknats. Begäran blir en funktion enbart av den tid som krävs för att få åtkomst till en viss bit data och utföra en beräkning. Denna metod stöder konceptet att arbete görs en gång och resultaten används sedan om och om igen. Flerdimensionella databaser är en relativt ny teknik. Användningen av MDB har samma nackdelar som de flesta nya tekniker. De är nämligen inte lika stabila som relationsdatabaser (RDB) och de är inte optimerade i samma utsträckning. En annan svag punkt i MDB är omöjligheten att använda de flesta flerdimensionella databaser i processen för dataggregation, så det tar tid innan ny information blir tillgänglig för analys.

ROLAP.

ROLAP är Relational on-line analytisk bearbetning,det vill säga Relational OLAP.Termen ROLAP betyder att OLAP-servern är baserad på en relationsdatabas. Källdata läggs in i en relationsdatabas, vanligtvis i ett stjärna- eller snöflingaschema, för att minska hämtningstiderna. Servern tillhandahåller en flerdimensionell datamodell med optimerade SQL-frågor.

Det finns ett antal anledningar till att välja en relationsdatabas framför en flerdimensionell databas. RDB är en väletablerad teknik med många möjligheter till optimering. Verklig användning resulterade i en mer detaljerad produkt. Dessutom stöder RDB större mängder data än MDB. De är bara utformade för sådana volymer. Huvudargumentet mot RDB är komplexiteten i de frågor som krävs för att hämta information från en stor databas med SQL. En oerfaren SQL-programmerare kan lätt belasta värdefulla systemresurser genom att försöka utföra någon liknande fråga, vilket är mycket lättare att utföra i MDB.

Aggregerade / föraggregerade data.

Snabb implementering av frågor är avgörande för OLAP. Detta är en av de grundläggande principerna för OLAP - förmågan att intuitivt manipulera data kräver snabb hämtning av information. Generellt gäller att ju fler beräkningar som krävs för att få information, desto långsammare blir svaret. För att spara en liten tid för genomförandet av förfrågningar utsätts därför de informationsstycken som oftast nås, men som samtidigt kräver beräkning, för preliminär aggregering. De räknas och lagras sedan i databasen som nya data. Ett exempel på en datatyp som kan beräknas i förväg är sammanfattningsdata - till exempel försäljningssiffror per månad, kvartal eller år - för vilka de faktiska inmatade uppgifterna är dagliga siffror.

Olika leverantörer har olika urvalsmetoder för parametrar som kräver föraggregering och ett antal förberäknade värden. Aggregationsmetoden påverkar både databasen och körningstiden för frågan. Om fler värden beräknas ökar sannolikheten för att användaren kommer att be om ett redan beräknat värde och därför blir svarstiden kortare eftersom du inte behöver be om det ursprungliga värdet för beräkningen. Men om det inte är den bästa lösningen att beräkna alla möjliga värden - i det här fallet kommer databasens storlek att öka avsevärt, vilket gör den ohanterlig och aggregeringstiden blir för lång. Dessutom, när numeriska värden läggs till i databasen, eller om de ändras, bör denna information återspeglas i de förberäknade värdena beroende på de nya uppgifterna. Således kan uppdatering av databasen också ta lång tid vid ett stort antal förberäknade värden. Eftersom databasen vanligtvis är offline under aggregering är det önskvärt att aggregeringstiden inte är för lång.

OLAP -klienten är ordnad annorlunda. Bygga en flerdimensionell kub ochOLAP -beräkningar utförs i minnet på klientdatorn.OLAP -klienter är också uppdelade iROLAP 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 serververktyg jämfört med klientens, i ett antal fall användningen avOLAP - klienten för användare kan vara mer effektiv och lönsam än att användaOLAP-servrar.

Utveckling av analytiska applikationer med OLAP-klientverktyg är en snabb process och kräver ingen särskild 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.

När du använder en OLAP-server måste du studera två 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.

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

· Ekonomisk genomförbarhetOLAP -server uppstår när datamängden är mycket stor och outhärdlig förOLAP - klienten, annars är användningen av den senare mer motiverad. I detta fallOLAP -Kunder kombinerar höga prestandaegenskaper med låg kostnad.

· Kraftfulla analytiker-datorer är en annan bra anledningOLAP -klienter. Vid ansökanOLAP -server, dessa kapaciteter används inte.

Bland fördelarna med OLAP-klienter är följande:

· Implementerings- och underhållskostnaderOLAP - kunden är betydligt lägre än kostnaden förOLAP-server.

· Använder sig avOLAP - för en klient med en inbyggd maskin görs dataöverföring över nätverket en gång. Genom att göraOLAP -operationer av nya dataströmmar skapas inte.

5. Arbetsprinciper OLAP-klienter.

Låt oss titta på processen för att skapa en OLAP-applikation med klientverktyget (figur 1).

Bild 1. Skapa en OLAP-applikation med hjälp av ROLAP Client Tool

Principen för ROLAP-klienters funktion är en preliminär beskrivning av det semantiska skiktet bakom vilken den fysiska strukturen hos de ursprungliga uppgifterna ä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.

När du skapar ett semantiskt lager beskrivs datakällor - tabellerna Sales och Deal - 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" i produkten. Eftersom alla tabellfält inte behöver visas i rapporten använder affärsobjektet endast fälten "Artikel", "Datum" och "Belopp".

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 man arbetar med en interaktiv rapport kan användaren ställa in filtrerings- 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 varor i försäljningsrapporten kan du få en rapport om försäljningen av varorna av intresse till oss.

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

Allt som ingår i dessa applikationer är en standardvy på gränssnittet, fördefinierade funktioner och struktur, och snabba beslut för mer eller mindre vanliga situationer. Till exempel är finanspaket populära. Förutvecklade ekonomiska applikationer tillåter yrkesverksamma att använda bekanta finansiella instrument utan att behöva utforma en databasstruktur eller vanliga formulär och rapporter.

Internet är ny form klient. Dessutom bär den stämpeln av ny teknik; mycket av internetlösningar skiljer sig väsentligt i deras kapacitet i allmänhet och i kvaliteten på en OLAP-lösning i synnerhet. Det finns många fördelar med att generera OLAP-rapporter via Internet. Det viktigaste är frånvaron av behovet av specialiserad programvara för tillgång till information. Detta sparar företaget mycket tid och pengar.

6. Val av OLAP-applikationsarkitektur.

När du implementerar ett informations- och analyssystem är det viktigt att inte göra ett misstag när du väljer en OLAP-applikationsarkitektur. Den bokstavliga översättningen av termen On-Line Analytical Process - "on-line analytisk bearbetning" - tas ofta bokstavligen i den meningen att de data som kommer in i systemet analyseras omedelbart. Detta är en illusion - analysens effektivitet har inget att göra med den reala tiden för datauppdatering i systemet. Denna egenskap hänvisar till svarstiden för OLAP-systemet på användarförfrågningar. Samtidigt är de analyserade uppgifterna ofta en ögonblicksbild av information "för igår", om till exempel data i lagren uppdateras en gång om dagen.

I detta sammanhang är översättningen av OLAP som "interaktiv analytisk bearbetning" mer exakt. Det är förmågan att analysera data i interaktivt läge som skiljer OLAP-system från system för att förbereda reglerade rapporter.

Ett annat inslag i interaktiv bearbetning i formuleringen av grundaren av OLAP E. Codd är förmågan att "kombinera, visa och analysera data ur flera dimensioners synvinkel, det vill säga på det mest förståeliga sättet för företagsanalytiker." För Codd själv betecknar termen OLAP ett exklusivt specifikt sätt att representera data på begreppsnivå - flerdimensionellt. På den fysiska nivån kan data lagras i relationsdatabaser, men i verkligheten tenderar OLAP-verktyg att arbeta med flerdimensionella databaser, i vilka data är organiserade i en hyperkub (Figur 1).

Bild 1. OLAP - kub (hypercube, metacube)

Dessutom bestäms relevansen av dessa data av det ögonblick som hyperkuben fylls med nya data.

Uppenbarligen beror bildningstiden för en flerdimensionell databas avsevärt på datamängden som laddas in i den, så det är rimligt att begränsa denna volym. Men hur ska man inte begränsa analysmöjligheterna och inte beröva användaren tillgång till all information av intresse? Det finns två alternativa vägar: Analysera sedan fråga och fråga sedan analysera.

Följare av den första sökvägen föreslår att man läser in generaliserad information i en flerdimensionell databas, till exempel månatliga, kvartalsvisa, årliga summor för avdelningar. Och om det är nödvändigt att förfina uppgifterna, erbjuds användaren att generera en rapport om relationsdatabasen som innehåller det önskade urvalet, till exempel dag för en viss avdelning eller av månader och anställda i en utvald avdelning.

Förespråkare av det andra sättet, tvärtom, erbjuder användaren först och främst att bestämma de data som han ska analysera och ladda den i en mikrokub - en liten flerdimensionell databas. Båda metoderna skiljer sig åt begreppsmässigt och har sina egna fördelar och nackdelar.

Fördelarna med det andra tillvägagångssättet inkluderar "friskhet" av den information som användaren får i form av en flerdimensionell rapport - "mikrokub". Mikrokuben bildas baserat på den information som just begärts från den aktuella relationsdatabasen. Arbetet med mikrokuben utförs i ett interaktivt läge - att få informationsskivor och dess detaljer inom mikrokuben utförs omedelbart. En annan positiv punkt är att utformningen av strukturen och fyllningen av mikrokuben utförs av användaren "i farten" utan deltagande av databasadministratören. Tillvägagångssättet lider dock också av allvarliga nackdelar. Användaren ser inte den allmänna bilden och måste bestämmas i förväg med inriktningen för sin forskning. Annars kan den begärda mikrokuben vara för liten och inte innehålla all information av intresse, och användaren måste begära en ny mikrokub, sedan en ny, sedan om och om igen. Frågan analyserar sedan metoden implementerar företaget BusinessObjects med samma namn och verktyg Plattformsföretags konturIntersoftLabb.

Med tillvägagångssättet Analysera sedan kan mängden data som laddas in i en flerdimensionell databas vara ganska stor. Fyllningen måste utföras enligt reglerna och kan ta mycket tid. Men alla dessa nackdelar lönar sig senare när användaren har tillgång till nästan alla nödvändiga data i vilken kombination som helst. Hänvisningen till originaldata i en relationsdatabas utförs endast som en sista utväg, vid behov. detaljerad informationtill exempel på en specifik fraktsedel.

Arbetet med en enda flerdimensionell databas påverkas praktiskt taget inte av antalet användare som har åtkomst till den. De läser bara de tillgängliga uppgifterna där, i motsats till frågan sedan analysera metoden, där antalet mikrokuber i extrema fall kan växa i samma takt som antalet användare.

Med detta tillvägagångssätt ökar belastningen på IT-tjänster, som förutom de relationella också tvingas betjäna flerdimensionella databaser. Det är dessa tjänster som ansvarar för automatisk automatisk uppdatering av data i flerdimensionella databaser.

De mest framstående representanterna för “Analysera sedan frågan” -metoden är PowerPlay- och Impromptu-verktyg från Cognos.

Valet av både tillvägagångssätt och verktyg som implementerar det beror främst på det eftersträvade målet: du måste alltid balansera mellan att spara budget och att förbättra servicekvaliteten för slutanvändarna. Man bör komma ihåg att skapandet av informations- och analyssystem strategiskt strävar efter att uppnå en konkurrensfördel och inte undvika kostnaderna för automatisering. Till exempel kan ett företagsinformations- och analyssystem tillhandahålla den nödvändiga, snabba och tillförlitliga informationen om ett företag vars publicering för potentiella investerare kommer att säkerställa detta företags transparens och förutsägbarhet, vilket oundvikligen kommer att bli ett villkor för dess investeringsattraktivitet.

7. Användningsområden för OLAP-teknik.

OLAP är tillämpligt överallt där det finns en multifaktordataanalysuppgift. I allmänhet, om du har någon tabell med data, där det finns minst en beskrivande kolumn (dimension) och en kolumn med siffror (mått eller fakta), är ett OLAP-verktyg vanligtvis ett effektivt verktyg för att analysera och generera rapporter.

Låt oss överväga några tillämpningsområden för OLAP-teknologier, hämtade från verkliga livet.

1. Försäljning.

Baserat på analysen av försäljningsstrukturen löses de frågor som är nödvändiga för att fatta ledningsbeslut: om att ändra sortimentet av varor, priser, stänga och öppna butiker, filialer, säga upp och underteckna kontrakt med återförsäljare, genomföra eller avsluta reklamkampanjer etc.

2. Inköp.

Uppgiften är motsatsen till försäljningsanalys. Många företag köper komponenter och material från leverantörer. Handlare köper varor för återförsäljning. Det finns många möjliga uppgifter i upphandlingsanalyser, från att planera kontanter baserat på tidigare erfarenheter till kontroll över chefervälja leverantörer.

3. Priser.

Analys av inköp är nära relaterad till analys av marknadspriser. Syftet med denna analys är att optimera kostnaderna, välja de mest fördelaktiga erbjudandena.

4. Marknadsföring.

Med marknadsanalys menar vi endast analysområdet för köpare eller kunder-konsumenter av tjänster. Uppgiften för denna analys är korrekt positionering av produkten, identifiering av grupper av köpare för riktad annonsering och optimering av sortimentet. OLAP: s uppgift är i detta fall att ge användaren ett verktyg för att snabbt, med tankehastigheten, få svar på frågor som intuitivt uppstår under analysen av data.

5. Lager.

Analys av lagerbalansernas struktur i samband med varutyper, lager, analys av varans hållbarhet, analys av leverans per mottagare och många andra typer av analyser som är viktiga för företaget är möjliga om organisationen har lagerredovisning.

6. Kassaflöde.

Detta är ett helt analysområde, med många skolor och metoder. OLAP-teknik kan fungera som ett verktyg för implementering eller förbättring av dessa tekniker, men på inget sätt en ersättning för dem. Den monetära omsättningen för icke-kontanta och kontanta medel analyseras i termer av affärstransaktioner, motparter, valutor och tid för att optimera flöden, säkerställa likviditet etc. Mätningens sammansättning är starkt beroende av specifikationerna för verksamheten, branschen, metodiken.

7. Budget.

Ett av de mest bördiga användningsområdena för OLAP-teknik. Det är inte för ingenting som inget modernt budgeteringssystem anses vara komplett utan närvaron av OLAP-verktyg för budgetanalys i dess sammansättning. De flesta budgetrapporter bygger enkelt på OLAP-system. Samtidigt svarar rapporterna på ett mycket brett spektrum av frågor: analys av strukturen för kostnader och intäkter, jämförelse av kostnader för vissa poster i olika avdelningar, analys av dynamik och trender för kostnader för vissa poster, analys av kostnad och vinst .

8. Konton.

Den klassiska balansräkningen, som består av ett kontonummer och innehåller inkommande saldon, omsättningar och utgående saldon, kan analyseras perfekt i OLAP-systemet. Dessutom kan OLAP-systemet automatiskt och mycket snabbt beräkna de konsoliderade saldona för en organisation med flera grenar, saldon för månad, kvartal och år, aggregerade saldon efter kontohierarkin, analytiska saldon baserat på analytiska egenskaper.

9. Finansiell rapportering.

Ett tekniskt avancerat rapporteringssystem är inget annat än en uppsättning namngivna indikatorer med värden per datum, som måste grupperas och sammanfattas i olika aspekter för att få specifika rapporter. När så är fallet är det enklast och billigast att visa och skriva ut rapporter i OLAP-system. I vilket fall som helst är företagets interna rapporteringssystem inte så konservativt och kan byggas om för att spara pengar på tekniskt arbete med att skapa rapporter och för att få kapacitet för flerdimensionell operativ analys.

10. Webbplatstrafik.

Internetserverns loggfil är flerdimensionell, vilket innebär att den är lämplig för OLAP-analys. Fakta är: antalet besök, antalet träffar, tiden på sidan och annan information som finns i loggen.

11. Produktionsvolymer.

Detta är ett annat exempel på statistisk analys. Det är således möjligt att analysera volymerna av odlad potatis, smält stål, producerade varor.

12. Konsumtion av förbrukningsvaror.

Föreställ dig en anläggning bestående av dussintals verkstäder som förbrukar kylning, spolvätskor, oljor, trasor, sandpapper - hundratals artiklar av förbrukningsvaror. För noggrann planering och kostnadsoptimering krävs en grundlig analys av den faktiska förbrukningen av förbrukningsvaror.

13. Användning av lokaler.

En annan typ av statistisk analys. Exempel: analys av klassrum, hyrda byggnader och lokaler, användning av konferensrum etc.

14. Personalomsättning på företaget.

Analys av personalomsättningen vid företaget i samband med filialer, avdelningar, yrken, utbildningsnivå, kön, ålder, tid.

15. Passagerartrafik.

Analys av antalet sålda biljetter och belopp i samband med årstider, vägbeskrivningar, typer av bilar (klasser), tågtyper (flygplan).

Tillämpningsområdet är inte begränsat till denna lista.OLAP - teknik. Tänk till exempel på teknikenOLAP -analys inom försäljningsområdet.

8. Exempel på användningOLAP -tekniker för analys inom försäljningsområdet.

Designa en flerdimensionell datarepresentation förOLAP -analys börjar med bildandet av en mätkarta. När man till exempel analyserar försäljningen kan det vara tillrådligt att särskilja enskilda delar av marknaden (utvecklande, stabila, stora och små konsumenter, sannolikheten för nya konsumenter etc.) och bedöma försäljningsvolymerna efter produkter, territorier, kunder, marknadssegment, distributionskanaler etc. storleken på order. Dessa riktningar bildar rutan för den flerdimensionella synen på försäljningen - strukturen för dess dimensioner.

Eftersom varje företags verksamhet äger rum i tid är den första frågan som uppstår i analysen frågan om dynamiken i affärsutvecklingen. Den korrekta organisationen av tidsaxeln kommer att ge ett kvalitativt svar på denna fråga. Vanligtvis är tidsaxeln uppdelad i år, kvartal och månader. Ännu mer fragmentering i veckor och dagar är möjlig. Tidsdimensionens struktur utformas med hänsyn till frekvensen för datamottagning; kan också konditioneras av frekvensen av efterfrågan på information.

Dimensionen ”produktgrupp” är utformad för att så nära som möjligt återspegla strukturen på de produkter som säljs. Samtidigt är det viktigt att upprätthålla en viss balans för att å ena sidan undvika överdriven detaljering (antalet grupper bör kunna förutses) och å andra sidan att inte missa ett betydande marknadssegment.

Dimensionen ”Kunder” återspeglar försäljningsstrukturen efter geografisk plats. Varje dimension kan ha sina egna hierarkier, till exempel kan den i denna dimension vara en struktur: Länder - Regioner - Städer - Klienter.

För att analysera avdelningernas prestanda bör du skapa din egen dimension. Du kan till exempel skilja mellan två nivåer i hierarkin: avdelningar och deras underavdelningar, vilket bör återspeglas i dimensionen "Avdelningar".

Faktum är att dimensionerna "Tid", "Produkter", "Kunder" definierar helt utrymmet i ämnesområdet.

Dessutom är det användbart att dela upp detta utrymme i villkorliga områden med utgångspunkt från de beräknade egenskaperna, till exempel intervallen för transaktionsvolymen i termer av värde. Då kan hela verksamheten delas in i ett antal värdeintervall där den bedrivs. I det här exemplet kan du begränsa dig till följande indikatorer: mängden försäljning av varor, antalet sålda varor, inkomstbeloppet, antalet transaktioner, antalet kunder, volymen av inköp från tillverkare.

OLAP - kuben för analys kommer att se ut (figur 2):

Figur 2.OLAP - en kub för att analysera försäljningsvolymen

Det är just en sådan tredimensionell matris i OLAP-termer som kallas en kub. I själva verket, från strikt matematisk synvinkel, kommer en sådan matris inte alltid att vara en kub: en riktig kub ska ha samma antal element i alla dimensioner, och OLAP-kuber har inte en sådan begränsning. En OLAP-kub behöver inte vara 3D. Det kan vara både två- och flerdimensionellt - beroende på vilket problem som löses. Allvarliga OLAP-produkter är utformade för cirka 20 dimensioner. Enklare skrivbordsapplikationer stöder cirka 6 dimensioner.

Långt ifrån alla kubens delar bör fyllas: om det inte finns någon information om försäljningen av produkt 2 till kund 3 under tredje kvartalet kommer värdet i motsvarande cell helt enkelt inte att bestämmas.

Kuben i sig är dock inte lämplig för analys. Om det fortfarande är möjligt att på ett adekvat sätt representera eller skildra en tredimensionell kub, då med sex- eller nitton-dimensionell situationen är mycket värre. Därför extraheras vanliga tvådimensionella tabeller före flerdimensionell kub före användning. Denna operation kallas "skivning" av kuben. Analytikern tar så att säga och "skär" kubens mått enligt de intressanta etiketterna. På detta sätt tar analytikern en tvådimensionell del av kuben (rapport) och arbetar med den. Rapportens struktur visas i figur 3.

Figur 3.Analytisk rapportstruktur

Låt oss klippa vår OLAP-kub och få försäljningsrapporten för tredje kvartalet, det kommer att se ut så här (fig. 4).

Figur 4. Försäljningsrapport för tredje kvartalet

Du kan klippa kuben längs en annan axel och få en rapport om försäljningen av produktgrupp 2 under året (fig. 5).

Figur 5.Produktförsäljning kvartalsrapport 2

På samma sätt kan du analysera relationen med klienten 4, genom att klippa kuben vid etiketten Clients (fig. 6)

Figur 6. Rapportera om leverans av varor till kunden 4

Du kan gå in i rapporten per månad eller prata om leveranser av varor till en specifik kundfilial.

datalager bildas på grundval av ögonblicksbilder av operativa databaser informationssystem och möjligen olika externa källor. Datalager använder databasteknik, OLAP, djupdataanalys, datavisualisering.

De viktigaste egenskaperna hos datalager.

• innehåller historiska data;
• lagrar detaljerad information, samt delvis och fullständigt aggregerad data;
• uppgifterna är mestadels statiska;
• ad hoc, ostrukturerat och heuristiskt sätt att bearbeta data;
• medelhög och låg intensitet av transaktionshantering;
• oförutsägbart sätt att använda data;
• avsedd för analys;
• fokuserad på ämnesområden;
• stöd för strategiskt beslutsfattande;
• tjänar ett relativt litet antal chefer.

Termen OLAP (On-Line Analytical Processing) används för att beskriva datapresentationsmodellen och följaktligen tekniken för deras bearbetning i datalager. OLAP använder en flerdimensionell vy av aggregerade data för att ge snabb åtkomst till strategisk information för djupgående analys. OLAP-applikationer måste ha följande grundläggande egenskaper:

• flerdimensionellt datapresentation;
• stöd för komplexa beräkningar;
• korrekt hänsyn till tidsfaktorn.

OLAP-fördelar:

• uppgången produktivitet produktionspersonal, utvecklare applikationsprogram... Tidig tillgång till strategisk information.
• ger användarna goda möjligheter att göra sina egna ändringar i schemat.
• oLAP-applikationer är beroende av datalager och OLTP-system, som tar emot uppdaterade data från dem, vilket gör det möjligt att spara integritetskontroll företagsdata.
• minska belastningen på OLTP-system och datalager.

OLAP och OLTP. Egenskaper och huvudskillnader

OLAP	OLTP
Datalagring bör innehålla både interna företagsdata och externa uppgifter	den viktigaste informationskällan som kommer in i den operativa databasen är företagets aktiviteter och för dataanalys krävs det att externa informationskällor involveras (till exempel statistiska rapporter)
Volymen av analytiska databaser är åtminstone en storleksordning större än volymen av operativa databaser. för tillförlitlig analys och prognoser i datalagring du måste ha information om företagets verksamhet och marknadens tillstånd i flera år	För operativ bearbetning krävs uppgifter för de senaste månaderna
Datalagring bör innehålla enhetligt presenterad och överenskommen information som bäst matchar innehållet i operativa databaser. En komponent behövs för att extrahera och "rengöra" information från olika källor. Många stora företag har samtidigt flera operativa IS: er med egna databaser (av historiska skäl).	Operativa databaser kan innehålla semantiskt likvärdig information som presenteras i olika format, med en annan indikation på tidpunkten för mottagandet, ibland till och med motstridiga
Uppsättningen av frågor mot den analytiska databasen är omöjlig att förutsäga. datalager finns för att svara på ad hoc-analytikerförfrågningar. Du kan bara räkna med att förfrågningar inte kommer för ofta och involverar stora mängder information. Analysdatabasens storlek stimulerar användningen av frågor med aggregat (summa, minimum, maximalt, betyda etc.)	Databehandlingssystem är byggda med en lösning i åtanke specifika uppgifter... Information från databasen väljs ofta och i små delar. Vanligtvis är uppsättningen frågor till online-databasen känd redan under utformningen.
Med låg variation i analytiska databaser (endast vid laddning av data) visar sig ordningen av matriser vara rimliga, snabbare indexeringsmetoder för massprovtagning, lagring av föraggregerade data	Databehandlingssystem är till sin natur mycket flyktiga, vilket beaktas i den använda DBMS (normaliserad databasstruktur, rader lagras på ett oordnat sätt, B-träd för indexering, transaktion)
Analytisk databasinformation är så kritisk för ett företag att en stor granulering av skydd krävs (individuell åtkomsträtt till vissa rader och / eller kolumner i tabellen)	För databehandlingssystem brukar det räcka informationsskydd på bordsnivå

Kodregler för OLAP-system

1993 publicerade Codd ett verk med titeln OLAP for Analytic Users: The Way It Should Be. I det redogjorde han för de grundläggande begreppen online-analysbehandling och identifierade 12 regler som måste uppfyllas av produkter som möjliggör online-analysbehandling.

1. Konceptuell flerdimensionell vy. OLAP-modellen måste vara flerdimensionell. Ett flerdimensionellt konceptuellt schema eller anpassad vy underlättar modellering och analys samt beräkning.
2. Genomskinlighet. Användaren kan hämta alla nödvändiga data från OLAP-maskinen utan att ens veta var den kommer ifrån. Oavsett om OLAP-produkten är en del av användarens verktyg eller inte, bör detta faktum vara osynligt för användaren. Om OLAP tillhandahålls av klientserverberäkning, bör detta faktum också, om möjligt, vara osynligt för användaren. OLAP ska presenteras i en riktigt öppen arkitektur som gör det möjligt för användaren, var de än befinner sig, att kommunicera med servern med hjälp av ett analysverktyg. Utöver detta måste transparens också uppnås när analysverktyget interagerar med homogena och heterogena databasmiljöer.
3. Tillgänglighet. OLAP måste tillhandahålla sina egna logikdiagram för åtkomst i en heterogen databasmiljö och utföra lämpliga omvandlingar för att tillhandahålla data till användaren. Dessutom är det nödvändigt att i förväg ta hand om var och hur och vilka typer fysisk organisation data kommer faktiskt att användas. OLAP-systemet ska endast få åtkomst till den data som faktiskt krävs och inte tillämpas allmänna principen "köktratt", vilket medför onödig inmatning.
4. Konstant prestanda när du utvecklar rapporter. Prestanda rapportering bör inte sjunka betydligt med ökningen av antalet dimensioner och storleken på databasen.
5. Klient-server-arkitektur. Det krävs att produkten inte bara är klientserver utan också att serverkomponenten är tillräckligt smart så att olika klienter kan ansluta med ett minimum av ansträngning och programmering.
6. Allmän flerdimensionalitet. Alla dimensioner måste vara lika, varje dimension måste vara ekvivalent både i struktur och i operativ kapacitet. Det är sant att ytterligare operativa funktioner för enskilda mätningar är tillåtna (tydligen är tiden underförstått), men sådan ytterligare funktioner måste ges till alla dimensioner. Det borde inte vara så grundläggande data struktur, beräkningsformat eller rapporteringsformat var mer specifika för en dimension.
7. Dynamisk kontroll glesa matriser... OLAP-system bör automatiskt justera sitt fysiska schema baserat på modelltyp, datavolymer och databasgleshet.
8. Stöd för flera spelare. OLAP-verktyget måste tillhandahålla funktioner delning (begäran och tillägg), integritet och säkerhet.
9. Obegränsad delning. Alla typer av operationer måste vara tillåtna för alla mätningar.
10. Intuitiv datamanipulation. Datamanipulation utfördes genom direkta åtgärder på celler i visningsläget utan att använda menyer och flera operationer.
11. Flexibla rapporteringsalternativ. Mätningar bör placeras i rapporten efter användarens behov.
12. Obegränsat

Introduktion

Under vår tid kan nästan ingen organisation klara sig utan databashanteringssystem, särskilt bland dem som traditionellt är inriktade på interaktion med kunder. Banker, försäkringsbolag, flyg- och andra transportföretag, stormarknadskedjor, telekommunikations- och marknadsföringsföretag, serviceorganisationer och andra - de samlar och lagrar alla gigabyte data om kunder, produkter och tjänster i sina databaser. Värdet av sådan information är utan tvekan. Sådana databaser kallas operativa eller transaktionsmässiga eftersom de kännetecknas av ett stort antal små transaktioner eller läs-skriv-operationer. Datorsystemför att redovisa transaktioner och den faktiska tillgången till transaktionsbaserna är det vanligt att ringa transaktionsbearbetningssystem online (OLTP - On-Line Transactional Processing) eller bokföringssystem.

Redovisningssystemen är inställda och optimerade för att utföra det maximala antalet transaktioner på kort tid. Vanligtvis är de enskilda operationerna mycket små och inte relaterade till varandra. Varje datapost som kännetecknar interaktionen med en kund (ett supportanrop, en kontanttransaktion, en katalogorder, ett besök på företagets webbplats etc.) kan dock användas för att få kvalitativ ny information, nämligen för att skapa rapporter och analysera företagets verksamhet ...

Uppsättningen av analytiska funktioner i redovisningssystem är vanligtvis mycket begränsad. De scheman som används i OLTP-applikationer gör det svårt att skapa till och med enkla rapporter, eftersom data ofta sprids över många tabeller och komplexa sammanfogningar måste utföras för att aggregera dem. Vanligtvis är försök att skapa komplexa rapporter beräkningsintensiva och resulterar i prestandaförsämring.

Dessutom lagrar redovisningssystemen ständigt förändrade data. När transaktioner samlas in ändras summan mycket snabbt, så två analyser som tagits med intervaller på flera minuter kan ge olika resultat. Analysen utförs oftast i slutet av rapportperioden, annars kan bilden förvrängas. Dessutom kan de data som krävs för analys lagras i flera system.

Vissa typer av analyser kräver strukturella förändringar som är oacceptabla i den nuvarande driftsmiljön. Till exempel måste du ta reda på vad som händer om företaget har nya produkter. Sådan forskning kan inte utföras på en levande bas. Följaktligen utförs effektiv analys sällan direkt i redovisningssystemet.

Beslutsstödsystem har vanligtvis medel för att förse användaren med samlade data för olika prover från den ursprungliga uppsättningen i en form som är bekväm för uppfattning och analys. Sådana aggregerade funktioner bildar vanligtvis en flerdimensionell (och därför icke-relationell) dataset (ofta kallad hypercube eller metacube) vars axlar innehåller parametrar och cellerna - den samlade informationen som är beroende av dem - och sådan data kan lagras också i relationstabeller. Längs varje axel kan data organiseras i en hierarki som representerar olika nivåer deras detaljer. Med denna datamodell kan användare formulera komplexa frågor, generera rapporter, få delmängder av data.

Det var just det som ledde till intresset för beslutsstödsystem, som har blivit det viktigaste användningsområdet för OLAP (On-Line Analytical Processing, on-line analytisk bearbetning, on-line dataanalys), som vänder "malmen" av OLTP-system till en färdig "produkt" som chefer och analytiker kan använda direkt. Denna metod gör det möjligt för analytiker, chefer och chefer att "komma till hjärtat" av den ackumulerade informationen genom snabb och konsekvent tillgång till ett brett spektrum av informationsvyer.

Syftet terminspapper är hänsyn till OLAP-teknik.

flerdimensionell analytisk databehandling

Huvudsak

1 Förstå OLAP

OLAP-konceptet bygger på principen om flerdimensionell datapresentation. 1993 myntades termen OLAP av Edgar Codd. Efter att ha beaktat bristerna i relationsmodellen påpekade han först och främst att det är omöjligt att "kombinera, se och analysera data ur flera dimensioner, det vill säga på det mest förståeliga sättet för företagsanalytiker," och definierade allmänt krav på OLAP-system som utökar funktionaliteten hos relations-DBMS och inkluderar flerdimensionell analys som en av dess egenskaper.

I ett stort antal publikationer betecknar förkortningen OLAP inte bara en flerdimensionell vy av data utan också lagringen av själva data i en flerdimensionell databas. Generellt sett är detta inte sant, eftersom Codd själv konstaterar att "Relationsdatabaser har varit, är och kommer att vara den lämpligaste tekniken för lagring av företagsdata. ny teknologi DB, utan snarare i analysverktyg som kompletterar funktionerna i befintligt DBMS och är tillräckligt flexibla för att föreställa sig och automatisera de olika typerna av gruvdrift som är inneboende i OLAP. "Denna förvirring leder till motstånd som" OLAP eller ROLAP ", vilket inte är helt korrekt , eftersom ROLAP (relationell OLAP) på konceptnivå stöder all funktionalitet som definieras av termen OLAP. Det verkar mer föredraget att använda den speciella termen MOLAP för OLAP baserat på flerdimensionell DBMS. Enligt Codd är en flerdimensionell konceptuell vy en multipelperspektiv, bestående av flera oberoende dimensioner längs vilka specifika datamängder kan analyseras. Samtidig analys över flera dimensioner definieras som multivariatanalys. Varje dimension inkluderar riktningar för datakonsolidering, bestående av en serie successiva aggregeringsnivåer, där varje högre nivå nb motsvarar en större grad av dataggregation längs motsvarande dimension. Så, mätning.

Artisten kan bestämmas av konsolideringsriktningen, bestående av generaliseringsnivåerna "företag - avdelning - avdelning - anställd". Tidsdimensionen kan till och med innehålla två konsolideringsriktningar - år - kvartal - månad - dag och veckodag, eftersom tidräkning efter månad och vecka är oförenlig. I detta fall blir det möjligt att godtyckligt välja önskad informationsnivå för var och en av mätningarna. En nedborrningsoperation motsvarar en rörelse från högre till lägre stadier av konsolidering; tvärtom innebär en upprullning att flytta från lägre nivåer till högre nivåer.

Codd definierar 12 regler som måste uppfyllas programvara OLAP-klass.

1.2 Krav på analysverktyg online

Flerdimensionell konceptuell vy. Den konceptuella representationen av en datamodell i en OLAP-produkt bör ha flerdimensionell karaktär, det vill säga den ska göra det möjligt för analytiker att utföra intuitiva "slice and dice", rotera och vrida operationer av konsolideringsriktningar. Genomskinlighet Användaren ska inte vara medveten om vilka specifika medel som används för att lagra och bearbeta data, hur data är organiserade och varifrån de kommer.

Tillgänglighet. Analytikern ska kunna utföra analys inom ramen för en gemensam konceptuell ram, men samtidigt kan uppgifterna förbli under kontroll av DBMS återstående arv, samtidigt som de är bundna till den allmänna analysmodellen. Det vill säga OLAP-verktygslådan måste lägga sitt logiska schema på fysiska datamängder och utföra alla de transformationer som krävs för att ge en enda, konsekvent och helhetssyn av användaren på information.

Konsekvent rapporteringsprestanda Eftersom antalet dimensioner och databasstorlekar ökar bör analytiker inte uppleva någon prestandaförsämring. Hållbar prestanda är viktigt för att upprätthålla användarvänlighet och frihet från den komplexitet som krävs för att föra OLAP till slutanvändaren.

Client - server architecture (Client-Server Architecture). De flesta av de data som kräver analytisk bearbetning online lagras i mainframe-system och hämtas från personliga datorer... Därför är ett av kraven OLAP-produkters förmåga att arbeta i en klientservermiljö. Huvudidén här är att serverkomponenten i OLAP-verktyget ska vara tillräckligt smart och ha förmågan att bygga ett allmänt konceptuellt schema baserat på generalisering och konsolidering av olika logiska och fysiska scheman i företagsdatabaser för att ge en transparent effekt.

Generisk dimensionalitet Alla datamätningar måste vara lika. Ytterligare egenskaper kan tillhandahållas till enskilda dimensioner, men eftersom de alla är symmetriska, kan denna ytterligare funktionalitet ges till alla dimensioner. Den underliggande datastrukturen, formlerna och rapportformaten bör inte förlita sig på någon dimension.

Dynamisk sparsam matrishantering. OLAP-verktyget ska kunna hantera glesa matriser optimalt. Åtkomsthastigheten bör bibehållas oavsett platsen för datacellerna och vara konstant för modeller med olika antal dimensioner och olika sparsamhet.

Stöd för fleranvändarläge (Multi-User Support). Ofta behöver flera analytiker arbeta med samma analysmodell samtidigt eller skapa olika modeller baserat på samma företagsdata. OLAP-verktyget måste ge dem åtkomst samtidigt, dataintegritet och skydd.

Obegränsad tvärdimensionell verksamhet. Beräkning och manipulering av data över ett antal dimensioner bör inte förbjuda eller begränsa någon relation mellan dataceller. Transformationer som kräver godtycklig definition måste anges i ett funktionellt komplett formuleringsspråk.

Intuitiv datahantering. Omorientering av konsolideringsanvisningar, datadetaljer i kolumner och rader, aggregering och andra manipulationer som är inneboende i strukturen för hierarkin för konsolideringsriktningar bör utföras i det mest bekväma, naturliga och bekväma användargränssnittet.

Flexibel rapporteringsmekanism (Flexible Reporting). Olika sätt för datavisualisering bör stödjas, det vill säga rapporter bör presenteras i alla möjliga riktningar.

Obegränsade dimensioner och aggregeringsnivåer. Det rekommenderas starkt att anta minst femton och helst tjugo dimensioner i analysmodellen i varje seriöst OLAP-verktyg.

2 Komponenter i OLAP-system

2.1 Server. Klient. Internet

OLAP låter dig utföra snabba och effektiva analyser av stora mängder data. Data lagras i en flerdimensionell form som närmast återspeglar det naturliga tillståndet för verkliga affärsdata. Dessutom ger OLAP användarna möjlighet att hämta sammanfattningsdata snabbare och enklare. Med hjälp kan de gå igenom innehållet i dessa uppgifter om det behövs för att få mer detaljerad information.

Ett OLAP-system består av många komponenter. På den högsta presentationsnivån inkluderar systemet en datakälla, en OLAP-server och en klient. En datakälla är en källa från vilken data tas för analys. Data från källan överförs eller kopieras till OLAP-servern, där den är organiserad och förberedd för snabbare efterföljande generering av svar på frågor. Klienten är användargränssnittet till OLAP-servern. Detta avsnitt av artikeln beskriver funktionerna för varje komponent och betydelsen av hela systemet som helhet. Källor. Källan i OLAP-system är servern som levererar data för analys. Beroende på omfattningen av OLAP-produkten kan källan vara ett datalager, en ärvd databas som innehåller allmänna data, en uppsättning tabeller som kombinerar ekonomiska data eller någon kombination av ovanstående. En OLAP-produkts förmåga att arbeta med data från olika källor är mycket viktig. Kräver ett enhetligt format eller en enda bassom skulle lagra all originalinformation är inte lämplig för databasadministratörer. Dessutom minskar detta tillvägagångssätt OLAP-produktens flexibilitet och kraft. Administratörer och användare anser att OLAP-produkter som extraherar data inte bara från olika men också från flera källor är mer flexibla och användbara än de med strängare krav.

Server. OLAP-servern är den tillämpade delen av OLAP-systemet. Denna komponent gör allt arbete (beroende på systemmodell) och lagrar i sig all information till vilken aktiv åtkomst ges. Serverarkitektur styrs av olika koncept. I synnerhet är den viktigaste funktionella egenskapen hos en OLAP-produkt användningen av en flerdimensionell (MMDB, MDDB) eller relationsdatabas (RDB, RDB) för datalagring. Aggregerade / föraggregerade data

Snabb implementering av frågor är avgörande för OLAP. Detta är en av de grundläggande principerna för OLAP - förmågan att intuitivt manipulera data kräver snabb hämtning av information. Generellt, ju mer beräkning som krävs för att få en bit information, desto långsammare blir svaret. För att spara en liten tid för genomförandet av frågor utsätts därför de informationsstycken som oftast nås, men som samtidigt kräver beräkning, för preliminär aggregering. De räknas och lagras sedan i databasen som nya data. Ett exempel på en datatyp som kan beräknas i förväg är sammanfattningsdata - till exempel försäljningssiffror per månad, kvartal eller år - för vilka de faktiska inmatade uppgifterna är dagliga siffror.

Olika leverantörer har olika urvalsmetoder för parametrar som kräver föraggregering och ett antal förberäknade värden. Aggregationsmetoden påverkar både databas och körningstid för frågan. Om fler värden beräknas ökar sannolikheten att användaren kommer att be om ett redan beräknat värde och därför blir svarstiden kortare eftersom du inte behöver be om det ursprungliga värdet för beräkningen. Men om det inte är den bästa lösningen att beräkna alla möjliga värden - i det här fallet kommer databasens storlek att öka avsevärt, vilket gör den ohanterlig och aggregeringstiden blir för lång. Dessutom, när numeriska värden läggs till i databasen, eller om de ändras, bör denna information återspeglas i de förberäknade värdena beroende på de nya uppgifterna. Således kan uppdatering av databasen också ta lång tid när det gäller ett stort antal förberäknade värden. Eftersom databasen vanligtvis är offline under aggregering är det önskvärt att aggregeringstiden inte är för lång.

Klient. Klienten är det som används för att representera och manipulera data i databasen. Klienten kan vara ganska enkel - i form av en tabell, som inkluderar sådana OLAP-funktioner som till exempel datarotation (pivotering) och fördjupning av data (borrning), och det kan vara en specialiserad, men lika enkel rapportvisare eller vara så kraftfull som en skräddarsydd applikation som är utformad för komplex datamanipulation. Internet är en ny form av klienten. Dessutom bär den stämpeln av ny teknik; många Internetlösningar skiljer sig väsentligt åt i deras kapacitet i allmänhet och i kvaliteten på OLAP-lösningar i synnerhet. Detta avsnitt diskuterar de olika funktionella egenskaperna för varje klienttyp.

Även om servern är ryggraden i en OLAP-lösning är klienten lika viktig. Servern kan ge en gedigen grund för att underlätta datamanipulation, men om klienten är komplex eller inte särskilt funktionell kommer användaren inte att kunna dra full nytta av en kraftfull server. Kunden är så viktig att många leverantörer enbart fokuserar på kundutveckling. Allt som ingår i dessa applikationer är en standardvy på gränssnittet, fördefinierade funktioner och struktur, samt snabba lösningar för mer eller mindre standardsituationer. Till exempel är finanspaket populära. Förbyggda ekonomiska applikationer gör det möjligt för yrkesverksamma att använda bekanta finansiella instrument utan att behöva utforma en databasstruktur eller vanliga formulär och rapporter. Frågeverktyg / rapportgenerator. Ett frågeverktyg eller rapportgenerator ger enkel åtkomst till OLAP-data. De är lätta att använda grafiskt gränssnitt och låta användare skapa rapporter genom att flytta objekt till en rapport med " dra och drop ". Medan den traditionella rapportgeneratorn ger användaren möjlighet att snabbt släppa formaterade rapporter genererar de OLAP-kompatibla rapportgeneratorerna uppdaterade rapporter. Slutprodukten är en rapport som har förmågan att gå ner i data ner till detaljnivå, pivotrapporter, supporthierarkier och etc. Tillägg (tillägg) av kalkylark.

Idag, i många branscher, utförs olika former av analys av företagsdata med hjälp av kalkylblad. På ett sätt är det en idealisk rapporterings- och datavisning. En analytiker kan skapa makron som fungerar med data i en vald riktning, och en mall kan utformas så att när data matas in beräknar formlerna de rätta värdena, vilket eliminerar behovet av att ange enkla beräkningar igen.

Allt detta resulterar dock i en "platt" rapport, vilket innebär att när den väl har skapats är det svårt att se den på olika sätt. Exempelvis visar ett diagram information över en tidsperiod, till exempel en månad. Och om man vill se siffrorna för dagen (i motsats till uppgifterna för månaden) kommer det att bli nödvändigt att skapa ett helt nytt diagram. Det finns nya datamängder som ska definieras, nya etiketter ska läggas till i diagrammet och många andra enkla men tråkiga förändringar som ska göras. Dessutom finns det ett antal områden där misstag kan göras, vilket i allmänhet minskar tillförlitligheten. När OLAP läggs till i en tabell blir det möjligt att skapa ett enda diagram och sedan utsätta det för olika manipulationer för att förse användaren med nödvändig information utan att belasta sig med att skapa alla möjliga vyer. Internet som klient. Internet är en ny medlem i OLAP-klientfamiljen. Det finns många fördelar med att generera OLAP-rapporter via Internet. Det viktigaste är frånvaron av behovet av specialiserad programvara för åtkomst till information. Detta sparar företaget mycket tid och pengar.

Varje internetprodukt är specifik. Vissa gör det enklare att skapa webbsidor, men är mindre flexibla. Andra låter dig skapa vyer över dina data och sedan spara dem som statiska HTML-filer. Allt detta gör det möjligt att visa data över Internet, men inget mer. Det är omöjligt att aktivt manipulera data med deras hjälp.

Det finns en annan typ av produkt, interaktiv och dynamisk, som förvandlar sådana produkter till kompletta verktyg. Användare kan gå ner i data, pivot, begränsa dimensioner med mera Innan du väljer ett Internetimplementeringsverktyg är det viktigt att förstå vilken funktionalitet som krävs av en webblösning och sedan bestämma vilken produkt. det bästa sättet kommer att innehålla denna funktion.

Applikationer. Applikationer är en typ av klient som använder OLAP-databaser. De är identiska med frågverktygen och rapportgeneratorerna som beskrivs ovan, men de ger också mer funktionalitet till produkten. Applikationen är i allmänhet kraftfullare än frågeverktyget.

Utveckling. Vanligtvis tillhandahåller OLAP-leverantörer en utvecklingsmiljö för användarna att skapa egna anpassade applikationer. Utvecklingsmiljön som helhet är ett grafiskt gränssnitt som stöder objektorienterad applikationsutveckling. Dessutom tillhandahåller de flesta leverantörer ett API som kan användas för att integrera OLAP-databaser med andra applikationer.

2.2 OLAP-klienter

OLAP-klienter med en inbäddad OLAP-maskin installeras på användarnas datorer. De behöver inte en server för beräkning, och de har ingen administration. Dessa klienter tillåter användaren att ställa in sina befintliga databaser; som regel skapar detta en ordlista som döljer den fysiska strukturen för uppgifterna bakom ämnesbeskrivningen, förståelig för en specialist. OLAP-klienten kör sedan godtyckliga frågor och visar resultaten i en OLAP-tabell. I den här tabellen kan användaren i sin tur manipulera data och ta emot hundratals olika rapporter på skärmen eller på papper. OLAP-klienter som är utformade för att fungera med RDBMS gör att du kan analysera data som redan finns i ett företag, till exempel lagrat i en OLTP-databas. Deras andra syfte kan dock vara att snabbt och billigt skapa datalager eller datamärtor - i det här fallet behöver organisationens programmerare bara skapa samlingar av stjärntabeller i relationsdatabaser och dataladdningsförfaranden. Den mest tidskrävande delen av arbetet - att skriva gränssnitt med många alternativ för anpassade frågor och rapporter - implementeras i OLAP-klienten på bara några timmar. Slutanvändaren tar å andra sidan cirka 30 minuter att behärska ett sådant program. OLAP-klienter tillhandahålls av databasutvecklarna själva, både flerdimensionella och relationella. Dessa är SAS Corporate Reporter, som nästan är en standardprodukt när det gäller bekvämlighet och skönhet, Oracle Discoverer, en uppsättning MS Pivot Services och Pivot Table-program etc. Många program som är utformade för att fungera med MS OLAP Services levereras som en del OLAP-kampanj, som genomförs av Microsoft Corporation. Vanligtvis är de förbättrade versioner av pivottabellen och är utformade för användning i MS Office eller en webbläsare. Detta är produkter från Matryx, Knosys, etc., som har vunnit enorm popularitet i väst på grund av sin enkelhet, låga kostnad och effektivitet.

3 Klassificering av OLAP-produkter

3.1 Flerdimensionell OLAP

För närvarande finns det ett stort antal produkter på marknaden som tillhandahåller OLAP-funktioner i en eller annan grad. Genom att tillhandahålla en flerdimensionell konceptvy från användargränssnittet till källdatabasen är alla OLAP-produkter uppdelade i tre klasser, liknande källdatabasstypen.

1. De tidigaste analyssystemen 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 full 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.

2. System för online analytisk bearbetning av relationsdata (ROLAP) gör att du kan representera data som lagras i en relationsdatabas i flerdimensionell form, vilket säkerställer omvandlingen av information till en flerdimensionell modell genom ett mellanliggande lager av metadata. Denna klass inkluderar DSS Suite från MicroStrategy, MetaCube från Informix, DecisionSuite från Information Advantage och andra. Mjukvarupaket InfoVisor, utvecklat i Ryssland vid Ivanovo State Power Engineering University, är också ett system av denna klass. 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.

3. 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.

Förutom dessa verktyg finns det en annan klass - skrivbordsfråga och rapporteringsverktyg, kompletterade med OLAP-funktioner eller integrerade med externa verktyg som utför sådana funktioner. Dessa välutvecklade system hämtar data från originalkällor, transformerar den och placerar den i en dynamisk flerdimensionell databas som körs på slutanvändarens klientstation. De viktigaste företrädarna för denna klass är BusinessObjects från företaget med samma namn, BrioQuery från Brio Technology och PowerPlay från Cognos. En översikt över vissa OLAP-produkter finns i bilagan.

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.

1. Vid användning av ett flerdimensionellt DBMS är datasökning och hämtning mycket snabbare än med en flerdimensionell konceptvy av en relationsdatabas, eftersom en flerdimensionell databas denormaliseras, innehåller föraggregerade indikatorer och ger optimerad åtkomst till de begärda cellerna.

2. Flerdimensionellt DBMS hanterar enkelt uppgifterna att inkludera olika inbyggda funktioner i informationsmodellen, samtidigt som 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.

1. Flerdimensionell 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.

2. Flerdimensionella DBMS används mycket ineffektivt i jämförelse 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 största möjliga sammanhängande grupper . Men även i det här fallet ä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.

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

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

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

4. 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.

Direkt användning av relationsdatabaser i online-analysbehandlingssystem har följande fördelar.

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

2. När det gäller en variabel dimension av problemet, när förändringar i mätstrukturen måste göras ganska ofta, är ROLAP-system med en dynamisk representation av dimensionen den optimala lösningen, eftersom sådana ändringar inte kräver någon fysisk omorganisation av databasen.

3. Relational DBMS ger en betydligt högre nivå av dataskydd och goda möjligheter att skilja åtkomsträttigheter.

Den största nackdelen med ROLAP jämfört med flerdimensionell DBMS är lägre prestanda. Relationssystem kräver omfattande 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 system baserat på flerdimensionella databaser.

Beskrivningen av stjärnschemat och rekommendationer för dess användning ägnas helt åt arbetet. Dess idé är att det finns tabeller för varje dimension, och alla fakta placeras i en tabell, indexeras av en multipelnyckel som består av nycklarna för enskilda dimensioner (bilaga A). Varje stråle i stjärnschemat definierar, i Codds terminologi, riktningen för datakonsolidering längs motsvarande dimension.

I komplexa problem med mått på flera nivåer är det vettigt att vända sig till utvidgningarna av stjärnschemat - konstellationsschemat och snöflingaschemat. I dessa fall skapas separata faktatabeller för möjliga kombinationer av sammanfattningsnivåer av olika dimensioner (bilaga B). Detta möjliggör bättre prestanda, men leder ofta till dataredundans och betydande komplikationer i strukturen i databasen där stor mängd faktatabeller.

Ökningen av antalet faktatabeller i databasen kan inte bara bero på mångfalden av nivåer av olika dimensioner, utan också från det faktum att fakta i allmänhet har olika uppsättningar dimensioner. Vid abstrahering från enskilda mätningar bör användaren få en projektion av den mest kompletta hyperkuben, och inte alltid bör värdena på indikatorerna vara resultatet av en elementär summering. Med ett stort antal oberoende dimensioner är det sålunda nödvändigt att upprätthålla många faktatabeller motsvarande varje möjlig kombination av dimensioner som valts i frågan, vilket också leder till slösaktig användning av externt minne, en ökning av tiden för laddning av data i stjärnschemadatabas från externa källor och administrationskomplexitet.

Förlängningar av SQL-språket (operatörer GROUP BY CUBE "," GROUP BY ROLLUP "och" GROUP BY GROUPING SETS ") löser delvis detta problem. Dessutom föreslås en mekanism för att hitta en kompromiss mellan redundans och prestanda, där man rekommenderar att faktatabeller skapas inte för alla möjliga kombinationer av dimensioner, utan bara för dem vars cellvärden inte kan erhållas med den efterföljande aggregeringen av mer fullständiga faktatabeller (bilaga B).

I vilket fall som helst, om den flerdimensionella modellen implementeras som en relationsdatabas, bör du skapa långa och "smala" faktatabeller och relativt små och "breda" dimensionstabeller. Faktatabeller innehåller de numeriska värdena för cellerna i hyperkuben, och resten av tabellerna definierar den flerdimensionella dimensionen som innehåller dem. En del av informationen kan erhållas med dynamisk aggregering av data som distribueras över icke-stjärniga normaliserade strukturer, även om man bör komma ihåg att frågor som involverar aggregering med en mycket normaliserad databasstruktur kan vara ganska långsamma.

Genom att fokusera på representationen av flerdimensionell information med hjälp av stjärnformade relationsmodeller kan du bli av med problemet med att optimera lagring av glesa matriser, vilket är akut för flerdimensionella DBMS (där problemet med gleshet löses med ett speciellt val av schema) . Även om en hel post används för att lagra varje cell, som förutom själva värdena innehåller sekundära nycklar - hänvisningar till dimensionstabeller, ingår icke-existerande värden helt enkelt inte i faktatabellen.

Slutsats

Efter att ha övervägt frågorna om drift och tillämpning av OLAP-teknik har företagen frågor vars svar gör det möjligt att välja den produkt som bäst uppfyller användarens behov.

Det här är följande frågor:

Varifrån kommer uppgifterna? - De data som ska analyseras kan lokaliseras på olika platser. Det är möjligt att OLAP-databasen tar emot dem från ett företags datalager eller från ett OLTP-system. Om OLAP-produkten redan har tillgång till en datakälla minskas kategoriserings- och datarengöringsprocesserna.

Vilken typ av manipulationer utför användaren med data? -
När användaren har öppnat databasen och börjat utföra analysen är det viktigt att han kan manipulera data på rätt sätt. Beroende på användarens behov kan det hända att du behöver en kraftfull rapportgenerator eller möjlighet att skapa och vara värd för dynamiska webbsidor. Det kan emellertid vara att föredra för användaren att ha ett sätt att enkelt och snabbt skapa sina egna applikationer.

Vad är den totala mängden data? - Detta är den viktigaste faktorn när man definierar en OLAP-databas. Relationella OLAP-produkter kan hantera stora mängder data bättre än flerdimensionella. Om datamängden inte kräver användning av en relationsdatabas kan den flerdimensionella produkten användas med lika framgång.

Vem är användaren? - När man definierar en OLAP-systemklient är användarens skicklighetsnivå viktig. Vissa användare tycker att det är bekvämare att integrera OLAP med ett kalkylark, medan andra föredrar en specialapplikation. Beroende på användarens kvalifikationer avgörs också frågan om utbildning. Ett stort företag kanske vill betala för användarutbildning, ett mindre företag kanske inte. Klienten ska vara sådan att användare känner sig självsäkra och kan använda den effektivt.

Idag har de flesta av världens företag gått över till att använda OLAP as grundläggande teknik att ge information till beslutsfattare. Därför är den grundläggande frågan inte om kalkylblad ska fortsätta att användas som den primära plattformen för rapportering, budgetering och prognoser. Företagen måste fråga sig om de är beredda att förlora konkurrensfördelar genom att använda felaktig, irrelevant och ofullständig information innan de mognar och överväger alternativ teknik.

Sammanfattningsvis bör det noteras att OLAP-teknologins analytiska kapacitet ökar användbarheten av data som lagras i företagets informationslager, vilket gör att företaget kan interagera mer effektivt med sina kunder.

Ordlista

	Begrepp	Definition
1	BI-verktyg	Verktyg och teknik som används för att komma åt information. Inkluderar OLAP-teknik, datautvinning och komplex analys; slutanvändarverktyg och ad hoc-verktyg för verktygsfråga, instrumentpaneler för företagsövervakning och företagsrapporteringsgeneratorer.
2	On-line Analitic Processing, OLAP	En teknik för analytisk bearbetning av information i realtid, inklusive förberedelse och dynamisk publicering av rapporter och dokument.
3	Slice and Dice	En term som används för att beskriva den sofistikerade dataanalysfunktionen som tillhandahålls av OLAP-verktyg. Hämtar data från en flerdimensionell kub med angivna värden och specificerad relativ position för dimensioner.
4	Datapivot	Processen att rotera en datatabell, det vill säga konvertera kolumner till rader och vice versa.
5	Beräknad medlem	Ett dimensionelement vars värde bestäms av värdena för andra element (till exempel matematiska eller logiska applikationer). Det beräknade objektet kan vara en del av OLAP-servern eller beskrivas av användaren under en interaktiv session. En beräknad artikel är varje artikel som inte matas in utan beräknas.
6	Globala affärsmodeller	En typ av datalager som ger tillgång till information som distribueras över olika företagssystem och som är under kontroll av olika avdelningar eller avdelningar med olika databaser och datamodeller. Denna typ av datalager är svår att bygga på grund av behovet av att kombinera ansträngningar från användare från olika avdelningar för att utveckla en gemensam datamodell för lagret.
7	Data Mining	Tekniker med programvaruverktygdesignad för en användare som som regel inte kan säga i förväg vad han letar efter, men bara kan ange vissa mönster och sökriktningar.
8	Klient-server	Tekniskt tillvägagångssätt som består i att dela upp processen i separata funktioner. Servern utför flera funktioner - kommunikationshantering, databasunderhåll etc. Klienten utför individuella användarfunktioner - tillhandahåller lämpliga gränssnitt, utför navigering mellan skärmar, tillhandahåller hjälpfunktioner etc.
9	Flerdimensionell databas, MDBS och MDBMS	En kraftfull databas som gör det möjligt för användare att analysera stora mängder data. En databas med en speciell lagringsorganisation - kuber, som tillhandahåller höghastighetsarbete med data lagrade som en samling fakta, dimensioner och förberäknade aggregat.
10	Borra ner	En detaljerad data mining metod som används för att analysera den sammanlagda nivån på data. De "fördjupande" nivåerna beror på granulariteten hos data i [lagring.
11	Centralt lager	1. Databas som innehåller data som samlats in från operativsystem organisationer. Har en struktur som är bekväm för dataanalys. Designad för att stödja beslutsfattande och skapa ett enda informationsutrymme för företaget. 2. Ett sätt att automatisera, som täcker alla informationssystem som hanteras från en plats.

1 Golitsina O.L., Maksimov N.V., Popov I.I. Databas: Handledning... - M.: FORUM: INFRA-M, 2003. - 352 s.

2 Datum K. Introduktion till databassystem. - M.: Nauka, 2005 - 246 s.

3 Elmanova N.V., Fedorov A.A. Introduktion till Microsoft OLAP-teknik. - M .: Dialog-MEPhI, 2004. - 312 s.

4 Karpova T.S. Databaser: modeller, utveckling, implementering. - SPb.: Peter, 2006. - 304 s.

5 Korovkin S. D., Levenets I. A., Ratmanova I. D., Starykh V. A., Shchavelev L. V. Lösning av problemet med komplex operativ analys av information i datalager // DBMS. - 2005. - Nr 5-6. - 47-51 s.

6 Krechetov N., Ivanov P. Produkter för datagrupp ComputerWeek-Moscow. - 2003. - Nr 14-15. - 32-39 s.

7 Przhiyalkovskiy V.V. Komplex analys av stora data: nya perspektiv på datorisering // DBMS. - 2006. - Nr 4. - 71-83 s.

8 Sakharov A.A. Begreppet konstruktion och implementering av informationssystem fokuserade på dataanalys // DBMS. - 2004. - Nr 4. - 55-70 s.

9 Ullman J. Grunderna i databassystem. - M.: Ekonomi och statistik, 2003. - 312 s.

10 Hubbard J. Datorstödd design av databaser. - M.: Mir, 2007. - 294 s.

Korovkin S.D., Levenets I.A., Ratmanova I.D., Starykh V.A., Shchavelev L.V.Lösning av problemet med komplex operativ analys av information i datalager // DBMS. - 2005. - Nr 5-6. - 47-51 s.

Ullman J. Grunderna i databassystem. - M.: Ekonomi och statistik, 2003. - 312 s.

Barsegyan A.A., Kupriyanov M.S. Teknik för dataanalys: DataMining, VisualMining, TextMining, Olap. - SPb.: BHV-Petersburg, 2007. - 532 s.

Elmanova N.V., Fedorov A.A. Introduktion till Microsoft OLAP-teknik. - M .: Dialog-MEPhI, 2004. - 312 s.

Datum K. Introduktion till databassystem. - M.: Nauka, 2005 - 246 s.

Golitsina O.L., Maksimov N.V., Popov I.I. Databaser: Handledning. - M.: FORUM: INFRA-M, 2003. - 352p.

Sakharov A.A. Begreppet konstruktion och implementering av informationssystem fokuserade på dataanalys // DBMS. - 2004. - Nr 4. - 55-70 s.

Przhiyalkovsky V.V. Komplex analys av stora data: nya perspektiv på datorisering // DBMS. - 2006. - Nr 4. - 71-83 s.

Begreppet multivariat dataanalys är nära relaterat till operativ analys, som utförs med hjälp av OLAP-system.

OLAP (On-Line Analytical Processing) är en teknik för operativ analytisk databehandling som använder metoder och verktyg för att samla in, lagra och analysera flerdimensionella data för att stödja beslutsprocesser.

Huvudsyftet med OLAP-system är att stödja analytiska aktiviteter, godtyckliga (begreppet ad-hoc används ofta) förfrågningar från analytikeranvändare. Syftet med OLAP-analys är att testa nya hypoteser.

I början av OLAP-teknik är grundaren av den relationella metoden E. Codd. 1993 publicerade han en artikel med titeln "OLAP för analytiska användare: hur det borde vara". Denna uppsats beskriver de grundläggande begreppen online-analysbehandling och identifierar följande 12 krav som måste uppfyllas av produkter som tillåter online-analysbehandling. Tokmakov G.P. Databas. Databaskoncept, relationsdatamodell, SQL-språk. S 51

Nedan listas de 12 regler som Codd beskriver som definierar OLAP.

1. Flerdimensionalitet - OLAP-systemet på konceptnivå bör representera data i form av en flerdimensionell modell, vilket förenklar processerna för analys och uppfattning av information.

2. Transparens - OLAP-systemet måste dölja för användaren den verkliga implementeringen av den flerdimensionella modellen, organisationssätt, källor, bearbetnings- och lagringsanläggningar.

3. Tillgänglighet - OLAP-systemet ska ge användaren en enda, konsekvent och fullständig datamodell som ger tillgång till data oavsett hur och var den lagras.

4. Konsekvent prestanda vid utveckling av rapporter - OLAP-systemens prestanda bör inte försämras avsevärt med en ökning av antalet dimensioner som analyseras.

5. Klient-server-arkitektur - OLAP-system måste kunna arbeta i en klient-server-miljö, för de flesta av de uppgifter som idag måste utsättas för online-analysbehandling lagras på ett distribuerat sätt. Huvudidén här är att serverkomponenten i OLAP-verktyget ska vara tillräckligt intelligent och göra det möjligt att bygga ett allmänt konceptuellt schema baserat på generalisering och konsolidering av olika logiska och fysiska system för företagsdatabaser för att säkerställa effekten av öppenhet.

6. Lika dimensioner - OLAP-systemet måste stödja en flerdimensionell modell där alla dimensioner är lika. Om nödvändigt ytterligare egenskaper kan ges till enskilda dimensioner, men en sådan möjlighet måste ges till alla dimensioner.

7. Dynamisk hantering av glesa matriser - OLAP-systemet ska ge optimal bearbetning av glesa matriser. Åtkomsthastigheten bör bibehållas oavsett platsen för dataceller och vara konstant för modeller med olika antal dimensioner och olika grader av datasparhet.

8. Stöd för fleranvändarläge - OLAP-systemet bör ge möjlighet att arbeta flera användare tillsammans med en analysmodell eller skapa olika modeller för dem från en enda data. I detta fall är både läsning och skrivning av data möjlig, därför måste systemet säkerställa deras integritet och säkerhet.

9. Obegränsad korsoperationer - OLAP-systemet måste säkerställa bevarandet av funktionella förhållanden som beskrivs med hjälp av ett visst formellt språk mellan cellerna i hyperkuben vid utförande av operationer av skiva, rotation, konsolidering eller detaljering. Systemet ska självständigt (automatiskt) utföra omvandlingen av de etablerade relationerna utan att användaren behöver omdefiniera dem.

10. Intuitiv datamanipulation - Ett OLAP-system bör tillhandahålla ett sätt att utföra skivnings-, rotations-, konsoliderings- och borrningsoperationer på en hyperkub utan att användaren behöver göra många gränssnittsåtgärder. Mätningarna som definieras i analysmodellen måste innehålla all nödvändig information för att utföra ovanstående operationer.

11. Flexibla möjligheter att ta emot rapporter - OLAP-systemet bör stödja olika sätt för datavisualisering, dvs. rapporter bör presenteras i alla möjliga riktningar. Rapporteringsverktyg bör representera syntetiserad data eller information som härrör från datamodellen i alla möjliga riktningar. Detta innebär att rader, kolumner eller sidor måste visa från 0 till N-dimensioner samtidigt, där N är antalet dimensioner i hela analysmodellen. Dessutom måste varje innehållsdimension som visas i en post, kolumn eller sida kunna visa vilken delmängd som helst av elementen (värdena) i dimensionen, i vilken ordning som helst.

12. Obegränsad dimension och antal aggregeringsnivåer - Undersökning av det möjliga antalet erforderliga dimensioner som krävs i en analysmodell har visat att upp till 19 dimensioner kan användas samtidigt. Därav den starka rekommendationen att analysverktyget samtidigt kan ge minst 15 och helst 20 mätningar. Dessutom bör var och en av de allmänna dimensionerna inte begränsas av antalet användaranalytiska användardefinierade aggregeringsnivåer och konsolideringsvägar.

Ytterligare kodregler.

Uppsättningen av dessa krav, som fungerade som de facto-definitionen av OLAP, orsakar ganska ofta olika klagomål, till exempel, regler 1, 2, 3, 6 är krav och regler 10, 11 är opformerade önskemål. Tokmakov G.P. Databas. Databaskoncept, relationsdatamodell, SQL-språk. S. 68 Således tillåter de listade 12 kraven i Codd inte att exakt definiera OLAP. 1995 lade Codd till följande sex regler i listan:

13. Partiextraktion kontra tolkning - Ett OLAP-system bör ge åtkomst till både inhemska och externa data lika effektivt.

14. Stöd för alla OLAP-analysmodeller - Ett OLAP-system måste stödja alla fyra dataanalysmodeller som definierats av Codd: kategoriska, tolkande, spekulativa och stereotypa.

15. Bearbetning av onormaliserad data - OLAP-systemet måste integreras med onormaliserade datakällor. Datamodifieringar som görs i OLAP-miljön bör inte ändra de data som lagras i de ursprungliga externa systemen.

16. Spara OLAP-resultat: lagra dem separat från originaldata - ett OLAP-system som fungerar i läs- och skrivläge bör spara resultaten separat efter att originaldata har ändrats. Med andra ord säkerställs säkerheten för de ursprungliga uppgifterna.

17. Eliminera värden som saknas - OLAP-systemet måste, när det presenterar data för användaren, kasta alla värden som saknas. Med andra ord måste saknade värden skilja sig från nollvärden.

18. Hantering av saknade värden - OLAP-systemet ska ignorera alla värden som saknas oavsett källa. Denna funktion är associerad med den 17: e regeln.

Dessutom delade Codd alla 18 regler i följande fyra grupper och kallade dem funktioner. Dessa grupper fick namnet B, S, R och D.

Viktiga funktioner (B) inkluderar följande regler:

Flerdimensionell konceptuell representation av data (regel 1);

Intuitiv datamanipulation (regel 10);

Tillgänglighet (regel 3);

Partiextraktion kontra tolkning (regel 13);

Stöd för alla OLAP-analysmodeller (regel 14);

Klient-server-arkitektur (regel 5);

Öppenhet (regel 2);

Stöd för flera spelare (regel 8)

Specialfunktioner (S):

Bearbetning av onormaliserad data (regel 15);

Spara OLAP-resultat: hålla dem åtskilda från originaldata (regel 16);

Eliminering av saknade värden (regel 17);

Hantering av saknade värden (regel 18). Rapporteringsfunktioner (R):

Flexibilitet vid generering av rapporter (regel 11);

Standardrapportering (regel 4);

Automatisk fysisk lagerkonfiguration (modifierad originalregel 7).

Mätkontroll (D):

Mångsidighet av mätningar (regel 6);

Obegränsat antal dimensioner och aggregeringsnivåer (regel 12);

Obegränsade operationer mellan måtten (regel 9).

Villkoren för hög konkurrens och den växande dynamiken i den yttre miljön dikterar ökade krav på företagsledningssystem. Utvecklingen av ledningens teori och praktik åtföljdes av framväxten av nya metoder, teknologier och modeller med fokus på att förbättra effektiviteten i aktiviteterna. Metoder och modeller bidrog i sin tur 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 i första hand nödvändiga för människor vars beslut företagets utveckling beror på: chefer, experter, analytiker. Analytiska system gör det möjligt att lösa problemen med konsolidering, rapportering, optimering och prognoser. Hittills har den slutliga klassificeringen av analytiska system inte utvecklats, liksom det finns inget allmänt definitionssystem i termer som används i denna riktning. Informationsstrukturen för ett företag kan representeras av en sekvens av nivåer, som var och en 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 att analysera och generera rapporter. Datalager, datamärken och OLAP-system som diskuterats ovan klassificeras som Business Intelligence (BI) -system.

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 Informationssystem chef (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ängliga 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 grundlig studie 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 i 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 bilda frågor och studera deras resultat.

Men dynamiska DSS kan fungera i mer än bara ramen 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.

Sfär av aggregat. En omfattande titt på informationen som samlas in i datalagret, dess generalisering och aggregering, hyperkubrepresentation och flerdimensionell analys är uppgifterna för OLAP-system (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 aggregeringen av information utföras i farten i processen att skanna 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, konstruktionen av modeller och regler som förklarar de hittade avvikelserna 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 bristerna i relationsmodellen och påpekade främst 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 allmänna krav på OLAP-system som utökar funktionaliteten i relationsdatabas 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 tillhandahåller OLAP-funktioner i en eller annan grad. Cirka 30 av de mest kända listas på översikten Webbserver http://www.olapreport.com/. Genom att tillhandahålla en flerdimensionell konceptvy från användargränssnittet till källdatabasen är alla OLAP-produkter uppdelade i tre klasser, liknande källdatabasstypen.

De tidigaste on-line analytiska bearbetningssystemen (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 full cykel av OLAP-bearbetning. De inkluderar antingen, förutom serverkomponenten, sitt eget integrerade klientgränssnitt eller använder externa kalkylprogram för att kommunicera med användaren. 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 On-Line Analytical Processing (ROLAP) -system gör att du kan representera data som lagras i en relationsdatabas i en flerdimensionell form, vilket ger omvandling av information 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 nackdelarna med 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ökning och val 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.

Flerdimensionella DBMS klarar enkelt uppgifterna att inkludera olika inbyggda funktioner i informationsmodellen, medan de objektivt existerande begränsningarna i SQL-språket gör det ganska 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 använder externt minne mycket ineffektivt jämfört med relationella. 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 största möjliga sammanhängande grupper . Men även i det här fallet ä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 måste du i riktiga system 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 med 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.

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)

Direkt användning av relationsdatabaser i online-analysbehandlingssystem har följande fördelar.

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

När det gäller en variabel dimension av problemet, när förändringar i mätstrukturen måste göras ganska ofta, är ROLAP-system med en dynamisk representation av dimensionen den optimala lösningen, eftersom sådana modifieringar i dem inte kräver någon fysisk omorganisation av databas.

Relationella DBMS ger en betydligt högre nivå av dataskydd och goda möjligheter att skilja åtkomsträttigheter.

Den största nackdelen med ROLAP jämfört med flerdimensionell DBMS är lägre prestanda. Relationssystem kräver omfattande 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.