I allmänhet vet varje specialist vad OLAP är idag. Åtminstone är begreppen "OLAP" och "flerdimensionell data" fast förbundna i våra sinnen. Jag hoppas dock att det faktum att detta ämne tas upp igen kommer att godkännas av majoriteten av läsarna, för för att idén om något inte ska bli föråldrad med tiden måste du regelbundet kommunicera med smarta människor eller läs artiklar i en bra publikation...
Datalager (platsen för OLAP i företagets informationsstruktur)
Termen "OLAP" är oupplösligt kopplad till termen "data warehouse" (Data Warehouse).
Här är definitionen formulerad av "grundläggaren" av datalager, Bill Inmon: "Ett datalager är en domänspecifik, tidsbunden, oföränderlig samling av data för att stödja ledningens beslutsfattande."
Datan i lagret kommer från operativa system (OLTP-system), som är designade för att automatisera affärsprocesser. Dessutom kan förvaret fyllas på från externa källor, såsom statistiska rapporter.
Varför bygga datalager - trots allt innehåller de uppenbart överflödig information som redan "bor" i databaser eller operativsystemfiler? Svaret kan vara kort: det är omöjligt eller mycket svårt att direkt analysera data från operativsystem. Detta beror på olika anledningar, inklusive fragmentering av data, dess lagring i olika DBMS-format och i olika "hörn" av företagsnätverket. Men även om ett företag lagrar all sin data på en central databasserver (vilket är extremt sällsynt), kommer en analytiker nästan säkert inte att förstå deras komplexa, ibland förvirrande strukturer. Författaren har en ganska sorglig erfarenhet av att försöka "mata" hungriga analytiker med "rå" data från operativa system - det visade sig vara "för mycket för dem".
Syftet med förvaret är alltså att tillhandahålla ”råvarorna” för analys på ett ställe och i en enkel, begriplig struktur. Ralph Kimball, i förordet till sin bok "The Data Warehouse Toolkit", skriver att om läsaren efter att ha läst hela boken bara förstår en sak - nämligen att strukturen på lagret ska vara enkel - kommer författaren att överväga sin uppgift avslutad.
Det finns ytterligare ett skäl som motiverar uppkomsten av en separat lagringsanläggning - komplexa analytiska frågor för operativ information saktar ner företagets nuvarande arbete, blockerar tabeller under lång tid och lägger beslag på serverresurser.
Enligt min mening behöver ett förvar inte nödvändigtvis innebära en gigantisk ansamling av data – huvudsaken är att det är bekvämt för analys. Generellt sett finns det en separat term för små lagringsanläggningar - Data Marts (datakiosker), men i vår ryska praxis hör du det inte ofta.
OLAP - ett bekvämt analysverktyg
Centralisering och bekväm strukturering är inte allt som en analytiker behöver. Han behöver fortfarande ett verktyg för att se och visualisera information. Traditionella rapporter, även de som bygger på ett enda förråd, saknar en sak - flexibilitet. De kan inte "tvinnas", "expanderas" eller "komprimeras" för att få önskad bild av data. Naturligtvis kan du ringa en programmerare (om han vill komma), och han (om han inte är upptagen) kommer att göra en ny rapport snabbt nog - säg inom en timme (jag skriver det här och jag tror inte på det själv - det går inte så snabbt i livet, låt oss ge honom tre timmar). Det visar sig att en analytiker inte kan testa mer än två idéer per dag. Och han (om han är en bra analytiker) kan komma på flera sådana idéer per timme. Och ju fler "skivor" och "sektioner" av data analytikern ser, desto fler idéer har han, som i sin tur kräver fler och fler "skivor" för verifiering. Om han bara hade ett verktyg som skulle tillåta honom att expandera och kollapsa data enkelt och bekvämt! OLAP fungerar som ett sådant verktyg.
Även om OLAP inte är ett nödvändigt attribut för ett datalager, används det allt oftare för att analysera informationen som samlas i lagret.
Komponenterna som ingår i ett typiskt förvar visas i fig. 1.
Ris. 1. Datalagerstruktur
Verksamhetsdata samlas in från olika källor, rensas, integreras och lagras i ett relationslager. Dessutom är de redan tillgängliga för analys med hjälp av olika rapporteringsverktyg. Därefter förbereds data (helt eller delvis) för OLAP-analys. De kan laddas in i en speciell OLAP-databas eller lagras i relationslagring. Dess viktigaste element är metadata, det vill säga information om struktur, placering och transformation av data. Tack vare dem säkerställs effektiv interaktion mellan olika lagringskomponenter.
För att sammanfatta kan vi definiera OLAP som en uppsättning verktyg för multidimensionell analys av data som ackumuleras i ett lager. Teoretiskt kan OLAP-verktyg appliceras direkt på operativa data eller deras exakta kopior(för att inte störa operativa användare). Men vi riskerar därmed att trampa på den rake som redan beskrivits ovan, d.v.s. börja analysera operativa data som inte är direkt lämpliga för analys.
Definition och grundläggande begrepp för OLAP
Först, låt oss dechiffrera: OLAP är Online Analytical Processing, det vill säga operationell dataanalys. De 12 definierande principerna för OLAP formulerades 1993 av E. F. Codd, "uppfinnaren" av relationsdatabaser. Senare omarbetades dess definition till det så kallade FASMI-testet, vilket kräver att OLAP-applikationen ger möjlighet att snabbt analysera delad flerdimensionell information ().
FASMI test
Snabb(Snabb) - analys bör utföras lika snabbt på alla aspekter av informationen. Acceptabel svarstid är 5 sekunder eller mindre.
Analys(Analys) - det måste vara möjligt att utföra grundläggande typer av numerisk och statistisk analys, fördefinierad av applikationsutvecklaren eller fritt definierad av användaren.
Delad(Delad) – många användare måste ha tillgång till data, samtidigt som det är nödvändigt att kontrollera åtkomsten till konfidentiell information.
Flerdimensionell(Multidimensional) är den viktigaste, mest väsentliga egenskapen hos OLAP.
Information(Information) - applikationen måste kunna komma åt all nödvändig information, oavsett dess volym och lagringsplats.
OLAP = Flerdimensionell vy = Kub
OLAP erbjuder bekväma, snabba sätt att komma åt, visa och analysera affärsinformation. Användaren får en naturlig, intuitiv datamodell som organiserar dem i form av flerdimensionella kuber (kuber). Axlarna i det flerdimensionella koordinatsystemet är huvudattributen för den analyserade affärsprocessen. För försäljning kan det till exempel vara produkt, region, typ av köpare. Tid används som en av dimensionerna. I skärningspunkterna mellan axlarna - dimensioner (Dimensioner) - finns data som kvantitativt karakteriserar processen - mått (mått). Detta kan vara försäljningsvolymer i bitar eller i monetära termer, lagersaldon, kostnader etc. En användare som analyserar information kan "klippa" kuben i olika riktningar, få en sammanfattning (till exempel efter år) eller omvänt detaljerad (per vecka) ) information och utföra andra manipulationer som kommer till honom under analysprocessen.
Som mått i den tredimensionella kuben som visas i fig. 2 används försäljningsbelopp och tid, produkt och butik används som dimensioner. Mätningar presenteras på specifika grupperingsnivåer: produkter grupperas efter kategori, butiker efter land och transaktionstidsdata per månad. Lite senare kommer vi att titta på nivåerna för gruppering (hierarki) mer i detalj.
Ris. 2. Kubexempel
"Skär" en kub
Även en tredimensionell kub är svår att visa på en datorskärm så att värdena för de intressanta måtten är synliga. Vad kan vi säga om kuber med mer än tre dimensioner? För att visualisera data lagrad i en kub används som regel välbekanta tvådimensionella, det vill säga tabellvyer med komplexa hierarkiska rad- och kolumnrubriker.
En tvådimensionell representation av en kub kan erhållas genom att "skära" den över en eller flera axlar (dimensioner): vi fixar värdena för alla dimensioner utom två, och vi får en vanlig tvådimensionell tabell. Tabellens horisontella axel (kolumnrubriker) representerar en dimension, den vertikala axeln (radrubriker) representerar en annan, och tabellcellerna representerar måttens värden. I det här fallet betraktas en uppsättning mått faktiskt som en av dimensionerna - vi väljer antingen ett mått att visa (och sedan kan vi placera två dimensioner i rad- och kolumnrubrikerna), eller visar flera mått (och sedan en av tabellaxlar kommer att upptas av namnen på måtten och de andra - värden för den enda "oklippta" dimensionen).
Ta en titt på fig. 3 - här är en tvådimensionell del av kuben för ett mått - Enhetsförsäljning (sålda stycken) och två "oklippta" dimensioner - Butik (Butik) och Tid (Tid).
Ris. 3. 2D-kubskiva för ett mått
I fig. Figur 4 visar bara en "oskuren" dimension - Butik, men den visar värden för flera mått - Enhetsförsäljning (sålda enheter), Butiksförsäljning (försäljningsbelopp) och Butikskostnad (butikskostnader).
Ris. 4. 2D-kubskiva för flera mått
En tvådimensionell representation av en kub är också möjlig när fler än två dimensioner förblir "oskurna". I det här fallet kommer två eller flera dimensioner av den "skurna" kuben att placeras på skivaxlarna (rader och kolumner) - se fig. 5.
Ris. 5. 2D-kubskiva med flera dimensioner på en axel
Taggar
Värdena "lagda" längs dimensioner kallas medlemmar eller etiketter. Etiketter används både för att "klippa ut" kuben och för att begränsa (filtrera) vald data - när vi i en dimension som förblir "oklippt" inte är intresserade av alla värden, utan av en delmängd av dem, till exempel tre städer av flera dussin. Etikettvärden visas i 2D-kubvyn som rad- och kolumnrubriker.
Hierarkier och nivåer
Etiketter kan kombineras till hierarkier som består av en eller flera nivåer. Till exempel är etiketterna för dimensionen Butik naturligt grupperade i en hierarki med nivåer:
Land
stat
Stad
Lagra.
Aggregerade värden beräknas enligt hierarkinivåerna, till exempel försäljningsvolym för USA ("Lands"-nivå) eller för Kalifornien ("State"-nivå). Det är möjligt att implementera mer än en hierarki i en dimension - säg för tid: (År, Kvartal, Månad, Dag) och (År, Vecka, Dag).
Arkitektur av OLAP-applikationer
Allt som sades ovan om OLAP hänförde sig huvudsakligen till multidimensionell presentation av data. Hur datan lagras berör, grovt sett, varken slutanvändaren eller utvecklarna av verktyget klienten använder.
Flerdimensionalitet i OLAP-applikationer kan delas in i tre nivåer:
- Multidimensionell datarepresentation - slutanvändarverktyg som tillhandahåller multidimensionell visualisering och manipulering av data; Det flerdimensionella representationsskiktet abstraherar från den fysiska strukturen av datan och behandlar datan som flerdimensionell.
- Flerdimensionell bearbetning är ett medel (språk) för att formulera flerdimensionella frågor (det traditionella relationsspråket SQL är olämpligt här) och en processor som kan bearbeta och exekvera en sådan fråga.
- Flerdimensionell lagring är ett sätt att fysiskt organisera data som säkerställer effektiv exekvering av flerdimensionella frågor.
De två första nivåerna är obligatoriska i alla OLAP-verktyg. Den tredje nivån, även om den är utbredd, är inte nödvändig, eftersom data för en multidimensionell representation kan extraheras från vanliga relationsstrukturer; Den flerdimensionella frågeprocessorn översätter i detta fall flerdimensionella frågor till SQL-frågor som exekveras av den relationella DBMS.
Specifika OLAP-produkter är som regel antingen ett multidimensionellt datarepresentationsverktyg, en OLAP-klient (till exempel pivottabeller i Excel 2000 från Microsoft eller ProClarity från Knosys), eller en flerdimensionell server-DBMS, en OLAP-server (till exempel Oracle Express Server eller Microsoft OLAP Services).
Det flerdimensionella bearbetningsskiktet är vanligtvis inbyggt i OLAP-klienten och/eller OLAP-servern, men kan isoleras i sin rena form, såsom Microsofts Pivot Table Service-komponent.
Tekniska aspekter av multidimensionell datalagring
Som nämnts ovan kan OLAP-analysverktyg också extrahera data direkt från relationssystem. Detta tillvägagångssätt var mer attraktivt på den tiden då OLAP-servrar inte ingick i prislistorna för ledande DBMS-tillverkare. Men idag erbjuder Oracle, Informix och Microsoft fullfjädrade OLAP-servrar, och även de IT-chefer som inte gillar att skapa en "zoo" av mjukvara från olika tillverkare i sina nätverk kan köpa (eller snarare göra en motsvarande begäran till företagsledningen ) OLAP-server av samma märke som huvuddatabasservern.
OLAP-servrar, eller flerdimensionella databasservrar, kan lagra sina flerdimensionella data på olika sätt. Innan vi överväger dessa metoder måste vi prata om en så viktig aspekt som att lagra enheter. Faktum är att i vilket datalager som helst - både vanligt och flerdimensionellt - tillsammans med detaljerad data extraherad från operativa system, lagras även sammanfattningsindikatorer (aggregerade indikatorer, aggregationer), såsom summan av försäljningsvolymer per månad, per kategori varor, etc. Aggregat lagras uttryckligen i det enda syftet att påskynda exekveringen av frågor. När allt kommer omkring, å ena sidan, som regel, ackumuleras en mycket stor mängd data i lagret, och å andra sidan är analytiker i de flesta fall inte intresserade av detaljerade, utan av generaliserade indikatorer. Och om miljontals individuella försäljningar måste läggas ihop varje gång för att beräkna den totala försäljningen för året, skulle hastigheten med största sannolikhet vara oacceptabel. Därför, när data laddas in i en flerdimensionell databas, beräknas och sparas alla totala indikatorer eller delar av dem.
Men du måste som bekant betala för allt. Och för snabbheten att bearbeta förfrågningar om sammanfattningsdata måste du betala för en ökning av datamängder och tid för att ladda dem. Dessutom kan en ökning av volymen vara bokstavligt talat katastrofal - i ett av de publicerade standardtesterna krävde en fullständig beräkning av aggregat för 10 MB källdata 2,4 GB, d.v.s. data växte 240 gånger! Graden av data "svällning" vid beräkning av aggregat beror på antalet dimensioner av kuben och strukturen av dessa dimensioner, det vill säga förhållandet mellan antalet "fäder" och "barn" på olika mätnivåer. För att lösa problemet med att lagra enheter används de ibland komplexa kretsar, som gör det möjligt att uppnå en betydande ökning av frågeprestanda när man inte beräknar alla möjliga aggregat.
Nu om de olika alternativen för att lagra information. Både granulära data och aggregat kan lagras i antingen relationella eller flerdimensionella strukturer. Flerdimensionell lagring låter dig behandla data som en flerdimensionell array, vilket säkerställer lika snabba beräkningar av totala indikatorer och olika flerdimensionella transformationer längs någon av dimensionerna. För en tid sedan stödde OLAP-produkter antingen relationell eller multidimensionell lagring. Idag tillhandahåller som regel samma produkt båda dessa typer av lagring, såväl som en tredje typ - blandad. Följande villkor gäller:
- MOLAP(Multidimensional OLAP) - både detaljerad data och aggregat lagras i en flerdimensionell databas. I detta fall erhålls den största redundansen, eftersom flerdimensionell data helt innehåller relationsdata.
- ROLAP(Relational OLAP) - detaljerad data finns kvar där den ursprungligen "levde" - i relationsdatabasen; aggregat lagras i samma databas i speciellt skapade tjänstetabeller.
- HOLAP(Hybrid OLAP) - detaljerad data finns kvar (i en relationsdatabas), och aggregat lagras i en flerdimensionell databas.
Var och en av dessa metoder har sina egna fördelar och nackdelar och bör användas beroende på förhållandena - datavolymen, kraften i det relationella DBMS, etc.
Vid lagring av data i flerdimensionella strukturer finns det ett potentiellt problem med "bloat" på grund av lagring av tomma värden. När allt kommer omkring, om i en flerdimensionell matris utrymme är reserverat för alla möjliga kombinationer av dimensionsetiketter, men bara en liten del faktiskt fylls (till exempel ett antal produkter säljs endast i ett litet antal regioner), då de flesta av kuben kommer att vara tom, även om utrymmet kommer att vara upptaget. Moderna OLAP-produkter kan hantera detta problem.
Fortsättning följer. I framtiden kommer vi att prata om specifika OLAP-produkter som produceras av ledande tillverkare.
OLAP (On-Line Analytical Processing)är en metod för elektronisk analytisk databehandling som representerar organiseringen av data i hierarkiska kategorier med hjälp av förberäknade totaler. OLAP-data är organiserade hierarkiskt och lagras i kuber snarare än tabeller. OLAP-kuber är en flerdimensionell datamängd med axlar som innehåller parametrar och celler som innehåller parameterberoende aggregerad data. Kuber är designade för komplex, flerdimensionell analys av stora datamängder eftersom de endast ger sammanfattande resultat för rapportering istället för stort antal separata register.
Begreppet OLAP beskrevs 1993 av den berömda databasforskaren och författaren till relationsdatamodellen E. F. Codd. För närvarande är OLAP-stöd implementerat i många DBMS och andra verktyg.
En OLAP-kub innehåller två typer av data:
· totala värden, värden som du vill sammanfatta, representera beräknade datafält;
· beskrivande information som representerar mätningar eller mått. Beskrivande information är vanligtvis organiserad i detaljnivåer. Till exempel: "År", "Kvartal", "Månad" och "Dag" i dimensionen "Tid". Genom att organisera fält i detaljnivåer kan rapporterande användare välja vilken detaljnivå de vill se, börja med sammanfattningsdata på hög nivå och sedan gå ner till en mer detaljerad vy och vice versa.
Med Microsoft Query-verktyg kan du också skapa OLAP-kuber från en fråga som laddar data från en relationsdatabas som Microsoft Access, och omvandlar en linjär tabell till en strukturerad hierarki (kub).
Skapa OLAP Cube Wizard är ett inbyggt Microsoft Query-verktyg. För att skapa en OLAP-kub baserad på en relationsdatabas måste du utföra följande steg innan du kör guiden.
1. Bestäm datakällan (se figur 6.1).
2. Använd Microsoft Query och skapa en fråga, inklusive endast de fält som antingen kommer att vara datafält eller dimensionsfält i en OLAP-kub. Om ett fält i en kub används mer än en gång måste det inkluderas i frågan den nödvändiga antal gånger.
3. I det sista steget i guiden för att skapa frågor ställer du in omkopplaren på objektet Skapa en OLAP-kub från en given fråga(se Fig. 6.2) eller efter att begäran skapats direkt med hjälp av menyn Fråga Fil välja ett lag Skapa OLAP Cube, varefter guiden Skapa OLAP-kub startas.
Guiden Skapa OLAP-kub består av tre steg.
I det första steget i guiden (se fig. 6.6) datafält– beräknade fält för vilka totala värden måste bestämmas.
Ris. 6.6. Definiera datafält
Guiden placerar förväntade beräknade fält (vanligtvis numeriska fält) överst i listan, kontrollerar dem och bestämmer den resulterande funktionen för dessa fält, vanligtvis - Belopp. Vid val av datafält måste minst ett fält väljas som ett beräknat fält och minst ett fält måste lämnas omarkerat för att bestämma dimensionen.
När du skapar en OLAP-kub kan du använda fyra sammanfattningsfunktioner − Belopp, siffra(antal värden), Minimum, Maximal för numeriska fält och en funktion siffra för alla andra områden. Om du vill använda flera olika sammanfattningsfunktioner i samma fält måste det fältet inkluderas i frågan så många gånger som krävs.
Namnet på ett beräknat fält kan ändras i en kolumn Datafältnamn.
I det andra steget i guiden bestäms beskrivande data och deras dimensioner (se fig. 6.7). För att välja ett mätfält måste du från listan Källfält dra önskat dimensionsfält på översta nivån till listan Mått till området markerat som Dra fält hit för att skapa dimensioner. För att skapa en OLAP-kub måste du definiera minst en dimension. I samma steg i guiden kan du använda snabbmenyn för att ändra namnet på dimensionen eller nivåfältet.
Ris. 6.7. Definiera dimensionsfält
Fält som innehåller isolerade eller diskreta data och som inte tillhör en hierarki kan definieras som ennivådimensioner. Emellertid kommer kuben att bli mer effektiv om några av fälten är organiserade i nivåer. För att skapa en nivå som en del av en dimension, dra ett fält från listan Källfält på ett fält som är en dimension eller nivå. Fält som innehåller mer detaljerad information bör placeras på lägre nivåer. Till exempel, i figur 6.7 fältet Jobbtitelär fältnivån Avdelningsnamn.
För att flytta ett fält till en lägre eller högre nivå hög nivå måste du dra den till ett lägre eller högre fält inom dimensionen. Använd knapparna eller för att visa eller dölja nivåer.
Om du använder datum- eller tidsfält som toppnivådimension, skapar OLAP Cube Wizard automatiskt nivåer för dessa dimensioner. Användaren kan sedan välja vilka nivåer som ska visas i rapporterna. Du kan till exempel välja veckor, kvartal och år eller månader (se figur 6.7).
Kom ihåg att guiden automatiskt skapar nivåer för datum- och tidsfält endast när du skapar en toppnivådimension; När du lägger till dessa fält som undernivåer av en dimension skapas inte automatiska nivåer.
I det tredje steget av guiden bestäms typen av kub som skapas av guiden, med tre möjliga alternativ (se Fig. 6.8).
Ris. 6.8. Välj den typ av kub som ska skapas i det tredje steget i guiden
· De två första alternativen innebär att du skapar en kub varje gång du öppnar en rapport (om kuben visas från Excel, då talar vi om en pivottabell). I det här fallet, förfrågningsfilen och filen kub definitioner *.oqy, som innehåller instruktioner för att skapa en kub. *.oqy-filen kan öppnas i Excel för att skapa rapporter baserade på kuben, och om du behöver göra ändringar i kuben kan du öppna den med Query för att köra Skapa kub-guiden igen.
Som standard lagras kubdefinitionsfiler, såväl som frågefiler, i användarprofilmappen i Application Data\Microsoft\Que-ries. När du sparar en *.oqy-fil i standardmappen visas namnet på kubdefinitionsfilen på fliken OLAP kuber när du öppnar en ny fråga i Microsoft Query eller när du väljer ett kommando Skapa en förfrågan(meny Data, undermeny Importera extern data) i Microsoft Excel.
· Om du väljer det tredje alternativet av kubtyp Sparar en kubfil som innehåller all data för kuben, all data för kuben hämtas och en kubfil med tillägget * skapas på en användarspecificerad plats .Valp, där denna data lagras. Denna fil skapas inte direkt när knappen klickas Redo; filen skapas antingen när du sparar kubdefinitionen i en fil eller när du skapar en rapport baserad på kuben.
Valet av kubtyp bestäms av flera faktorer: mängden data som kuben innehåller; typen och komplexiteten för rapporter som kommer att skapas baserat på kuben; systemresurser (minne och diskutrymme) etc.
En separat *.cub-kubfil bör skapas i följande fall:
1) för ofta ändrade interaktiva rapporter om det finns tillräckligt med diskutrymme;
2) när du behöver spara kuben på en nätverksserver för att ge åtkomst till den för andra användare när du skapar rapporter. En kubfil kan tillhandahålla specifik data från källdatabasen samtidigt som känslig eller känslig data som du vill förhindra att andra användare får tillgång till utelämnas.
I en vanlig pivottabell lagras källdata på din lokala hårddisk. På så sätt kan du alltid hantera och omorganisera dem, även utan tillgång till nätverket. Men detta gäller inte på något sätt för OLAP-pivottabeller. I OLAP-pivottabeller lagras cachen aldrig på den lokala hårddisken. Därför omedelbart efter att ha kopplat från lokalt nätverk din pivottabell kommer inte längre att fungera. Du kommer inte att kunna flytta ett enda fält i den.
Om du fortfarande behöver analysera OLAP-data efter att ha gått offline, skapa en offlinedatakub. En offlinedatakub är en separat fil som är en pivottabellscache och lagrar OLAP-data som visas efter att ha kopplats från det lokala nätverket. OLAP-data som kopierats till en pivottabell kan skrivas ut, detta beskrivs i detalj på webbplatsen http://everest.ua.
För att skapa en fristående datakub, skapa först en OLAP-pivottabell. Placera markören i pivottabellen och klicka på knappen OLAP-verktyg på kontextfliken Verktyg, som är en del av kontextfliken för Pivottabellverktyg. Välj kommandot Offline OLAP (Fig. 9.8).
Dialogrutan Offline OLAP Data Cube Settings visas på skärmen. Klicka på knappen Skapa offlinedatafil. Du har startat guiden Skapa datakubfil. Klicka på Nästa för att fortsätta proceduren.
Först måste du ange de dimensioner och nivåer som ska inkluderas i datakuben. I dialogrutan måste du välja de data som ska importeras från OLAP-databasen. Tanken är att endast specificera de dimensioner som kommer att behövas efter att datorn kopplats bort från det lokala nätverket. Ju fler dimensioner du anger, desto större storlek kommer att ha en fristående datakub.
Klicka på knappen Nästa för att gå till nästa dialogruta i guiden. Detta ger dig möjlighet att ange medlemmar eller dataelement som inte kommer att inkluderas i kuben. I synnerhet behöver du inte måttet Internet-försäljningsextended Amount, så dess kryssruta kommer att avmarkeras i listan. En avmarkerad kryssruta anger att det angivna objektet inte kommer att importeras och tar upp onödigt utrymme på din lokala hårddisk.
I det sista steget anger du platsen och namnet på datakuben. I vårt fall kommer kubfilen att heta MyOfflineCube.cub och kommer att finnas i Work-mappen.
Datakubfiler har tillägget .Valp
Efter en tid kommer Excel att spara offlinedatakuben i den angivna mappen. För att testa det, dubbelklicka på filen, som automatiskt genererar en Excel-arbetsbok som innehåller en pivottabell som är associerad med den valda datakuben. När den har skapats kan du distribuera offlinedatakuben till alla intresserade användare som arbetar i offline-LAN-läge.
När du är ansluten till ditt lokala nätverk kan du öppna offlinedatakubfilen och uppdatera den och den tillhörande datatabellen. Huvudprincip anger att offlinedatakuben endast används för att fungera när det lokala nätverket är frånkopplat, men den måste uppdateras efter att anslutningen har återställts. Ett försök att uppdatera en offlinedatakub efter ett anslutningsfel kommer att resultera i ett misslyckande.
Som en del av detta arbete kommer följande frågor att övervägas:
- Vad är OLAP-kuber?
- Vad är mått, dimensioner, hierarkier?
- Vilka typer av operationer kan utföras på OLAP-kuber?
Huvudpostulatet för OLAP är multidimensionalitet i datapresentation. I OLAP-terminologi används begreppet en kub, eller hyperkub, för att beskriva ett flerdimensionellt diskret datautrymme.
Kubär en multidimensionell datastruktur från vilken en användaranalytiker kan fråga information. Kuber skapas utifrån fakta och dimensioner.
Data– detta är data om objekt och händelser i företaget som kommer att analyseras. Fakta av samma typ bildar mått. Ett mått är typen av värde i en kubcell.
Mått- Dessa är de dataelement med vilka fakta analyseras. En samling av sådana element bildar ett dimensionsattribut (till exempel kan veckodagar bilda ett tidsdimensionsattribut). I affärsanalysuppgifter kommersiella företag Dimensioner inkluderar ofta kategorier som "tid", "försäljning", "produkter", "kunder", "anställda" och "geografisk plats". Dimensioner är oftast hierarkiska strukturer, som representerar logiska kategorier genom vilka användaren kan analysera faktiska data. Varje hierarki kan ha en eller flera nivåer. Således kan hierarkin för dimensionen "geografisk plats" innefatta nivåerna: "land - region - stad". I tidshierarkin kan vi till exempel urskilja följande nivåsekvens: En dimension kan ha flera hierarkier (varje hierarki av en dimension måste ha samma nyckelattribut som dimensionstabellen).
En kub kan innehålla faktiska data från en eller flera faktatabeller och innehåller oftast flera dimensioner. Varje given kub har vanligtvis ett specifikt fokus för analys.
Figur 1 visar ett exempel på en kub utformad för att analysera försäljningen av petroleumprodukter av ett visst företag per region. Denna kub har tre dimensioner (tid, produkt och region) och ett mått (försäljning uttryckt i monetära termer). Mätvärden lagras i motsvarande celler i kuben. Varje cell identifieras unikt av en uppsättning medlemmar av varje dimension, som kallas en tupel. Till exempel specificeras cellen i det nedre vänstra hörnet av kuben (innehåller värdet $98399) av tupeln [juli 2005, Far East, Diesel]. Här visar värdet på 98 399 $ försäljningsvolymen (i monetära termer) av diesel i Fjärran Östern för juli 2005.
Det är också värt att notera att vissa celler inte innehåller några värden: dessa celler är tomma eftersom faktatabellen inte innehåller data för dem.
Ris. 1. Kub med information om försäljning av petroleumprodukter i olika regioner
Det slutliga målet med att skapa sådana kuber är att minimera bearbetningstiden för frågor som extraherar den nödvändiga informationen från den faktiska datan. För att utföra denna uppgift innehåller kuber vanligtvis förberäknade totaler som anropas aggregationer(aggregationer). De där. kuben täcker ett datautrymme som är större än det faktiska - det finns logiska, beräknade punkter i den. Aggregeringsfunktioner låter dig beräkna värdena för punkter i logiskt utrymme baserat på faktiska värden. De enklaste aggregeringsfunktionerna är SUM, MAX, MIN, COUNT. Så, till exempel, med hjälp av MAX-funktionen, för kuben som ges i exemplet, kan du identifiera när toppen i dieselförsäljningen inträffade i Fjärran Östern, etc.
En annan specifik egenskap hos flerdimensionella kuber är svårigheten att bestämma ursprunget. Till exempel, hur ställer du in punkten 0 för dimensionen Produkt eller Regioner? Lösningen på detta problem är att introducera ett speciellt attribut som kombinerar alla element i dimensionen. Detta attribut (skapas automatiskt) innehåller endast ett element - Alla. För enkla aggregeringsfunktioner som summa, är elementet Alla ekvivalent med summan av värdena för alla element i det faktiska rummet för en given dimension.
Ett viktigt koncept i en multidimensionell datamodell är underrummet, eller underkuben. En subkub är en del av hela utrymmet i en kub i form av någon flerdimensionell figur inuti kuben. Eftersom det flerdimensionella utrymmet för en kub är diskret och begränsat, är subkuben också diskret och begränsad.
Operationer på OLAP-kuber
Följande operationer kan utföras på en OLAP-kub:
- skiva;
- rotation;
- konsolidering;
- detaljering.
Ris. 2. OLAP kub skiva
Rotation(Figur 3) - funktionen för att ändra platsen för mätningar som presenteras i en rapport eller på den visade sidan. En rotationsoperation kan till exempel innebära omarrangering av rader och kolumner i en tabell. Om du roterar en datakub flyttas dessutom dimensioner utanför tabell på plats med dimensioner som finns på den visade sidan och vice versa.
Jag har varit bosatt i Habr ganska länge, men jag har aldrig läst artiklar om ämnet multidimensionella kuber, OLAP och MDX, även om ämnet är mycket intressant och blir mer och mer relevant för varje dag.
Det är ingen hemlighet att under den korta tidsperioden av utveckling av databaser, elektroniska bokföring och onlinesystem har mycket data i sig samlats. Nu är också en fullständig analys av arkiven, och kanske ett försök att förutsäga situationer för liknande modeller i framtiden, av intresse.
Å andra sidan kan stora företag, även under loppet av flera år, månader eller till och med veckor, ackumulera så stora mängder data att även deras grundläggande analys kräver extraordinära tillvägagångssätt och stränga hårdvarukrav. Dessa kan vara system för behandling av banktransaktioner, aktieombud, telefonoperatörer etc.
Jag tror att alla är väl medvetna om två olika tillvägagångssätt för databasdesign: OLTP och OLAP. Det första tillvägagångssättet (Online Transaction Processing - realtidstransaktionsbearbetning) är utformat för effektiv datainsamling i realtid, medan det andra (Online Analytical Processing - realtidsanalytisk bearbetning) syftar specifikt till att sampla och bearbeta data på den mest effektiva sätt.
Låt oss titta på huvudfunktionerna hos moderna OLAP-kuber och vilka problem de löser (Analysis Services 2005/2008 tas som grund):
- snabb tillgång till data
- föraggregation
- hierarki
- arbetar med tiden
- flerdimensionellt dataåtkomstspråk
- KPI (Key Performance Indicators)
- datum mining
- cachelagring på flera nivåer
- flerspråkigt stöd
Lite mer om möjligheterna
Snabb tillgång till dataI själva verket är snabb åtkomst till data, oavsett storleken på arrayen, grunden för OLAP-system. Eftersom detta är huvudfokus är ett datalager vanligtvis byggt på principer som skiljer sig från relationsdatabaser.
Här mäts tiden för att hämta enkla data i bråkdelar av en sekund, och en fråga som överstiger några sekunder kräver sannolikt optimering.
Föraggregation
Förutom att snabbt hämta befintlig data, ger den också möjligheten att föraggregera värden som "mest sannolikt kommer att användas". Till exempel, om vi har dagliga register över försäljning av en viss produkt, systemet Kanske Vi kan också föraggregera månads- och kvartalsförsäljningsbelopp, vilket innebär att om vi begär data månadsvis eller kvartalsvis kommer systemet omedelbart att ge oss resultatet. Varför förekommer inte alltid föraggregation, eftersom teoretiskt möjliga kombinationer av varor/tid/etc. det kan vara ett enormt antal, vilket innebär att du måste ha tydliga regler för vilka element aggregeringen ska byggas och för vilka inte. I allmänhet är ämnet att ta hänsyn till dessa regler och själva utformningen av aggregering ganska omfattande och förtjänar en separat artikel i sig.
Hierarkier
Det är naturligt att man när man analyserar data och konstruerar slutrapporter måste ta hänsyn till att månader består av dagar, och de själva bildar kvartal, och städer ingår i områden som i sin tur ingår i regioner eller länder. . Den goda nyheten är att OLAP-kuber initialt visar data i termer av hierarkier och relationer med andra parametrar för samma enhet, så att bygga och använda hierarkier i kuber är mycket enkelt.
Jobbar med tiden
Eftersom dataanalys huvudsakligen sker i tidsområden tillmäts tiden särskild betydelse i OLAP-system, vilket gör att man genom att helt enkelt definiera för systemet var vi har tid här, i framtiden enkelt kan använda funktioner som Year To Date, Month To Date (perioden från början av året/månaden till det aktuella datumet), Parallell period (på samma dag eller månad, men förra året), etc.
Flerdimensionellt dataåtkomstspråk
MDX(Multidimensional Expressions) - ett frågespråk för enkel och effektiv åtkomst till flerdimensionella datastrukturer. Och det säger allt – det kommer att finnas några exempel nedan.
Key Performance Indicators (KPI)
Key Performance Indicatorsär ett finansiellt och icke-finansiellt mätsystem som hjälper en organisation att fastställa uppnåendet av strategiska mål. Nyckeltal kan enkelt definieras i OLAP-system och användas i rapporter.
Gruvdatum
Data Mining(Data Mining) - i huvudsak identifiera dolda mönster eller relationer mellan variabler i stora datamängder.
Den engelska termen "Data Mining" har inte en entydig översättning till ryska (data mining, data mining, information mining, data/information extraction) därför används den i de flesta fall i originalet. Den mest framgångsrika indirekta översättningen är termen "data mining" (DMA). Detta är dock ett separat, inte mindre intressant ämne att överväga.
Caching på flera nivåer
Faktiskt, för att säkerställa den högsta hastigheten för dataåtkomst, förutom knepiga datastrukturer och föraggregationer, stöder OLAP-system flernivåcachelagring. Förutom att cachelagra enkla frågor, cachelagras också delar av data som läses från butiken, aggregerade värden och beräknade värden. Således, ju längre du arbetar med en OLAP-kub, desto snabbare börjar den faktiskt fungera. Det finns också konceptet att "värma upp cachen" - en operation som förbereder OLAP-systemet för att arbeta med specifika rapporter, frågor eller allt tillsammans.
Flerspråkigt stöd
Ja ja ja. Analysis Services 2005/2008 (även om Enterprise Edition) stöder åtminstone flerspråkighet. Det räcker med att tillhandahålla en översättning av strängparametrarna för dina data, och klienten som angav sitt språk kommer att få lokaliserad data.
Flerdimensionella kuber
Så vad exakt är dessa flerdimensionella kuber?Låt oss föreställa oss ett 3-dimensionellt utrymme vars axlar är tid, produkter och kunder.
En punkt i ett sådant utrymme kommer att indikera det faktum att en av köparna köpte en specifik produkt under en viss månad.
Faktum är att planet (eller uppsättningen av alla sådana punkter) kommer att vara kuben, och följaktligen kommer tid, produkter och kunder att vara dess dimensioner.
Det är lite svårare att föreställa sig (och rita) en fyrdimensionell eller mer kub, men essensen förändras inte, och viktigast av allt, för OLAP-system spelar det ingen roll i hur många dimensioner du kommer att arbeta (inom rimligt gränser förstås).
Lite MDX
Så, vad är skönheten med MDX? Troligtvis är det att vi behöver beskriva inte hur vi vill välja data, men Vad exakt Vi vill.Till exempel,
VÄLJ
( . ) PÅ KOLUMNER,
( ., . ) PÅ RADER
FRÅN
VAR (., .)
Vilket betyder att jag vill ha antalet sålda iPhones i juni och juli i Moçambique.
Samtidigt beskriver jag som detta är data jag vill ha och Hur Jag vill se dem i rapporten.
Vackert, eller hur?
Här är lite mer komplicerat:
MED MEDLEM AverageSpend AS
. / .
VÄLJ
( Average Spend ) PÅ KOLUMNER,
( .., .. ) PÅ RADER
FRÅN
VAR (.)* Den här källkoden har markerats med Source Code Highlighter.
I själva verket bestämmer vi först formeln för att beräkna den "genomsnittliga köpstorleken" och försöker jämföra vem (vilket kön) som spenderar mer pengar under ett besök i Apple Store.
Språket i sig är oerhört intressant både att studera och att använda, och kanske förtjänar mycket diskussion.
Slutsats
Faktum är att den här artikeln täcker väldigt lite av ens grundläggande begrepp; jag skulle kalla det en "aptitretare" - en möjlighet att intressera Habra-gemenskapen i detta ämne och utveckla det ytterligare. När det gäller utveckling finns det ett enormt oplogat fält här, och jag svarar gärna på alla dina frågor.P.S. Detta är mitt första inlägg om OLAP och den första publikationen om Habré - jag skulle vara mycket tacksam för konstruktiv feedback.
Uppdatering: Jag överförde det till SQL, jag kommer att överföra det till OLAP så snart de tillåter mig att skapa nya bloggar.
Taggar: Lägg till taggar
